Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Eric B]

Is my syntax for exclusion incorrect though?  It doesn't seem to be
working.  I added:


   
   
   



But I still see the aspect being rewritten (and reverted) in the _ajdump
folder.   However, if i explicitly set the exclude to the full package name:

   

it works fine.

Is my exclusion syntax by Annotation name incorrect?  Do I need to specify
a fully-qualified annotation name (ie:
 )?

Thanks,

Eric







On Thu, Jun 14, 2018 at 11:21 AM Andy Clement 
wrote:

> I added a bug yesterday
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=535877 with my minimal test
> code in. Basically annotation style just hasn't got equal test coverage
> with code style so we are going to hit things like this occasionally.
> Excluding via @Aspect annotation is quite a clever workaround :)
>
> Andy
>
> On 13 June 2018 at 19:02, Eric B  wrote:
>
>> I have worked around the issue by adding it to an  in the
>>  tag, but I was a bit surprised I had to do that.  Reading your
>> explanation now, makes it a little more clear.
>>
>> I tend to prefer annotation style aspects, simply because, in general,
>> most other people who need to maintain the codebase are not very versed in
>> aspect programming, and I don't want to introduce yet another syntax to the
>> code.  I guess for now, I'll just leave it in the  although it
>> might be more interesting to see if I can exclude it by type instead of by
>> class name.  I'm guessing I could simply exclude it by the @Aspect
>> annotation?
>>
>> 
>>
>> Do I need to file a bug for this?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Wed, Jun 13, 2018 at 4:08 PM, Andy Clement 
>> wrote:
>>
>>> I did just recreate this, I suspect one reason is hasn’t shown up before
>>> is because we don’t typically use annotation style aspects in test cases.
>>> If your aspect is annotation style and not code style you will see the
>>> aspectOf() issue.  I originally wrote mine as code style (the CTW aspect) -
>>> everything fine. The minute I switched it to annotation style, exactly the
>>> same problem as you.
>>>
>>> Andy
>>>
>>>
>>> On Jun 13, 2018, at 12:43 PM, Andy Clement 
>>> wrote:
>>>
>>> Let me try to interpret this from what I remember:
>>>
>>>
>>> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982]
>>> debug weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
>>> info processing reweavable type
>>> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
>>> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
>>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
>>> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>>> woven into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>>> must be defined to the weaver (placed
>>> on the aspectpath, or defined in an aop.xml file if using LTW).
>>>
>>>
>>>
>>> That suggests to me the weaver has encountered a type that *might* be a
>>> candidate for modification (ClientErrorExceptionHandler) - per
>>> http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
>>> ‘weaving
>>> XXX’ doesn’t mean XXX is being modified, it just means the weaver is
>>> looking at it (terrible message, needs improvement) - and since you have
>>> weave info on then if something about it matched a pointcut you’d see a
>>> weave info message.
>>>
>>> Looking at the reweavable state is fine but maybe it isn’t currently
>>> smart enough to make the distinction that it doesn’t matter that the
>>> ClientErrorExceptionHandler isn’t on the aspect path because none of the
>>> new aspects are matching it - I honestly can’t recall how that situation is
>>> handled and would need to dig through the code. I’m surprised if that is
>>> the case, but it could be. The fact that there is an error is probably why
>>> the resultant system doesn’t work, once the error happens all bets are off.
>>>
>>> What I’d try for experiments:
>>> - stick ClientErrorExceptionHandler on the aspect path. This means it
>>> can be found by reweaving processing - is it all good now?
>>> - include an exclude in the weaver XML for that
>>> ClientErrorExceptionHandler - if excluding it entirely is the reweavable
>>> state ignored?
>>> - run with overweaving on - should avoid reweavable processing.
>>>
>>> I’m not saying there isn’t a problem here just collecting more data
>>> points and looking at possible workarounds,
>>>
>>> cheers,
>>> Andy
>>>
>>>
>>> On Jun 12, 2018, at 8:42 AM, Eric B  wrote:
>>>
>>> Thanks for the link Andy.  I read through the overweaving description,
>>> and I agree that it doesn't sound like it applies.
>>>
>>> The aspect missing the aspectOf() is part of the CTW.  All Aspects are
>>> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW
>>> aspects, everything runs smoothly; all I have done was add in an additional
>>> jar with CTW aspect/classes.  The LTW still seems to be working, 

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

