Me, I still don't get it. See below.
Thom Park wrote:
> Hi Alex,
>
> I wrestled with this one as well - I'd like to see a DTD for server.xml as also The
> problem is that, as various connectors/interceptors/valves/whoknowswhat are added to
> tomcat during a development cycle, the parameters can change tremendously.
>
> e.g. there was a marked change in the 'shape' of the contexts between the tomcat
> 3.2.b4 and the final 3.2 production.
Ok, but at any given point there's one possible definition? Of course DTDs change, when
the data needed changes as well. You only have a final DTD when you have a final
version,
right?
> Ideally, this could be managed by having different versions of a DTD for each
> release/revision of tomcat. The restriction is that some of the current
> freedom for 'interceptor' implementors would be lost - you couldn't just change the
> parameters to an interceptor on a whim - you'd now need to submit revisions to the
>DTD
> for server.xml thereby adding one extra step to the development cycle.
This one is more understandable. Perhaps the problem is in defining the parameters for
all
interceptors in one file.
> What do others think - should we consider locking down a DTD for each release of
> tomcat that matches the 'current' defintion for all of the components?
>
> I think it's possible and desirable, it just adds a level of complexity to the
>rollout
> of new functionality
> Comments?
Would a different file for each different interceptor be possible, or are there too
many
for that? I mean, 10 small xml's seem to be more manageable than one, big, hairy xml.
Thanks, Thom.
Alex.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
