Bill Kocik wrote:
>
>> 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.
Good point.
>
> 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?
Yes, that's what I meant.
>
> 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.
I specifically put in code that, when you choose <Run>, ensure the
server is running and that your application is correctly deployed,
including checking that the current context root is what is expected. I
have had trouble with race conditions in the area of server starting before.
Can you try this: Ensure the app is properly deployed in one form,
server running, etc. Stop the server, toggle the deploy at "/"
property, then manually start the server and wait until it says the
Rails app is ready again (about 8-12 seconds depending on hardware).
Only then, choose <Run> from the project menu and see if it works properly.
>
> 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.
It is odd -- you're not supposed to have to and last time I checked,
this worked.
>
> 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.
Well honestly, I don't think _any_ of your observations should be
impacted by Rails 2.2 or JRuby 1.1.5, but you never know.
> 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.
Well that explains why I hadn't seen this before.
Thanks for the issue reports. We'll see what we can do.
-Peter
> 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
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>