[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [aspectj-users] RE: RE: keeping aop.xml in system class path and aspect classes in a child class loader for LTW?
|
Great to hear that worked for me.
-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of sandesh g
Sent: Wednesday, August 29, 2007 6:03 AM
To: aspectj-users@xxxxxxxxxxx
Subject: [aspectj-users] RE: RE: keeping aop.xml in system class path and
aspect classes in a child class loader for LTW?
HI RON,
Thnax a lot :)
As you suggested I kept aop1.xml file in conf folder of my application (file
in system classpath)
in which I could mention the aspects to be excluded while loadtime weaving.
And aop2.xml (second aop xml) which contains the list of all aspects is
bundled within jar file. This worked perfectly for me as I wanted to turn on
or off aspects selectively without redeploying my ear.
Regards,
Sandesh.
Ron Bodkin wrote:
>
> 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: aspectj-users-bounces@xxxxxxxxxxx
> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of sandesh g
> Sent: Monday, August 27, 2007 3:31 AM
> To: aspectj-users@xxxxxxxxxxx
> 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: aspectj-users-bounces@xxxxxxxxxxx
>> [mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of sandesh g
>> Sent: Friday, August 24, 2007 6:16 AM
>> To: aspectj-users@xxxxxxxxxxx
>> 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
>> aspectj-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@xxxxxxxxxxx
>> 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
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> 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#a12386649
Sent from the AspectJ - users mailing list archive at Nabble.com.
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
