This is exactly my current work around. Actually, I'm only building XMLUtils and placing the class files (there is an inner class) in my WEB-INF/classes. This ensures that this version of the classes are loaded before those in the lib directory.
Also, I am using Crimson, and crimson.jar is in my WEB-INF/lib. This insures that the wrong (old) version of Xerces is not gotten from Weblogic's system class path. If I explicitly call the Xerces SAXParserFactory, I may be referring to an older version because the package and class names have remained the same from version to version.
I don't want to change Weblogic's parser out from under it, but I think my webapp should be able to use it's own parser. It should, in theory, have it's own class loader that will load my favorite parser impl from WEB-INF/lib. I guess I am trying to work around two problems, one with Weblogic, and one with JAXP itself. Weblogic exposes the system class path to webapps - this isn't so good because one of the things in the system class path happens to be an old version of a parser that I don't want to use. My problem with JAXP is the whole concept that the parser used is a system wide property. When did global variables come back into style? In my mind, J2EE components (webapps and even EJBs) should be self contained.
Correct me if I'm wrong, but instantiating the SAXParserFactory by name will only cause problems if that SAXParserFactory class is available in the system class path in addition to the webapp's. Even then you have a chance that your app server will search the system class path last. Is this right? Is there a reason XMLUtils couldn't first look for a resource bundle (which I like because it will be loaded from the webapps class path)? Even a system property (eek) such as axis.xml.parsers.SAXParserFactory could do the job.
BTW - I'm not down on the way Axis is doing things. I'm just currently stuck with an old version of Weblogic. What I really want is for Weblogic's Registry SAXParserFactory to give me a reference to a real parser, rather than giving me a proxy. Oh, and I also what Sun to get rid of the concept of system properties. Is that too much to ask?
-Jeff
Paul Brown <[EMAIL PROTECTED]>wrote:
Jeff --
I'll chime in.
> I propose that it be made possible to configure Axis's
> DocumentBuilderFactory and SAXParserFactory independent of
> the system's default. It is fine to use the default, but
> it would be nice to be able to override this behavior -
> especially when working with an older application server.
I think that your request is already allowed for by org.apache.axis.utils.XMLUtils, since this is the only place that the factories are used or set up. You can simply go in and hard-wire the constructor(s) and rebuild axis. For example, if you want to use Xerces-J2, then you want to replace:
SAXParserFactory.newInstance()
with
new org.apache.xerces.jaxp.SAXParserFactoryImpl()
You will have to make a similar adjustment to the DOMBuilderFactory. (This will open an interesting can of worms with respect to which DOM implementation and which SAX implementation are present.)
This may sound a little low-level at first, but it is really the best way to accomplish your goal. Here are three reasons: (1) there is no pluggable alternative to JAXP other than to use implementation-specific classes. (2) Doing a Class.forName() or attempting to access a particular class by classloader (which is how most JAXP implementations do it -- see the xml-commons project:
http://cvs.apache.org/viewcvs.cgi/xml-commons/java/external/src/javax/xml/parsers/FactoryFinder.java?rev=1.7.4.1&content-type=text/vnd.viewcvs-markup
) will introduce other interesting behaviors depending on the J2EE container. (3) Overriding JAXP behavior for the container itself may (i.e., will) generate unexpected and undesirable results.
In the worst case, you can just be out of luck.
-- Paul Brown
FiveSight Technologies, Inc.
Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes
