This surprises me, since SpringProvider's ClassLoader should already be the
current classloader:
https://github.com/forge/core/blob/master/shell/src/main/java/org/jboss/f...
AHA! But since this is actually being executed from the ScaffoldPlugin,
which is BUILT IN, the classloader is actually still that of the
scaffold-impl (ScaffoldPlugin) - Ok. This means that we need an internal
utility to wrap external invocations in a new TCCL.
https://issues.jboss.org/browse/FORGE-487
~Lincoln
On Fri, Mar 2, 2012 at 10:43 AM, Ryan Bradley <rbradley(a)redhat.com> wrote:
On 03/02/2012 01:12 AM, Richard Kennard wrote:
> 5. Class loading: getClass().getResourceAsStream() works differently
depending on which JAR the class was loaded from. So for example the
> getClass().getResourceAsStream() that lives inside metawidget.jar
couldn't see the resources that were declared in my plugin.jar
Richard,
I've experienced this ClassLoader problem with my plugin as well. The
solution thus far has been to force the current thread to use of the
ScaffoldProvider's ClassLoader in the generateFromEntity() method. That
is, save the current thread's ClassLoader at the beginning of the
method, encapsulate the rest of the method in a try block (changing the
thread's class loader to that of the ScaffoldProvider), and add a
finally block which restores the original class loader.
The code can be found here:
https://github.com/forge/plugin-spring-mvc/blob/master/src/main/java/org/...
Cheers,
Ryan
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"