Hi Hong,
Can you tell me how an admin would change the context-root after the deployment
is done, if:
- this information is not in domain.xml &&
- contents of sun-web.xml are not (yet) exposed through admin interfaces?
Also, I was not sure if we always generated sun-web.xml for a web-app
that did not have one in the archive.
Web-apps embedded in enterprise apps is a different case because
application.xml (standard) itself has context-root information for all of them.
I am OK doing this either way, but then doing it sun-web.xml way implies
that that information needs to be exposed through admin. Also, a command
line support for the same should be desired. We'll talk offline about this.
Pramod brought out a point that context-root is not specific to web-apps
alone. For example, a rails app has a context-root too. Does that app have
a sun-web.xml? I guess not.
My gut tells me it is domain.xml that should have this information owing
to above reasons. I can go with sun-web.xml if similar things are possible
with that. Please discuss.
Regards,
Kedar
Hong Zhang wrote:
> Hi, Kedar
> Just want to bring up there was a potential issue in exposing the
> context-root in domain.xml (as a writable attribute). This is actually
> more of a general issue where same information exist in both deployment
> descriptor and domain.xml. For a standalone web module, the sun-web.xml
> has the context root information and the domain.xml also has the context
> root information. This works in v2 this way: the value in domain.xml
> takes precedence, and we don't allow user to modify deployment
> descriptor (sun-web.xml) without doing a redeployment (where value in
> domain.xml will be refreshed). But if we were to allow user to edit
> deployment descriptor in v3 without doing redeployment, with two
> possible sources of value being changed, which value do we use?
> So I think, if possible, we should avoid exposing this context-root
> information in domain.xml. It is needed right now by the web container
> to load the web module as the context root information in the domain.xml
> takes precedence, so the web container code reads from there. It should
> be possible to just read the context root information from DOL object
> which is similar to how the web container handles the ear case (embedded
> wars).
>
> - Hong
>
>>
>>
>> Yes, without a doubt. I missed that for a pure web module, without
>> which, the web-container wouldn't know what context to open on
>> server startup.
>>
>> In V2, we had a context-root as an attribute of a web-module. Perhaps
>> for V3, we should use a property instead, since this is a web-module
>> specific thing?
>>
>> Can you please open an issue-tracker bug to track it?
>>
>> Regards,
>> Kedar
>>
>> Pramod Gopinath wrote:
>>> Hi Kedar
>>> Should not the contextRoot information also be persisted ?
>>> I have deployed a application that is deployed as :
>>> asadmin deploy --name "abc" --contextRoot /def hello
>>>
>>> Currently the application would work correctly as
>>> http://localhost:8080/def after a deployment before the server has
>>> been restarted. But after the restart the application can only be
>>> accessed at http://localhost:8080/abc/a.
>>> This is because the contextRoot information is lost between the
>>> server restart and we pick up the name instead.
>>>
>>> Thanks
>>> Pramod
>>>
>>>
>>> Kedar Mhaswade wrote:
>>>>
>>>> The minimum data required is:
>>>> - name
>>>> - location
>>>> - whether the app/module is enabled
>>>>
>>>> That should be available for any deployment, I believe.
>>>>
>>>> Is there other meta-data that you were thinking of persisting to
>>>> domain.xml?
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>