I added a bug yesterday
https://bugs.eclipse.org/bugs/show_bug.cgi?id=535877 with
my minimal test code in. Basically annotation style just hasn't got equal
test coverage with code style so we are going to hit things like this
occasionally. Excluding via @Aspect annotation is quite a clever workaround
:)

Andy

On 13 June 2018 at 19:02, Eric B  wrote:

> I have worked around the issue by adding it to an  in the
>  tag, but I was a bit surprised I had to do that.  Reading your
> explanation now, makes it a little more clear.
>
> I tend to prefer annotation style aspects, simply because, in general,
> most other people who need to maintain the codebase are not very versed in
> aspect programming, and I don't want to introduce yet another syntax to the
> code.  I guess for now, I'll just leave it in the  although it
> might be more interesting to see if I can exclude it by type instead of by
> class name.  I'm guessing I could simply exclude it by the @Aspect
> annotation?
>
> 
>
> Do I need to file a bug for this?
>
> Thanks,
>
> Eric
>
>
> On Wed, Jun 13, 2018 at 4:08 PM, Andy Clement 
> wrote:
>
>> I did just recreate this, I suspect one reason is hasn’t shown up before
>> is because we don’t typically use annotation style aspects in test cases.
>> If your aspect is annotation style and not code style you will see the
>> aspectOf() issue.  I originally wrote mine as code style (the CTW aspect) -
>> everything fine. The minute I switched it to annotation style, exactly the
>> same problem as you.
>>
>> Andy
>>
>>
>> On Jun 13, 2018, at 12:43 PM, Andy Clement 
>> wrote:
>>
>> Let me try to interpret this from what I remember:
>>
>>
>> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982]
>> debug weaving 'org.webapp.sso.keycloak.aspec
>> t.ClientErrorExceptionHandler'
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
>> info processing reweavable type 
>> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
>> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
>> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>> woven into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>> must be defined to the weaver (placed
>> on the aspectpath, or defined in an aop.xml file if using LTW).
>>
>>
>>
>> That suggests to me the weaver has encountered a type that *might* be a
>> candidate for modification (ClientErrorExceptionHandler) - per
>> http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
>> ‘weaving
>> XXX’ doesn’t mean XXX is being modified, it just means the weaver is
>> looking at it (terrible message, needs improvement) - and since you have
>> weave info on then if something about it matched a pointcut you’d see a
>> weave info message.
>>
>> Looking at the reweavable state is fine but maybe it isn’t currently
>> smart enough to make the distinction that it doesn’t matter that the
>> ClientErrorExceptionHandler isn’t on the aspect path because none of the
>> new aspects are matching it - I honestly can’t recall how that situation is
>> handled and would need to dig through the code. I’m surprised if that is
>> the case, but it could be. The fact that there is an error is probably why
>> the resultant system doesn’t work, once the error happens all bets are off.
>>
>> What I’d try for experiments:
>> - stick ClientErrorExceptionHandler on the aspect path. This means it can
>> be found by reweaving processing - is it all good now?
>> - include an exclude in the weaver XML for that
>> ClientErrorExceptionHandler - if excluding it entirely is the reweavable
>> state ignored?
>> - run with overweaving on - should avoid reweavable processing.
>>
>> I’m not saying there isn’t a problem here just collecting more data
>> points and looking at possible workarounds,
>>
>> cheers,
>> Andy
>>
>>
>> On Jun 12, 2018, at 8:42 AM, Eric B  wrote:
>>
>> Thanks for the link Andy.  I read through the overweaving description,
>> and I agree that it doesn't sound like it applies.
>>
>> The aspect missing the aspectOf() is part of the CTW.  All Aspects are
>> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW
>> aspects, everything runs smoothly; all I have done was add in an additional
>> jar with CTW aspect/classes.  The LTW still seems to be working, although I
>> would have to do more in-depth tests to validate that they are still being
>> triggered where they need to be.
>>
>> My application is running under JBoss EAP 7/Wildfly 10, so I'm honestly
>> not entirely sure if they are all using the same classloader.  Given that
>> the CTW classes are in the ear/lib folder, as are the LTW aspects (both
>> jars are found in ear/lib), I suspect that they both are in the same
>> classloader, but I'm really not sure.  I know that WF has done a lot of
>> work, separating classloaders by module (so that the different modules in
>> 

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Eric B]

