geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <>
Subject Re: Geronimo Deployment Descriptors
Date Sun, 07 Sep 2003 07:51:15 GMT


I think you have to think about our POJO approach to XML parsing
more.  Just because handling multiple descriptors in JB was a nightmare,
does not mean that it needs to be so in G.    One of the good things
about our POJO approach to XML parsing is that the marshalling code
should be able to hide any multiple files or override mechanisms that
we wish to have.

taking your points out of order....

Dain Sundstrom wrote:
 > 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.

We need an approach that works for all deployment desciptors, simple or
complex, well designed or not.    I don't think we should have a
different approach to each and every deployment descriptor.   So whatever
we do needs to work for ejb-jar.xml, web.xml, application.xml, etc.

 > For web, I bet it feels like over kill to dupe the file to add things,
 > and for web you have more tools.

I'm not worried about overkill.  I'm worried about duplication.
Duplicating content is just *BAD*, no matter how many tools you have to
try to sync the duplication.

Why write a tool to fix duplication if you can avoid the duplication in
the first place.

If you are going to have a tool, then use the tool to write the
the multiple files rather than trying to resolve duplication between

Our XML parsing code should be able to put the multiple files
together into a single POJO structure and implement any
override mechansims that we may want.

 > 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?

You need container specific configuration for all the ejb-ref, resource
references etc. etc.

So what ever approach we take for geronimo-ejb-jar.xml, we should do the same
for geronimo-web.xml

>>  + 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.

If you find it a pain, then use a tool to generate the file(s).

Being a pain is not a reason to de-normalize your data.  The files
have the same structure and same "indexing" but they have different
semantic content.

>>  + 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.

If tools is the answer to the problem, then tools are just as happy
to write two files rather than one.

We have to have a better reason that it being a bit of a pain to break
every tool out there that currently generates or parses standard deployment

Also it is not just tools.  What if in a multi container project it is
other developers working with weblogic or jboss that are making changes
to the standard descriptors.  How do you automate that their changes
propogate back to the geronimo descriptors?

>> 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.  

Well I was not too keen on the idea either - just suggesting it as a more
acceptable way to allow a *optional* single file solution.   So I'd prefer
the normal 2 file solution (without duplication or overrides), but will
answer your points below anyway....     don't read on if you think it
is TOTALLY a bad idea (as I probably agree with you).

 > 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 file.

Which you would be doing anyway if the content was generated/copied.
At least with override you have the option of putting all the content in the
geronimo-ejb-jar.xml and never switching back and forth.

>> 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.

Why a nightmare?  We load the standard descriptor into our descriptor
POJOs. Then we load the container specific descriptor into the same POJOs
then we use them - overide is now handled already and no searching required.
Note that even if we don't allow overrides, the POJOs we use for descriptors
will hide multiple descriptors from us.

There are no nightmares of duplicate content, because the content
is never duplicated - it is overridden (only if the developer wishes it
to be).

>> 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.

You duplicate structure and naming - but you should not duplicate content.

>> 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.

That helps in some situations, but not all.   If the standard descriptor
is being generated then they need a tool to apply diffs - style sheets
are not up to 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 totally agree that the descriptors are not nice.

But duplicating data and making it difficult for 3rd party tools
is only going to make it worse.

If you are using XDoclet or similar, then it is not relevant that
the files are ugly or a pain to deal with.


View raw message