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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
