questions about default GlassFish deployment for JRuby apps

[Chris Kutler]

While trying to learn about the new behavior (the default server is JRuby) when running JRuby apps, I ran into

http://www.netbeans.org/issues/show_bug.cgi?id=139188

I was not able to get any of the expected URLs to work (that is, the 8080 equivalent of the 3000 URLs). For example, for the sample Depot application,

http://localhost:8080/store

does not work, when I select GlassFish for the server.

However, when I select WEBrick for the server,

http://localhost:3000/store

does work.


Now, on to the questions

1) I discovered that if I opened the GlassFish server's properties, clicked the JRuby tab and selected the Deploy All Rails Applications At Root Context checkbox, and redeployed the app, then the above URL worked.

So, it seems to me that our users must not want to deploy Rails apps at the root context. Why wouldn't they? If you don't check the box, what URLs do you use to access the Rails app. When/why would one decide to check this box (it seems to me that the box should be checked by default, but I am sure I am not understanding what the default behavior should be). I certainly need some help to describe to our uses when they need to go and check this box.


2) I noticed that when I went to delete public/index.html from a Rails application that I was working on I got an error message from the IDE saying it was unable to delete the file (it didn't say why), I had to shutdown GF before I could delete the file. This was never a problem with WEBrick. Is this as expected for GF, if so, I had better document it?

[Peter Williams-4]

Chris Kutler wrote:

> While trying to learn about the new behavior (the default server is
> JRuby) when running JRuby apps, I ran into
> http://www.netbeans.org/issues/show_bug.cgi?id=139188
>
>  
> I was not able to get any of the expected URLs to work (that is, the
> 8080 equivalent of the 3000 URLs). For example, for the sample Depot
> application,
> http://localhost:8080/store
>  

Known bug - http://www.netbeans.org/issues/show_bug.cgi?id=139188 (which
I think you found already).  I wasn't able to fix this for NB 6.1 but I
will for NB 6.5.  I can't promise having it fixed for M2 though.

>  
> does not work, when I select GlassFish for the server.
>
> However, when I select WEBrick for the server,
>
> http://localhost:3000/store <http://localhost:8080/store>
>
> does work.
>
>
> Now, on to the questions
>
> 1) I discovered that if I opened the GlassFish server's properties,
> clicked the JRuby tab and selected the Deploy All Rails Applications
> At Root Context checkbox, and redeployed the app, then the above URL
> worked.
>
> So, it seems to me that our users must not want to deploy Rails apps
> at the root context. Why wouldn't they?

