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 Mon, 08 Sep 2003 01:47:39 GMT

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

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?


View raw message