geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emerson Cargnin" <echoflor...@bol.com.br>
Subject Re: Geronimo Deployment Descriptors
Date Sun, 07 Sep 2003 10:20:23 GMT
-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
>   *************************/
>


Mime
View raw message