WEBrick and Mongrel run applications at context root but at different
ports (3000, 3001, etc.).  GlassFish runs the apps all on one port
(8080) with a context root field.  I put the "run at /" option in for
Arun's JavaONE demo's (because of the above bug), and because it made a
certain amount of sense.
> If you don't check the box, what URLs do you use to access the Rails app.
http://localhost:8080/[url-encoded name of Rails project]
> When/why would one decide to check this box (it seems to me that the
> box should be checked by default, but I am sure I am not understanding
> what the default behavior should be). I certainly need some help to
> describe to our uses when they need to go and check this box.
This part of the plugin is not as well thought out as I'd like it to
be.  I have a bullet item on my schedule that involves tuning the
workflow and issues here are one of the main things I want to look more at.
>
>
> 2) I noticed that when I went to delete public/index.html from a Rails
> application that I was working on I got an error message from the IDE
> saying it was unable to delete the file (it didn't say why), I had to
> shutdown GF before I could delete the file. This was never a problem
> with WEBrick.
I assume you are running on Windows?
> Is this as expected for GF
I don't know.  It seems like a bug to me.  I will have to investigate.  
Will you an issue with detailed steps to reproduce including OS and JDK
version information?

-Peter

> , if so, I had better document it?
>
>
>
>
>
>
>
>
>
>
> <http://localhost:8080/store>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Chris Kutler]

Hi Peter,

Thanks for your reply. Comments interspersed.

Peter Williams wrote:

> Chris Kutler wrote:
>> While trying to learn about the new behavior (the default server is
>> JRuby) when running JRuby apps, I ran into
>> http://www.netbeans.org/issues/show_bug.cgi?id=139188
>>
>>   I was not able to get any of the expected URLs to work (that is,
>> the 8080 equivalent of the 3000 URLs). For example, for the sample
>> Depot application,
>> http://localhost:8080/store
>>  
> Known bug - http://www.netbeans.org/issues/show_bug.cgi?id=139188 
> (which I think you found already).  I wasn't able to fix this for NB
> 6.1 but I will for NB 6.5.  I can't promise having it fixed for M2
> though.

For what it is worth, that bug says  

Running a Rails app shows the default page as "http://localhost:8080" which is the default page for v3. It should
instead be "http://localhost:8080/<RAILS_APPLICATION_NAME>" which is the default Rails page."


Fixing that bug will run the application using the application name but
will not make http://localhost:8080/store URL work. What I have learned
from your other answers in this thread is that (and I am still guessing
because I the app server integration is too buggy to this out) when you
deploy a Rails application to GlassFish, you must include the
application name in the URL (UNLESS YOU CHECK THE DEPLOY AT ROOT
CHECKBOX). That is instead of http://localhost:8080/store you must use
http://localhost:8080/Depot Application/store.

Is this correct?


>>
> WEBrick and Mongrel run applications at context root but at different
> ports (3000, 3001, etc.).  GlassFish runs the apps all on one port
> (8080) with a context root field.  
OK, now I understand.
> I put the "run at /" option in for Arun's JavaONE demo's (because of
> the above bug), and because it made a certain amount of sense.
Can you explain "made a certain amount of sense" for me. It makes sense
because....

Sorry to be a pest, but if I don't understand this, I won't be able to
explain it to our uses.

Can you finish this sentence:  "Select the eploy All Rails
Applications At Root Context if ...<explanation of when or why to select
this box>.."

Do you think it makes sense to check this box by default?

>> If you don't check the box, what URLs do you use to access the Rails
>> app.
> http://localhost:8080/[url-encoded name of Rails project]
OK, but that is not working,
>> When/why would one decide to check this box (it seems to me that the
>> box should be checked by default, but I am sure I am not
>> understanding what the default behavior should be). I certainly need
>> some help to describe to our uses when they need to go and check this
>> box.
> This part of the plugin is not as well thought out as I'd like it to
> be.  I have a bullet item on my schedule that involves tuning the
> workflow and issues here are one of the main things I want to look
> more at.

I am wondering if maybe we should not make GlassFish the default server
in the New Project Wizard for Rails applications and the Depot sample
application. It looks like making the GlassFish server the default is
going to bring a bit of grief to new users who don't change that setting
to something else, such as WEBrick.
>
>>
>>
>> 2) I noticed that when I went to delete public/index.html from a
>> Rails application that I was working on I got an error message from
>> the IDE saying it was unable to delete the file (it didn't say why),
>> I had to shutdown GF before I could delete the file. This was never a
>> problem with WEBrick.
> I assume you are running on Windows?
yes
>> Is this as expected for GF
> I don't know.  It seems like a bug to me.  I will have to
> investigate.  Will you an issue with detailed steps to reproduce
> including OS and JDK version information?
yes
I am thinking this is related to a GlassFish bug that I as well as our
users ran into developing Visual Web Applications. I was always having
to shut down the server so I could do things like delete files.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brandon Hauff]

I would agree that Glassfish should not be the default server for new
projects.

-----Original Message-----
From: Chris.Kutler@... [mailto:Chris.Kutler@...]
Sent: Friday, July 11, 2008 11:32 AM
To: dev@...
Subject: Re: questions about default GlassFish deployment for JRuby apps


Hi Peter,

Thanks for your reply. Comments interspersed.

Peter Williams wrote:

> Chris Kutler wrote:
>> While trying to learn about the new behavior (the default server is
>> JRuby) when running JRuby apps, I ran into
>> http://www.netbeans.org/issues/show_bug.cgi?id=139188
>>
>>   I was not able to get any of the expected URLs to work (that is,
>> the 8080 equivalent of the 3000 URLs). For example, for the sample
>> Depot application,
>> http://localhost:8080/store
>>  
> Known bug - http://www.netbeans.org/issues/show_bug.cgi?id=139188
> (which I think you found already).  I wasn't able to fix this for NB
> 6.1 but I will for NB 6.5.  I can't promise having it fixed for M2
> though.

