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*)
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
>