Re: [aspectj-users] How to turn of "optimized matching"?

[Ramnivas Laddad <ramnivas@xxxxxxxxxxxx>]

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.clement@xxxxxxxxx> 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 <aant00@xxxxxxxxx> 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 <aant00@xxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> 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.clement@xxxxxxxxx> 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 <aant00@xxxxxxxxx> 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@xxxxxxxxxxx
>> > https://dev.eclipse.org/mailman/listinfo/aspectj-users
>> >
>> >
> _______________________________________________
> 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