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

[Andy Clement <andrew.clement@xxxxxxxxx>]

That is a shame that it surfaces the warning as an exception.

AspectJ does a lot of type analysis to work out what does and does not
match a pointcut.  Sometimes the types it can't find don't matter
because they would not lead to valid matches.  This is why
cantFindType is a configurable warning - if you really don't think it
matters then you can turn it off.  This is why I asked if your app was
working fine - if it is then perhaps you can ignore this problem (turn
it off).  If only we could work out where to put the aop.xml so that
it gets picked up...

The more recent versions of AspectJ walk the type structure
differently than they used to - which could be the difference between
an old 1.5.3 and a recent 1.6.9 release (actually this change occurred
in 1.6.7 so if you tried 1.6.6 that might be interesting).  Perhaps
with 1.5.3 when a different route is taken, another type is reached
sooner that eliminates the need to search any further (and so the
problematic type isn't reached).  I remember some list discussion a
while back about enhancing the search algorithm so that when it hits a
missing type, it searches for others that would definetly cause the
join point to match or not match, before producing an error that it
really needs to know about a missing type - but that work isn't on the
radar just yet.

Andy

On 7 January 2011 14:44, Anthony Tang <aant00@xxxxxxxxx> wrote:
> Hi Andy/Ramnivas -
>
> Unfortunately, it does not seem to be just a warning, as it ends up throwing
> an Exception up.  Are you suggesting we can ignore this exception?
>
> ERROR [org.apache.catalina.core.ContainerBase] Servlet.service() for servlet
> jsp threw exception
> 'org.aspectj.weaver.reflect.ReflectionWorld$ReflectionWorldException:
> warning can't determine modifiers of missing type $Proxy363
>  [Xlint:cantFindType]
>
> I did add an aop.xml in the META-INF of the ear, but it doesn't seem to be
> picked up.
>
> Thanks.
> - Anthony
>
>
> Date: Fri, 7 Jan 2011 11:42:03 -0800
> From: Andy Clement <andrew.clement@xxxxxxxxx>
> To: aspectj-users@xxxxxxxxxxx
> Subject: Re: [aspectj-users] How to turn of "optimized matching"?
> Message-ID:
>     <AANLkTinT1q-bHvSu7d-dvHjhEtB30WhT_AUSL1exEfe_@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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
>
>