Hi all We've been using WOInject for a few months and encountered two issues due to the classloader manipulation done at startup (the one to enable interception through javassist, in the WOInject class).
The first issue is a known Guice 2.0 bug (http://code.google.com/p/google-guice/issues/detail?id=343). This one pops up when from Guice grabs some class from another classloader that the one it was started in. In our case, it meant Guice was grabing some class from the default class loader instead of the the javassist one. It appeared in a very unexpected way: suddenly one binding was causing the whole application to break down. Finally, we had to switch to Guice 3.0, which incorporates the bug fix and avoids the issue to show up another time somewhere else. Turned out since that the woinject repo on github states "Guice 3.0" as a requirement. Was this bug the reason for it? The second issue is a security exception when trying to encrypt some file. The issue was boiled down to a classloader one again, the required class being "on the bootclasspath" instead of the current classloader (the javassist one). I append the stack trace to the end of this mail, if some one wants to have a look at it. In order to get rid of this bug, we ended removing the classloading trick and, instead, using our own _NSUtilities where we do the injector.injectMembers(newInstance) ourselves. In order to make it possible, we made sure our own version of this class came on top of the classpath provided to the application (thanks to Maven). Since it works again. What do you think of that ? Could it be done as well in WOInject ? Indeed, we were planning to use WOInject once the "WOInjectProposal" on github would have been incorporated. Personally, getting rid of classloader manipulations would be a plus IMHO. It removes a whole bunch of potential issues, from memory leaks to "classes from the wrong classloader". For sure, I may miss some good points of javassist, so I'm really eager to read you back. Alternative solutions are also welcome, but the few I could make up (using an agent instead of classloader manipulation for example) don't come for cheap neither: overall class shadowing and classpath ordering look like the less impacting option. Best, joseph The encryption error: java.lang.SecurityException: JCE cannot authenticate the provider BC at javax.crypto.Cipher.getInstance(DashoA13*..) at org.bouncycastle.openpgp.PGPEncryptedDataGenerator$PubMethod.addSessionInfo(Unknown Source) at org.bouncycastle.openpgp.PGPEncryptedDataGenerator.open(Unknown Source) at org.bouncycastle.openpgp.PGPEncryptedDataGenerator.open(Unknown Source) at com.resurgences.xdi.invs.INVSService.encryptFile(INVSService.java:1571) (...) Caused by: java.util.jar.JarException: Class is on the bootclasspath at javax.crypto.SunJCE_c.a(DashoA13*..) at javax.crypto.SunJCE_b.b(DashoA13*..) at javax.crypto.SunJCE_b.a(DashoA13*..) _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
