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