WOInject: harmed twice by classloader manipulation
WOInject: harmed twice by classloader manipulation
- Subject: WOInject: harmed twice by classloader manipulation
- From: Joseph Pachod <email@hidden>
- Date: Wed, 06 Jun 2012 09:04:23 +0200
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden