[
https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13130133#comment-13130133
]
Howard M. Lewis Ship commented on TAP5-1424:
--------------------------------------------
This may work correctly under 5.3; the new PlasticClassLoader (part of plastic,
replacing Javassist with ASM) does not have all the characteristics your
describe as causing problems.
I'm going to close the issue; you can retest with a recent beta (say
5.3-beta-24) and re-open if the issue is still present.
> IOC class loading issue in OSGi
> -------------------------------
>
> Key: TAP5-1424
> URL: https://issues.apache.org/jira/browse/TAP5-1424
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-ioc
> Affects Versions: 5.2.4, 5.1.0.5
> Reporter: Richard Schurig
> Priority: Critical
> Attachments: bundle.a-1.0.0-SNAPSHOT.jar, bundle.a.zip,
> bundle.b-1.0.0-SNAPSHOT.jar, bundle.b.zip
>
>
> we're using Tapestry IOC in an OSGi environment (Equinox 3.4) and recently
> discovered some serious class loading issues when installing multiple
> versions of the Tapestry Jars (5.1.0.5 and 5.2.4).
> the problem itself lies in the class ClassFactoryClassPool, which picks up
> every class loader from every class it ever sees. this completely bypasses
> the OSGi way of class loading!
> see the 2 attached bundles for an example: bundle A is using T5.1 and bundle
> B is using T5.2. but B is also using imports from A for implementing a
> service, an every day scenario in OSGi. now what happens: the IOC registry
> starting in bundle B is proxying some class in its bundle, which has
> references to a class in A. this results in ClassFactoryClassPool picking up
> the class loader of bundle A also and therefore seeing all T5.1 classes. so
> you end up with two Tap versions in allLoaders, and it's just a matter of
> timing, if you have a working sequence in the chain.
> i managed to produce a non working sequence that raises an exception:
> Caused by: compile error: getCoercion(java.lang.Class,java.lang.Class) not
> found in org.apache.tapestry5.ioc.services.TypeCoercer
> this happens because the T5.1 classes are picked instead of T5.2 in bundle B
> and getCoercion did not exist in that version. but T5.1 should not be visible
> to bundle B since it neither includes nor imports its classes.
> the solution seems to be just using the thread context class loader, which
> (properly set) provides all the classes needed by IOC, at least in OSGi. i
> tested the solution by modifying ClassFactoryClassPool like that:
> public ClassFactoryClassPool(ClassLoader contextClassLoader)
> {
> super(null);
> ClassPath path = new LoaderClassPath(contextClassLoader);
> insertClassPath(path);
> }
> public synchronized void addClassLoaderIfNeeded(ClassLoader loader)
> {
> // Just do nothing
> }
> This worked for me: in the first place a lot of "ClassNotFoundExceptions"
> occurred, revealing all the classes that we're accessible by bypassing the
> OSGi bundle class Loader, but after adding them to the imports of my bundle,
> everything was fine.
> as i did not understand the purpose of the sophisticated class loader
> handling, i assume that the above is not a fix option. but maybe some kind of
> switch can be implemented, that turns off class loader collecting on demand.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
