remove the dependency of xerces

No, I cannot really, as there's plenty of (corporate) users still relying on JDK 1.3 and 1.4. And with them, they'd have to change existing applications to get things working again when upgrading to newer Castor releases. Se, Castor has been around for nearly 9+ yrs now, and as such we have to maintain backwards compatibility to a certain degree.

Given that there's a HTML page that highlights this issue already, and seeing that it has not been easy enough for you to find this page, I guess the documentation could and should be improved. Can you have a look at

http://castor.org/xml-faq.html#Serialization

and let me know what you'd like to see added. Please note that this page has already changed in SVN, so parts of your request have been met already.

Where else would you want to see changes being introduced, e.g. links to the FAQ entry, etc ? Or should this information be moved/copied elsewhere, to a more prominent page ?

As already mentioned, parts of the required information has been added as part of the work on CASTOR-2032.

I think it would be helpful if you could add the following 2 lines to the faq

1. use the JDK5 XML SAX parser
   org.exolab.castor.parser=org.xml.sax.helpers.XMLReaderAdapter

I am wondering if it is possible to load JDK5 SAX parser and XML serializer if the castor failed to find the Xerces ones.

> I am wondering if it is possible to load JDK5 SAX parser and XML serializer if the castor
> failed to find the Xerces ones.
Not sure about this. This would mean that if somebody specified a wrong class name, he's not get any exception but the default Xerces parser.

Other than that, I'll add the lines enlisted above to the FAQ, and probably add a new HTML page to the existing docs (in a prominent place).

I think I will create a new dependencies HTML page, which currently happens to be living within download.xml, and copy some of the information related to Java 5 to this new page.

Initial patch for review.

Just created CASTOR-2046 to track my above comment.

Patch submitted as is. The remainder of the work will be done through CASTOR-2046.

Cross-posted Comment from CASTOR-267. (Cross-posting because 267 was closed as won't fix, where as it appears the issue has resurfaced here.)

+1 on the request to make Castor Java 1.5 friendly by default, and use Xerces 1.4.0 only by configuration change.

Users don't really mind if Castor has legacy support for Xerces 1.4.0, but does it really have to be the default? Sure, it made sense to be the default in 2001, but here in 2007 people will likely be running Java 1.5 or later or have newer versions of Xerces in their dependency set, and it causes all sorts of annoying classpath problems when a transative dependency on Xerces 1.4.0 introduces old code into their classpath. And the trend towards newer versions of Java are only going to increase. Instead of requiring the mainstream of developers to put org.exolab.castor.parser=org.xml.sax.helpers.XMLReaderAdapter into their config, why not require those who want your next release but still use JDK 1.3 to include line explicitly requesting Xerces 1.4.

In other words, the problem isn't that Xerces supports 1.4.0. The problem is that by default Castor (and more notably Castor's POM) requires Xerces 1.4.0 in an era where more and more people want to use classes from XercesImpl 2.6.2 or later (which conflict with Xerces 1.4.0 as they both contain org.apache.xerces.jaxp.DocumentBuilderFactoryImpl). This problem is only going to get worse with time, not better. Can you please consider changing the default?

Doug, just returning to this issue in order to prepare for Castor 1.1.3. Before trying to agree on an approach, let me ask you the following question related to the use of Maven. I agree that version 1.4.0 of Xerces as defined in its POM is maybe a bit unlucky. But it should be sufficiently easy to override the version number in your own application POM(s) when declaring the dependency to Castor.

My problem with upgrading the dependency of Apache Xerces to a newer version is that it doe snot really make a difference for e.g. those who rely on the XML parser as shipped with Java 5 and above. I think it should be far clearer to actually define a dependency to the JAXP APIs, and nothing else. It will then be in the user's responsibility to include an additional dependency to a JAXP-complaint parser, and (have it) download(ed) separately.

I'd like to hear opinions on this before going about this.

Re-opening this.

Some recent findings. I am just experiencing with using the XML APIs only as a compile time dependency. So far things look good, but as I am switching to using these interfaces plus XercesImpl 2.6.1, the test suite does not complete without errors. Looks like there's about 6 assertions failing. Any help appreciated.

Initial patch for review, that includes the following changes:

a) include xml-apis:xml-apis:2.0.2 as new dependeny
b) set scope of dependency to xerces 1.4.0 to test only
c) change build.* scripts to reference the new XML APIs JAR only.

