DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3809 Jar files in the wrong directories. [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|FIXED | ------- Additional Comments From [EMAIL PROTECTED] 2001-10-02 02:26 ------- Firstly, I think that it is wrong to expose an XML parser just because other J2EE servers do. We use most if not all of the major J2EE servers and each one causes us problems because of the XML parser that they expose. They do not all expose the same one, the ones that they do expose support different levels of jaxp and have different often conflicting functionality. As for it causing problems with newbies, that should never be a reason for this sort of change, improved documentation and FAQs are the way to address newbie issues and to be honest as relative newbies we have had more problems with the XML parser being present than we would have had without it. As far as I am concerned Tomcat had the perfect solution to this problem in its documented hierarchy of class loaders and this is a backward step. The fact that an XML parser is present in the shipped code is simply a consequence of the implementation, exposing that to users of the server is the equivalent to exposing the internals of a class. It causes instability in customer code which comes to rely on it being present, reduces the amount of reuse by increasing its cost and also goes against all good design principles. Tomcat is supposed to be a reference platform and as such should be setting the direction for the other J2EE servers to move in, not being guided by them. It should be the shepherd not a sheep. Having said that if the solution is to allow web applications to control whether or not they see the XML parser classes through any of the class loaders that they use without affecting any of the other web applications and without and code changes, or any changes to the installation then that will probably be ok, although nowhere near as clean or elegant as the currently documented solution. If this solution does not allow this level of control then it is not an acceptable solution to this problem. I am reopening as I need a reply to the above comments as I do not currently have the ability to check out the latest code from CVS.
