Hi Sandesh, That's why I proposed using 2 aop.xml files. The one that lists the aspects themselves can and should be bundled with the aspect classes in its jar file. Any other configuration of aop.xml can and probably should be done in an external xml file that's visible to the loader, e.g., in your case on the system classpath. Note that you can disable aspects that are listed in the aop.xml file that's in your jar file, so you don't even have to use all of the aspects that are contained in it. I think that should meet your needs. I'd suggest you use -outxml with the compiler to generate that list of classes and then write an aop.xml file that just doesn't list any aspects. That's the right way to do this.
>From a technical standpoint, it's not sensible to define aspects in a classloader that doesn't have the class definitions visible, so I don't see how the current policy would be changed. I don't think there's a workaround, although I think my proposal would meet your needs. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of sandesh g Sent: Monday, August 27, 2007 3:31 AM To: [email protected] Subject: [aspectj-users] RE: keeping aop.xml in system class path and aspect classes in a child class loader for LTW? Thanx Ron, But the reason, we want to keep aop.xml in system classpath is because then we can keep it in our 'conf' folder which is in system classpath and thus it is easily modifiable. Once it is bundled within an EAR, modifying it becomes very difficult because in production scenario redeploying an EAR is very rare. Usually Class loading policy is 'parent-first', which means ask the parent class loader first, if not found only then try to load it in current. Is there any way or workaround to make AspectJ follow this policy for loading 'aop.xml' file (and may be even aspect classes)? Or is there any way to tell aspectj that aop.xml is to be loaded from specified classloader? Thanks in advance. Sandesh Ron Bodkin wrote: > > This is as expected: if you include an aspect in an aop.xml file, the > class > file for it needs to be visible to the class loader that included the > file. > You could put the aop.xml file in the jar file that is included in your > ear > to avoid this problem. You could also include a top-level aop.xml file > that > controls system-wide weaving properties but doesn't list the aspects, and > just include a listing of aspects (e.g., from the -outxml compiler option) > in the child loader. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of sandesh g > Sent: Friday, August 24, 2007 6:16 AM > To: [email protected] > Subject: [aspectj-users] keeping aop.xml in system class path and aspect > classes in a child class loader for LTW? > > > Hi All, > I have my aop.xml in system classpath for LTW, so it is getting loaded by > SystemClassLoader But my aspectj classes are bundled in a jar file which > is > in my applications's ear file. So these classes are getting loaded by > EARClassLoader (child of System CL). The problem is that when I start my > app > server, javaagent is able to find this aop.xml file, but it prints > following > exceptions(copying a small piece of exceptions below). Looks like the > weaver > can't find aspect classes. Is it because aop.xml is in system class loader > and my aspect classes (those generated from .aj files) are in a EAR class > loader (which is child of system CL)? I purposefully want to keep aop.xml > in > system class path; is there any way out? > > Thanks in advance, > Sandesh > > savvion.sbm.bizlogic.aspects.BizLogicDAO > Cannot register non aspect: com$savvion$sbm$bizlogic$aspects$BizLogicDAO , > com.s > avvion.sbm.bizlogic.aspects.BizLogicDAO > java.lang.RuntimeException: Cannot register non aspect: > com$savvion$sbm$bizlogic > $aspects$BizLogicDAO , com.savvion.sbm.bizlogic.aspects.BizLogicDAO > at > org.aspectj.weaver.bcel.BcelWeaver.addLibraryAspect(BcelWeaver.java:2 > 05) > at > org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerAspects > (ClassLoaderWeavingAdaptor.java:399) > at > org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerDefinit > ions(ClassLoaderWeavingAdaptor.java:240) > at > org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(Clas > sLoaderWeavingAdaptor.java:152) > at > org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavin > gAdaptor.initialize(Aj.java:151) > at > org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavin > gAdaptor.getWeavingAdaptor(Aj.java:156) > at > org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:122) > > at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:73) > at > org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(C > lassPreProcessorAgentAdapter.java:55) > at > sun.instrument.TransformerManager.transform(TransformerManager.java:1 > 22) > at > sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java > :155) > at java.lang.reflect.Proxy.defineClass0(Native Method) > at java.lang.reflect.Proxy.getProxyClass(Proxy.java:487) > at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:564) > at > com.pramati.jms.server.PramatiMessageService.initializeProxyServer(Pr > amatiMessageService.java:724) > at > com.pramati.jms.server.PramatiMessageService.initializeRMINonSecureCo > nnectionRetryTransport(PramatiMessageService.java:806) > at > com.pramati.jms.server.PramatiMessageService.startJMSService(PramatiM > essageService.java:694) > at > com.pramati.jms.server.PramatiMessageService.start(PramatiMessageServ > ice.java:236) > at > com.pramati.services.framework.kernel.LifeCycleManager.startService(L > ifeCycleManager.java:198) > at > com.pramati.services.framework.kernel.LifeCycleManager.startServices( > LifeCycleManager.java:106) > at > com.pramati.services.framework.kernel.LifeCycleManager.startServices( > LifeCycleManager.java:115) > at > com.pramati.services.framework.kernel.LifeCycleManager.startServices( > LifeCycleManager.java:115) > at > com.pramati.services.framework.kernel.ServerKernelImpl.startServices( > ServerKernelImpl.java:405) > at > com.pramati.services.framework.kernel.ServerKernelImpl.access$000(Ser > verKernelImpl.java:70) > at > com.pramati.services.framework.kernel.ServerKernelImpl$1.run(ServerKe > rnelImpl.java:289) > at > com.pramati.security.util.JAASSecurityHelper.doAs(JAASSecurityHelper. > java:156) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. > java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces > sorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > com.pramati.services.security.spi.SecurityHelper.doAs(SecurityHelper. > java:142) > at > com.pramati.services.framework.kernel.ServerKernelImpl.start(ServerKe > rnelImpl.java:284) > at com.pramati.Server.startKernel(Server.java:313) > at com.pramati.Server.start(Server.java:225) > at com.pramati.Server.main(Server.java:888) > > -- > View this message in context: > http://www.nabble.com/keeping-aop.xml-in-system-class-path-and-aspect-classe > s-in-a-child-class-loader-for-LTW--tf4323522.html#a12312226 > Sent from the AspectJ - users mailing list archive at Nabble.com. > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > _______________________________________________ > aspectj-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > -- View this message in context: http://www.nabble.com/keeping-aop.xml-in-system-class-path-and-aspect-classe s-in-a-child-class-loader-for-LTW--tf4323522.html#a12344671 Sent from the AspectJ - users mailing list archive at Nabble.com. _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users _______________________________________________ aspectj-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/aspectj-users
