tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 3809] - Jar files in the wrong directories.
Date Tue, 02 Oct 2001 09:26:40 GMT
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.

pduffin@volantis.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |



------- Additional Comments From pduffin@volantis.com  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.

Mime
View raw message