Hi Peter. Thanks for your responses. Mine are below.
On 8 Nov, 2008, at 10:48 PM, Peter Williams wrote:
>> I raised these issues over on a NetBeans list and was met with
>> mixed reviews. I thought I'd try them out here. I hope no one minds.
> I don't remember if I saw them. I keep up on dev_at_ruby.netbeans.org,
> but users, not so much. If you are asking about things you think
> are bugs, it's better to ask on the dev list since it's more likely
> we'll see them. Or just file the bugs :)
I try to walk a fine line of not adding traffic to developer lists
unless I'm reasonably sure I have something that needs to be brought
to their attention. 9 times out of 10 when I encounter a problem, I'm
the cause of it. :)
>> I begin with that setting on and my application loaded and running
>> at "/". The first thing I notice is that when I start the server,
>> NetBeans sends my browser to http://localhost:8080// (note the
>> extra slash). The second slash is harmless, but clearly shouldn't
>> be there.
> I haven't seen this but I agree it shouldn't happen. Can you file a
> bug please? (http://issues.netbeans.org, category/subcategory
> serverplugins/glassfish_v3)
Certainly. 152802 filed.
>
>>
>> The next thing I notice is that I can't get to the admin console.
>> If I go to http://localhost:4848/ I get my deployed Rails
>> application.
> Ok, that's weird and definitely shouldn't happen. You're using the
> default domain, correct?
I believe so. By that I mean that I haven't knowingly done anything to
cause it to use some other domain.
> So HTTP is on 8080 and admin is on 4848? Please file a bug against
> glassfish (https://glassfish.dev.java.net/issues, category/
> subcategory V3/jruby)
>
> I think you can workaround this by going directly to http://localhost:4848/login.jsf
Unfortunately not. Because the Rails app is receiving those requests,
its dispatcher is attempting to route them. Trying to retrieve
login.jsf results in a Rails routing error.
6746 filed.
> This is expected behavior, though I was reading some various user
> experiences that suggested exactly your impression -- what happens
> is not intuitive. The "deploy at / (or not)" setting, if changed,
> does not affect applications that are already deployed. <Run> will
> cause the plugin to redeploy the application if this setting has
> been changed.
>
> I've had some thoughts about how to improve the experience here but
> they likely won't be implemented until the next version of
> NetBeans. In the meantime, <Run> on the application (and if you
> really want to be sure, undeploy it via the services tab first) will
> fix it.
I'm not sure I made clear what I'm doing. Before (or after) changing
that setting, I shut down my GlassFish server completely, and then run
my application by right-clicking on it in the Projects pane, and
choosing "Run" from the contextual menu. I think that's what you mean
by <Run> the application, or am I mistaken?
I did this just now. I had the root context setting turned on, and my
app was running at "/". I shut down the GF server (and closed its
output pane for good measure), turned off the root context setting,
and ran the app from the contextual menu. The server started, and the
application was deployed at "/" again (instead of its own context),
but NetBeans pointed my browser at
http://localhost:8080/
twittertracks, where I got a routing error. I stop the server again,
and run the app again, and all is well - my application is deployed in
its own context.
You are correct, though, that if I first undeploy the application and
then take the steps to change the context setting, on the next run it
behaves correctly. It just seems odd that I should have to undeploy
the application; I would think that completely shutting down the
server and then launching it via the "Run" menu item would behave
unsurprisingly.
One other thing. You asked if I could test all of this with a less
bleeding-edge setup, using Rails 2.1 and JRuby 1.1.4. I did, and it
seems that some of what I'm seeing is a result of my using JRuby 1.1.5
- but only some of it. With 1.1.4, I see the same behavior with having
to stop and start the server twice to change contexts (which I'm
starting to think is because the server starts up whatever apps it had
deployed at whatever contexts it had them deployed at the last time it
was running). Also, if I change the root context setting and "Run" the
app without bouncing the server, it does swap the context as expected
when using JRuby 1.1.4. With 1.1.5, it sends the browser to whatever
I've changed the context to, but it never actually redeploys the app
at that context.
The extra "/" when deploying to the root context happens with both
environments. The inability to access the admin console with a Rails
app deployed at "/" also happens with both environments.
> I recall that inside rails, there are some changes you need to add
> to make sure that the context root is stripped before doing internal
> routing. See this message, and the entire thread:
>
> http://markmail.org/message/msijwo7gm73aw5ea#query:%22server
> %20integration%20in%20rails%20project%22+page:1+mid:es7ymjy4t7as4hlg+state:results
I had considered the relative_url_root solution. I just wasn't sure if
I should need to use it. Now I know. :)
--
Bill Kocik