dev@glassfish.java.net

Re: Different root context for the same app

From: Vivek Pandey <Vivek.Pandey_at_Sun.COM>
Date: Thu, 10 Apr 2008 19:57:55 -0700

Jan.Luehe_at_Sun.COM wrote:
> Arun Gupta wrote:
>
>> Hmm, I'm still seing an error with hudson #3238 (4:41pm today). Here
>> is the message shown during app deployment...
>
>
> OK, from your original bug report, it wasn't clear which aspect of the
> deployment you were complaining about:
>
> >If the app is deployed then the following message is shown:
> >INFO: Loading application ttt_ruby at /ttt_ruby
>
> when in fact there are 2 deployments involved: one rails related:
>
> INFO: Loading application ttt_ruby at /ttt_ruby
>
> and the other one web related:
>
> INFO: Loading application ttt_ruby at /ruby_comet
>
right.
> Are you saying that after a server restart, you would have expected
> the rails deployment to continue to load at /ttt_ruby,
yes.
> but it suddenly
> started honoring the context-root from sun-web.xml and deployed at
> /ruby_comet?
>
> When I marked the bug as WORKSFORME, I only considered the web
> deployment aspect (since I was deploying a WAR), which works as
> expected, i.e., the context-root from sun-web.xml is being honored.
>
I will look at it.
> So this looks like a problem with the RailsDeployer?

Although, what surprises me is the fact that the first time deployment
goes thru fine. It is re-deployment that causes not work. Is it possible
that somewhere in grizzly or v3, the logic to invoke a specific deployer
is such that it is not giving chance to RailsDeployer once it is
identified as web app?

I will need to look at it to see what is going on.

> Is this owned by
> Pramod?
Pramod is no longer working on it, I am the new owner.

-vivek.
>
> Thanks,
>
> Jan
>
>
>
>>
>> Apr 10, 2008 5:50:52 PM com.sun.enterprise.rails.RailsDeployer
>> registerAdapter
>> INFO: Loading application ttt_ruby at /ttt_ruby
>> Apr 10, 2008 5:50:52 PM
>> INFO: Starting Rails instances
>> Apr 10, 2008 5:50:59 PM
>> SEVERE: JRuby limited openssl loaded. gem install jruby-openssl for
>> full support.
>> http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
>> Apr 10, 2008 5:51:00 PM com.sun.grizzly.jruby.RubyObjectPool$1 run
>> INFO: Rails instance instantiation took : 8174ms
>> Apr 10, 2008 5:51:00 PM com.sun.enterprise.web.WebApplication start
>> INFO: Loading application ttt_ruby at /ruby_comet
>> Apr 10, 2008 5:51:00 PM
>> com.sun.enterprise.v3.deployment.DeployCommand execute
>> INFO: Deployment of ttt_ruby done is 9858 ms
>>
>> This is correctly deployed at ttt_ruby & ruby_comet. And the message
>> shown when server is restarted ...
>>
>> Apr 10, 2008 5:51:50 PM com.sun.enterprise.rails.RailsDeployer
>> registerAdapter
>> INFO: Loading application ttt_ruby at /ruby_comet
>> Apr 10, 2008 5:51:50 PM
>> INFO: Starting Rails instances
>> Apr 10, 2008 5:51:56 PM
>> SEVERE: JRuby limited openssl loaded. gem install jruby-openssl for
>> full support.
>> http://wiki.jruby.org/wiki/JRuby_Builtin_OpenSSL
>> Apr 10, 2008 5:51:57 PM com.sun.grizzly.jruby.RubyObjectPool$1 run
>> INFO: Rails instance instantiation took : 6813ms
>> Apr 10, 2008 5:51:57 PM com.sun.enterprise.web.WebApplication start
>> INFO: Loading application ttt_ruby at /ruby_comet
>> Apr 10, 2008 5:51:57 PM
>> com.sun.enterprise.v3.services.impl.ApplicationLoaderService
>> processApplication
>> INFO: Loading ttt_ruby Application done is 8653 ms
>>
>> Here both are deployed at ruby_comet. I'll try a more recent build
>> later tonight.
>>
>> -Arun
>>
>> Jan.Luehe_at_Sun.COM wrote:
>>
>>> Peter Williams wrote:
>>>
>>>> If you are doing what I think you are doing, this might be a
>>>> NetBeans plugin bug, but I'm not certain yet.
>>>>
>>>> Are you deploying this to a JRuby container running on V3 or are
>>>> you packaging it as a WAR and then deploying to V3? And if the
>>>> latter, are you using asadmin to deploy the app, or are you using
>>>> the V3 Plugin?
>>>
>>>
>>>
>>> This is working as expected for me with a fresh build off the trunk,
>>> i.e., the webapp is
>>> deployed to, and accessible at, the context-root specified in its
>>> sun-web.xml at its initial
>>> deployment. (I've tried to reproduce the issue by deploying a WAR
>>> using "asadmin".)
>>>
>>> Jan
>>>
>>>>
>>>> -Peter
>>>>
>>>> Arun Gupta wrote:
>>>>
>>>>> I've created a Rails app and added WEB-INF/sun-web.xml directory
>>>>> with the contents as:
>>>>>
>>>>> -- cut here --
>>>>> <sun-web-app error-url="">
>>>>> <context-root>/ruby_comet</context-root>
>>>>> <class-loader delegate="true"/>
>>>>> -- cut here --
>>>>>
>>>>> If the app is deployed then the following message is shown:
>>>>>
>>>>> INFO: Loading application ttt_ruby at /ttt_ruby
>>>>>
>>>>> However if I restart the server (w/o re-deploying the app) then
>>>>> the following message is shown:
>>>>>
>>>>> INFO: Loading application ttt_ruby at /ruby_comet
>>>>>
>>>>> The same app is getting loaded in different root context. And
>>>>> indeed this is verified by accessing the URL as well.
>>>>>
>>>>> Am I missing something or this is a bug ?
>>>>>
>>>>> -Arun
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>