I have worked around the issue by adding it to an  in the 
tag, but I was a bit surprised I had to do that.  Reading your explanation
now, makes it a little more clear.

I tend to prefer annotation style aspects, simply because, in general, most
other people who need to maintain the codebase are not very versed in
aspect programming, and I don't want to introduce yet another syntax to the
code.  I guess for now, I'll just leave it in the  although it
might be more interesting to see if I can exclude it by type instead of by
class name.  I'm guessing I could simply exclude it by the @Aspect
annotation?



Do I need to file a bug for this?

Thanks,

Eric


On Wed, Jun 13, 2018 at 4:08 PM, Andy Clement 
wrote:

> I did just recreate this, I suspect one reason is hasn’t shown up before
> is because we don’t typically use annotation style aspects in test cases.
> If your aspect is annotation style and not code style you will see the
> aspectOf() issue.  I originally wrote mine as code style (the CTW aspect) -
> everything fine. The minute I switched it to annotation style, exactly the
> same problem as you.
>
> Andy
>
>
> On Jun 13, 2018, at 12:43 PM, Andy Clement 
> wrote:
>
> Let me try to interpret this from what I remember:
>
>
> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982]
> debug weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
> info processing reweavable type 
> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982]
> error aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> woven into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> must be defined to the weaver (placed
> on the aspectpath, or defined in an aop.xml file if using LTW).
>
>
>
> That suggests to me the weaver has encountered a type that *might* be a
> candidate for modification (ClientErrorExceptionHandler) - per
> http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
> ‘weaving
> XXX’ doesn’t mean XXX is being modified, it just means the weaver is
> looking at it (terrible message, needs improvement) - and since you have
> weave info on then if something about it matched a pointcut you’d see a
> weave info message.
>
> Looking at the reweavable state is fine but maybe it isn’t currently smart
> enough to make the distinction that it doesn’t matter that the
> ClientErrorExceptionHandler isn’t on the aspect path because none of the
> new aspects are matching it - I honestly can’t recall how that situation is
> handled and would need to dig through the code. I’m surprised if that is
> the case, but it could be. The fact that there is an error is probably why
> the resultant system doesn’t work, once the error happens all bets are off.
>
> What I’d try for experiments:
> - stick ClientErrorExceptionHandler on the aspect path. This means it can
> be found by reweaving processing - is it all good now?
> - include an exclude in the weaver XML for that
> ClientErrorExceptionHandler - if excluding it entirely is the reweavable
> state ignored?
> - run with overweaving on - should avoid reweavable processing.
>
> I’m not saying there isn’t a problem here just collecting more data points
> and looking at possible workarounds,
>
> cheers,
> Andy
>
>
> On Jun 12, 2018, at 8:42 AM, Eric B  wrote:
>
> Thanks for the link Andy.  I read through the overweaving description, and
> I agree that it doesn't sound like it applies.
>
> The aspect missing the aspectOf() is part of the CTW.  All Aspects are
> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW
> aspects, everything runs smoothly; all I have done was add in an additional
> jar with CTW aspect/classes.  The LTW still seems to be working, although I
> would have to do more in-depth tests to validate that they are still being
> triggered where they need to be.
>
> My application is running under JBoss EAP 7/Wildfly 10, so I'm honestly
> not entirely sure if they are all using the same classloader.  Given that
> the CTW classes are in the ear/lib folder, as are the LTW aspects (both
> jars are found in ear/lib), I suspect that they both are in the same
> classloader, but I'm really not sure.  I know that WF has done a lot of
> work, separating classloaders by module (so that the different modules in
> an EAR each have different classloaders), but I suspect there must be a
> common one for all classes in the ear/lib folder.
>
> All that being said, I enabled the aspectj dumper with the beforeandafter
> option:
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
>
> and interestingly enough, in the _before folder, I see the problematic
> Aspect class properly woven, but in the after class, it reappears in its
> original non-woven form.  As the LTW overweaver has reverted the class.
> And 

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

