Jeremy Boynes wrote:
Using the "code is checked in" resolution to discussions is not a good precident to set.The "I don't like what you did but don't have a working alternative" one isn't either :-)
I think the proceedural point is that you should have flagged your intent to try a single file approach before writing and checking in the code. Then both bad discussion styles could have been avoided.
If you turn the thought process around so that the 'merge' becomes stripping all geronimo-namespace elements from the file, the sync is trivial. It is much simpler than trying to merge the structure elements of two partial files.
Except if there are modifications to the standard elements of the files - with some modifications done in the standard file by developers/tools working on jboss/websphere etc and other modifications done to the standard elements in the geronimo file.
I don't see the problem here - if Jasper is using web.xml, then
a) generating it from a unified geronimo-web.xml is trivial
b) as all the geronimo elements are in a different namespace,
it would be easy for Jasper to ignore them (if it doesn't
already)
I'm not worried about the geronimo elements. I'm worried about the duplicate content of the standard elements.
Think of an IDE that is running a webapp itself. It is going to be parsing and/or generating web.xml. The developer adds some filters, adjusts some initparams, fixes some security constraints.
They now want to deploy the results in geronimo, but have an geronimo-web.xml in existance.
But they can't just regenerate that geronimo-web.xml because another developer may have been fixing their servlets using geronimo and may have added some filters, adjusted some initparams, fixed some security constraints etc. etc.
If the geronimo using developer was forced to make those changes in the standard web.xml (instead of geronimo-web.xml) then the IDE developer will be able to use normal change control to merge the differences. If they just regenerate geronimo-web.xml they may blat over the changes of the geronimo developer.
OK, you can come back with other examples of how changes in web.xml by the IDE developer will totally break a geronimo-web.xml. However, I think it is the case that both approaches ugly sync and maintenance scenarios. We can both come up with nightmare scenarios, so I don't think we can say one is better than the other for all uses and lifecycles.
So given that I see no clear advantage, I believe it is best to go with defacto standard practises and good comp sci principals of normalized data.
c) you have already said you wanted to avoid duplicate parsing which would mean exposing the POJO model to Jasper. As the standard one is a generalization of the geronimo one, this should be simple.
Eventually. Don't hold your breath waiting for this.
But the two files approach can still create a single POJO tree that we pass to a modified jasper.
I can probably get a simple loader done tonight - would that help?
I am (or probably Jan) is happy to write the code for the web.xml loader (although I see the POJO model has been created/generated - thanks whoever).
It's not a matter of writing the loader, it is a matter of designing the loader and the geronimo-web.xml schema.
If you think having working code is good for the debate, then I'll write a web POJO loader that loads from web.xml and geronimo-web.xml?
cheers
