- This topic has 20 replies, 4 voices, and was last updated 16 years, 9 months ago by Riyad Kalla.
-
AuthorPosts
-
Steve PriorMemberWhen moving code that compiled/worked cleanly on 5.5.1 to MyEclipse 6.0M1 I’m getting:
java.lang.SecurityException: class “com.geekster.bookmark.model.Bookmark$$EnhancerByCGLIB$$e7ad7470″‘s signer information does not match signer information of other classes in the same package
Googling around a bit I came across:
http://scott-tabar-safari.blogspot.com/2007/02/java-web-start-and-eclipse-signing-jars.html
If you look at that page under “Jar Files MUST be Signed” you will see 2 hibernate support libs mentioned that cannot be signed – hibernate3.jar and cglib-2.1.3.jar.
I checked cglib-2.1.3.jar file in the MyEclipse libs for Hibernate 3.0 and it appears that it IS signed and maybe cannot be.
Steve PriorMemberI have now confirmed that once I substitute the Hibernate 3.0 jars hibernate3.jar and cglib-2.1.3.jar from the 5.5.1 version of MyEclipse to the corresponding library of MyEclipse 6.0M1 that all my Hibernate problems go away and my entire workspace runs fine again. I’ll admit that I don’t understand WHY signing these two jars causes the problem, but apparently it does.
Steve PriorMemberOne more source of info on this issue:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-1365
It sounds like cglib-2.1.3.jar cannot be signed, version 2.2.beta has a fix, but I wouldn’t expect you to start upgrading the versions of jars from what ships with the respective Hibernate versions.
Riyad KallaMembersprior it’s true that we sign the JARs, we currently sign the entire product for distrobution reasons…
reading your posts (thanks for all the digging) am I to understand that this problem will be fixed with future releases of cglib not being able to be signed?
I also find that off that it *cannot* be signed… that would rule out any WebStart use with a signed app…
Steve PriorMemberYour signing of the jars is new with the 6.0M1 – it doesn’t appear to be the case with 5.5.1. From the atlassian.com (JBoss) site link I gave it does appear that this will be fixed in versions greater then 2.2 of cglib, but I don’t think it would be right for you to change your 3.0, 3.1, or 3.2 Hibernate libraries to use a newer version of cglib than they were distributed with.
I don’t know about how this affects WebStart use, but I do know that moving to the signed jars broke all my existing standalone code as well as webapps which worked before.
I am also unclear about your answer – if my findings are confirmed, would you back out to unsigned jars for at least cglib for the 6.0GA or leave it in it’s current (apparently broken) state because signed jars are such a major requirement?
I’ll help in any way I can to sort this out – I just don’t want to get to 6.0GA and have the problem not resolved.
Riyad KallaMembersprior,
I was trying to collect some info to hand back to our installer guys so they could understand why they can’t sign the JARs. Thanks for the info.
Steve PriorMemberAny response from the “installer guys”/developers on this situation? Are those specific jars going to be unsigned in 6.0GA, or is there another solution?
Riyad KallaMemberYes, cglib-2.1.3.jar and hibernate3.jar were added to the exclusion list for JARs that were getting signed, should be fixed in 6.0 GA
This will fix the issue right?
Steve PriorMemberYes, thank you.
benson_marguliesMemberI just ran into this. Is there any recipe for patching around this? I guess the obvious would be to stop using your libs and use copies I have somewhere else.
Steve PriorMemberIt may not be worth the trouble since the MyEclipse folks seem to be on the edge of releasing 6.0 – can you guys give us a hint when the releazse will happen so we’ll have an idea?
The recipe is to unjar the jarfile into a directory, edit the manifest file to remove the signer information, then rejar the file. That’ll fix you up.
benson_marguliesMemberAs a general rule, using those libs delivered inside of MyEclipse is no help to me. As my code approaches production, all the dependencies have to move to source control. So I might as well sort out the inventory of spring and hibernate jars for myself at this point.
Steve PriorMemberOk… You asked for the recipe so I gave it to you.
Assuming that your production libs are on a shared filesystem or common directory, I’d recommend that you standardize on a set of CLASSPATH variables which point to the base of where third party libs are stored. That way the developers can check the exclipse project and classpath files into source code control and another developer can check out all the code and it’ll just work. For things like Hibernate which are a set of jars, you can create a standard set of user libs which would also be portable across developers. It would be great if CLASSPATH variables could be used with custom libs, but it’s an either or feature.
In any case, once you start using your own production Hibernate libs you avoid this signing issue – you can create a new project, add hibernate capabilities, then switch the MyEclipse libs for your own in the classpath and you’re all set – I do exactly this at work all the time. It was my home development where I found the bug in the first place.
Riyad KallaMembersprior,
You are right 6.0 is on the cusp of hitting the road. Should be a quiet release this weekend I expect.
CyTGMemberdownloading and using the latest hibernate3 from hibernate.org and cglib(beta) from sourceforge did the trick for me!
-
AuthorPosts