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" <[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
*************************/
