dev@glassfish.java.net

Re: Deploy a web app, rename domain.xml to domain.bak, can't restart

From: Jerome Dochez <Jerome.Dochez_at_Sun.COM>
Date: Mon, 11 Feb 2008 10:37:36 -0800

Hong Zhang wrote:
> Hi, Kedar
> In v3, we have the new converged application model where different
> components of the application could be targeted to different
> containers. Should we encapsulate this information in the domain.xml?
> For example, in JavaEE6, we will start to support EJBs inside the war
> file. Do we want to persist the ejb information inside the web module
> in this case?
> What do you think of the following "applications" element?
>
> applications = (application)*
> application = (module+, name, location, object-type, enabled,
> libraries, availability-enabled, directory-deployed, property*)
> module = (sniffer, property*)
module=(sniffer, context-root, property*)
no ?
>
> where module represents a component of the application which targets
> to a particular container.
>
> So in the above case (where EJBs inside the war), we would have two
> modules, a web module and ejb module. Let's discuss whether it's
> useful to persist the module information in the domain.xml. If we use
> the old v2 domain.xml format, only the web-module will be persisted.
>
> - Hong
>
>
> Kedar Mhaswade wrote:
>>
>>
>> Jerome Dochez wrote:
>>>
>>> On Feb 8, 2008, at 2:16 PM, Kedar Mhaswade wrote:
>>>
>>>>
>>>>>>>> I was referring to something like DeployCommand.java to do
>>>>>>>> this. AdminAdaptor
>>>>>>>> will end up calling DeployCommand for deployment purpose, right?
>>>>>>> yes. but the deployment command does not have all the meta data
>>>>>>> that would eventually be stored in the configuration, it's
>>>>>>> calculated along the way of deployment,
>>>>>>
>>>>>> 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?
>>>>> list of containers, extra properties per container at least, so far.
>>>> Hmmm. Can these properties be "managed"? If not, is it better if we
>>>> persist them elsewhere? If a developer/administrator needs to know
>>>> them
>>>> (even from a read-only perspective) it's OK to persist them there, but
>>>> I am not sure.
>>>>
>>>> Anyway, the minimal set is different from complete set. I think we
>>>> should
>>>> add the application/module's name/location/enable-status as a
>>>> minimum to
>>>> domain.xml and admin code should do that. If you don't object to
>>>> it, I will
>>>> make that change.
>>> I do object... I want only one location to update the tree,
>>> otherwise you end up
>>> in having to have two different parts changing the config and having
>>> to synchronize them manually
>>>
>>> what are you trying to solve here ?
>>
>> I am all for making one portion of the code change the config tree,
>> not multiple
>> places.
>>
>> But I am making a case for it to happen at least once. All I am asking
>> is whether I can make the change that, upon deployment, adds an entry
>> like:
>> <application name="foo" location="${com.sun.aas.instanceRoot}/apps
>> ..." enabled="true">
>>
>> ...
>>
>> <application-ref> foo </application-ref>
>>
>> in domain.xml.
>>
>> Let me know if you are ok with it.
>>
>>
>>>
>>> Jerome
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>