You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Richard Schurig (JIRA)" <ji...@apache.org> on 2011/01/25 09:24:44 UTC
[jira] Created: (TAP5-1424) IOC class loading issue in OSGi
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.1.0.5, 5.2.4
Reporter: Richard Schurig
Priority: Critical
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.
-
You can reply to this email to add a comment to the issue online.
[jira] [Commented] (TAP5-1424) IOC class loading issue in OSGi
Posted by "Howard M. Lewis Ship (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: bundle.b.zip
bundle.a.zip
> 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.zip, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] [Commented] (TAP5-1424) IOC class loading issue in OSGi
Posted by "Howard M. Lewis Ship (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.b.zip)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: bundle.b-1.0.0-SNAPSHOT.jar
bundle.a-1.0.0-SNAPSHOT.jar
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] [Resolved] (TAP5-1424) IOC class loading issue in OSGi
Posted by "Howard M. Lewis Ship (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship resolved TAP5-1424.
----------------------------------------
Resolution: Incomplete
Assignee: Howard M. Lewis Ship
Incomplete: don't know if it is still a problem in 5.3.
> 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
> Assignee: Howard M. Lewis Ship
> 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
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.a.zip)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.a.zip)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.a-1.0.0-SNAPSHOT.jar)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: bundle.b.zip
bundle.a.zip
> 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.zip, 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.b-1.0.0-SNAPSHOT.jar)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.a-1.0.0-SNAPSHOT.jar)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: bundle.b-1.0.0-SNAPSHOT.jar
bundle.a-1.0.0-SNAPSHOT.jar
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.b-1.0.0-SNAPSHOT.jar)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TAP5-1424) IOC class loading issue in OSGi
Posted by "Richard Schurig (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Schurig updated TAP5-1424:
----------------------------------
Attachment: (was: bundle.b.zip)
> 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
>
> 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.
-
You can reply to this email to add a comment to the issue online.
[jira] [Resolved] (TAP5-1424) IOC class loading issue in OSGi
Posted by "Howard M. Lewis Ship (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship resolved TAP5-1424.
----------------------------------------
Resolution: Incomplete
Assignee: Howard M. Lewis Ship
Incomplete: don't know if it is still a problem in 5.3.
> 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
> Assignee: Howard M. Lewis Ship
> 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