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