I was wondering why GenericAspectFactory uses the thread context class loader
by default to load aspect classes?
| public Class getClazz()
| {
| ....
| {
| clazz =
Thread.currentThread().getContextClassLoader().loadClass(classname);
| }
| catch (ClassNotFoundException e)
| ....
| }
|
This is causing me some trouble when I deploy an MDB that needs to use a scoped
Messaging instance (and there can only be a scoped Messaging instance with
JBoss 4.x), because the MDB deployment is done by a "ScannerThread" whose
thread context class loader is a UCL associated with the main loader
repository. This UCL cannot access scoped Messaging interceptor classes and the
MDB deployment fails with ClassNotFoundException.
I fixed this by temporarily replacing the ScannerThread's (and any thread's
that touches the AOP stack during deployment) context class loader during
deployment, but I don't like at all this solution since I don't know what else
this may break due to lateral effects.
How about allowing for a pluggable classloader to use for aspect loading?
An AspectXmlLoader.deployXML(Document, URL, ClassLoader) method would help me.
Does this make sense?
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3914007#3914007
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3914007
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
JBoss-user mailing list
JBoss-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-user
