|
It wouldn't fix it – they depend on mutually incompatible bytecode under the same package. I'm not an OSGi wizard, but personally I'd rather take care of a problem like this myself.
The only way to make this work is to apply the patch I submitted to HHH-2222 and run Spring and Hibernate with cglib-nodep (which repackages ASM 1.5.3). It's not a big change, and Hibernate could easily fix it if they wanted to. There isn't really anything Spring can do about this, since they already use cglib-nodep for their ASM 1.5.3 needs. It would be good that the hibernate team changed it but as they havent done so since the patch sent in May of this year, are they likely to do it? What other solutions are there?
I dont see why the solution I proposed in my first email wouldnt work : "The solution seems to be: create a fork of the asm project, changing the package name, and recompile the spring source with that version.
the only problem is that there would be a non standard asm jarfile I would do it but I dont fancy a custom built spring framework to maintain. Or maybe in the jar manifest we could put a version number of the jar and then specify its dependencies and then write a custom class loader that always loads the right version of a class from the jar thats configured for that code! I just noticed that the asm faq has the solution http://asm.objectweb.org/doc/faq.html
15 How to resolve conflicts between different ASM API versions available in a global classpath or within the same ClassLoader? Tools and frameworks that are using ASM for bytecode processing (e.g. Hibernate, CGLIB, AspectWerkz) should repackage ASM code within their own name space. This can be automated with Jar Jar Links tool. http://tonicsystems.com/products/jarjar/
... Jar Jar Friendly Libraries: include ASM ... so it doesnt seem like any source code changes are needed ! Hope its possible to implement this soon. We're using Hibernate with the cglib-nodep.jar, with the standard asm jars used for Spring's own purposes. As far as I understand, the conflict only arises when using separate cglib and asm jars instead of cglib-nodep? Is there a reason why you can't simply use cglib-nodep in your application builds, no matter what the Hibernate distribution looks like? I'm not sure what Hibernate would have to 'fix' there... Using cglib-nodep is completely up to you and has been working with Hibernate for years.
That said, I'm open to repackaging the ASM version that Spring uses. The unfortunate part there is that ASM is optional for those purposes; Spring only uses ASM for specific features (such as component scanning). Including a repackaged ASM version will increase the size of spring-core.jar by 85 KB - and that only for an optional feature... I guess we could ship a separate spring-asm.jar with only the repackaged ASM version, but that would have to be maintained as a dedicated module (uploaded to ibiblio etc), updated along with new ASM versions, etc. Quite a bit of effort for a purely optional feature... Juergen I apologize in advance that the following stack traces dont explain what the situation is (they are copied and pasted from the server logs)
and I dont have a record of exactly what I tried at what time. Basically I changed asm versions or left out the asm jar I dont think cglib-nodep is the cause/solution as the asm lib was repackaged as net.sf.cglib.asm in the cglib-nodep jar I think the problem is that the ClassPathScanner uses the org.objectweb.asm package and so does hibernate but that they need 2 different versions. I know you say its optional but it would be great to use hibernate and more sophisticated spring features together. I hope you can see the problem from the traces. Thanks in advance Andy --------------------------- nested exception is java.lang.NoClassDefFoundError: org/object ----------------------------------------- Invocation of init method failed; nested exception is java.lang.N Invocation of init method failed; nested --------------------------------- java.lang.NoClassDefFoundError: org/object ------------------------------ nested exception is java.lang.NoClassDefFoundError: org/object ------------------------- Invocation of init method failed; nested exception is java.lang.N --------------------------- As far as I'm aware, Hibernate is NOT using ASM directly - it's only using ASM through CGLIB. So if you use the cglib-nodep.jar, Hibernate should not talk to ASM natively at all. Which means that the native ASM jar can be the one that Spring requires, without any conflicts.
So if you have:
and no other CGLIB or ASM jars on your classpath, things should work fine with Spring and Hibernate on top. Juergen Juergen,
I did the patch referenced in HHH-2222 and Hibernate unfortunately does depend directly on ASM 1.5.3: src/org/hibernate/bytecode/cglib/CglibClassTransformer.java And in my testing I've proven that Hibernate won't run with Spring's 2.2.3 ASM dependency. However, it is a Hibernate problem, and I'm not sure what you guys could do to fix it. People in Andrew's situation will have to patch Hibernate themselves or avoid using any part of Spring that requires ASM. Ouch, that's pretty bad - I wasn't aware of this. We're running our PetClinic Hibernate version with cglib and asm-2.2.3 on the classpath and it seems to work just fine... Puzzling.
In any case, we do intend to repackage ASM for Spring's purposes for 2.5 RC1. This is all we can do from Spring's side. Juergen We have a Hibernate committer on staff here – I'll talk to her and see if we can get the patch into Hibernate. That'll solve your problem for you
 Wow, you guys work fast!
So if I understand the situation I cant use things like the ClassPathScanner with hibernate until spring 2.5RC1 (unless I run a custom version of hibernate/spring (which Im not about to do!)) There is one thing that puzzles me, the application in eclipse worked but then failed in tomcat, something to do with OSGi and eclipses classloading? By the way I would like to move to OSGi for my spring applications and have played around with spring OSGi, would this help in this instance? Thanks for the help. Per HHH-2222, the Hibernate guys are dead set against repackaging their use of ASM 1.x. However, it seems they won't release 3.2.6 until cglib 2.2 (which repackages ASM 2.2.1) is ready. If ASM 2.2.1 and ASM 2.2.3 are binary compatible, this problem will go away for good.
For now, though, the options are to either apply HHH-2222 to your copy of Hibernate or use javassist as Hibernate's bytecode provider. We do repackage ASM for Spring 2.5 now (as part of spring.jar and spring-core.jar), avoiding conflicts with other ASM versions as well as making it easier to use Spring's component scanning feature (no need for adding any asm-* jars for those purposes anymore).
This required a revision of Spring's "core.type" package, using ASM internally now, with no ASM artifacts exposed publically - meaning that other packages (other Spring framework packages as well as third-party packages) can use "core.type" without being tied to the original or repackaged ASM location. Juergen Excellent, thanks very much.
I know its not a jira issue but I cant find Spring 2.5 in any maven repository, as I understood the snapshots should be in |
|||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Major
Jar incompatibility: Hibernate 3.2.5GA requires asm 1.5.3 and Spring 2.1M3 requires asm 2.2.3
states:
The spring-core module currently does not specify a version for the import of the org.objectweb.asm* packages. Since asm v1 is binary incompatible with v2 this can cause a problem. Some other projects (e.g. hibernate) require the v1 version while Spring requires the v2 version.
(I dont understand how the proposed solution would fix it if hibernate and spring are loaded by the same classloader)