geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: Geronimo Deployment Descriptors
Date Sun, 07 Sep 2003 06:39:13 GMT

Oops - I have re-read Jeremys email - and yes he is not extending the
standard based descriptor, but moving it's content to our own descriptor.

That is better than extending the standards descriptor.

However, I am still concerned with this proposal as many of the
tools, lifecycle and duplication issues remain:

  + Content will be duplicated in a ejb-jar.xml and geronimo-ejb-jar.xml
    This will have to be kept is sync, or validated that it is in sync.
    Either way, this is a pain.   Not having the ejb-jar.xml is not an
    option, as we are then encouraging non-standard deployments.

  + The lifecycle of the file will still be an issue for any tools that
    generates ejb-jar.xml files.  Merging will need to be done with
    any content added to the geronimo version after the last generation
    was done.

So I am still -1 on this...

UNLESS we have it that all the contents of the geronimo-ejb-jar.xml
file is optional and IFF present overrides the contents of an ejb-jar.xml
file on an element by element basis.

In this way, content of the geronimo-ejb-jar.xml is not *duplicating* the
ejb-jar.xml, it is *overriding* it.  Which is a subtle but meaningful difference.

If developers want to avoid the lifecycle issues, they simply don't duplicate
the content to the geronimo file.

If they are not concerned about cross container deployment then they don't
need to generate the standards file.

If they have a standard file supplied by a third party, they can deploy
on geronimo and change specific content without changing the original file
(and thus allowing simple updates from the third party).

I have often wanted this in web.xml, where I can override initparams
without editing the original web.xml (and losing them when I update the

Dain Sundstrom wrote:
> That is not what Jeremy did.  He has extended the j2ee schema using the 
> xml extension system.  If the spec committee did not want the schemas 
> extended they would have marked them as final.  So we have our own 
> schema the extends the j2ee one and allows for our tags to be added.
> Also note he wrote that out files our files would have a different 
> name.  For example, ejb-jar.xml would be named geronimo-ejb-jar.xml.  If 
> the user had the geronimo file, that is what we would use to deploy, if 
> they only had an ejb-jar.xml file then they would get a default 
> deployment.  Basically this is the same thing as what JB does, except 
> instead of having a weird 2 file thing we put everything in a single 
> consistent descriptor.
> -dain
> On Saturday, September 6, 2003, at 08:26 PM, Greg Wilkins wrote:
>> -1
>> I understand that the single file nature of this approach is considered
>> attractive.  JSR154 was considering supporting such descriptor extensions
>> as part of the spec.  However, this was removed from the spec and the
>> feeling is that the J2EE jsrs will no longer favour such descriptor 
>> extensions
>> (as was once going to be the case for all j2ee 1.4 descriptors).
>> The problems listed included:
>>  + difficulties in file lifecycles for tools that generate descriptors.
>>    Anything that does not know about geronimo would probably constantly
>>    overwrite any geronimo specific elements.
>>  + Difficulties in maintaining multi container deployment.  Change 
>> control
>>    and generation of container specific configuration will be 
>> difficult if
>>    multiple tools want to add container specific information into the
>>    standards descriptors.
>> Jeremy Boynes wrote:
>>> I have recently checked in a XML Schema for a couple of
>>> Geronimo-specific deployment descriptors. These rely on namespaces to
>>> allow vendor-specific elements to be included in standard deployment
>>> descriptors.
>>> For example, an ejb-ref would be defined as:
>>>     <ejb-ref>
>>>         <ejb-ref-name>ejb/MyEJB</ejb-ref-name>
>>>         <ejb-ref-type>Session</ejb-ref-type>
>>>         <home>my.EJB.Home</home>
>>>         <remote>my.EJB.Remote</remote>
>>>         <ger:jndi-name>TestEJB</ger:jndi-name>
>>>     </ejb-ref>
>>> where ger: is the prefix for the Geronimo namespace.
>>> The way this is intended to work is that the deployer will copy the
>>> standard deployment descriptor file to the Geronimo one and then add in
>>> out entries. If a geronimo descriptor exists, we will not use the
>>> standard one at all so developers will be able to work exclusively with
>>> the geronimo version. We will provide a tool for generating a standard
>>> descriptor by stripping out all geronimo-specific elements.
>>> This is working for the application-client descriptor and we will be
>>> building out the EJB one once we know what the container-specific
>>> elements actually are.
>>> This is a little different from the old-style form of vendor descriptors
>>> (e.g. as used by Weblogic or JBoss) where they were separate documents
>>> that contained just supplemental information. In light of this, I would
>>> appreciate feedback on the approach before we get too far along.
>>> -- 
>>> Jeremy
> /*************************
>  * Dain Sundstrom
>  * Partner
>  * Core Developers Network
>  *************************/

View raw message