On Tue, 9 Apr 2002, Larry Isaacs wrote: > The instructions for installing Coyote on Tomcat 3.3.x say to > replace connectors_util.jar with j-t-c's tomcat-utils.jar. Since
j-t-c tomcat-utils are a subset of tomcat-utils.jar from container/ Sorry, I didn't read the instructions for Coyote - I'm using coyote with the 'old' minimal common loader and it works fine. I have 2 concerns: - we can't have same tomcat-utils.jar name and different content in common and container. - I want to make sure all code that goes to common is carefully reviewed from security standpoint. We had a potential problem with jdk11 compat package ( now it is safe, but at some point it wasn't ). That's the main reason for keeping only minimal utils. > the tomcat-utils.jar that j-t-c builds. So why not just use the > "util" jar that j-t-c builds? I would be +1 for renaming the > "util" jar that j-t-c builds to connectors_util.jar to avoid > name confusion with the tomcat_util.jar. Or we can rename container/tomcat_util.jar to container/container_util.jar, and leave tomcat_util name to j-t-c. Both are fine - but we still need to review any extra class that ends in common ( i.e. re-read the code and look for static methods/fields, package-protected methods, doPriviledged blocks, etc ) I will do that, but it would help if you could duplicate :-) ( duplication is good sometimes ). > > I don't have any special urge to have a single "util" jar. > I find it preferable to not have a XML parser in the common loader. > IMHO, auto-adding the XML parser to the web application loader is a > good solution for providing a default XML parser. If this means we > keep separate common and container "util" jars, I'm in favor of that. No, xml parser in common was not the issue. XmlMapper is also ok and could sit in common loader. The only problem is that XmlMapper doesn't work at this moment in common/ because we don't set the context loader to point to container/ ( this also affects common-logger ). I think the only reason for keeping some utils in container is security and webapp-awareness - as we find time and review the code we can move it to common. By webapp-awareness I mean it should deal with the fact that webapps may use it and use thread class loader instead of Class.forName, etc. Not all code 'behaves' nicely in commons, and I would like to avoid playing ClassLoader tricks and breaking delegation. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
