Skip to main content

Deployment contexts with GF v3 Prelude

8 replies [Last post]
Anonymous

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'm developing a Rails application using Rails 2.2RC1 and JRuby 1.1.5
with NetBeans 6.5RC2 and GlassFish v3 Prelude (yep, I'm way out there
on the edge - but for the record the same problems I'm seeing happen
with Rails 2.1.0 as well). I'm having a bit of trouble understanding
deployment contexts. There is a setting at Tools -> Servers ->
GlassFish v3 Prelude -> JRuby labeled "Deploy All Rails Applications
At Root Context (/)", which is a checkbox. For brevity I'll call this
the "root context setting".

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.

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.

If I stop the server, turn the root context setting off, and start the
server, it deploys the app at the root context anyways (INFO: Loading
Rails application twittertracks at /). Often stopping and starting the
server again (by stopping the running GF server and right-clicking on
my app in NetBeans and choosing "Run"), it gets it right on the second
try (INFO: Loading Rails application twittertracks at /twittertracks).
Sometimes it takes several starts and stops to get it to do this,
though.

Once the application is running in its own context, I can access the
admin console again at http://localhost:4848. But now my application's
routes seem not to work correctly. If I try to access my one
scaffolded controller (this is a brand new blank Rails-generated app
with only one scaffolded controller and model for testing), I get a
routing error: No route matches "/twittertracks/fakes" with
{:method=>:get}.

If I turn the root context setting back on and stop and start the
server - at least twice - it deploys my application at the root
context again, and I'm back where I started. My application works, but
I cannot access the GlassFish console.

Sorry for the long-winded explanation. Just trying to paint as
complete a picture as I can. Can someone shed a little light on what
I'm seeing?

--
Bill Kocik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Bill Kocik

One more note on all of this . . .

On 8 Nov, 2008, at 10:48 PM, Peter Williams wrote:

>> Once the application is running in its own context, I can access
>> the admin console again athttp://localhost:4848. But now my
>> application's routes seem not to work correctly. If I try to access
>> my one scaffolded controller (this is a brand new blank Rails-
>> generated app with only one scaffolded controller and model for
>> testing), I get a routing error: No route matches "/twittertracks/
>> fakes" with {:method=>:get}.
> 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

If you view Arun Gupta's screencast about debugging Rails apps with NB
6.5 and GF v3 (http://blogs.sun.com/arungupta/entry/screencast_26_develop_run_debug
) and watch closely, you'll see that his demo application is deployed
in its own context when he's not running in debug mode, and that he is
able to access the controller he created at that context without any
further configuration. In my setup, I cannot - even after adding a
relative_url_root setting to my routes.rb file. I can access the
default "Welcome Aboard" index.html page that new Rails apps create,
but everything else generates a routing error.

Clearly this works correctly, though - Arun's screencast proves it. I
really don't know what's so weird about my setup.

I'm working around all of this by just deploying my app at "/" and
foregoing access to the GlassFish admin console, which I don't really
need for development.

--
Bill Kocik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Peter Williams

Hi Bill,

Comment inline.

Bill Kocik 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@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'm developing a Rails application using Rails 2.2RC1 and JRuby 1.1.5
> with NetBeans 6.5RC2 and GlassFish v3 Prelude (yep, I'm way out there
> on the edge - but for the record the same problems I'm seeing happen
> with Rails 2.1.0 as well). I'm having a bit of trouble understanding
> deployment contexts.
Bleeding edge for sure. I haven't tested anything resembling that combo
yet.

> There is a setting at Tools -> Servers -> GlassFish v3 Prelude ->
> JRuby labeled "Deploy All Rails Applications At Root Context (/)",
> which is a checkbox. For brevity I'll call this the "root context
> setting".
>
> 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)
>
> 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? 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

>
> If I stop the server, turn the root context setting off, and start the
> server, it deploys the app at the root context anyways (INFO: Loading
> Rails application twittertracks at /). Often stopping and starting the
> server again (by stopping the running GF server and right-clicking on
> my app in NetBeans and choosing "Run"), it gets it right on the second
> try (INFO: Loading Rails application twittertracks at /twittertracks).
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. 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, on the application (and if you really want to be sure,
undeploy it via the services tab first) will fix it.

This setting is originally sort of a hack that I put in to resolve some
issues in 6.1 + V3 TP2 for JavaONE demos. It needs improvement.