For what it is worth, that bug says  

Running a Rails app shows the default page as "http://localhost:8080"
which is the default page for v3. It should
instead be "http://localhost:8080/<RAILS_APPLICATION_NAME>" which is the
default Rails page."


Fixing that bug will run the application using the application name but
will not make http://localhost:8080/store URL work. What I have learned
from your other answers in this thread is that (and I am still guessing
because I the app server integration is too buggy to this out) when you
deploy a Rails application to GlassFish, you must include the
application name in the URL (UNLESS YOU CHECK THE DEPLOY AT ROOT
CHECKBOX). That is instead of http://localhost:8080/store you must use
http://localhost:8080/Depot Application/store.

Is this correct?


>>
> WEBrick and Mongrel run applications at context root but at different
> ports (3000, 3001, etc.).  GlassFish runs the apps all on one port
> (8080) with a context root field.  
OK, now I understand.
> I put the "run at /" option in for Arun's JavaONE demo's (because of
> the above bug), and because it made a certain amount of sense.
Can you explain "made a certain amount of sense" for me. It makes sense
because....

Sorry to be a pest, but if I don't understand this, I won't be able to
explain it to our uses.

Can you finish this sentence:  "Select the eploy All Rails
Applications At Root Context if ...<explanation of when or why to select

this box>.."

Do you think it makes sense to check this box by default?

>> If you don't check the box, what URLs do you use to access the Rails
>> app.
> http://localhost:8080/[url-encoded name of Rails project]
OK, but that is not working,
>> When/why would one decide to check this box (it seems to me that the
>> box should be checked by default, but I am sure I am not
>> understanding what the default behavior should be). I certainly need
>> some help to describe to our uses when they need to go and check this

>> box.
> This part of the plugin is not as well thought out as I'd like it to
> be.  I have a bullet item on my schedule that involves tuning the
> workflow and issues here are one of the main things I want to look
> more at.

I am wondering if maybe we should not make GlassFish the default server
in the New Project Wizard for Rails applications and the Depot sample
application. It looks like making the GlassFish server the default is
going to bring a bit of grief to new users who don't change that setting

to something else, such as WEBrick.
>
>>
>>
>> 2) I noticed that when I went to delete public/index.html from a
>> Rails application that I was working on I got an error message from
>> the IDE saying it was unable to delete the file (it didn't say why),
>> I had to shutdown GF before I could delete the file. This was never a

>> problem with WEBrick.
> I assume you are running on Windows?
yes
>> Is this as expected for GF
> I don't know.  It seems like a bug to me.  I will have to
> investigate.  Will you an issue with detailed steps to reproduce
> including OS and JDK version information?
yes
I am thinking this is related to a GlassFish bug that I as well as our
users ran into developing Visual Web Applications. I was always having
to shut down the server so I could do things like delete files.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Arun Gupta]

Sorry to jump in late on this, have been busy in a fire drill ...

> For what it is worth, that bug says
> Running a Rails app shows the default page as "http://localhost:8080"
> which is the default page for v3. It should
> instead be "http://localhost:8080/<RAILS_APPLICATION_NAME>" which is the
> default Rails page."
>
>
> Fixing that bug will run the application using the application name but
> will not make http://localhost:8080/store URL work. What I have learned
> from your other answers in this thread is that (and I am still guessing
> because I the app server integration is too buggy to this out) when you

There are minor issues but that does not qualify it to be called "buggy".

Please help by filing appropriate bugs using "serverplugins" category
and "jruby" sub-category.

> deploy a Rails application to GlassFish, you must include the
> application name in the URL (UNLESS YOU CHECK THE DEPLOY AT ROOT
> CHECKBOX). That is instead of http://localhost:8080/store you must use
> http://localhost:8080/Depot Application/store.
>
> Is this correct?
Yes, what is the error you are getting by deploying Depot. We run this
app as part of QLs and it works like a charm. Now the state of v3 build
is shaky this week but if you try with TP2, it just works!

