>>
>> 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 ?
Yeah, let's add the context-root information.
module=(sniffer, context-root?, property*)
make the context-root as optional as context root is not applicable to
all the modules.
- Hong
>>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>