> Sometimes it takes several starts and stops to get it to do this, though.
That is strange and I've not seen such behavior. If you want to test
further, run netbeans with -J-Dglassfish.level=FINE and the V3 plugin
will log the admin commands it executes when you choose on your
application. What you should see is that it checks the deployment
context root and compares against the current server setting and
redeploys if they are found to be different. I have never seen this
fail as you describe, nor can I imagine why it would -- it's pretty
straight forward.
>
> Once the application is running in its own context, I can access the
> admin console again at http://localhost:4848. But now my application's
> routes seem not to work correctly. If I try to access my one
> scaffolded controller (this is a brand new blank Rails-generated app
> with only one scaffolded controller and model for testing), I get a
> routing error: No route matches "/twittertracks/fakes" with
> {:method=>:get}.
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%20integrati...

This was in reference to Rails 2.0.2 I think so perhaps things have
changed somewhat. I'm not sure.

Is it possible for you to try a test application using the stock NB 6.5
ruby bundle (JRuby 1.1.4, Rails 2.1, V3 Prelude) and see it behaves the
same way with respect to your issues above? It would be good to rule
out the changes in environment.

Hope this helps.

-Peter
>
> If I turn the root context setting back on and stop and start the
> server - at least twice - it deploys my application at the root
> context again, and I'm back where I started. My application works, but
> I cannot access the GlassFish console.
>
> Sorry for the long-winded explanation. Just trying to paint as
> complete a picture as I can. Can someone shed a little light on what
> I'm seeing?
>
>
> --
> Bill Kocik
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Bill Kocik

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@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. 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, 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 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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Peter Williams

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. 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, 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 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 , 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 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%20integrati...
>>
>
> 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@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Bill Kocik

On 9 Nov, 2008, at 1:16 AM, Peter Williams wrote:

> 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 from the project menu and see if
> it works properly.

Sure. Incidentally, last night I switched this project and NetBeans'
settings to use the bundled JRuby 1.1.4. There were simply too many
things I couldn't get to work with 1.1.5 (like debugging). So here's
what I did:

1) Server is running. Application is deployed at "/". Root context
setting is on.
2) Stopped server. Turned root context setting off.
3) Started GlassFish independently of my application (Services ->
Servers -> GlassFish v3 Prelude -> Start)
4) Waited until I saw this:

INFO: Jruby version is: 1.1.4
INFO: Starting Rails instances
INFO: New instance created in 12,128 milliseconds
INFO: Loading Rails application twittertracks at /
INFO: Loading twittertracks Application done is 12616 ms
INFO: GlassFish v3 Prelude startup time : Felix(1915ms) startup
services(13954ms) total(15869ms)

5) Right-clicked my application and chose "Run"
6) The line "INFO: Started bundle org.glassfish.admin.monitoring-core
[55]" is added to the server log, and my browser is sent to http://localhost:8080/twittertracks/
, where I get:

Routing Error
No route matches "/twittertracks/" with {:method=>:get}

I can repeat step 5 as many times as I like, and all that happens is
that my browser is sent to the URL NetBeans thinks my app should be
at; but it's not there. I can, however, access it at "/". If I restart
the server (apart from the application), 2nd time's the charm, as I've
been seeing:

INFO: Jruby version is: 1.1.4
INFO: Starting Rails instances
INFO: New instance created in 11,922 milliseconds
INFO: Loading Rails application twittertracks at /twittertracks

--
Bill Kocik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Peter Williams

Bill Kocik wrote:
>
> On 9 Nov, 2008, at 1:16 AM, Peter Williams wrote:
>
>> 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 from the project menu and see if it works
>> properly.
>
> Sure. Incidentally, last night I switched this project and NetBeans'
> settings to use the bundled JRuby 1.1.4. There were simply too many
> things I couldn't get to work with 1.1.5 (like debugging).
Not surprising. All testing of 6.5 has been done against 1.1.4. I'm
not surprised there may be something we have to fix.

> So here's what I did:
>
> 1) Server is running. Application is deployed at "/". Root context
> setting is on.
> 2) Stopped server. Turned root context setting off.
> 3) Started GlassFish independently of my application (Services ->
> Servers -> GlassFish v3 Prelude -> Start)
> 4) Waited until I saw this:
>
> INFO: Jruby version is: 1.1.4
> INFO: Starting Rails instances
> INFO: New instance created in 12,128 milliseconds
> INFO: Loading Rails application twittertracks at /
> INFO: Loading twittertracks Application done is 12616 ms
> INFO: GlassFish v3 Prelude startup time : Felix(1915ms) startup
> services(13954ms) total(15869ms)
>
> 5) Right-clicked my application and chose "Run"
> 6) The line "INFO: Started bundle org.glassfish.admin.monitoring-core
> [55]" is added to the server log, and my browser is sent to
> http://localhost:8080/twittertracks/, where I get:
>
> Routing Error
> No route matches "/twittertracks/" with {:method=>:get}
Weird. I can't reproduce this at all. Would you do this for me please
-- modify netbeans.conf to add "-J-Dglassfish.level=FINE". Reproduce
the problem once or twice. File an issue against netbeans
(serverplugins/glassfish_v3) and attach the messages.log file from
NetBeans. I want to see what's up.