In addition, I had to change the XMLFileReader class as well to use JAXP for obtaining a parser, and change the fall-back mechanism to using reflection when instantiating Xerces directly.

Any feedback appreciated.

As a result, a new JAR needs to be added, i.e. xml-apis-1.0.b2.jar. In theory, Xerces 1.4 could be removed (though this would render it a bit more difficult for committers to run the CTF test suite).

Updated patch, pointing dependency to xml-apis to version 1.0.b2

Basically, with this dependency refactoring, all CTS tests still execute without any problems. I will be dealing with newer versions of Xerces through a follow-up issue.

To make a few things clearer, let me highlight the major changes to the Maven POM:

        <dependency>
            <groupId>xml-apis</groupId>
            <artifactId>xml-apis</artifactId>
            <version>1.0.b2</version>
        </dependency>

is new, and the dependency to Xerces will be changed to

        <dependency>
            <groupId>xerces</groupId>
            <artifactId>xerces</artifactId>
            <version>1.4.0</version>
            <scope>test</scope>
        </dependency>

As an alternative, the dependency for Xerces could be removed alltogether, and be included within the xmlctf project only.

I still have to change download.xml (actually src/doc/dependencies.xml) to explain the new procedures.

In addition, some testing by users running on Java 5.0 only would be appreciated ...

I have just been able to fix a few problems related to the CTF test suite when switching to a newer version of Xerces, 2.6.2 in my case. In other words, the test suite now finished successfully against the following two dependencies:

• XML APIs (1.3.03)
• Xerces 2.6.2 (implementation classes only).

Whilst this does not address Java 5 users at all, it is a step forward towards cleaner dependencies.

Actually, let me 'fix' one of my comments above. Here's the new set of dependencies I will be using in the root Maven POM.

    <profiles>
    	<profile>
    		<activation>
    			<jdk>1.4</jdk>
    		</activation>
    		<dependencies>
    			<dependency>
    				<groupId>xerces</groupId>
    				<artifactId>xercesImpl</artifactId>
    				<version>2.6.2</version>
    				<scope>test</scope>
    				<exclusions>
    					<exclusion>
    						<artifactId>xml-apis</artifactId>
    						<groupId>xml-apis</groupId>
    					</exclusion>
    				</exclusions>
    			</dependency>
    			<dependency>
    				<groupId>xml-apis</groupId>
    				<artifactId>xml-apis</artifactId>
    				<version>1.3.03</version>
    			</dependency>
    		</dependencies>
    	</profile>
    </profiles>

In other words, only users running on JDK 1.4 will have dependencies to xml-apis:xml-apis:1.3.03 added. And by default, no dependency to Xerces will be added. Or maybe an optional one, but I have not made up my mind (yet).

As mentioned already, the dependency for Xerces could be changed to

   			<dependency>
    				<groupId>xerces</groupId>
    				<artifactId>xercesImpl</artifactId>
    				<version>2.6.2</version>
    				<!-- <scope>test</scope> -->
    				<exclusions>
    					<exclusion>
    						<artifactId>xml-apis</artifactId>
    						<groupId>xml-apis</groupId>
    					</exclusion>
    				</exclusions>
    				<optional>true</optional>
    			</dependency>

to imply that Xerces is an optional dependency, as it is required when you use pretty printing. In other words, it's up to the user to include Xerces as a dependency or not.

I have been attempting to migrate from Xerces to JAXP, and am stumped right now by the dependencies.
As suggested, I have replaced the serializer property pointing to the JDK5 Serializer factory, and my parser property, as below

org.exolab.castor.parser=org.xml.sax.helpers.XMLReaderAdapter
org.exolab.castor.xml.serializer.factory=org.exolab.castor.xml.XercesJDK5XMLSerializerFactory

I still cannot get rid of Castor dependency on Xerces.. I keep getting these errors..

Caused by: org.xml.sax.SAXParseException: Content is not allowed in prolog.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)^M
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)^M
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)^M
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)^M
at org.apache.xerces.impl.XMLScanner.reportFatalError(Unknown Source)^M
at org.apache.xerces.impl.XMLDocumentScannerImpl$PrologDispatcher.dispatch(Unknown Source)^M
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)^M
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)^M
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)^M
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)^M

Just to make sure, you have tried this against what `? 1.1.2.1 or 1.2-SNAPSHOT ? And migrating towards JAXP sounds confusing to me. I guess you are on Java 5.0, and you don't want to download Xerces and add it to your classpath, right ?