I did just recreate this, I suspect one reason is hasn’t shown up before is 
because we don’t typically use annotation style aspects in test cases. If your 
aspect is annotation style and not code style you will see the aspectOf() 
issue.  I originally wrote mine as code style (the CTW aspect) - everything 
fine. The minute I switched it to annotation style, exactly the same problem as 
you.

Andy

> On Jun 13, 2018, at 12:43 PM, Andy Clement  wrote:
> 
> Let me try to interpret this from what I remember:
> 
> 
>> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
>> weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] info 
>> processing reweavable type 
>> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler: 
>> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
>> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] error 
>> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
>> into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' must be 
>> defined to the weaver (placed
>> on the aspectpath, or defined in an aop.xml file if using LTW).
> 
> 
> That suggests to me the weaver has encountered a type that might be a 
> candidate for modification (ClientErrorExceptionHandler) - per 
> http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
>  
> ‘weaving XXX’ doesn’t mean XXX is being modified, it just means the weaver is 
> looking at it (terrible message, needs improvement) - and since you have 
> weave info on then if something about it matched a pointcut you’d see a weave 
> info message.
> 
> Looking at the reweavable state is fine but maybe it isn’t currently smart 
> enough to make the distinction that it doesn’t matter that the 
> ClientErrorExceptionHandler isn’t on the aspect path because none of the new 
> aspects are matching it - I honestly can’t recall how that situation is 
> handled and would need to dig through the code. I’m surprised if that is the 
> case, but it could be. The fact that there is an error is probably why the 
> resultant system doesn’t work, once the error happens all bets are off.
> 
> What I’d try for experiments:
> - stick ClientErrorExceptionHandler on the aspect path. This means it can be 
> found by reweaving processing - is it all good now?
> - include an exclude in the weaver XML for that ClientErrorExceptionHandler - 
> if excluding it entirely is the reweavable state ignored?
> - run with overweaving on - should avoid reweavable processing.
> 
> I’m not saying there isn’t a problem here just collecting more data points 
> and looking at possible workarounds,
> 
> cheers,
> Andy
> 
> 
>> On Jun 12, 2018, at 8:42 AM, Eric B > > wrote:
>> 
>> Thanks for the link Andy.  I read through the overweaving description, and I 
>> agree that it doesn't sound like it applies.
>> 
>> The aspect missing the aspectOf() is part of the CTW.  All Aspects are 
>> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW 
>> aspects, everything runs smoothly; all I have done was add in an additional 
>> jar with CTW aspect/classes.  The LTW still seems to be working, although I 
>> would have to do more in-depth tests to validate that they are still being 
>> triggered where they need to be.
>> 
>> My application is running under JBoss EAP 7/Wildfly 10, so I'm honestly not 
>> entirely sure if they are all using the same classloader.  Given that the 
>> CTW classes are in the ear/lib folder, as are the LTW aspects (both jars are 
>> found in ear/lib), I suspect that they both are in the same classloader, but 
>> I'm really not sure.  I know that WF has done a lot of work, separating 
>> classloaders by module (so that the different modules in an EAR each have 
>> different classloaders), but I suspect there must be a common one for all 
>> classes in the ear/lib folder.
>> 
>> All that being said, I enabled the aspectj dumper with the beforeandafter 
>> option:
>> 
>> 
>>  
>>  
>>  > />
>>  
>>  > />
>>  
>>  
>>  
>>  
>> 
>> 
>> and interestingly enough, in the _before folder, I see the problematic 
>> Aspect class properly woven, but in the after class, it reappears in its 
>> original non-woven form.  As the LTW overweaver has reverted the class.  And 
>> even more interesting, I cannot seem to find the pointcut in my LTW aspects 
>> that would have picked out this class in the first place.  Most of my 
>> pointcuts are "execution" pointcuts pointing to completely different pkgs.  
>> There are a couple of "call" pointcuts as well as one cflow(), but in all 
>> cases, none should be picking out this Aspect.
>> 
>> If I check the server.log file, I see the following being logged, which 

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

