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/forge/shell/command/Execution.java#L148

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@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/jboss/forge/scaffold/spring/SpringScaffold.java

Cheers,
Ryan
_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev



--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"