Strange contents of JAR-files

• Key: XMLBEANS-324
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Unassigned
• Reporter: Oskar Carlstedt
• Affects Version/s: Version 2.2
• Fix Version/s: Version 2.3

Description

Hello!!

I have som deploying issues that are related to xml beans. Can someone tell me why javax.xml.namespae is included in xbean.jar and xmlpublic.jar. Also, why are these bundeled into xml beans. Isn't it better to leave them as a dependency to xml beans.

Ok, I know that people hate dependencies to other jars - but anyway, today's solution makes me (and a lot of other people too) getting a java.lang.LinkedError when using the QName class.

Is i tpossible to remove these classes ffrom the xml beans distribution.

Best Regards
Oskar Carlstedt

Comments

[Radu Preotiuc-Pietro]

Problem is XmlBeans is designed to work with JDK1.4 and JDK1.4 doesn't have this class if I am not mistaken. Having that class in the jar allows users of both JDK1.4 and JDK1.5 and above to use XmlBeans without having to worry about a dependency that really is not available anywhere for download.

What environment are you in that makes this error happen? Is it possible for you to remove this class from the jar?

[Oskar Carlstedt]

Hello!

This happens i JBoss 4.0.x where I get a LinkedError when using isolated classloaders on earfiles (i.e. server/default/deploy/ear-deployer.xml has the value Isolated set to true). A better idea might be to not mix different things in the same jar file. What I mean is, it is better to provide a new jar file called javax-xml-namespace.jar with the javax.xml.namespace contents. Then it is up to the user to use this jar file as a dedpendency or not.

I have removed the selected packages fom the jar file and that solved my problem. But doing this way means that I have to patch my own xbean.jar everytime you provide a new version.

Best
Oskar

[Radu Preotiuc-Pietro]

Yeah, and removing it in an XmlBeans release means that all the people who don't have any problems right now and use JDK1.4 will now have their apps break until the get the extra jar and add it to the classpath.

I think that the negatives far ouweigh the positives in this case and I would vote for not making this change.

When everybody moves to JDK1.5 and later, the class will be loaded by the bootstrap classloader and this will cease being a problem.

[Radu Preotiuc-Pietro]

It actually appears that this can still cause problems even with JDK 1.5 and as such we've decided to fix it. The fix has been comitted with SVN revision 537261 and will be part of the upcoming 2.3.0 release.