Let me try to interpret this from what I remember:


> 2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982] debug 
> weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] info 
> processing reweavable type 
> org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler: 
> org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
> 2018-06-12 10:21:52,093 ERROR [stderr]   [ModuleClassLoader@2d758982] error 
> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
> into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' must be 
> defined to the weaver (placed
> on the aspectpath, or defined in an aop.xml file if using LTW).


That suggests to me the weaver has encountered a type that might be a candidate 
for modification (ClientErrorExceptionHandler) - per 
http://andrewclement.blogspot.com/2009/02/load-time-weaving-basics.html 
 
‘weaving XXX’ doesn’t mean XXX is being modified, it just means the weaver is 
looking at it (terrible message, needs improvement) - and since you have weave 
info on then if something about it matched a pointcut you’d see a weave info 
message.

Looking at the reweavable state is fine but maybe it isn’t currently smart 
enough to make the distinction that it doesn’t matter that the 
ClientErrorExceptionHandler isn’t on the aspect path because none of the new 
aspects are matching it - I honestly can’t recall how that situation is handled 
and would need to dig through the code. I’m surprised if that is the case, but 
it could be. The fact that there is an error is probably why the resultant 
system doesn’t work, once the error happens all bets are off.

What I’d try for experiments:
- stick ClientErrorExceptionHandler on the aspect path. This means it can be 
found by reweaving processing - is it all good now?
- include an exclude in the weaver XML for that ClientErrorExceptionHandler - 
if excluding it entirely is the reweavable state ignored?
- run with overweaving on - should avoid reweavable processing.

I’m not saying there isn’t a problem here just collecting more data points and 
looking at possible workarounds,

cheers,
Andy


> On Jun 12, 2018, at 8:42 AM, Eric B  wrote:
> 
> Thanks for the link Andy.  I read through the overweaving description, and I 
> agree that it doesn't sound like it applies.
> 
> The aspect missing the aspectOf() is part of the CTW.  All Aspects are 
> annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW 
> aspects, everything runs smoothly; all I have done was add in an additional 
> jar with CTW aspect/classes.  The LTW still seems to be working, although I 
> would have to do more in-depth tests to validate that they are still being 
> triggered where they need to be.
> 
> My application is running under JBoss EAP 7/Wildfly 10, so I'm honestly not 
> entirely sure if they are all using the same classloader.  Given that the CTW 
> classes are in the ear/lib folder, as are the LTW aspects (both jars are 
> found in ear/lib), I suspect that they both are in the same classloader, but 
> I'm really not sure.  I know that WF has done a lot of work, separating 
> classloaders by module (so that the different modules in an EAR each have 
> different classloaders), but I suspect there must be a common one for all 
> classes in the ear/lib folder.
> 
> All that being said, I enabled the aspectj dumper with the beforeandafter 
> option:
> 
> 
>   
>   
>/>
>   
>/>
>   
>   
>   
>   
> 
> 
> and interestingly enough, in the _before folder, I see the problematic Aspect 
> class properly woven, but in the after class, it reappears in its original 
> non-woven form.  As the LTW overweaver has reverted the class.  And even more 
> interesting, I cannot seem to find the pointcut in my LTW aspects that would 
> have picked out this class in the first place.  Most of my pointcuts are 
> "execution" pointcuts pointing to completely different pkgs.  There are a 
> couple of "call" pointcuts as well as one cflow(), but in all cases, none 
> should be picking out this Aspect.
> 
> If I check the server.log file, I see the following being logged, which I 
> don't particularly understand:
> 2018-06-12 10:21:51,708 ERROR [stderr]   [ModuleClassLoader@2d758982] info 
> processing reweavable type 
> org.webapp.sso.keycloak.administration.SessionAdministrationImpl: 
> org\webapp.sso\keycloak\administration\SessionAdministrationImpl.java
> 2018-06-12 10:21:51,711 ERROR [stderr]   [ModuleClassLoader@2d758982] error 
> aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven 
> into 'org.webapp.sso.keycloak.administration.SessionAdministrationImpl' must 
> be defined to the weaver (p
> laced on the aspectpath, or defined in an aop.xml file if 

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Eric B]

 Thanks for the link Andy.  I read through the overweaving description, and
