geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Geronimo Deployment Descriptors
Date Sun, 07 Sep 2003 07:06:35 GMT
On Sunday, September 7, 2003, at 01:39 AM, Greg Wilkins wrote:

> Oops - I have re-read Jeremys email - and yes he is not extending the
> standard based descriptor, but moving it's content to our own 
> descriptor.
> That is better than extending the standards descriptor.
> However, I am still concerned with this proposal as many of the
> tools, lifecycle and duplication issues remain:
>  + Content will be duplicated in a ejb-jar.xml and geronimo-ejb-jar.xml
>    This will have to be kept is sync, or validated that it is in sync.
>    Either way, this is a pain.   Not having the ejb-jar.xml is not an
>    option, as we are then encouraging non-standard deployments.

So what?  Sun was the one that remove the ability to extend the files.  
I think it a much bigger pain to maintain an ejb-jar.xml file and one 
that has the same structure with just a few bits added.

>  + The lifecycle of the file will still be an issue for any tools that
>    generates ejb-jar.xml files.  Merging will need to be done with
>    any content added to the geronimo version after the last generation
>    was done.

The spec expects custom tools provided by the vendor to configure an 
application before deployment. We will be writing the tags for XDoclet, 
so that is taken care of.  As for other tools, we just make the 
requirement that they are 88 compliant.  From what I understand an 88 
compliant tool must use the Config beans we write and we simply code 
our beans to maintain the geronimo config file to match the ejb-jar one 
the tool will write out.  So I don't think this is a problem for tools.

> So I am still -1 on this...
> UNLESS we have it that all the contents of the geronimo-ejb-jar.xml
> file is optional and IFF present overrides the contents of an 
> ejb-jar.xml
> file on an element by element basis.

-1 That sucked in JB.  It was a huge pain.  You were always switching 
back an forth between many deployment files.  I think if we find a 
geronimo-ejb-jar.xml file we don't even go looking for an ejb-jar.xml 

> In this way, content of the geronimo-ejb-jar.xml is not *duplicating* 
> the
> ejb-jar.xml, it is *overriding* it.  Which is a subtle but meaningful 
> difference.

It just means that you end up searching through files an matching stuff 
up.  When you get into stuff that has heavy metadata needs like 
persistence, it becomes a nightmare.

> If developers want to avoid the lifecycle issues, they simply don't 
> duplicate
> the content to the geronimo file.

You can't avoid that when you have things like persistence.  You 
basically end up redeclaring the entire bean in you persistence 
metadata because you want to do explicit mappings or special indexing.

> If they are not concerned about cross container deployment then they 
> don't
> need to generate the standards file.

They can always back a standard file out of ours by removing everything 
in out name space.  We will provide a simple style sheet to do this.

> If they have a standard file supplied by a third party, they can deploy
> on geronimo and change specific content without changing the original 
> file
> (and thus allowing simple updates from the third party).

That is a nightmare... go pick through the descrptiors in the JB test 
suite... I have been to several sites where these the JB separate file 
thing was a huge problem.  Also every site I went to that was targeting 
several containers used XDoclet to do it.

> I have often wanted this in web.xml, where I can override initparams
> without editing the original web.xml (and losing them when I update the
> software).

Greg I think this is a difference in perspective again.  The web.xml 
file is way better designed the the ejb stuff, and you simply don't 
have the amount of metadata you get in a persistence engine.  For web, 
I bet it feels like over kill to dupe the file to add things, and for 
web you have more tools. On the other hand having ejb do the add bits 
in a separate file model falls apart as you add higher level services 
like persistence.  Anyway for web, how often do people need a vendor 
specific extension?  Is this really a concern for you?


View raw message