>>>
>> WEBrick and Mongrel run applications at context root but at different
>> ports (3000, 3001, etc.).  GlassFish runs the apps all on one port
>> (8080) with a context root field.  
> OK, now I understand.
Once https://glassfish.dev.java.net/issues/show_bug.cgi?id=3964 is
fixed, then the behavior will be similar to WEBrick.

>> I put the "run at /" option in for Arun's JavaONE demo's (because of
>> the above bug), and because it made a certain amount of sense.
> Can you explain "made a certain amount of sense" for me. It makes sense
> because....
... to mimic the behavior closer to WEBrick.

>
> Sorry to be a pest, but if I don't understand this, I won't be able to
> explain it to our uses.
>
> Can you finish this sentence:  "Select the eploy All Rails
> Applications At Root Context if ...<explanation of when or why to select
> this box>.."
Once the --port option is enabled in GlassFish.

>
> Do you think it makes sense to check this box by default?
Nope, because that means deploying new applications will override the
existing application. That's why the workaround is to deploy multiple
apps in their own context root. But I agree that the behavior needs to
be closer to WEBrick and that's why the bug id above.

>
>>> If you don't check the box, what URLs do you use to access the Rails
>>> app.
>> http://localhost:8080/[url-encoded name of Rails project]
> OK, but that is not working,
And what tells you it's not working ?

>> This part of the plugin is not as well thought out as I'd like it to
>> be.  I have a bullet item on my schedule that involves tuning the
>> workflow and issues here are one of the main things I want to look
>> more at.
>
> I am wondering if maybe we should not make GlassFish the default server
> in the New Project Wizard for Rails applications and the Depot sample
> application. It looks like making the GlassFish server the default is
> going to bring a bit of grief to new users who don't change that setting
> to something else, such as WEBrick.

We'd really like to make GlassFish the best development/deployment
platform for Rails. So if you feel there are issues then please file
them. As mentioned above, we'll be mimicking the behavior close to WEBrick.

>> I assume you are running on Windows?
> yes
>>> Is this as expected for GF
>> I don't know.  It seems like a bug to me.  I will have to
>> investigate.  Will you an issue with detailed steps to reproduce
>> including OS and JDK version information?
> yes
> I am thinking this is related to a GlassFish bug that I as well as our
> users ran into developing Visual Web Applications. I was always having
> to shut down the server so I could do things like delete files.

This used to a problem for Web services related projects as well, but
not any longer. I suggest you file a bug and this will get fixed.

-Arun


--
Application Platform, Sun Microsystems, Inc.
Blog: http://blogs.sun.com/arungupta

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian Leonard]

I would also argue that GlassFish should not be the default server for Rails projects. In the very least, it needs to be made configurable so that I can turn in off.

[Chris Kutler]

Note: When you create a project you can set a different server. You can
also change the server in the project's properties window.

Brian Leonard wrote:
> I would also argue that GlassFish should not be the default server for Rails
> projects. In the very least, it needs to be made configurable so that I can
> turn in off.
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Brian Leonard]

Right, but what's the default server? It should match the server that
starts when I run "ruby script/server" from the command line.

/Brian

Chris Kutler wrote:

> Note: When you create a project you can set a different server. You
> can also change the server in the project's properties window.
>
> Brian Leonard wrote:
>> I would also argue that GlassFish should not be the default server
>> for Rails
>> projects. In the very least, it needs to be made configurable so that
>> I can
>> turn in off.
>>  
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

--
William Leonard
Technology Evangelist
408.404.6884
http://weblogs.java.net/blog/bleonard



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Chris Kutler]

I hadn't thought about that.

William Leonard wrote:

> Right, but what's the default server? It should match the server that
> starts when I run "ruby script/server" from the command line.
>
> /Brian
>
> Chris Kutler wrote:
>> Note: When you create a project you can set a different server. You
>> can also change the server in the project's properties window.
>>
>> Brian Leonard wrote:
>>> I would also argue that GlassFish should not be the default server
>>> for Rails
>>> projects. In the very least, it needs to be made configurable so
>>> that I can
>>> turn in off.
>>>  
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...