Hi, Kedar
I see your point that as we expose this context root through admin
interface for standalone web module, it's easier if we persist the
information in the domain.xml.
For the ear case, the application.xml is also optional since
JavaEE5. I think the difference here is we don't expose the context
roots of an application through admin interface. So we don't need to
persist this information in domain.xml.
I am ok with keeping the context root information in domain.xml for
standalone web module. And for the cases where we allow the user to edit
deployment descriptor (sun-web.xml) for context root, we just need to
always keep the domain.xml value in synch (through redeployment or other
mechanism).
- Hong
Kedar Mhaswade wrote:
> 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
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>