July 23, 2007 at 12:30 am #273024
When 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:
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.July 23, 2007 at 9:50 pm #273074
I 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.July 23, 2007 at 9:59 pm #273075
One more source of info on this issue:
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.July 24, 2007 at 12:52 pm #273122
sprior 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…July 24, 2007 at 1:04 pm #273127
Your 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.July 24, 2007 at 1:10 pm #273128
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.July 28, 2007 at 2:10 pm #273261
Any 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?July 30, 2007 at 10:38 am #273290
Yes, 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?July 30, 2007 at 10:43 am #273294
Yes, thank you.August 15, 2007 at 7:34 am #273917
I 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.August 15, 2007 at 7:49 am #273918
It 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.August 15, 2007 at 7:54 am #273919
As 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.August 15, 2007 at 10:06 am #273930
Ok… 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.August 15, 2007 at 11:37 am #273938
You are right 6.0 is on the cusp of hitting the road. Should be a quiet release this weekend I expect.August 15, 2007 at 3:03 pm #273951
downloading and using the latest hibernate3 from hibernate.org and cglib(beta) from sourceforge did the trick for me!