Morning Werner,
Another option - follow Sun's lead and grab the base Xerces version,
stick it in a Castor namespace and just use that? Castor and Xerces are
both Apache 2 licensed code-bases, so I don't see any issue with that?
I'm not sure how big an object graph it requires, but it might be worth
considering.
Cheers,
James
Werner Guttmann wrote:
Good morning James,
No worries. I guess I'll wait for Stoil to create the issue, then. We could use the fallback mechanism as pointed out by you, but that would prevent users from (easily) using a different XML parser (Cerces instance) than the one shipped with the JDK, right ?
I guess I will simply create a new implementation class for the Castor-internal
serialization interface, and make it available through the castor.properties
file in the usual way.
Regards
Werner
-----Ursprüngliche Nachricht-----
Von: James Abley [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 08. Jänner 2007 09:30
An: [email protected]
Betreff: Re: [castor-user] XercesSerializer depends on hardcoded xerces
class
Hi Werner,
I think maybe Stoil is best placed to do this, seeing as that's who
reported having an issue? I was just pointing out a possible reason why
Castor has a dependency on Xerces and doesn't use the version that
comes with Java 5. I haven't checked out that area of the Castor
codebase - it's possible that it could use a fallback mechanism to check
if it's running within a Sun Java 5 or above JVM and instantiate the
bundled version directly before trying the vanilla Xerces version.
I'm currently working on a similar problem for another open-source
project, so if I find something that helps me there, I'll obviously
share that with the group.
Cheers,
James
Werner Guttmann wrote:
James,
can you please create a new issue at
http://jira.codehaus.org/broewse/CASTOR, and I'll handle the rest.
Please make sure that you attach all relevant information from this
thread to the new issue.
Regards
Werner
James Abley wrote:
In Sun's Java 5 JDK, they learned from bundling Xalan-J in 1.4 as part
of rt.jar, and put the bundled version of Xerces into a different
namespace. I think you still have a dependency on Xerces when using
Java
5 since Castor directly tries to create an instance of
org.apache.xml.serialize.XMLSerializer, rather than the Sun Java 5
class
com.sun.org.apache.xml.serialize.XMLSerializer.
Cheers,
James
Werner Guttmann wrote:
Yes and no. In other words, it depends.
If you want to use 'pretty printing', there's currently a dependency
on
Xerces as Castor internally uses Xerces to achieve e.g. indentation.
But
good news is that there's an interface involved which you can provide
a
custom serializer for.
What surprises me, though, is that you are facing problems with JDK
5.0,
as I am sure this has been tested before. What's the problem you are
facing ?
Werner
stoil valchkov wrote:
Hi,
I have a problem to detach from xerces 1.4 jar. class
org.exolab.castor.xml.XercesSerializer has in its constructor
Class.forName("org.apache.xml.serialize.XMLSerializer").newInstance();
This results in class not found if I try using xerces comming with
JDK
1.5. Is it possible to remove this dependency?
Best regards,
Stoil
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
