Hi, It has been a very long time since I dealt with an ear!
The apo.xml file needs to be on classpath element META-INF. For a war file, it need to be in either classes/META-INF/aop.xml or in a jar under META-INF. You will need to place apo.xml for ear under an equivalent location. Can you try this and we can go from there. -Ramnivas On Fri, Jan 7, 2011 at 11:42 AM, Andy Clement <andrew.clem...@gmail.com>wrote: > Hi Anthony, > > Your description of what might be the problem sounds correct. I'm not > an expert on the spring usage of AspectJ though, I might have to wait > for Ramnivas to chime in on this thread. > > In your first post, I got the impression that everything works as > expected even when the type cannot be found? It is only a warning > that the type cannot be found, and an Xlint warning at that (which > means it can be turned off entirely). If running via an agent, then a > META-INF/aop.xml can be setup to turn off xlints or turn off optimized > matching, but I can't say for certain how you do it in the > spring-using-aspectj case, another thing it'd be nice to hear from > Ramnivas on. in the aop.xml file you just need to set the weaver > options section: > > <weaver options="-Xset:optimizedMatching=false"/> > or > <weaver options="-Xlint:ignore"/> > > Given that it is just a warning, do you just want to run completely > clean in your environment? > > Andy > > > On 6 January 2011 17:39, Anthony Tang <aan...@yahoo.com> wrote: > > Actually, on further inspection, it looks like this is a potential > problem > > in AspectJ. ReflectionBasedRefereceTypeDelegateFactory uses a > classloader > > that is set during initialization, but this classloader is not > necessarily > > the correct one. For example, in our app, we're running two wars within > an > > ear (in jboss), and we need classloader isolation between those two > > webapps. There are some common beans in the ear so spring is initialized > at > > the ear level, which ends up setting the "usingClassLoader"in > > ReflectionBasedReferenceTypeDelegateFactory to the ear's classloader. > But > > later, when the war specific beans are initialized, this classloader does > > not have visibility to the war loaded objects, which results in this > > failure. > > > > Is my understanding of how this is working correct? > > > > Thanks. > > - Anthony > > > > > > ________________________________ > > From: Anthony Tang <aan...@yahoo.com> > > To: aspectj-users@eclipse.org > > Sent: Wed, January 5, 2011 11:02:02 AM > > Subject: Re: How to turn of "optimized matching"? > > > > Hi Andy - > > > > Thanks for the quick reply. We are doing load time weaving. How do I > > specify this option when using spring for the aop configuration? I tried > > adding an aop.xml file to the ear's META-INF/ directory, but it doesn't > seem > > to have an effect. > > > > The bug we're encountering is probably more on our side than in aspectj. > > Our custom Adaptor Factory Bean returns a Proxy, which fails to be loaded > by > > ReflectionBasedReferenceTypeDelegateFactory (line 38) which results in > the > > creation of a MissingResolvedTypeWithKnownSignature type. During > optimized > > matching, it looks like it tries to get some information from the object > (in > > KindedPointcut, line 126), but since it's a > > "MissingResolvedTypeWithKnownSignature", this results in an exception > thrown > > instead: > > > > Post-processing of the FactoryBean's object failed; nested exception is > > org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException: > warning > > can't determine modifiers of missing type $Proxy380 > > [Xlint:cantFindType] > > > > The specific problem seems to be that our custom adaptor factory bean > loads > > the proxy in a different class loader than the World is initialized with. > > The deployment consists of an ear with multiple wars, and the first war > ends > > up initializing spring/aspectj, so its classloader is the one used by the > > World, but other wars end up using a different classloader for the proxy > > object. Once the postprocessing is allowed to occur in the first war and > > the object is cached, the problem goes away. In aspectj 1.5.3, this > wasn't > > a problem, but I can't find source code to step through what it's doing > > differently. I assumed turning off the optimized matching in 1.6.9 would > > help, since that's where the above exception is coming from (plus > everything > > works after it's correctly loaded/post processed by the first war). That > > would be a quick fix while we tried to untangle the classloader problems. > > > > Thanks. > > - Anthony > > > > On 4 January 2011 21:41, Andy Clement <andrew.clem...@gmail.com> wrote: > >> Hi Anthony, > >> > >> Do you mean the optimized matching that became default in AspectJ > >> 1.6.7 onwards? (Discussed here: > >> > >> > http://andrewclement.blogspot.com/2009/11/aspectj-how-much-faster-is-aspectj-167.html > >> ). Ideally I'd like to fix any bugs so it isn't causing you an issue > >> under Spring - do you want to raise an AspectJ bug for the problem? > >> There is a configuration option for the weaver that turns it off: > >> > >> -Xset:optimizedMatching=false > >> > >> But I'm not sure where you would set that, it depends on your spring > >> configuration. I would normally set it either on the command line (if > >> compile time weaving), or in an aop.xml file (if loadtime weaving). > >> > >> cheers > >> Andy > >> > >> On 4 January 2011 18:40, Anthony Tang <aan...@yahoo.com> wrote: > >> > Hi - > >> > > >> > I am having a problem with optimized matching specific to a custom > >> > Adaptor > >> > Factor Bean I have in Spring.? While trying to figure that out, it > looks > >> > like I can get around it by turning off "optimized matching", but I > >> > can't > >> > find documentation on how to specify these configurations. > >> > > >> > How do I specify an option to the JVM so that aspectj turns off > >> > optimized > >> > matching?? I am running a web application deployed as an EAR in JBoss. > >> > > >> > Thanks! > >> > > >> > _______________________________________________ > >> > aspectj-users mailing list > >> > aspectj-users@eclipse.org > >> > https://dev.eclipse.org/mailman/listinfo/aspectj-users > >> > > >> > > > _______________________________________________ > > aspectj-users mailing list > > aspectj-users@eclipse.org > > https://dev.eclipse.org/mailman/listinfo/aspectj-users > > > > > _______________________________________________ > aspectj-users mailing list > aspectj-users@eclipse.org > https://dev.eclipse.org/mailman/listinfo/aspectj-users >
_______________________________________________ aspectj-users mailing list aspectj-users@eclipse.org https://dev.eclipse.org/mailman/listinfo/aspectj-users
