I don't suppose you've solved this issue yet?

Even if I define a scoped class loader it still seems to find dom4j (maybe because it's loaded in ServerLoader?)

Tried forcing JDOM to load first via -L flags to run.sh, but then JBoss fails to boot (incompatible jaxen change it seems).

Going by: http://www.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration
I tried the tip on 3.2.4, making the EAR deployer isolated, but then i can't even resolve classes from other jars in my own EAR file (a.jar references b.jar, both inside c.ear... if A deploys first it will throw CNF, and application.xml order seems to be ignored)

I'm basically out of ideas on how to solve this issue.

Add a sample to the following bug report to expidite the invesitgation:

http://sourceforge.net/tracker/?group_id=22866&atid=376685&func=detail&aid=957704

I wrote as simple of an example as I could to show the problem, but I have no idea how to attach files to sf.net bugs.

Should I just mail it to you Scott? or is there some trick? (yes, i logged in to sf.net)

You have to check the box labelled: 'Check to Upload and Attach a File:'
in order to upload attachements to the case. If you still can't add the example send it to me and I'll add it.

I swapped out the JBoss supplied log4j.jar with log4j-1.5-rc1.jar and it all works well now. I'm thinking that maybe the dom4j that jboss ships with had a corrupt jaxen file maybe?

This is under jboss 3.2.5, system starts up fine, and my test ear file deploys properly (it's an mbean that parses then executes an xpath using jdom)


So maybe the 'fix' for this is just to include a more current dom4j in jboss 3.2.6. Hopefully dom4j will be final before 3.2.6 is (just so people don't freak about a rc1 being in jboss)


fyi, setting ear deployer to Isolated and CallByValue (both set to true) doesn't solve the problem.

I suspect it really has to do with ServerLoader loading the class. I'm not super familure with what REALLY goes on in ServerLoader, but I would imagine that any of the jboss/lib files (toplevel lib) may be non-overridable due to them needing to be loaded as part of the bootstrap phase. I could be COMPLETELY wrong on that though.

I'll go try all this with my real application now and report back if anything werid comes up.

David, i beleive that you mean you swapped dom4j out - not log4j. Correct?

Opps, my mistake

Yes, swapped out dom4j, not log4j

And, for production purposes, I've actually swapped it out in the jboss src thirdparty directory and rebuilt 3.2.5, just in case there was any wacky inlining or build time generation that depended on the previous version.

works like a charm

jdom works with zero problems (xpaths and all)

Hi,

I have the same problem.

The solution that works for me, with Jboss 3.2.5 is download dom4j-1.5-rc1.jar, and rename to dom4j.jar in /lib folder

I don't change anything in the source code, and works fine.

Thanks to all.

Jordi.