geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Geronimo Deployment Descriptors
Date Sun, 07 Sep 2003 13:24:52 GMT
	It seems like there are two advantages to this approach:

 - No code needs to be written to read through multiple DDs and match up 
the content in each (i.e. find the "ejb/MyEJB" EJB ref for the same bean 
for multiple DDs).

 - We wouldn't require the developer to use optional nodes (such as the
relationship name or the ID attributes), just so we could do the
aforementioned matching up

	I also see a number of disadvantages:

 - It becomes much hard to maintain these things by hand.  Every change
you make in the ejb-jar.xml needs to be made in the geronimo-ejb-jar.xml,
and the place to do it may be inobvious because the standard content
you're looking for may be drowned in the ger: content (try to change a 
CMP field in a JAR full of entities).

 - If we ignore the ejb-jar.xml in favor of reading only the Geronimo DD, 
then we introduce bugs where someone updated the standard DD but we ignore 
it.  See OC4J, where you have to delete your application-deployments 
directory every time you make a substantive change to the DDs, because it 
generates its own authoritative DD based on the input you supply, and 
then it doesn't update the authoritative one often enough.

 - If we do not ignore the ejb-jar.xml in favor of reading only the 
Geronimo DD, we have the same matching-up problem as before if the content 
differs between the two DDs.  Let's say the user changes the name of an 
EJB -- do we just trash all the settings we had before?  We still need to 
add new Geronimo content for new EJBs and remove old Geronimo content for 
removed ones too.

 - Bottom line, I think this amounts to requiring the developer to use a
tool to create their DDs -- I don't think it will be manageable otherwise.  
But we can't do that (users will be users), so I think we'd just be
setting ourselves up for a lot of trouble.


	All that said, I would support the Geronimo POJOs fitting in with 
the J2EE POJOs this way, so we can have the XML reader do the matching-up, 
and then all the Geronimo code can access one unified set of POJO 
metadata.

Aaron

On Sat, 6 Sep 2003, 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
> 


Mime
View raw message