Joseph,
I have created a issue [1] to track this problem.
There is a new commit in the hotfix-classloading branch that tries to solve the
problem. It removes the dependency on a custom class loader. It's still very
experimental, but I would like to know if this patch solves your problem.
There is one requirement: you have to create a AppRunner class, and start your
application from it. Here is an example of a very simple runner:
public class AppRunner {
public static void main(String[] args) {
WOInject.init("your.app.Application", args);
}
}
I've deployed a new WOInject SNAPSHOT to the WOCommunity repository. Just
update to the 1.1-SNAPSHOT version in your pom to download the latest changes.
[1]https://github.com/hprange/woinject/issues/7
Cheers,
Henrique
On 07/06/2012, at 23:30, Henrique Prange wrote:
> Hi Joseph,
>
> On 06/06/2012, at 04:04, Joseph Pachod wrote:
>
>> 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).
>>
>
> You're not alone. I've faced problems because of the classloader manipulation
> too. Take a look at issue #2 [1]. I've provided a simple fix, but I know it
> is not a definitive solution.
>
>> 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?
>>
>
> In fact, I was not aware of this Guice bug until now. :)
>
> The WOInject code responsible for object instantiation was heavily inspired
> by the AssistedInject module. It requires the bind().toConstructor() method
> API added in Guice 3.0. To support Guice 2.0, WOInject would not be able to
> take advantage of the AOP support, for instance.
>
>> 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.
>>
>
> This problem seems to be related to the issue #2 mentioned above. Clearly, an
> alternative is required to the Javassist classloader to solve this problem.
>
>> 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 ?
>>
>
> Yes. It could be done. However, this solution also has some problems:
>
> 1) It doesn't scale: that is the same approach employed by Wonder. We can't
> apply this kind of solution every time, for every framework.
>
> 2) It is subject to license issues.
>
> 3) It makes the user responsible for the solution of the problem. This
> problem is an extension of the first problem. In the beginning, ERExtensions
> should come first in the classpath. Then ERFoundation and ERWebObjects were
> created and took precedence. With this solution, WOInject must come before
> those libraries.
>
> 4) I'm not sure this solution works in a JEE environment.
>
> Changing the behavior of core classes of WebObjects is a general problem that
> anyone developing WO apps/frameworks face sooner or later. IMHO, we should
> develop a common solution in Wonder, some kind of ERPatcher framework. This
> would enable us to solve long-standing problems without violating the Apple
> license and in an organized manner. I really would like to know what others
> think about it. I'm really inclined to implement this framework, as soon as I
> figure out how. :)
>
>> Indeed, we were planning to use WOInject once the "WOInjectProposal"
>> on github would have been incorporated.
>>
>
> I'm planning to add this feature in the next release. I'm really out of time
> right now, but it is in my TODO list.
>
>> 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".
>>
>
> Classloader manipulations are complicated and can have side effects. However,
> it has been widely used in Java frameworks (including Guice). I'll try to
> produce a better solution. I'll ping you as soon as I have a new version for
> testing.
>
>> 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.
>>
>
> I also would like to avoid using an agent to solve this problem. IMHO, we
> have the following alternatives:
>
> 1) A better custom classloader: the Javassist classloader is just an example
> of how to create a Classloader able to load Javassist manipulated classes. We
> can write a better one that loads only the _NSUtilities class from Javassist
> and delegates everything else to the parent classloader.
>
> 2) Loading the manipulated classes right on the System classloader: the
> manipulated _NSUtilities could be loaded directly in the System classloader
> through reflection. I don't know what are the side effects of this solution
> yet.
>
> 3) Classpath ordering: as you mentioned, avoids runtime problems at the cost
> of delegating the responsibility to the user of the library.
>
> I'll try to implement the first solution and send you a new version of
> WOInject as soon as possible.
>
> [1]https://github.com/hprange/woinject/issues/2
>
> Cheers,
>
> Henrique
_______________________________________________
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]
