geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <d...@coredevelopers.net>
Subject Re: Geronimo Deployment Descriptors
Date Sun, 07 Sep 2003 17:32:02 GMT
We don't have problems with third party tools.  They must use our 
config beans... it is required by JSR 88.

-dain

On Sunday, September 7, 2003, at 05:41 AM, Jason Dillon wrote:

> 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.
>
> --jason
>
>
> 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" <dain@coredevelopers.net>
>> To: <geronimo-dev@incubator.apache.org>
>> 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
>>>   *************************/
>>>
>>
>
>

/*************************
  * Dain Sundstrom
  * Partner
  * Core Developers Network
  *************************/


Mime
View raw message