-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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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 > *************************/ >