I agree that it doesn't sound like it applies.

The aspect missing the aspectOf() is part of the CTW.  All Aspects are
annotation based (@Aspect).  The LTW was built using ajc.  Without the CTW
aspects, everything runs smoothly; all I have done was add in an additional
jar with CTW aspect/classes.  The LTW still seems to be working, although I
would have to do more in-depth tests to validate that they are still being
triggered where they need to be.

My application is running under JBoss EAP 7/Wildfly 10, so I'm honestly not
entirely sure if they are all using the same classloader.  Given that the
CTW classes are in the ear/lib folder, as are the LTW aspects (both jars
are found in ear/lib), I suspect that they both are in the same
classloader, but I'm really not sure.  I know that WF has done a lot of
work, separating classloaders by module (so that the different modules in
an EAR each have different classloaders), but I suspect there must be a
common one for all classes in the ear/lib folder.

All that being said, I enabled the aspectj dumper with the beforeandafter
option:














and interestingly enough, in the _before folder, I see the problematic
Aspect class properly woven, but in the after class, it reappears in its
original non-woven form.  As the LTW overweaver has reverted the class.
And even more interesting, I cannot seem to find the pointcut in my LTW
aspects that would have picked out this class in the first place.  Most of
my pointcuts are "execution" pointcuts pointing to completely different
pkgs.  There are a couple of "call" pointcuts as well as one cflow(), but
in all cases, none should be picking out this Aspect.

If I check the server.log file, I see the following being logged, which I
don't particularly understand:

2018-06-12 10:21:51,708 ERROR [stderr]   [ModuleClassLoader@2d758982] info
processing reweavable type
org.webapp.sso.keycloak.administration.SessionAdministrationImpl:
org\webapp.sso\keycloak\administration\SessionAdministrationImpl.java
2018-06-12 10:21:51,711 ERROR [stderr]   [ModuleClassLoader@2d758982] error
aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven
into 'org.webapp.sso.keycloak.administration.SessionAdministrationImpl'
must be defined to the weaver (p
laced on the aspectpath, or defined in an aop.xml file if using LTW).
2018-06-12 10:21:51,802 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.administration.UserServiceImpl'
2018-06-12 10:21:51,834 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.administration.SessionAdministration'
2018-06-12 10:21:51,861 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.administration.AccountAdministrationImpl'
2018-06-12 10:21:51,877 ERROR [stderr]   [ModuleClassLoader@2d758982] info
processing reweavable type
org.webapp.sso.keycloak.administration.AccountAdministrationImpl:
org\webapp.sso\keycloak\administration\AccountAdministrationImpl.java
2018-06-12 10:21:51,877 ERROR [stderr]   [ModuleClassLoader@2d758982] error
aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven
into 'org.webapp.sso.keycloak.administration.AccountAdministrationImpl'
must be defined to the weaver (p
laced on the aspectpath, or defined in an aop.xml file if using LTW).
2018-06-12 10:21:51,896 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.administration.UserService'
2018-06-12 10:21:51,932 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.config.KeycloakConfigBean'
2018-06-12 10:21:51,968 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.keycloak.admin.client.Keycloak'
2018-06-12 10:21:51,973 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.keycloak.admin.client.resource.UserResource'
2018-06-12 10:21:51,975 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.administration.AccountAdministration'
2018-06-12 10:21:52,011 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.administration.UserService'
2018-06-12 10:21:52,026 ERROR [stderr]   [ModuleClassLoader@2d758982] debug
weaving 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler'
2018-06-12 10:21:52,046 ERROR [stderr]   [ModuleClassLoader@2d758982] info
processing reweavable type
org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler:
org\webapp.sso\keycloak\aspect\ClientErrorExceptionHandler.java
2018-06-12 10:21:52,046 ERROR [stderr]   [ModuleClassLoader@2d758982] error
aspect 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' woven
into 'org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler' must be
defined to the weaver (placed
on the aspectpath, or defined in an aop.xml file if using LTW).
2018-06-12 10:21:52,079 ERROR [stderr]   [ModuleClassLoader@2d758982] debug