What you should see (in the server log window) is the following sequence:

1. server shutdown
2. server start sequence
3. rails start sequence
4. second rails start sequence

It sounds like you never see (4) which means the app was not redeployed,
which explains why it would fail. Can you try this: do steps 1-3
again, but just do the context root setting change and the server
start. Do NOT run the application. Now, in your browser, invoke this
URL:
http://localhost:4848/__asadmin/get?pattern=applications.application.twi...
(replace fields with proper application name if required -- you can use
"http://localhost:4848/__asadmin/get?pattern=applications.*" to find out
the exact deployment names if I didn't guess correctly).

See what it says for the context root. (Alternatively, you can check
domain.xml, but this technique what our code is invoking to check to see
if redeployment is necessary).

By the way, I reproduced the double // problem and the "no admin
available at localhost:4848 when rails app deployed at slash" problem here.

-Peter

>
> I can repeat step 5 as many times as I like, and all that happens is
> that my browser is sent to the URL NetBeans thinks my app should be
> at; but it's not there. I can, however, access it at "/". If I restart
> the server (apart from the application), 2nd time's the charm, as I've
> been seeing:
>
> INFO: Jruby version is: 1.1.4
> INFO: Starting Rails instances
> INFO: New instance created in 11,922 milliseconds
> INFO: Loading Rails application twittertracks at /twittertracks
>
> --
> Bill Kocik
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Bill Kocik

On 9 Nov, 2008, at 6:48 PM, Peter Williams wrote:

> Weird. I can't reproduce this at all. Would you do this for me
> please -- modify netbeans.conf to add "-J-Dglassfish.level=FINE".
> Reproduce the problem once or twice. File an issue against netbeans
> (serverplugins/glassfish_v3) and attach the messages.log file from
> NetBeans. I want to see what's up.

15281 filed.

> Can you try this: do steps 1-3 again, but just do the context root
> setting change and the server start. Do NOT run the application.
> Now, in your browser, invoke this URL: http://localhost:4848/__asadmin/get?pattern=applications.application.twi...

Well, sort of. For this test I had to start with the app running in
its own context, instead of at the root context, since if I'd gone the
other way around those steps would have left the Rails app at
"/" (GlassFish issue 6746) and I'd have been unable to get to the URL
above. So my steps are these:

1) Begin with root context setting off, application running at /
twittertracks
2) Stop server. Turn root context setting on.
3) Start server from the "Services" panel in NetBeans:

INFO: Jruby version is: 1.1.4
INFO: Starting Rails instances
INFO: New instance created in 12,114 milliseconds
INFO: Loading Rails application twittertracks at /twittertracks
INFO: Loading twittertracks Application done is 12660 ms

At http://localhost:4848/__asadmin/get?pattern=applications.application.twi...
I see this:

Exit Code : SUCCESS
null
applications.application.twittertracks.context-root=/twittertracks
applications.application.twittertracks.directory-deployed=true
applications.application.twittertracks.enabled=true
applications.application.twittertracks.location=file:/Users/bkocik/Dev/
twittertracks/
applications.application.twittertracks.name=twittertracks
applications.application.twittertracks.object-type=user
applications.application.twittertracks.engine.jruby.sniffer=jruby
applications.application.twittertracks.property.keepSessions=true

For good measure, at this point I right-clicked my app and chose
"Run". That URL now yields this (note the changed context-root):

Exit Code : SUCCESS
null
applications.application.twittertracks.context-root=/
applications.application.twittertracks.directory-deployed=true
applications.application.twittertracks.enabled=true
applications.application.twittertracks.location=file:/Users/bkocik/Dev/
twittertracks/
applications.application.twittertracks.name=twittertracks
applications.application.twittertracks.object-type=user
applications.application.twittertracks.engine.jruby.sniffer=jruby
applications.application.twittertracks.property.keepSessions=true

However my application is not available at http://localhost:8080/
(though NetBeans thinks it is, and sends my browser there). It is
still available at http://localhost:8080/twittertracks/

--
Bill Kocik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

Bill Kocik

On 9 Nov, 2008, at 8:23 PM, Bill Kocik wrote:

> 15281 filed.

Sorry, that's 152831.

--
Bill Kocik

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net