Skip to main content

Re: Question regarding context-root in admin UI

1 reply [Last post]
anilam
Offline
Joined: 2005-03-29
Points: 0

Hi Noah,
When you deploy the WAR, the context root field is optional. If this
isn't what you want, you can overwrite it, or just empty it out.
If the context root is not specified, then it will be using the one
specified in the web.xml.

This is the same behavior as if you are using the command line to deploy
where
[--contextroot ] contextroot is optional.

So, just don't fill in the context root, and it will pick up from web.xml.

thanks
Anissa.

On 9/19/12 7:21 AM, Noah White wrote:
> When deploying a WAR via the admin UI the context root is automatically set to the name of the WAR file minus the .war extension.
>
> This is regardless of the presence of a defined in a glassfish-web.xml or a web.xml file.
>
> If I want to override this behavior I have to manually set the Context Root field in the admin UI to the same value in application's web.xml.
>
> This becomes an issue when you name your WAR file with version information. For example MyApplication-1.0.1.war or MyApplication-Experimental.war but you want the deployed context root to be version agnostic.
>
> If you use the asadmin cmd line tool to deploy then it will use the context-root specified in the *web.xml file by default. Much simpler!
>
> I would like the admin UI to behave the way asadmin does in this regard as it is simpler to deploy. Is there a way to configure things so that it will?
>
> Thanks,
>
> -Noah
>
>

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
emailnbw
Offline
Joined: 2008-05-28
Points: 0

Hi Anissa,

Yes, the point I was making was the Admin UI _automatically_ fills in the context root based on the name of the WAR file being uploaded (minus the .war extension) and so you have to as you described change this by hand.

On the other hand the cmd line asadmin -deploy does not automatically set a context root based on the WAR file name. If you don't set it with the --contextroot switch it gets set to whatever is defined in your web.xml/glassfish-web.xml if you have one.

So the default behavior of these two tools is slightly different in that respect.

I prefer the cmd line behavior because you don't have to do a manual step of setting the context root field should your context root (in your web.xml etc.) be different then the name of your WAR file.

This makes for a more succinct deployment process for the use case where your WAR file contains a version agnostic context root specified in a deployment descriptor but your WAR file name contains version information.

I wish the UI behaved the same in that regard, that's all.

Thanks,

-Noah

On Sep 19, 2012, at 2:25 PM, Anissa Lam wrote:

>
> Hi Noah,
> When you deploy the WAR, the context root field is optional. If this isn't what you want, you can overwrite it, or just empty it out.
> If the context root is not specified, then it will be using the one specified in the web.xml.
>
> This is the same behavior as if you are using the command line to deploy where
> [--contextroot ] contextroot is optional.
>
> So, just don't fill in the context root, and it will pick up from web.xml.
>
> thanks
> Anissa.
>
> On 9/19/12 7:21 AM, Noah White wrote:
>> When deploying a WAR via the admin UI the context root is automatically set to the name of the WAR file minus the .war extension.
>>
>> This is regardless of the presence of a defined in a glassfish-web.xml or a web.xml file.
>>
>> If I want to override this behavior I have to manually set the Context Root field in the admin UI to the same value in application's web.xml.
>>
>> This becomes an issue when you name your WAR file with version information. For example MyApplication-1.0.1.war or MyApplication-Experimental.war but you want the deployed context root to be version agnostic.
>>
>> If you use the asadmin cmd line tool to deploy then it will use the context-root specified in the *web.xml file by default. Much simpler!
>>
>> I would like the admin UI to behave the way asadmin does in this regard as it is simpler to deploy. Is there a way to configure things so that it will?
>>
>> Thanks,
>>
>> -Noah
>>
>>
>