tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allen Holub <>
Subject Re[2]: JNDI DataSource GlobalResources problem
Date Thu, 28 Oct 2004 00:52:49 GMT
BM> The question is, are the arbiters of taste interested in considering
BM> making the administrative configuration process more convenient?

BM> It seems to me that there is a tension here: from a security standpoint,
BM> administrative configuration has to be outside the webapp. From a
BM> convenience standpoint, it sure would be nice to have a single package.

(Since this discussion is not really a technical one, please ignore
this post if you don't think it's appropriate.)

It's not really a matter of "convenience" when a deployment-based
inconsistency can severely impact development time. I'd love to see
context.xml treated uniformly across all deployment options. That is,
you should be able to put it into the META-INF directory of your
development directory, deploy with an "ant install" or
equivalent, and everything should work. Giving conflicting server.xml
entries precedence over context.xml should resolve the security
issues. At minimum, it would be wonderful if the documentation could
at least be updated to explain when context.xml works and when it doesn't.

I was a bit disturbed by a comment someone posted earlier on this
thread to the effect that the poster, who I believe *is* an arbiter
of taste, always deployed in a .war file, and didn't see the necessity
for having context.xml work in any other context (so to speak :-). The
rational was that the spec didn't require it, so we shouldn't complain
if TC won't do it. The fact is that uniform treatment of context.xml
would clear up a lot of confusion, make a lot of developer's lives
easier, and make TC a more professional product. This issue doesn't
seem to me to be so trivial that's it can be so easily dismissed.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message