Unneeded BCEL classes in Xalan.jar (2 jar version)

• Key: XALANJ-2196
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Sarah McNamara
• Reporter: Eric Everman
• Component/s: Xalan
• Affects Version/s: 2.7

Description

The binary '2 jar' distribution of Xalan includes the BCEL classes in the xalan.jar. These classes are not required for Xalan, only for XMLTC. I marked this bug as 'major' because it prevents xalan 2.7 from being used under Oracle's OC4J J2EE web container, which relies on an older version of BCEL and will crash if the newer version is on the classpath.

Note that I was able to get the 2.7 version of xalan to work under OC4J by using a non-public portion of the ant build script to build the xalan.jar without BCEL.

This thread on the user's discussion list has slightly more information then this post:
http://marc.theaimsgroup.com/?l=xalan-j-users&m=112597125332553

Sarah McNamara claims to have a patch available.

Thanks Much,
Eric Everman

Comments

Now I remember what the *-nojardepends tasks were for. They were for building the separatejars distribution.
I inadvertently removed those tasks a while back thinking I was cleaning up the build file. The patch I've attached has
put them back in and the separatejars distribution should no longer pick up the XSLTC dependencies in the xalan.jar
once this patch is applied.

[Eric Everman]

I'd like to add a (mild) sense of urgency to this:

While applications are expecting XML/XSLT parsers to be swapped, they are not expecting versions of BCEL to be swaped. Last I tried, placing the xalan.jar on the class path of Oracle's OC4J (a J2EE application server) bombed the entire server because of clashing BCEL versions.

I've managed to force this to work by futzing with a custom build, but I think its safe to say that anyone running a framework that makes use of BCEL is essentially cut-off from this version of Xalan. Could this patch possibly be included in a dot release?

Thanks Much!

[Brian Minchau]

Comments from JIRA bug Triage on Febrary 7, 2006:
> Henry has looked at build issues before and will review.

[Mark Woon]

Since this appears to be a packaging issue rather than a coding issue, can't 2.7 just be repackaged correctly instead of wating for a new release? Pretty please?

[Eric Everman]

A simple repackaging would be great - no new release required (In my non-project-affiliated opinion). This issues pops up occasionally on the user's list and it is a very difficult error to track down.

[Henry Zongaro]

I have reviewed and approve Sarah's patch.

[Henry Zongaro]

Applied patch to source repository.

[Henry Zongaro]

I've marked this bug as fixed, because I've applied the patch to the source repository, but I have not repackaged 2.7, because I don't personally have the resources at my disposal to do all the testing that would be necessary.