Eureka! And I find it hard to believe I'm the only one this is affecting.
If I explicitly add crimson.jar first in the project.class.path with
<fileset dir="lib">
<include name="crimson.jar"/>
<include name="**/*.jar" />
</fileset>
then everything validates perfectly. My guess is that xalan-2.0.0.jar is
getting put before it in the classpath, and is what's causing the problem.
The exception mentions org.apache.xerces.jaxp.SAXParserFactoryImpl - the
xalan jar has a file META-INF/services/javax.xml.parsers.SAXParserFactory
containing the string "org.apache.xerces.jaxp.SAXParserFactoryImpl", which
means JAXP will want to use it as the SAX parser (and, of course, it isn't
found). With crimson first on the path, it gets set up to that instead.
What determines the order of the fileset's jars in <include
name="**/*.jar" /> anyway? (so we can make sure crimson comes first)
Incidentally, 2.0.0 seems quite an old version of xalan (I assume that's
what's in the jar based on its name) - the current one on xml.apache.org
is 2.3.1.
Andrew.
A wise old hermit known only as Andrew Stevens
<[EMAIL PROTECTED]> once said:
> The exception's being thrown during XML validation; it's not just the
> deploymentdescriptor subtask that's affected - if I set validatexml to
> false on that one it just fails on the weblogic subtask instead. If I
> set it to false on weblogic, it fails at the jrun task instead...
>
> The ejb-jar.xml file *is* valid, though - it's validated okay by
> Netbeans' XML module (at least, once I change the DTD's system ID to
> point to the local disk copy). So, it appears to be a problem with
> XDoclet's validator.
>
> I don't suppose the java.io.File->java.net.URL changes could have
> messed up the validation? (e.g. by stopping it resolving the DTD) The
> only change to xdoclet.util.XmlValidator since my i18n stuff (and I
> know it worked okay after that) is "Refactored the use of java.io.File
> for reading to use java.net.URL instead. This is cleaner and safer, and
> makes it possible to read templates from within other jar files" What
> about the subsequent change to fix the file:/// problem for
> templatefile? Would that need anything equivalent doing in the
> XmlValidator too?
>
> Again, am I the only one that's getting this?
>
>
> Andrew.
>
>
> A wise old hermit known only as Andrew Stevens
> <[EMAIL PROTECTED]> once said:
>
> > Is it just me, or is something wrong with building the samples? I do
> > a total-clean, build the main dist, go the the samples and build, and
> > I get
> >
> > [ejbdoclet] javax.xml.parsers.FactoryConfigurationError:
> > java.lang.ClassNotFoundException:
> > org.apache.xerces.jaxp.SAXParserFactoryImpl
> > [ejbdoclet] at
> >
> >
> javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:150
> > )
> > [ejbdoclet] at
> > xdoclet.util.XmlValidator.validate(XmlValidator.java:169)
> > [ejbdoclet] at
xdoclet.XmlSubTask.engineFinished(XmlSubTask.java:132)
> > [ejbdoclet] at
> > xdoclet.TemplateSubTask.startEngine(TemplateSubTask.java:550)
> > [ejbdoclet] at
> > xdoclet.TemplateSubTask.startProcess(TemplateSubTask.java:354)
> >
> >
> > Andrew.
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