Re: [aspectj-users] Are there conflicts using LTW and CTW in the same application?

[Andy Clement]

By default if you weave aspects on top of aspects then we use a model where
we revert to the original class file before the first set of aspects was
applied and apply all of them (the original aspects plus the new ones) at
the same time to ensure consistency. This behavior is configurable using
the overweaving option (
http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html ). I'm
not sure whether I suspect that though.

Is the aspect with the aspectOf() missing part of the CTW or the LTW?  Was
the LTW library built with javac or ajc? Building annotation style aspects
with javac can be done but it will mean they are 'unfinished' and don't
have aspectOf/hasAspect - those will be added later when a weaver sees them.
Is everything loaded by the same class loader?  If you were LTWing some
code but the aspects were loaded by a class loader not subject to weaving
then this might happen. But then I know you are showing decompiled output
that contains the missing methods.

I don't have an obvious answer but there are no known issues with mixing
things up like this, really shouldn't be a race condition. You could turn
on verbose output for LTW and see if the things you are expecting to get
modified *are* modified.

cheers,
Andy

On 11 June 2018 at 14:07, Eric B  wrote:

> I have a multi-module EAR application that is comprised of:
> - EJB jar
> - WAR
> - aspect library
> - supporting libs
>
> My AspectJ library is designed to be used as LTW; it has pointcuts
> targetting some of the 3rd party libs.
>
> I have now created a new jar module in which I would like to use CTW.  I
> have configured by build properly, and can see that all my jars in my new
> module have been properly woven during the build process.  However, when I
> include the new lib in my ear, I get the following error message:
>
> 16:43:39,689 ERROR [io.undertow.request] (default task-35) UT005023:
> Exception handling request to /webapp/updateUserAccount.do:
> java.lang.NoSuchMethodError: org.webapp.sso.keycloak.aspect.
> ClientErrorExceptionHandler.aspectOf()Lorg/webapp/sso/keycloak/aspect/
> ClientErrorExceptionHandler;
> at org.webapp.sso.keycloak.administration.
> AccountAdministrationImpl.updateUserPassword(AccountAdministrationImpl.
> java:1)
> at org.webapp.sso.keycloak.administration.
> AccountAdministrationImpl$Proxy$_$$_WeldClientProxy.updateUserPassword(Unknown
> Source)
>
>
>
> However, when I look at the decompiled code for
> ClientErrorExceptionHandler, I see it contains the aspectOf() method:
>
>
> @Aspect
> public class ClientErrorExceptionHandler
> {
>   public static ClientErrorExceptionHandler aspectOf()
>   {
> if (ajc$perSingletonInstance == null) {
>   throw new 
> NoAspectBoundException("org.webapp.sso.keycloak.aspect.ClientErrorExceptionHandler",
> ajc$initFailureCause);
> }
> return ajc$perSingletonInstance;
>   }
>
>   public static boolean hasAspect()
>   {
> return ajc$perSingletonInstance != null;
>   }
> ...
> ...
>
> So I'm not sure what is happening.  Can this be some form of a race
> condition between the Load Time weaver and the Compile Time code?  My LTW
> aspects are in a completely different jar file, with their own aop.xml that
> have nothing to do with my current package.
>
> I've also double checked that my new jar does not contain an aop.xml.
>
> How can I further debug this issue?
>
> Thanks,
>
> Eric
>
>
>
>
>
>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/aspectj-users