geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <>
Subject Re: Geronimo Deployment Descriptors
Date Sun, 07 Sep 2003 10:41:05 GMT
Is the spec leaning towards using namespaces to handle this ?  if it is 
then we should impl this way, otherwise we are just asking for trouble 
with 3rd deployment tools and shit.  Personally I like using namespaces 
though, makes more sense IMO.


On Sunday, September 7, 2003, at 05:20  PM, Emerson Cargnin wrote:

> -1. I think that changing the default thinking of ejb-jar.xml for
> non-specific server config. and server-name-ejb-jar.xml for specific
> deploying settings is a bad thing. Good or bad this is a pattern that 
> is
> going on for a while in J2EE, why changing it? Let ejb-jar.xml be the
> default one, and geronimo-ejb-jar.xml be our specific server 
> configuration
> file. IMHO.
> Emerson Cargnin
> ----- Original Message -----
> From: "Dain Sundstrom" <>
> To: <>
> Sent: Saturday, September 06, 2003 10:50 PM
> Subject: Re: Geronimo Deployment Descriptors
>> 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