You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Jesse Glick (JIRA)" <xe...@xml.apache.org> on 2010/06/29 17:08:49 UTC

[jira] Commented: (XERCESJ-814) Use of ContextClassLoader is not appropriate

    [ https://issues.apache.org/jira/browse/XERCESJ-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883577#action_12883577 ] 

Jesse Glick commented on XERCESJ-814:
-------------------------------------

It's going on two years since a patch to correct this bug was suggested; is anyone taking it?

DTDDVFactory seems to suffer from a similar problem according to

http://netbeans.org/bugzilla/show_bug.cgi?id=187728

The code

    private static final String DEFAULT_FACTORY_CLASS = "org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl";
    public static final DTDDVFactory getInstance() throws DVFactoryException {
        return getInstance(DEFAULT_FACTORY_CLASS);
    }

should likely be replaced with the simpler and safer

    public static DTDDVFactory getInstance() {
        return new org.apache.xerces.impl.dv.dtd.DTDDVFactoryImpl();
    }

and code calling

DTDDVFactory.getInstance(XML11_DATATYPE_VALIDATOR_FACTORY)

should be changed to use

new org.apache.xerces.impl.dv.dtd.XML11DTDDVFactoryImpl()

so there is no real need for either of the getInstance methods. SchemaDVFactory is similar, so it is probable that org.apache.xerces.impl.dv.ObjectFactory could just be deleted, greatly simplifying the code: it is never used to load a user-configurable service.

There are other places where excessively flexible class loading is used; for example, XIncludeHandler has the rather roundabout code:

    public final static String XINCLUDE_DEFAULT_CONFIGURATION =
        "org.apache.xerces.parsers.XIncludeParserConfiguration";
...
            	String parserName = XINCLUDE_DEFAULT_CONFIGURATION;
            	if (xpointer != null)
            		parserName = "org.apache.xerces.parsers.XPointerParserConfiguration";
            	
                fChildConfig =
                    (XMLParserConfiguration)ObjectFactory.newInstance(
                        parserName,
                        ObjectFactory.findClassLoader(),
                        true);

which could be greatly simplified:

fChildConfig = xpointer != null ? new org.apache.xerces.parsers.XPointerParserConfiguration() : new org.apache.xerces.parsers.XIncludeParserConfiguration();

again removing the need for org.apache.xerces.xinclude.ObjectFactory entirely.

> Use of ContextClassLoader is not appropriate
> --------------------------------------------
>
>                 Key: XERCESJ-814
>                 URL: https://issues.apache.org/jira/browse/XERCESJ-814
>             Project: Xerces2-J
>          Issue Type: Bug
>          Components: JAXP (javax.xml.parsers)
>    Affects Versions: 2.5.0
>         Environment: Operating System: Other
> Platform: Other
>            Reporter: Thomas Pasch
>            Assignee: Xerces-J Developers Mailing List
>
> On jdk >=1.2 (but <1.4) xerces uses the ContextClassLoader to load classes of 
> its own distribution. This is never appropriate and will lead to 
> ClassCastException in a J2EE setting.
> For loading classes of its own distribution, the (current) ClassLoader that has 
> loaded the distribution classes (i.e. xercesImpl.jar) should be used.
> Glory Details:
> --------------
> The problem shows up when there is a (outdated) xerces in your (ClassLoader) 
> path but you want to use a newer version of xerces in your application. Note 
> that this is NOT an obscure setting but the normal case in every J2EE (1.3) 
> application because you are guarantied to have JAXP XML access, but often to an 
> outdated product (in my case I'm using IBM WAS 5.0.1 on Solaris).  
> One of the possible solution is to load the JAXP factory classes by a self 
> created (URL)ClassLoader. (Note that this is not 100% to the specs but works on 
> most application servers I know.)
> The problem however arises from within xerces. It exist in some variants but 
> basically boils down to the following:
> 1. 
> While creating a SAX/DOM object xerces creates a XMLParserConfiguration first. 
> For example, when trying to instantiate a 
> org.apache.xerces.jaxp.DocumentBuilderImpl (by means of 
> org.apache.xerces.jaxp.DocumentBuilderFactoryImpl) first a 
> XMLParserConfiguration is created by org.apache.xerces.util.ObjectFactory 
> invoked by org.apache.xerces.parsers.DOMParser(SymbolTable, XMLGrammarPool).
> 2.
> ObjectFactory.findClassLoader(), however, uses the ContextClassLoader to load 
> the Class "org.apache.xerces.xni.parser.XMLParserConfiguration". BUMMER! This 
> is the (outdated) class of the old version of xerces.
> 3.
> Xerces 2.5.0 fails miserably because of a ClassCastException. Typical 
> stacktrace is:
> java.lang.IllegalArgumentException: 
> org.apache.xerces.parsers.StandardParserConfiguration
>         at org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.setAttribute
> (DocumentBuilderFactoryImpl.java:128)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: j-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: j-dev-help@xerces.apache.org