Re: [aspectj-users] meta-data problem with aspectj-maven-plugin

[Eric B via aspectj-users]

Thanks Alex,

My code was actually cut & paste; I'm not sure what happened with the email
client

Your message helped me reapproach it, and I got it to work.  I'm not sure
what the plugin is doing, but I needed to identify the sources better than
I was doing.  By specifying exact sources that I was targeting to compile,
the plugin works and is able to weave.  Of course, I am once again running
into my problems that I tried to work out with Andy 10yrs ago with Lombok,
but that's a whole different topic to figure out.

In the meantime, I've managed to cobble together the necessary pieces for
the team to work with.

Thanks!

Eric


On Wed, Aug 9, 2023 at 8:44 PM Alexander Kriegisch via aspectj-users <
aspectj-users@eclipse.org> wrote:

> Sorry, I sent half an answer. What I wrote before relates to
>
> [WARNING] bad version number found in 
> /Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar
>  expected 1.9.8.RC1 found 1.9.19
> :
>
> As for your compilation error, I really need a reproducer to get to the
> bottom of that. I cannot debug plain prose in that case.
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Alexander Kriegisch via aspectj-users schrieb am 10.08.2023 07:27 (GMT
> +07:00):
>
> Welcome back to the AspectJ world, Eric.
> Next time, please post your code as formatted text, links to repositories
> or attachments, rather than as a screenshot. Please also note that this
> question is about AspectJ Maven Plugin rather than AspectJ itself, which
> would make it better suited to Stack Overflow. But I can answer here, too.
> 🙂
>
> As you can see e.g. at
> https://mvnrepository.com/artifact/dev.aspectj/aspectj-maven-plugin/1.13.1,
> that plugin version depends on AspectJ 1.9.8.RC1, which can be updated to
> 1.9.19, the latter one being the version your own module depends on:
>
>
> You are experiencing the situation that you have defined dependencies on
> AspectJ for your module, but did not synchronise the plugin's dependency.
> How to do that is described in
> https://dev-aspectj.github.io/aspectj-maven-plugin/usage.html#Upgrading_or_downgrading_AspectJ:
> Simply define a plugin dependency to the aspectjtools version in sync with
> what your module uses. This also enables you to compile up to the Java
> source/target level represented by that AspectJ version, in this case Java
> 19.
>
> 
>   
> org.codehaus.mojo
> aspectj-maven-plugin
> 1.13.1
> 
>   
> org.aspectj
> aspectjtools
> ${aspectj.version}
>   
> 
>   
>   ...
> 
>
> Besides, your module does not need aspectjweaver for CTW, only for LTW. So
> you can eliminate that from your dependency list and just keep aspectjrt.
>
> Cheers
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
>
> Eric B via aspectj-users schrieb am 09.08.2023 18:55 (GMT +07:00):
>
> I've been away from AJ for a while, but needed to add it to my Java 17
> project recently.  This i my first time trying to use AJ with Java 11+.
>
> I tried adding the aspectjrt and weaver dependencies to my POM and
> enabling CTW using the aspectj-maven-plugin as follows:
>
>
> 
> 
>
> 
> org.aspectj
> aspectjrt
> 1.9.19
> 
> 
> org.aspectj
> aspectjweaver
> 1.9.19
> 
>
> 
>
> 
> 
> 
> dev.aspectj
> aspectj-maven-plugin
> 1.13.1
> 
> 17
> true
> true
> ignore
> UTF-8 
> 
> 
> 
> 
> 
> compile
> 
> test-compile
> 
> 
> 
> 
>
>
>
> Yet when I try to compile anything, I get the following error which stumps
> me:
>
> [INFO] --- aspectj:1.13.1:compile (default) @ poc-oauth-snowflake ---
> [INFO] Showing AJC message detail for messages of types: [error, warning,
> fail]
> [WARNING] bad version number found in
> /Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar
> expected 1.9.8.RC1 found 1.9.19
> :
>
> [ERROR] Internal compiler error: java.lang.Exception:
> java.lang.IllegalStateException: Error processing configuration meta-data
> on public org.springframework.boot.autoconfigure.jdbc.DataSourceProperties
> dataSourceProperties()  at
> org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:172)
>
> /Users/eric/dev/giis-finance/poc-oauth/src/main/java/poc/liquibase/oauth/service/AccessTokenService.java:0
> (no source information available)
>
>
> Removing AJC, and java compiles fine.
>
>
> Does anyone know what configuration meta-data AJC might be complaining
> abou

[aspectj-users] meta-data problem with aspectj-maven-plugin

[Eric B via aspectj-users]

I've been away from AJ for a while, but needed to add it to my Java 17
project recently.  This i my first time trying to use AJ with Java 11+.

I tried adding the aspectjrt and weaver dependencies to my POM and enabling
CTW using the aspectj-maven-plugin as follows:






org.aspectj
aspectjrt
1.9.19


org.aspectj
aspectjweaver
1.9.19







dev.aspectj
aspectj-maven-plugin
1.13.1

17
true
true
ignore
UTF-8 





compile

test-compile







Yet when I try to compile anything, I get the following error which stumps
me:

[INFO] --- aspectj:1.13.1:compile (default) @ poc-oauth-snowflake ---
[INFO] Showing AJC message detail for messages of types: [error, warning,
fail]
[WARNING] bad version number found in
/Users/eric/dev/.m2/repository/org/aspectj/aspectjrt/1.9.19/aspectjrt-1.9.19.jar
expected 1.9.8.RC1 found 1.9.19
:

[ERROR] Internal compiler error: java.lang.Exception:
java.lang.IllegalStateException: Error processing configuration meta-data
on public org.springframework.boot.autoconfigure.jdbc.DataSourceProperties
dataSourceProperties()  at
org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.RoundDispatcher.handleProcessor(RoundDispatcher.java:172)

/Users/eric/dev/giis-finance/poc-oauth/src/main/java/poc/liquibase/oauth/service/AccessTokenService.java:0
(no source information available)


Removing AJC, and java compiles fine.


Does anyone know what configuration meta-data AJC might be complaining
about, or what I might have missed in my config?

I'm running with :
openjdk version "17.0.7" 2023-04-18
OpenJDK Runtime Environment Homebrew (build 17.0.7+0)
OpenJDK 64-Bit Server VM Homebrew (build 17.0.7+0, mixed mode, sharing)


Thanks!

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJWeaver & java.util.logging

[Eric B]

Thanks!  That's exactly what the pointer I needed.  I dug around a little
bit more and noticed there is a system property
"-Dorg.aspectj.tracing.factory=default" that I can set which ironically is
different from the default if nothing is specified.
If there is nothing specified, AspectJ uses the Jdk14Trace class (which
delegates to the java 5+ java.util.logging subsystem).  If you specify
"default" for the factory, AspectJ uses the `DefaultTraceFactory` class
which uses its own internal logging system.

More insight can be found at:
https://www.eclipse.org/aspectj/doc/released/pdguide/trace.html

Problem solved!

Thanks,

Eric

On Fri, Nov 27, 2020 at 1:56 AM Andrei Ivanov 
wrote:

> Hi,
> Reading through the code, I see that TraceFactory seems to initialize by
> default a Jdk14TraceFactory if there's none specified
> in the system property "org.aspectj.tracing.factory". This also means that
> you can override it and choose a different implementation.
>
> Regards,
> Andrei
>
> On Fri, Nov 27, 2020 at 12:40 AM Eric B  wrote:
>
>> Hi,
>>
>> I've been forced to revisit a hackish approach that I put together to get
>> AspectJ working in Wildfly a couple of years ago,  It led me to this ticket:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=502093
>>
>> Looking through the code on github, I see that the Jdk14Trace.jav
>> <http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/weaver5/java5-src/org/aspectj/weaver/tools/Jdk14Trace.java#n13>a
>> class is still in the master branch still leveraging the java.util.logging
>> classes.
>>
>> Has any work been done to address this?  Is there any workaround that I
>> can apply to have the weaver defer using the logging subsystem until it
>> gets properly initialized in Wildfly?
>>
>> Thanks,
>>
>> Eric
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/aspectj-users
>>
> ___
> aspectj-users mailing list
> aspectj-users@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/aspectj-users
>
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] AspectJWeaver & java.util.logging

[Eric B]

Hi,

I've been forced to revisit a hackish approach that I put together to get
AspectJ working in Wildfly a couple of years ago,  It led me to this ticket:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=502093

Looking through the code on github, I see that the Jdk14Trace.jav
a
class is still in the master branch still leveraging the java.util.logging
classes.

Has any work been done to address this?  Is there any workaround that I can
apply to have the weaver defer using the logging subsystem until it gets
properly initialized in Wildfly?

Thanks,

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Anyway to use AJ to _prevent_ field assignment at initialization of an object?

[Eric B]

Thanks for the great example Alexander.

But to make you SSCCE example more inline with what is happening, the
no-arg constructor for DefaultCacheResolverFactory should be throwing a
runtime exception.

Consequently, just using a set() alone will still throw the exception since
the no-arg cstor is still being called.

I can wrap the set() with a cflow() as you suggested and catch the
exception, but in an ideal world, I would rather prevent the call to the
no-arg cstor altogether.

So essentially, I would be looking at doing something like:

Around(cflow(initialization(CacheLookupUtil.new(..)) &&
call(DefaultCacheResolverFactory.new())){
   return new DefaultCacheResolverFactory( new CacheManager();
}


I haven't tried that yet, but I believe it should get me where I need to
get.

Thanks,

Eric


On Thu, Aug 8, 2019, 9:48 PM Alexander Kriegisch  I replicated your situation with dummy classes:
> --
>
> package de.scrum_master.app;
>
> public class InvocationContext {}
>
> --
>
> package de.scrum_master.app;
>
> public interface CacheResolverFactory {
>   CacheManager getCacheManager();
> }
>
> --
>
> package de.scrum_master.app;
>
> public class DefaultCacheResolverFactory implements CacheResolverFactory {
>   private CacheManager cacheManager = new CacheManager("default");
>   public DefaultCacheResolverFactory() {
> System.out.println("DefaultCacheResolverFactory: no-args constructor");
>   }
>
>   public DefaultCacheResolverFactory(CacheManager cacheManager) {
> System.out.println("DefaultCacheResolverFactory: constructor with 
> CacheManager");
> this.cacheManager = cacheManager;
>   }
>
>   @Override
>   public CacheManager getCacheManager() {
> return cacheManager;
>   }
> }
>
> --
>
> package de.scrum_master.app;
>
> public class CacheManager {
>   private String name;
>
>   public CacheManager(String name) {
> this.name = name;
>   }
>
>   @Override
>   public String toString() {
> return "CacheManager [name=" + name + "]";
>   }
> }
>
> --
>
> package de.scrum_master.app;
>
> public abstract class AbstractCacheLookupUtil {
>   public abstract void doSomething();
> }
>
> --
>
> package de.scrum_master.app;
>
> public class CacheLookupUtil extends 
> AbstractCacheLookupUtil {
>   private CacheResolverFactory defaultCacheResolverFactory = new 
> DefaultCacheResolverFactory();
>
>   @Override
>   public void doSomething() {
> System.out.println(defaultCacheResolverFactory.getCacheManager());
>   }
>
>   public static void main(String[] args) {
> new CacheLookupUtil().doSomething();
>   }
> }
>
> --
>
> Now if you run that code, the console log says:
>
> DefaultCacheResolverFactory: no-args constructor
> CacheManager [name=default]
>
> No surprise here.
>
> Now you can use LTW (load-time weaving) and a set() pointcut like this:
> --
>
> package de.scrum_master.aspect;
>
> import de.scrum_master.app.CacheResolverFactory;
> import de.scrum_master.app.DefaultCacheResolverFactory;
> import de.scrum_master.app.CacheLookupUtil;
> import de.scrum_master.app.CacheManager;
>
> public aspect CacheResolverFactoryReplacer {
>   void around(CacheResolverFactory cacheResolverFactory) :
> set(CacheResolverFactory CacheLookupUtil.*) &&
> args(cacheResolverFactory)
>   {
> proceed(new DefaultCacheResolverFactory(new CacheManager("aspect")));
>   }
> }
>
> --
>
> The console log changes to:
>
> DefaultCacheResolverFactory: no-args constructor
> DefaultCacheResolverFactory: constructor with CacheManager
> CacheManager [name=aspect]
>
> Now as you can see, the no-args resolver factory constructor is still
> executed but the resulting object is no longer assigned to the member
> because the advice proceeds with the object you want to be assigned instead.
>
> If you want to be very specific in your aspect and limit setting the
> member during constructor execution or object initialisation, you can
> always add && cflow(execution(CacheLookupUtil.new(..))) or &&
> cflow(initialization(CacheLookupUtil.new(..))) to your pointcut.
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
>
> Eric B schrieb am 08.08.2019 21:20:
>
> I'm using the JCache API, in which a design decision made by the JSR-107
> team in impleme

Re: [aspectj-users] Anyway to use AJ to _prevent_ field assignment at initialization of an object?

[Eric B]

Not a bad idea.  It's a lot simpler than I was trying to make it out to be.

Thanks

Eric

On Thu, Aug 8, 2019, 10:39 AM Matthew Adams  Advise the call to the constructor of DefaultCacheResolverFactory with
> around advice, catch the exception, then return what you want to.  Note:
> don't use an "execution" pointcut expression -- you want a "call".
>
> On Aug 8, 2019, at 9:20 AM, Eric B  wrote:
>
> I'm using the JCache API, in which a design decision made by the JSR-107
> team in implementing the Reference Implementation is causing me a
> significant headache.  The class in question is:
> org.jsr107.ri.annotations.cdi.CacheLookupUtil from package org.jsr107.ri:
> cache-annotations-ri-cdi:1.1.0.
>
> This is the layout of the class:
>
> public class CacheLookupUtil extends 
> AbstractCacheLookupUtil {
>   @Inject
>   private BeanManagerUtil beanManagerUtil;
>
>   private CacheKeyGenerator defaultCacheKeyGenerator = new 
> DefaultCacheKeyGenerator();
>   private CacheResolverFactory defaultCacheResolverFactory = new 
> DefaultCacheResolverFactory();
>
>   ...
>
>   ...
>
> }
>
>
> My problem is the assignment of the defaultCacheResolverFactory, or to be
> even more specific the construction of the DefaultCacheResolverFactory()
> without arguments when initializing the object.  The default constructor
> used throws an exception which is extremely difficult to catch given that
> the DI framework is instantiating the object.
>
> Is there anyway I can use AspectJ to modify that assignment?  Ideally, I
> would like to prevent the construction of the DefaultCacheResolverFactory
> with no args, and replace it with a call to new
> DefaultCacheResolverFactory(CacheManager) instead.
>
> So my issue is not just being able to assign the field (which I would be
> able to do in a CacheLookupUtil constructor advice, but also prevent the
> construction of the DefaultCacheResolverFactory().
>
> Can you think of any kind of pointcut(s) that I could use to catch that
> condition?  I figure I need an Around advice against a pointcut which picks
> up the constructor of the DefaultCacheResolverFactory (so I can return my
> own object instead), but from what I understand I cannot use around with
> the initialization pointcut.
>
> Any suggestions what I can try?
>
> 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://www.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://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] Anyway to use AJ to _prevent_ field assignment at initialization of an object?

[Eric B]

I'm using the JCache API, in which a design decision made by the JSR-107
team in implementing the Reference Implementation is causing me a
significant headache.  The class in question is:
org.jsr107.ri.annotations.cdi.CacheLookupUtil from package org.jsr107.ri:
cache-annotations-ri-cdi:1.1.0.

This is the layout of the class:

public class CacheLookupUtil extends
AbstractCacheLookupUtil {
  @Inject
  private BeanManagerUtil beanManagerUtil;

  private CacheKeyGenerator defaultCacheKeyGenerator = new
DefaultCacheKeyGenerator();
  private CacheResolverFactory defaultCacheResolverFactory = new
DefaultCacheResolverFactory();

  ...

  ...

}


My problem is the assignment of the defaultCacheResolverFactory, or to be
even more specific the construction of the DefaultCacheResolverFactory()
without arguments when initializing the object.  The default constructor
used throws an exception which is extremely difficult to catch given that
the DI framework is instantiating the object.

Is there anyway I can use AspectJ to modify that assignment?  Ideally, I
would like to prevent the construction of the DefaultCacheResolverFactory
with no args, and replace it with a call to new
DefaultCacheResolverFactory(CacheManager) instead.

So my issue is not just being able to assign the field (which I would be
able to do in a CacheLookupUtil constructor advice, but also prevent the
construction of the DefaultCacheResolverFactory().

Can you think of any kind of pointcut(s) that I could use to catch that
condition?  I figure I need an Around advice against a pointcut which picks
up the constructor of the DefaultCacheResolverFactory (so I can return my
own object instead), but from what I understand I cannot use around with
the initialization pointcut.

Any suggestions what I can try?

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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] What is the correct pointcut expression to use with Proxied EJB classes?

[Eric B]

t; BTW and slightly off-topic, have you also tried to use internal
> application server logging/monitoring/reporting tools in order to check
> your assumptions? Or profiling tools like VisualVM? Anyway, this one is
> interesting purely from an AOP perspective. ;-)
>
> Kind regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Eric B schrieb am 11.02.2019 00:13:
>
> I've got a JEE application with some performance issues.  I suspect that
> it is due to MQ listeners (MessageDrivenBeans) that are not executing
> enough threads concurrently and figured that an easy way to validate my
> theory would be to write a quick Aspect to profile the number of threads
> being triggered at the same time.
>
> I'm using LTW in the rest of my application, so trying to use LTW for this
> aspect as well.
>
> While my Aspect works in theory, it seems to be advising the "wrong"
> beans; that is- it is picking out what seem to be container generated beans
> instead of my primary beans, and consequently, it is providing false
> information.  The 5 listeners that I want to advise extend a common
> Abstract class which implements the onMessage() method.  I'm trying to
> advise this method for all beans.
>
> My Aspect is as follows:
>
> @Aspect("pertypewithin(business.security.tables.mq.*)")
>
> public class ListenerThreadLoggingAspect {
> // get a static slf4j logger for the classprotected static final 
> Logger logger = getLogger(ListenerThreadLoggingAspect.class);
>
> private static AtomicInteger concurrentThreadCount = new AtomicInteger(0);
>
> // pointcut to pick out the onMessage() method
> @Pointcut("execution(!synthetic * (*..mq.AbstractSecurityAccessTableListener+ 
> && !*..mq.AbstractSecurityAccessTableListener).onMessage(..))")
> public void onMessagePointcut() {
> }
>
>
> @Around("onMessagePointcut()")
> public Object logThreadCount(ProceedingJoinPoint pjp) throws Throwable {
>
> // entering message handler, so increment threads and logint 
> concurrentThreads = concurrentThreadCount.incrementAndGet();
> logger.debug("ID[{}]:  Start [{}].  Concurrent Threads: {}", 
> System.identityHashCode(this), pjp.getTarget().getClass().getName(), 
> concurrentThreads);
>
> // execute the listenerObject result = pjp.proceed();
>
> // done so decrement number of threadsconcurrentThreads = 
> concurrentThreadCount.decrementAndGet();
> logger.trace("ID[{}]: Stop  [{}].  Concurrent Threads: {}", 
> System.identityHashCode(this), pjp.getTarget().getClass().getName(), 
> concurrentThreads);
>
> return result;
> }
>
> }
>
> While the weaver indicates that the correct classes are being woven, the
> execution shows a different trace:
>
> 2019-02-10 11:59:33,036 ERROR (default-threads - 5) [stderr]
>  [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
> business.security.tables.mq.SecurityAccessTablePurgeListener$$$endpoint11.onMessage(javax.jms.Message))'
> in Type
> 'business.security.tables.mq.SecurityAccessTablePurgeListener$$$endpoint11'
> (no debug info available) advised by around advice from
> 'izone.common.security.access.ListenerThreadLoggingAspect'
> (ListenerThreadLoggingAspect.java)
> 2019-02-10 11:59:33,124 ERROR (default-threads - 4) [stderr]
>  [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
> business.security.tables.mq.SecurityAccessTableConsumeListener$$$endpoint14.onMessage(javax.jms.Message))'
> in Type
> 'business.security.tables.mq.SecurityAccessTableConsumeListener$$$endpoint14'
> (no debug info available) advised by around advice from
> 'izone.common.security.access.ListenerThreadLoggingAspect'
> (ListenerThreadLoggingAspect.java)
> 2019-02-10 11:59:33,187 ERROR (default-threads - 10) [stderr]
>  [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
> business.security.tables.mq.SecurityAccessTableRequestListener$$$endpoint12.onMessage(javax.jms.Message))'
> in Type
> 'business.security.tables.mq.SecurityAccessTableRequestListener$$$endpoint12'
> (no debug info available) advised by around advice from
> 'izone.common.security.access.ListenerThreadLoggingAspect'
> (ListenerThreadLoggingAspect.java)
> 2019-02-10 11:59:33,296 ERROR (default-threads - 7) [stderr]
>  [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
> business.security.tables.mq.SecurityAccessTableReadyListener$$$endpoint9.onMessage(javax.jms.Message))'

[aspectj-users] What is the correct pointcut expression to use with Proxied EJB classes?

[Eric B]

I've got a JEE application with some performance issues.  I suspect that it
is due to MQ listeners (MessageDrivenBeans) that are not executing enough
threads concurrently and figured that an easy way to validate my theory
would be to write a quick Aspect to profile the number of threads being
triggered at the same time.

I'm using LTW in the rest of my application, so trying to use LTW for this
aspect as well.

While my Aspect works in theory, it seems to be advising the "wrong" beans;
that is- it is picking out what seem to be container generated beans
instead of my primary beans, and consequently, it is providing false
information.  The 5 listeners that I want to advise extend a common
Abstract class which implements the onMessage() method.  I'm trying to
advise this method for all beans.

My Aspect is as follows:
@Aspect("pertypewithin(business.security.tables.mq.*)")

public class ListenerThreadLoggingAspect {
// get a static slf4j logger for the class
protected static final Logger logger =
getLogger(ListenerThreadLoggingAspect.class);

private static AtomicInteger concurrentThreadCount = new AtomicInteger(0);

// pointcut to pick out the onMessage() method
@Pointcut("execution(!synthetic *
(*..mq.AbstractSecurityAccessTableListener+ &&
!*..mq.AbstractSecurityAccessTableListener).onMessage(..))")
public void onMessagePointcut() {
}


@Around("onMessagePointcut()")
public Object logThreadCount(ProceedingJoinPoint pjp) throws Throwable {

// entering message handler, so increment threads and log
int concurrentThreads = concurrentThreadCount.incrementAndGet();
logger.debug("ID[{}]:  Start [{}].  Concurrent Threads: {}",
System.identityHashCode(this), pjp.getTarget().getClass().getName(),
concurrentThreads);

// execute the listener
Object result = pjp.proceed();

// done so decrement number of threads
concurrentThreads = concurrentThreadCount.decrementAndGet();
logger.trace("ID[{}]: Stop  [{}].  Concurrent Threads: {}",
System.identityHashCode(this), pjp.getTarget().getClass().getName(),
concurrentThreads);

return result;
}

}


While the weaver indicates that the correct classes are being woven, the
execution shows a different trace:

2019-02-10 11:59:33,036 ERROR (default-threads - 5) [stderr]
 [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
business.security.tables.mq.SecurityAccessTablePurgeListener$$$endpoint11.onMessage(javax.jms.Message))'
in Type
'business.security.tables.mq.SecurityAccessTablePurgeListener$$$endpoint11'
(no debug info available) advised by around advice from
'izone.common.security.access.ListenerThreadLoggingAspect'
(ListenerThreadLoggingAspect.java)
2019-02-10 11:59:33,124 ERROR (default-threads - 4) [stderr]
 [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
business.security.tables.mq.SecurityAccessTableConsumeListener$$$endpoint14.onMessage(javax.jms.Message))'
in Type
'business.security.tables.mq.SecurityAccessTableConsumeListener$$$endpoint14'
(no debug info available) advised by around advice from
'izone.common.security.access.ListenerThreadLoggingAspect'
(ListenerThreadLoggingAspect.java)
2019-02-10 11:59:33,187 ERROR (default-threads - 10) [stderr]
 [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
business.security.tables.mq.SecurityAccessTableRequestListener$$$endpoint12.onMessage(javax.jms.Message))'
in Type
'business.security.tables.mq.SecurityAccessTableRequestListener$$$endpoint12'
(no debug info available) advised by around advice from
'izone.common.security.access.ListenerThreadLoggingAspect'
(ListenerThreadLoggingAspect.java)
2019-02-10 11:59:33,296 ERROR (default-threads - 7) [stderr]
 [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
business.security.tables.mq.SecurityAccessTableReadyListener$$$endpoint9.onMessage(javax.jms.Message))'
in Type
'business.security.tables.mq.SecurityAccessTableReadyListener$$$endpoint9'
(no debug info available) advised by around advice from
'izone.common.security.access.ListenerThreadLoggingAspect'
(ListenerThreadLoggingAspect.java)
2019-02-10 11:59:33,432 ERROR (default-threads - 6) [stderr]
 [ModuleClassLoader@572dc861] weaveinfo Join point 'method-execution(void
business.security.tables.mq.SecurityAccessTableStatisticsListener$$$endpoint8.onMessage(javax.jms.Message))'
in Type
'business.security.tables.mq.SecurityAccessTableStatisticsListener$$$endpoint8'
(no debug info available) advised by around advice from
'izone.common.security.access.ListenerThreadLoggingAspect'
(ListenerThreadLoggingAspect.java)



Execution Log:

12:00:19,585 DEBUG [common.security.access.ListenerThreadLoggingAspect]
(Thread-30 (ActiveMQ-client-global-threads-508854362)) ID[1049816548]:
Start [business.securitytyAccessTableConsumeListener$$$endpoint14].
Concurrent Threads: 1
12:00:19,586 DEBUG [common.security.access.ListenerThreadLoggingAspect]
(T

Re: [aspectj-users] Warning when using lombok's with aspectj

[Eric B]

I remember trying to get Lombok to play nice with AspectJ several years
back and failed miserably.  While it can be used for basic enhancement (ex:
around, before pointcut, etc) trying to use it with mixins was a total
failure as Lombok needed to use AJC to compile the code (chicken and egg
thing otherwise).

As Andy alluded to, the AJC compiler is based on the jdt compiler, but with
a different package name.  I had even tried to rename the AJC compiler
packaging to match what Lombok expected but that didn't work either.

If you search the AspectJ usergroup archive, you should be able to find a
thread from around 2014 relating to this.

If someone manages to make it work, I'd love to hear about it.  It was one
of the top reasons I decided to abstain from using Lombok; lack of full AJ
support was a deal breaker for me.

Thanks

Eric

On Fri, Jan 25, 2019, 11:58 AM Andy Clement, 
wrote:

> I haven't done much investigation work into the combination. If you do it
> in two steps you'd be fine (Lombok then binary weave) but that won't work
> if you are doing static introductions from aspects that you need around for
> your code to compile in the first place. If you tweaked Lombok to
> additionally recognize the aspectj compiler like it recognizes JDT, that
> may work (since AspectJ is based on the JDT compiler with a different
> package name) but I've never tried it - you'd need to rebuild Lombok
> yourself to try it out. Feels like that wouldn't be a totally unreasonable
> contribution back to Lombok if it did behave.
>
> cheers,
> Andy
>
> On Wed, 23 Jan 2019 at 23:59, Mikael Petterson <
> mikaelpetter...@hotmail.com> wrote:
>
>> Hi,
>>
>> Is there a way around this:
>>
>> https://github.com/rzwitserloot/lombok/issues/995
>>
>> br,
>>
>> //mikael
>> 
>> Can lombok work with aspectJ and maven together. · Issue #995 ·
>> rzwitserloot/lombok · GitHub
>> 
>> Join GitHub today. GitHub is home to over 28 million developers working
>> together to host and review code, manage projects, and build software
>> together.
>> github.com
>>
>>
>>
>>
>>
>> ___
>> aspectj-users mailing list
>> aspectj-users@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.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://www.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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Are there limitations of combining multiple cflow() together or using cflow with get pointcut?

[Eric B]

Hi Alexander,

Indeed, I think I came to that realization several hours after having
posted my question, and realizing that a pointcut around the getter is
probably not the same thing as a pointcut on the field access.

I tried looking at the decompiled code to see how AJ weaves the field
access, but got a bit lost with all the different AJC counters that it uses
and ended up focusing on the wrong thing.

The catch I have here is that the field is a reference to a lazy loaded
persistent object, and was trying to create a pointcut around the
persistence execution framework (ie: trying to catch the framework when
loading the object from the db).

I'm guessing the field access pointcut will only trigger after the
framework retrieves the data from the db, and in the return path from the
stack, when it would be reading the value.

Pointcut on the getter will definitely address my issue better.

Thanks

Eric



On Sun, Nov 25, 2018, 5:27 PM Alexander Kriegisch, 
wrote:

> > You understand something here.
>
> I mean *mis*understand.
>
>
> Alexander Kriegisch schrieb am 25.11.2018 23:16:
>
> > Hi Eric.
> >
> > You understand something here.
> >
> >get(* model.UserAccount.accountOwner)
> >
> > is in the control flow of
> >
> >execution(* model.UserAccount.getAccountOwner(..))
> >
> > but not the other way around. The control flow of reading the member
> > value starts right before it is read and ends right after it has been
> > read. It is a pretty much atomic operation. Whatever other methods are
> > called by the getter *method* are not yet or no longer within the
> > control flow of the member read operation. I can explain in more detail
> > if you provide the code of UserAccount.getAccountOwner().
> >
> > Regards
> > --
> > Alexander Kriegisch
> > https://scrum-master.de
> >
> > Eric B schrieb am 25.11.2018 19:59:
> >>
> >>
> >> I've tried to write a pointcut that combines a couple of different
> >> cflow()/cflowbelow() together, but it does not seem to work as expected.
> >> That is, the advise is still being executed even though one of the
> cflow()
> >> pointcuts is clearly in the stacktrace.
> >>
> >>
> >> My pointcut in question is:
> >>
> >> > @Pointcut("get(* model.UserAccount.accountOwner)")
> >> public voiduserAccountOwner(){}
> >>
> >>
> >>
> >>
> >> I then use the defined pointcut as:
> >>
> >> > @Before("aspectInitialized() && cflowbelow(ejbMethods()) &&
> >> !cflowbelow(userAccountOwner()) && (newModelsWhichReferenceUserA() ||
> >> (userAccountAccessibleMethods() ))")
> >> public voidpreventConstructorsForRelatedObjects(JoinPoint
> >> joinPoint)throwsSecurityAccessTableDataException{
> >>
> >> > // some logic
> >>
> >> > throw new RuntimeException( "USERA tables not yet ready");
> >>
> >> > }
> >>
> >>
> >> And in my stack trace in which the advice is clearly being executed (the
> >> GeneralException is being triggered by an exception thrown in the
> advice),
> >> I can observe the UserAccount.getAccountOwner() method being called.
> >>
> >>
> >> Caused by: <0|false|0.9.5-incubating> kodo.jdo.GeneralException: USERA
> >> tables are not yet ready
> >>
> >> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
> >>
> >> at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:749)
> >>
> >> at
> >>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.find(JDBCStoreManager.java:746)
> >>
> >> at
> >>
> org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.load(RelationFieldStrategy.java:550)
> >>
> >> at org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:791)
> >>
> >> at
> >>
> org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:483)
> >>
> >> at
> >>
> org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:113)
> >>
> >> at
> >>
> org.apache.openjpa.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:363)
> >>
> >> at
> >>
> org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:113)
> >>
> >> at
> org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:75)
> >>
> >> at
> >>
> org.

[aspectj-users] Are there limitations of combining multiple cflow() together or using cflow with get pointcut?

[Eric B]

I've tried to write a pointcut that combines a couple of different
cflow()/cflowbelow() together, but it does not seem to work as expected.
That is, the advise is still being executed even though one of the cflow()
pointcuts is clearly in the stacktrace.

My pointcut in question is:

@Pointcut("get(* model.UserAccount.accountOwner)")
public void userAccountOwner(){}


I then use the defined pointcut as:

@Before( "aspectInitialized() && cflowbelow(ejbMethods()) &&
!cflowbelow(userAccountOwner()) && (newModelsWhichReferenceUserA() ||
(userAccountAccessibleMethods() ))")
public void preventConstructorsForRelatedObjects(JoinPoint joinPoint)
throws SecurityAccessTableDataException{

// some logic

throw new RuntimeException( "USERA tables not yet ready");

}


And in my stack trace in which the advice is clearly being executed (the
GeneralException is being triggered by an exception thrown in the advice),
I can observe the UserAccount.getAccountOwner() method being called.

Caused by: <0|false|0.9.5-incubating> kodo.jdo.GeneralException: USERA
tables are not yet ready
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:852)
at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:749)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.find(JDBCStoreManager.java:746)
at
org.apache.openjpa.jdbc.meta.strats.RelationFieldStrategy.load(RelationFieldStrategy.java:550)
at
org.apache.openjpa.jdbc.meta.FieldMapping.load(FieldMapping.java:791)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:483)
at
org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:113)
at
org.apache.openjpa.datacache.DataCacheStoreManager.load(DataCacheStoreManager.java:363)
at
org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:113)
at
org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:75)
at
org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2742)
at
org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2820)
at
kodo.kernel.ProfilingStateManager.loadField(ProfilingStateManager.java:68)
at
org.apache.openjpa.kernel.StateManagerImpl.beforeAccessField(StateManagerImpl.java:1337)
at
kodo.kernel.ProfilingStateManager.beforeAccessField(ProfilingStateManager.java:49)
at
org.apache.openjpa.kernel.StateManagerImpl.accessingField(StateManagerImpl.java:1322)
at model.UserAccount.pcGetaccountOwner(UserAccount.java:1)
>   at model.UserAccount.getAccountOwner(UserAccount.java:500)
at
business.impl.PersistentManipulationUtil.findAccountablePersonWithUserName(PersistentManipulationUtil.java:991)
at business.impl.EJBUtil.createBusinessContext(EJBUtil.java:120)
at business.impl.EJBUtil.createBusinessContext(EJBUtil.java:78)
at
business.ejb3.base.BaseManagerBean.getBusinessContext(BaseManagerBean.java:410)
at
business.ejb3.EnterpriseManagerBean.getEnterpriseWindowThresholds(EnterpriseManagerBean.java:1680)


Changing the userAccountOwner() pointcut to read:

@Pointcut("execution(* model.UserAccount.getAccountOwner(..))")
public void userAccountOwner(){}


And the cflow() works as expected.

Is this behaviour expected based on the way field getter/setter pointcuts
are designed to work or is this a bug in my code (or my use of the field
getter) or AspectJ?

This is with AspectJ 1.8.13.

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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Core dumps with aspectjweaver 1.8.13 LTW

[Eric B]

Hi Andy,

I can see if I can get a small test case working.  Do you need source code
for all files, or is byte code good enough?  The reason I ask is because
there is actually an old byte code enhancer that is already manipulating
the classes in question that I am then asking for AspectJ to reweave with
LTW.  If I can reproduce, I have no issues with including the source code,
but the build process is a little convoluted and uses a custom maven plugin
with some custom libraries to do the byte enhancement.  While anything is
possible, just makes getting the package ready more difficult.  If just the
.class files are sufficient then it should be hopefully faster to produce.

As for the 1.9.3, any thoughts on when this might be available in a
release?  Are there any concerns I should have upgrading 1.8 to 1.9?  I
typically always try to use the same version as the JDK (ie: use 1.8 for
Java8 code, 1.9 for Java 9 code, etc).  Can I use 1.9 with a Java 8
compiler on a J8 platform without any issues/worries?

Thanks,

Eric



On Mon, Nov 19, 2018 at 12:18 PM Andrew Clement 
wrote:

> Hey,
>
> Obviously my preference would be to fix the problem, but that does require
> me to recreate it. Not sure if you are able to share the project that leads
> to it? (Or a cut down sample). It looks like something where I’d need to
> dig into the byte code involved.
>
> In the interim I have added is(AbstractType) to go with all the others,
> just fixed it under:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=541325
>
> I can give you a dev build with that in if that would be useful, I wasn’t
> planning on an imminent 1.9.3 (this would be fixed in 1.9 line, not the 1.8
> line)
>
> cheers,
> Andy
>
> On Nov 16, 2018, at 8:19 AM, Eric B  wrote:
>
> Thanks for the info; I suspected as much as not being able to target
> abstract classes directly (I hadn't found any documentation to that effect).
>
> Can you think of any other way I can attempt to exclude my problematic
> abstract classes without listing the explicitly?  I'm hoping that something
> like the following might work:
>
> @Pointcut( "execution( * *..AbstractClass1(..)) || execution (*
> *..AbstractClass2(..)) || ... )")
> public void abstractClasses();
>
> **
> * Execution of any pcClearFields() methods within a newInstance as
> injected by Kodo Enhancer
> */
> @Pointcut("cflow(*!abstractClasses() && *execution(*
> org.apache.openjpa.enhance.PersistenceCapable+.pcNewInstance(..))) &&
> execution(*
> org.apache.openjpa.enhance.PersistenceCapable+.pcClearFields(..))")
> public void kodoNewObject(){}
>
>
> But I haven't tested it, and it's kind of ugly, so hoping I can find
> something a little less bad?
>
> Thanks,
>
> Eric
>
> On Fri, Nov 16, 2018 at 5:15 AM Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
>
>> Sorry for being too busy to really investigate this report, but as a side
>> note to Andy I want to mention that currently there is not way to express
>> something like
>>
>>   !within(* && is(AbstractType))
>>
>> Since 1.6.9 [1] we have
>>-- ClassType,
>>-- AspectType,
>>-- InterfaceType,
>>-- InnerType,
>>-- AnonymousType,
>>-- EnumType.
>>
>> Since 1.8.4 [2] we have
>>   -- FinalType.
>>
>> According to [3] this still seems to be the current status. Maybe Andy
>> wants to think about adding support for 'AbstractType', independently of
>> how Eric's issue here is to be resolved.
>>
>> [1] https://www.eclipse.org/aspectj/doc/released/README-169.html
>> [2] https://www.eclipse.org/aspectj/doc/released/README-184.html
>> [3]
>> http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/TypeCategoryTypePattern.java#n35
>>
>>
>> --
>> Alexander Kriegisch
>> https://scrum-master.de
>>
>>
>> Eric B schrieb am 15.11.2018 21:11:
>> >
>> >
>> > I'm using aspectj 1.8.13 LTW'ing with Wildfly 10. Generally speaking,
>> > everything is working as expected. However, I have recently added in a
>> new
>> > Pointcut which is causing core dumps by the weaver:
>> >
>> >
>> > 2018-11-15 14:56:30,033 SEVERE [org.aspectj.weaver.loadtime.Aj]
>> > izone/adams/model/messaging/SMSMessageAbstract:
>> > java.lang.IllegalStateException: Unexpected problem whilst preparing
>> > bytecode for model.messaging.SMSMessa
>> >
>> >
>> geAbstract.pcNewInstance(Lorg/apache/openjpa/enhance/StateManager;Ljava/lang/Object;Z)Lorg/apache/openjpa/enhance/

Re: [aspectj-users] Core dumps with aspectjweaver 1.8.13 LTW

[Eric B]

Thanks for the info; I suspected as much as not being able to target
abstract classes directly (I hadn't found any documentation to that effect).

Can you think of any other way I can attempt to exclude my problematic
abstract classes without listing the explicitly?  I'm hoping that something
like the following might work:

@Pointcut( "execution( * *..AbstractClass1(..)) || execution (*
*..AbstractClass2(..)) || ... )")
public void abstractClasses();

**
* Execution of any pcClearFields() methods within a newInstance as injected
by Kodo Enhancer
*/
@Pointcut("cflow(*!abstractClasses() && *execution(*
org.apache.openjpa.enhance.PersistenceCapable+.pcNewInstance(..))) &&
execution(*
org.apache.openjpa.enhance.PersistenceCapable+.pcClearFields(..))")
public void kodoNewObject(){}


But I haven't tested it, and it's kind of ugly, so hoping I can find
something a little less bad?

Thanks,

Eric

On Fri, Nov 16, 2018 at 5:15 AM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Sorry for being too busy to really investigate this report, but as a side
> note to Andy I want to mention that currently there is not way to express
> something like
>
>   !within(* && is(AbstractType))
>
> Since 1.6.9 [1] we have
>-- ClassType,
>-- AspectType,
>-- InterfaceType,
>-- InnerType,
>-- AnonymousType,
>-- EnumType.
>
> Since 1.8.4 [2] we have
>   -- FinalType.
>
> According to [3] this still seems to be the current status. Maybe Andy
> wants to think about adding support for 'AbstractType', independently of
> how Eric's issue here is to be resolved.
>
> [1] https://www.eclipse.org/aspectj/doc/released/README-169.html
> [2] https://www.eclipse.org/aspectj/doc/released/README-184.html
> [3]
> http://git.eclipse.org/c/aspectj/org.aspectj.git/tree/org.aspectj.matcher/src/org/aspectj/weaver/patterns/TypeCategoryTypePattern.java#n35
>
>
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Eric B schrieb am 15.11.2018 21:11:
> >
> >
> > I'm using aspectj 1.8.13 LTW'ing with Wildfly 10. Generally speaking,
> > everything is working as expected. However, I have recently added in a
> new
> > Pointcut which is causing core dumps by the weaver:
> >
> >
> > 2018-11-15 14:56:30,033 SEVERE [org.aspectj.weaver.loadtime.Aj]
> > izone/adams/model/messaging/SMSMessageAbstract:
> > java.lang.IllegalStateException: Unexpected problem whilst preparing
> > bytecode for model.messaging.SMSMessa
> >
> >
> geAbstract.pcNewInstance(Lorg/apache/openjpa/enhance/StateManager;Ljava/lang/Object;Z)Lorg/apache/openjpa/enhance/PersistenceCapable;
> >
> > at
> org.aspectj.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:699)
> >
> > at
> org.aspectj.weaver.bcel.LazyMethodGen.getMethod(LazyMethodGen.java:498)
> >
> > at org.aspectj.weaver.bcel.LazyClassGen.writeBack(LazyClassGen.java:515)
> >
> > at
> >
> org.aspectj.weaver.bcel.LazyClassGen.getJavaClassBytesIncludingReweavable(LazyClassGen.java:697)
> >
> > at
> > org.aspectj.weaver.bcel.BcelWeaver.getClassFilesFor(BcelWeaver.java:1443)
> >
> > at
> org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1405)
> >
> > at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1183)
> >
> > at
> >
> org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:527)
> >
> > at
> >
> org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:363)
> >
> > at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:121)
> >
> > at
> >
> org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:54)
> >
> >
> > ...
> >
> > ...
> >
> >
> > at
> >
> org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.jrGetDeclaredMethods(DeploymentReflectionIndex.java:46001)
> >
> > at
> >
> org.jboss.as.server.deployment.reflect.ClassReflectionIndex.(ClassReflectionIndex.java:80)
> >
> > at
> >
> org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66)
> >
> > at
> >
> org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:57)
> >
> > at
> >
> org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:106)
> >
> > at
> >
> org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfi

[aspectj-users] Core dumps with aspectjweaver 1.8.13 LTW

[Eric B]

I'm using aspectj 1.8.13 LTW'ing with Wildfly 10.  Generally speaking,
everything is working as expected.  However, I have recently added in a new
Pointcut which is causing  core dumps by the weaver:

2018-11-15 14:56:30,033 SEVERE [org.aspectj.weaver.loadtime.Aj]
 izone/adams/model/messaging/SMSMessageAbstract:
java.lang.IllegalStateException: Unexpected problem whilst preparing
bytecode for model.messaging.SMSMessa
geAbstract.pcNewInstance(Lorg/apache/openjpa/enhance/StateManager;Ljava/lang/Object;Z)Lorg/apache/openjpa/enhance/PersistenceCapable;
at
org.aspectj.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:699)
at
org.aspectj.weaver.bcel.LazyMethodGen.getMethod(LazyMethodGen.java:498)
at
org.aspectj.weaver.bcel.LazyClassGen.writeBack(LazyClassGen.java:515)
at
org.aspectj.weaver.bcel.LazyClassGen.getJavaClassBytesIncludingReweavable(LazyClassGen.java:697)
at
org.aspectj.weaver.bcel.BcelWeaver.getClassFilesFor(BcelWeaver.java:1443)
at
org.aspectj.weaver.bcel.BcelWeaver.weaveAndNotify(BcelWeaver.java:1405)
at org.aspectj.weaver.bcel.BcelWeaver.weave(BcelWeaver.java:1183)
at
org.aspectj.weaver.tools.WeavingAdaptor.getWovenBytes(WeavingAdaptor.java:527)
at
org.aspectj.weaver.tools.WeavingAdaptor.weaveClass(WeavingAdaptor.java:363)
at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:121)
at
org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:54)
...
...
at
org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.jrGetDeclaredMethods(DeploymentReflectionIndex.java:46001)
at
org.jboss.as.server.deployment.reflect.ClassReflectionIndex.(ClassReflectionIndex.java:80)
at
org.jboss.as.server.deployment.reflect.DeploymentReflectionIndex.getClassIndex(DeploymentReflectionIndex.java:66)
at
org.jboss.as.ee.metadata.MethodAnnotationAggregator.runtimeAnnotationInformation(MethodAnnotationAggregator.java:57)
at
org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.handleAnnotations(InterceptorAnnotationProcessor.java:106)
at
org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.processComponentConfig(InterceptorAnnotationProcessor.java:91)
at
org.jboss.as.ee.component.deployers.InterceptorAnnotationProcessor.deploy(InterceptorAnnotationProcessor.java:76)
at
org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
at
org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.NullPointerException
at
org.aspectj.apache.bcel.generic.InstructionList.setPositions(InstructionList.java:892)
at
org.aspectj.apache.bcel.generic.InstructionList.setPositions(InstructionList.java:863)
at
org.aspectj.apache.bcel.generic.InstructionList.getByteCode(InstructionList.java:981)
at
org.aspectj.apache.bcel.generic.MethodGen.getMethod(MethodGen.java:697)


I've traced it down to my new cflow pointcut which targets a method in
classes implementating a specific interface, but the weaver throws the
exception if it tries to weave an abstract class implementing this
interface.

My pointcut:

/**
* Execution of any pcClearFields() methods within a newInstance as injected
by Kodo Enhancer
*/
@Pointcut("cflow(execution(*
org.apache.openjpa.enhance.PersistenceCapable+.pcNewInstance(..))) &&
execution(*
org.apache.openjpa.enhance.PersistenceCapable+.pcClearFields(..))")
public void kodoNewObject(){}


The weaver fails whenever it encounters an abstract class implementing
PersistenceCabaple without the pcNewInstance() method.

I'm not sure how to handle this.  There is no functional failure with the
LTW failing as a non-abstract class gets properly woven.  However, my logs
get polluted everytime the weaver tries to weave a such class and generates
a new ajcore..txt file everytime which will quickly fill my
directory.

AspectJ LTW is being used with LTW enabled ().

Given that I'm running the latest of the 1.8 branch, is there a way I can
simply tell me pointcut to not target abstract classes?  Is this even
feasible?

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://www.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Using AspectJ Aspect with CDI and dependency injection

[Eric B]

Hi Alex,

If you can share your maven config to get the two compilers to work
together nicely, that would be appreciated.  Which IDE do you use?  I
recently switched to IntelliJ to be more compatible with my team, and it
seems that it doesn't handle maven AJ compilation/weaving as
nicely/transparently as Eclipse does.  I tend to need to either launch the
maven compile process by hand, or manually activate a post-build trigger on
the maven-compile process.  Eclipse, on the other hand, "magically" uses
the ajc compiler instead of javac on a AspectJ faceted project without any
issues/worries.

I think I will need to revert to a factory based approach for the Aspect,
whereby I will manually "inject" the required dependencies.  I can at least
use DI to inject dependencies into my factory, and then use the aspectOf()
method to retrieve the Aspect and inject the appropriate fields/members
there.  It's the closest that I've been able to figure out.  Unfortunately,
I'm not able to retrieve everything from the joinpoint context, as I need
to access some services that aren't used by the target class, and hence,
aren't available through the JP.  However, they are in the application
context - hence the desire to have CDI inject the service into the Aspect
for me.

Thanks,

Eric


On Fri, Jul 13, 2018 at 1:04 AM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> I forgot to mention: Or can you get the dependencies your aspect needs to
> work with from the joinpoint context via args(), this(), target(),
> @annotation(), @target() etc.? This is what aspects usually do. What kind
> of dependency other than the ones available from the joinpoint context does
> the aspect need? And if it does need them, why? Maybe you should refactor
> your aspect in that case. A cross-cutting concern is usually be implemented
> with AOP because you want to avoid tangling, not because you want to
> increase it.
>
> Alexander Kriegisch schrieb am 13.07.2018 11:56:
>
> > Hi Eric,
> >
> > I usually do not disable Maven Compiler, I just configure it and AspectJ
> Maven
> > in a way so as not to interfere with each other. Let me know if you are
> > interested. But of course disabling Maven Compiler completely is a safe
> bet for
> > that kind of problem, too.
> >
> > As for your JEE/CDI problem: I am not a framework guy, I neither use
> Spring nor
> > JEE, mostly because programming is not my job (used to be 20 years ago)
> and I
> > just do it for fun. So maybe I am not the most qualified person to
> answer that.
> > But generally speaking, you already kinda nailed it: Aspect lifecycle is
> > handled by AJ, not via CDI. And frankly, I even think it shouldn't. We
> have a
> > bit of a hen and egg problem here, if you think about it. AOP is meant to
> > implement cross-cutting concerns, i.e. AOP needs "to be there first",
> > especially when thinking about AspectJ doing bytecode weaving during
> > class-loading, which is what you essentially do with LTW. So the weaving
> agent
> > needs to be up and running before any of the application classes are even
> > loaded into the JVM. Spring AOP is a different kind of beast because it
> uses
> > delegation via dynamic proxies, not bytecode weaving. Furthermore, a
> Spring
> > aspect is also a Spring component and only works for other Spring
> components,
> > i.e. there is a strong dependency on the surrounding framework.
> >
> > Maybe there is a way to get CDI working for aspects, but if there is,
> then only
> > in some kind of "lazy instantiation" scenario, i.e. aspect weaving and
> > class-loading is finished but DI into the aspect is only done later,
> e.g. when
> > the aspect first accesses the injected object. To me this feels a little
> creepy
> > though because suddenly the aspect would depend on the application and
> you
> > could run into issues with aspects that ought to be kicking in early,
> such as
> > logging or tracing. For aspects which are designed to only be used after
> the
> > application is already wired up, you might have a chance. Someone else
> might be
> > able to help you there. Does it work for you if you ask some kind of
> factory to
> > provide you with a dependency? I know, it is not DI and more difficult
> to test,
> > but you can still provide setters for the aspect's dependencies and then
> easily
> > unit-test the aspect, injecting mocks.
> >
> > Regards
> > --
> > Alexander Kriegisch
> > https://scrum-master.de
> >
> > Eric B schrieb am 13.07.2018 10:32:
> >>
> >> Hi Alex,
> >>
> >>
> >> Thanks fo

Re: [aspectj-users] Using AspectJ Aspect with CDI and dependency injection

[Eric B]

Hi Alex,

Thanks for pointing that out.  I can't believe I missed it.  I had
intentionally tried to disable the maven compiler using
-Dmaven.main.skip=true, but I must have forgotten to use it for this
attempt.

I'm still perturbed as to how to get CDI to inject an AJ aspect though.  I
cannot seem to find the magic solution (if one exists) to configure the
project such that I can get injections into my Aspect bean.  I'm using LTW
and realize that the lifecycle of the aspect is done via AJ and not through
CDI.  Nonetheless, in Spring, there is always the
SpringBeanAutowiringSupport utility that you can use to wire an existing
bean.  Do you know if there is anything equivalent in JEE to accomplish DI
in an Aspect?

Thanks,

Eric


On Thu, Jul 12, 2018 at 9:38 PM Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Hi Eric.
>
> The error comes from Maven Compiler, not from AspectJ Maven, i.e. Javac
> tries to compile something you probably want to be compiled by Ajc. Without
> seeing your POM I cannot say more, but the configuration with regard to
> those two plugins is probably the root cause of your problem.
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Eric B schrieb am 12.07.2018 23:22:
> >
> > I'm trying to figure out a way to inject dependencies into an Aspect that
> > is running under Wildfly 10 with CDI.
> >
> >
> > From what I can tell, by definition, I need to have a no-argument
> > constructor in the Aspect, which already implies AJ cannot support the
> > constructor injection pattern. Please correct me if I am mistaken.
> >
> >
> > Secondly, once I have fields annotated with @Inject, I'm not sure how to
> > tell CDI to inject beans into my aspect. If I remember correctly, in
> > Spring, I can use the .aspectOf() as a factory-method to declare the bean
> > to Spring. This was accomplished using XML definitions.
> >
> >
> > However, when I try to do something similar in CDI, using @Produces, it
> > does not seem to be work; the compiler throws errors that the .aspectOf()
> > method in my aspect does not exist.
> >
> >
> > > public classUserAccountAspectFactory {
> >
> > @Produces
> > publicUserAccountStatusAspect
> > injectUserAccountStatusAspectDependencies()throwsNoSuchMethodException,
> > InvocationTargetException, IllegalAccessException {
> > returnUserAccountStatusAspect.aspectOf();
> > }
> > }
> >
> >
> >
> >
> >> [ERROR] Failed to execute goal
> >> org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
> >> (default-compile) on project adams-aspects: Compilation failure
> >>
> >>
> >> [ERROR]
> >>
> /C:/dev/Projects/develop/aspects/src/main/java/model/interceptor/UserAccountAspectFactory.java:[11,39]
> >> cannot find symbol
> >>
> >>
> >> [ERROR] symbol: method aspectOf()
> >>
> >>
> >> [ERROR] location: class model.interceptor.UserAccountStatusAspect
> >>
> >>
> >> [ERROR]
> >>
> >>
> >> [ERROR] -> [Help 1]
> >>
> >
> > Which surprises me b/c when I look at the UserAccountStatusAspect.class
> > file, I see that ajc has added the .aspectOf() method to the compiled
> > class.
> >
> >
> > I'm obviously doing something wrong, but not quite sure what.
> >
> >
> > Can anyone point me in the right direction please?
> >
> >
> > 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

[aspectj-users] Using AspectJ Aspect with CDI and dependency injection

[Eric B]

I'm trying to figure out a way to inject dependencies into an Aspect that
is running under Wildfly 10 with CDI.

>From what I can tell, by definition, I need to have a no-argument
constructor in the Aspect, which already implies AJ cannot support the
constructor injection pattern.  Please correct me if I am mistaken.

Secondly, once I have fields annotated with @Inject, I'm not sure how to
tell CDI to inject beans into my aspect.  If I remember correctly, in
Spring, I can use the .aspectOf() as a factory-method to declare the bean
to Spring.  This was accomplished using XML definitions.

However, when I try to do something similar in CDI, using @Produces, it
does not seem to be work; the compiler throws errors that the .aspectOf()
method in my aspect does not exist.

public class UserAccountAspectFactory {

@Produces
public UserAccountStatusAspect
injectUserAccountStatusAspectDependencies() throws
NoSuchMethodException, InvocationTargetException,
IllegalAccessException {
return UserAccountStatusAspect.aspectOf();
}
}




[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.1:compile
(default-compile) on project adams-aspects: Compilation failure
[ERROR]
/C:/dev/Projects/develop/aspects/src/main/java/model/interceptor/UserAccountAspectFactory.java:[11,39]
cannot find symbol
[ERROR]   symbol:   method aspectOf()
[ERROR]   location: class model.interceptor.UserAccountStatusAspect
[ERROR]
[ERROR] -> [Help 1]



Which surprises me b/c when I look at the UserAccountStatusAspect.class
file, I see that ajc has added the .aspectOf() method to the compiled class.

I'm obviously doing something wrong, but not quite sure what.

Can anyone point me in the right direction please?

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

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?
>&g

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 asp

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

[Eric B]

ExceptionHandler' 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
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).



For some reason, the LTW thinks it should be weaving my
ClientErrorExceptionHandler (the aspect) even though it isn't part of my
aop.xml?  Is there a way to enable pointcut matching/debugging so I can see
which pointcut is triggering the reweaving/rewriting of this @Aspect class?

Thanks,

Eric



On Mon, Jun 11, 2018 at 6:29 PM Andy Clement 
wrote:

> 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

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

[Eric B]

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

Re: [aspectj-users] How to ensure AspectJ aspects are LTW'ed by Wildfly's modules?

[Eric B]

I did try with my aspect.jar on the bootclasspath with -Xbootclasspath/a (I
would be surprised if  /a or a /p would make a difference).  Didn't make
any difference.

I haven't tried posting on StackOverflow yet figuring that I would likely
get a more targeted response from here or the wildfly-dev forums.  But to
date, it's tough to reconcile information from the two independent camps. :)
I suspected that AJ just uses whatever classloader is provided to it.
That's kind of what it looked like to me.  But I couldn't/don't understand
how the Agent bootstraps though.  From what I can tell, its the base JVM's
classloader that calls the Agent premain, and instructs it to instrument
the classes.  In which case, I would expect any visibility of that
classloader to extend to AJ as well.

So given that the AJ Weaver doesn't find the classes, I figure that WF is
doing something with/to it.  But in that case, I dont understand at all how
the JVM's instrumentation works; I guess I'm confused where in the cycle
the instrumentation is called when loading classes.  Do you know if there
are any docs or whitepapers I can read up on how the
classloader/instrumentation cycle works?  I couldn't find enough clarity on
the Oracle site.

Thanks,

Eric

On Thu, Oct 26, 2017 at 3:07 PM, Andy Clement 
wrote:

> Did you try your aspect jar on the bootclasspath ? (Just wondering if that
> might help).
>
> AspectJ deliberately avoids getting involved in class loader shenanigans
> because it gets too complicated, hence relying on the delegation model in
> place for the system it is being used with.  However you make a ‘common
> jar’ available to all the individual module loaders in wildfly should work
> for AspectJ, unless they are handling delegation for classes differently to
> delegation for resource access. I don’t feel this is a new problem though,
> I feel it has come up again and again over the years - surely somebody
> solved it by now Did you try stack overflow? Sorry i don’t have any
> concrete answers.
>
> cheers,
> Andy
>
>
> On Oct 26, 2017, at 11:37 AM, Eric B  wrote:
>
> Thanks for the info.  I've been digging through AJ and WF code some more
> to try to figure this out, but am still not sure how the classloader is
> working.  I'm starting Wildfly using the following arguments:
>
> -Djboss.modules.system.pkgs=org.jboss.byteman,org.aspectj,te
> st.aspectj,org.jboss.logmanager
> -javaagent:c:/dev/tmp/jboss-eap-7.0.0/modules/system/layers/
> base/org/aspectj/main/aspectjweaver-1.8.10.jar
> -Dorg.aspectj.weaver.showWeaveInfo=true"
> -Dorg.aspectj.weaver.loadtime.configuration=file:c:/tmp/poc/aop.xml
> -cp C:/dev/Projects/jms/mixed-arch/ear-app/aspectj/target/aspect
> j-0.0.1-SNAPSHOT.jar
>
>
> So in it, I've defined an additional classpath pointing to my aspectj.jar
> file.  My /tmp/poc/aop.xml contains the aspect definition of "
> test.aspectj.TestAspect".
> I can now see that the AJ agent is looking for test.aspectj.TestAspect
> class.  But it still isn't able to find it; I get the following errors
> thrown my the AspectJ Weaver:
>
> 2017-10-26 12:11:39,889 ERROR [stderr] (MSC service thread 1-7)
> [ModuleClassLoader@336f62a1] info register aspect test.aspectj.TestAspect
> 2017-10-26 12:11:54,632 ERROR [stderr] (MSC service thread 1-7)
> [ModuleClassLoader@336f62a1] error The specified aspect
> 'test.aspectj.TestAspect' cannot be found
>
> I've confirmed that my class (test.aspectj.TestAspect) is indeed in the
> aspectj-0.0.1-SNAPSHOT.jar.
>
> So I get the impression that the aspectj-SNAPSHOT jar is not being made
> visible to the individual module classloaders.  I've tried to debug the
> weaver, and can see that it does indeed do the following:
>
> private URL toURL(String className) {
> URL url = (URL) nameMap.get(className);
> if (url == null) {
> String classFile = className.replace('.', '/');
> url = loaderRef.getClassLoader().getResource(classFile + ".class");
> nameMap.put(className, url);
> }
> return url;
> }
>
> where the loaderRef.getClassLoader() looks like it is the classloader that
> is passed to the ClassFileTransformer.transform() method (
> https://docs.oracle.com/javase/7/docs/api/java/lang/instrum
> ent/ClassFileTransformer.html).  But I'm not sure where/how to continue
> digging from here.  Which classloader is this?  Is this the base java
> classloader?  If Wildfly defines its own classloader (not sure if it does),
> will it be used instead?  On the other hand, if the base java classloader
> is passed, why is the classloader not able to find my
> test.aspectj.TestAspect class if it is in the jar that is part of my -cp
&g

Re: [aspectj-users] How to ensure AspectJ aspects are LTW'ed by Wildfly's modules?

[Eric B]

Thanks for the info.  I've been digging through AJ and WF code some more to
try to figure this out, but am still not sure how the classloader is
working.  I'm starting Wildfly using the following arguments:

-Djboss.modules.system.pkgs=org.jboss.byteman,org.aspectj,te
st.aspectj,org.jboss.logmanager
-javaagent:c:/dev/tmp/jboss-eap-7.0.0/modules/system/layers/
base/org/aspectj/main/aspectjweaver-1.8.10.jar
-Dorg.aspectj.weaver.showWeaveInfo=true"
-Dorg.aspectj.weaver.loadtime.configuration=file:c:/tmp/poc/aop.xml
-cp C:/dev/Projects/jms/mixed-arch/ear-app/aspectj/target/aspect
j-0.0.1-SNAPSHOT.jar


So in it, I've defined an additional classpath pointing to my aspectj.jar
file.  My /tmp/poc/aop.xml contains the aspect definition of "
test.aspectj.TestAspect".
I can now see that the AJ agent is looking for test.aspectj.TestAspect
class.  But it still isn't able to find it; I get the following errors
thrown my the AspectJ Weaver:

2017-10-26 12:11:39,889 ERROR [stderr] (MSC service thread 1-7)
[ModuleClassLoader@336f62a1] info register aspect test.aspectj.TestAspect
2017-10-26 12:11:54,632 ERROR [stderr] (MSC service thread 1-7)
[ModuleClassLoader@336f62a1] error The specified aspect
'test.aspectj.TestAspect' cannot be found

I've confirmed that my class (test.aspectj.TestAspect) is indeed in the
aspectj-0.0.1-SNAPSHOT.jar.

So I get the impression that the aspectj-SNAPSHOT jar is not being made
visible to the individual module classloaders.  I've tried to debug the
weaver, and can see that it does indeed do the following:

private URL toURL(String className) {
URL url = (URL) nameMap.get(className);
if (url == null) {
String classFile = className.replace('.', '/');
url = loaderRef.getClassLoader().getResource(classFile + ".class");
nameMap.put(className, url);
}
return url;
}

where the loaderRef.getClassLoader() looks like it is the classloader that
is passed to the ClassFileTransformer.transform() method (
https://docs.oracle.com/javase/7/docs/api/java/lang/instrum
ent/ClassFileTransformer.html).  But I'm not sure where/how to continue
digging from here.  Which classloader is this?  Is this the base java
classloader?  If Wildfly defines its own classloader (not sure if it does),
will it be used instead?  On the other hand, if the base java classloader
is passed, why is the classloader not able to find my
test.aspectj.TestAspect class if it is in the jar that is part of my -cp
arguments?


Thanks,

Eric

On Mon, Oct 23, 2017 at 1:45 PM, Andy Clement 
wrote:

> Yes, it is a bit specific to wildfly but I can talk to what AspectJ does.
> I will also call out to an old article I wrote on debugging LTW:
> http://andrewclement.blogspot.ca/2009/02/load-time-weaving-basics.html (might
> be useful).
>
> In the source for ClassLoaderWeavingAdaptor you will see three options for
> files we look for:
>
> META-INF/aop.xml  — the regular one
> META-INF/aop-ajc.xml — another option, useful in case you are using
> -outxml to generate the XML and don’t want to damage some user config you
> are maintaining (keep user stuff in aop-ajc.xml)
> org/aspectj/aop.xml — for OSGi usage but not specific to OSGi, can be used
> in other scenarios.
>
> Also in the same class you’ll see:
>
> *private* *final* *static* String *AOP_XML* = Constants.*AOP_USER_XML* +
> ";" + Constants.*AOP_AJC_XML* + ";" + Constants.*AOP_OSGI_XML*;
> String resourcePath = System.getProperty("org.aspectj.weaver.loadtime.
> configuration", *AOP_XML*);
>
> So you can override those 3 places and give it the path to something else
> if you want to by specifying that property. If the thing you provide starts
> with file then it will actually load direct from there:
>
> *if* (nextDefinition.startsWith("file:")) {
> *try* {
> String fpath = *new* URL(nextDefinition).getFile();
> File configFile = *new* File(fpath);
>
> If you just run default then it will be making calls to getClassLoader().
> getResources(name); for those three variants above. So you are at the
> mercy of whatever the class loader is allowing you to see.
>
> cheers,
> Andy
>
> On Oct 21, 2017, at 7:19 PM, Eric B  wrote:
>
> So this is probably more of a Wildfly question than an AspectJ question as
> such, and I have already asked the Wildfly team about it, but I thought I
> would try to get additional clarity from the AJ pros to understand exactly
> how the LTW agent works.
>
> My use case is that I want to use use AspectJ to advise some core classes
> in Wildfly/undertow.  Specifically, I'm trying to advise some of the
> Undertow HttpSession methods to get some more detailed logging when
> Sessions are created/expire/etc.
>
> To that extent, I've added AspectJ as a -javaagent which is launched on
> s

[aspectj-users] How to ensure AspectJ aspects are LTW'ed by Wildfly's modules?

[Eric B]

So this is probably more of a Wildfly question than an AspectJ question as
such, and I have already asked the Wildfly team about it, but I thought I
would try to get additional clarity from the AJ pros to understand exactly
how the LTW agent works.

My use case is that I want to use use AspectJ to advise some core classes
in Wildfly/undertow.  Specifically, I'm trying to advise some of the
Undertow HttpSession methods to get some more detailed logging when
Sessions are created/expire/etc.

To that extent, I've added AspectJ as a -javaagent which is launched on
startup of Wildfly.  I had to follow some of the steps listed at:
https://github.com/ChienChingLee/How-to-launch-Wildfly-9.0-with-AspectJ-1.8-LTW.
But it works; I can see that the AJ weaver is loaded and present.

My problem now has to do with the way that the Wildfly classloaders work.
>From my understanding, to avoid class conflict issues, the Application
Server is designed such that everything is broken down into individual
modules, with a separate classloader for each module.  Modules can declare
dependencies on other modules if they truly want/need to access classes
defined in a different module (see
https://docs.jboss.org/author/display/WFLY10/Class+Loading+in+WildFly)

I've tried to configure AJ to have the loader available to all modules, so
now my question is how does AJ detect Aspects in the classpath?  Where/how
does it search for the aop.xml file?  Does the weaver search every jar that
is in the classpath for these files?  How does it determine which files to
scan in the classpath?  Does it simply delegate that to the classloader?
(ie: Class.getResourceAsStream("aop.xml"))?  I haven't dug through the AJ
code to see exactly what it does.

Right now, I'm a little stuck in that I'm not sure how to ensure that my
Aspects are loaded with every module in WF.  I've managed to reconfigure a
single module and it works, but the idea of reconfiguring every module
individually doesn't make sense.

I tried to create an independent module in WF for it, and declaring it as a
global module but that didn't seem to work.

I tried to add it to the startup parameters in the WF startup configuration
file, specifying it as -classpath path/to/myaspect.jar, but that only
advised the startup WF (org.jboss) classes and none of the modules.

Can anyone shed some more light how the LTW works in order to search/find
and weave classes?  Or if anyone has any brilliant ideas how I can
configure my WF server such that I can drop my asepcts.jar in a "generic"
place to make it woven into every module, I would appreciate it.

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

Re: [aspectj-users] Aspectjweaver.jar outputting on stderr vs stdout

[Eric B]

I just created a ticket for it: https://bugs.eclipse.org/
bugs/show_bug.cgi?id=526344

Thanks,

Eric

On Sat, Oct 21, 2017 at 1:46 PM, Andy Clement 
wrote:

> I don’t think anything was done. I’ve been a bit heads down on AspectJ 9
> for the last little while. And if there isn’t a ticket, things tend to fall
> off the radar I’m afraid…  (And I don’t recall seeing one).
>
> cheers,
> Andy
>
> On Oct 20, 2017, at 10:37 AM, Eric B  wrote:
>
> Hi Andy,
>
> Was anything ever done about this, or a ticket opened for it?  I'm running
> AJ 1.8.10 and still seeing the same behaviour, so I figure it was probably
> never addressed (ticket or otherwise).
>
> Thanks,
>
> Eric
>
>
> On Thu, Oct 6, 2016 at 3:49 PM, Eric B  wrote:
>
>> Ok - thanks for the confirmation.  I will have to let the team know that
>> all ERROR logs are not actual ERROR logs, but only INFO logs.
>>
>> Eric
>>
>> On Thu, Oct 6, 2016 at 3:26 PM, Andy Clement 
>> wrote:
>>
>>> First time I've ever looked at that bit of code but I do see the code
>>> says this in the WeavingAdaptor:
>>>
>>> *protected* *void* *createMessageHandler*() {
>>> messageHolder = *new* WeavingAdaptorMessageHolder(*new*
>>> PrintWriter(System.*err*));
>>>
>>> So all messages sent to that message handler will go to System.err,
>>> regardless of severity. That seems a bit crappy. I guess presumably it was
>>> done to avoid messages messing up whatever your app was doing on System.out
>>> (possibly even just to make testing easier - look for app output on
>>> System.out and look for weaver output on System.err).
>>>
>>> It should be configurable but right now I can't see any way you can
>>> influence it.
>>>
>>> cheers,
>>> Andy
>>>
>>>
>>>
>>> On 6 October 2016 at 11:36, Eric B  wrote:
>>>
>>>> I'm using AspectJ 1.6 with JBoss 4.2.1 configured with LoadTimeWeaving.
>>>>
>>>> I have added the aspectjweaver.jar to the startup parameters:
>>>>  -javaagent:c:/dev/Java/aspectj1.6/lib/aspectjweaver.jar
>>>>
>>>> AspectJ is properly loaded and indeed is weaving my classes as
>>>> desired/expected.  However, any weaveinfo data that it is producing is
>>>> being logged as an "Error" as it appears in the stderr stream instead of
>>>> the stdout:
>>>>
>>>> 2016-10-06 13:31:40,310 ERROR [STDERR] [UnifiedClassLoader3@333cf5e3]
>>>> weaveinfo Join point 'method-call(business.impl.BusinessContext
>>>> business.ejb3.ManagerBean.getBusinessContext(izone.business.BusinessContextInfo))'
>>>> in Type 'business.ejb3.ManagerBean' (ManagerBean.java:112) advised by
>>>> afterThrowing advice from 'common.security.logger.AccessDeniedLoggerAspect'
>>>> (AccessDeniedLoggerAspect.java)
>>>>
>>>>
>>>> According to the JBoss documentation, System.err stream is redirected
>>>> into a category called STDERR, which is what I see above.
>>>>
>>>> Is there a way to configure the weaver to output on stdout instead?  Or
>>>> is it working this way by design?
>>>>
>>>> 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
>>>
>>
>>
> ___
> 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
>
___
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

Re: [aspectj-users] Aspectjweaver.jar outputting on stderr vs stdout

[Eric B]

Hi Andy,

Was anything ever done about this, or a ticket opened for it?  I'm running
AJ 1.8.10 and still seeing the same behaviour, so I figure it was probably
never addressed (ticket or otherwise).

Thanks,

Eric


On Thu, Oct 6, 2016 at 3:49 PM, Eric B  wrote:

> Ok - thanks for the confirmation.  I will have to let the team know that
> all ERROR logs are not actual ERROR logs, but only INFO logs.
>
> Eric
>
> On Thu, Oct 6, 2016 at 3:26 PM, Andy Clement 
> wrote:
>
>> First time I've ever looked at that bit of code but I do see the code
>> says this in the WeavingAdaptor:
>>
>> *protected* *void* *createMessageHandler*() {
>>
>> messageHolder = *new* WeavingAdaptorMessageHolder(*new*
>> PrintWriter(System.*err*));
>>
>> So all messages sent to that message handler will go to System.err,
>> regardless of severity. That seems a bit crappy. I guess presumably it was
>> done to avoid messages messing up whatever your app was doing on System.out
>> (possibly even just to make testing easier - look for app output on
>> System.out and look for weaver output on System.err).
>>
>> It should be configurable but right now I can't see any way you can
>> influence it.
>>
>> cheers,
>> Andy
>>
>>
>>
>> On 6 October 2016 at 11:36, Eric B  wrote:
>>
>>> I'm using AspectJ 1.6 with JBoss 4.2.1 configured with LoadTimeWeaving.
>>>
>>> I have added the aspectjweaver.jar to the startup parameters:
>>>  -javaagent:c:/dev/Java/aspectj1.6/lib/aspectjweaver.jar
>>>
>>> AspectJ is properly loaded and indeed is weaving my classes as
>>> desired/expected.  However, any weaveinfo data that it is producing is
>>> being logged as an "Error" as it appears in the stderr stream instead of
>>> the stdout:
>>>
>>> 2016-10-06 13:31:40,310 ERROR [STDERR] [UnifiedClassLoader3@333cf5e3]
>>> weaveinfo Join point 'method-call(business.impl.BusinessContext
>>> business.ejb3.ManagerBean.getBusinessContext(izone.business.BusinessContextInfo))'
>>> in Type 'business.ejb3.ManagerBean' (ManagerBean.java:112) advised by
>>> afterThrowing advice from 'common.security.logger.AccessDeniedLoggerAspect'
>>> (AccessDeniedLoggerAspect.java)
>>>
>>>
>>> According to the JBoss documentation, System.err stream is redirected
>>> into a category called STDERR, which is what I see above.
>>>
>>> Is there a way to configure the weaver to output on stdout instead?  Or
>>> is it working this way by design?
>>>
>>> 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
>>
>
>
___
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

Re: [aspectj-users] Enabling LTW dynamically without the -javaagent?

[Eric B]

Hi Alexander,

Thanks for the link/pointer.  I read through it, but am still unclear
how/where this becomes useful.  It is obvious how it can be used in a
standard console java application with a single "main" entry point.  This
would also apply to any self-contained Spring Boot applications (or their
equivalences).  But can something like this be used in any web container?
Be it a tomcat, jetty, wildfly, etc. ?  I don't know of a single entry
point, equivalent to a "main" in a console application.

>From what I understand from the release notes, any classes loaded prior to
the LTW agent being attached won't be woven.  So in the case of a JEE app
(ie: EJBs, etc), the container scans and loads beans in the Dependency tree
long before the application "starts".  So one would need to hook into the
classloading mechanism itself, or provide a custom classloader?  Do you
know if there is a mechanism to do this reliably?  I would obviously want
the Agent loaded as the first class in my EAR.

Thanks,

Eric

On Tue, Oct 17, 2017 at 6:00 PM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Hi Eric.
>
> I remember that one, Andy Clement accepted my corresponding patch a while
> ago.
>
> See https://www.eclipse.org/aspectj/doc/released/README-187.html.
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Am 17.10.2017 um 17:56 schrieb Eric B :
>
> Just a quick followup - this is JEE application - NOT a Spring
> application, if that makes any difference to enabling LTW dynamically.
>
> Thanks,
>
> Eric
>
>
> On Tue, Oct 17, 2017 at 11:54 AM, Eric B  wrote:
>
>> Hi,
>>
>> I recently read something on a Redhat tech doc (
>> https://access.redhat.com/solutions/328513) indicating that as of
>> AspectJ 1.8.7, one can enable LTW without using the javaagent on JVM
>> startup.  I've done a quick google search to see if I can find additional
>> documentation/references to this, but can't seem to find relevant links for
>> it.
>>
>> *Note:* The AspectJ 1.8.7 loadtime weaving agent can now be dynamically
>> attached to a JVM after it has started no need to use -javaagent just add
>> the AspectJ libs to the war lib folder.
>>
>> Can anyone provide me with more information as to what is required to
>> enable LTW in an EAR project?  Do I just have to drop the aspectjweaver.jar
>> in the EAR/lib folder?  What mechanism is being used to inject the weaving
>> agent?  Is there additional documentation in the AJ docs that pertains to
>> this that I missed?  I don't see anything on: https://www.eclipse.org/as
>> pectj/doc/released/devguide/ltw-configuration.html#enabling-
>> load-time-weaving
>>
>> 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
>
___
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

Re: [aspectj-users] Enabling LTW dynamically without the -javaagent?

[Eric B]

Just a quick followup - this is JEE application - NOT a Spring application,
if that makes any difference to enabling LTW dynamically.

Thanks,

Eric


On Tue, Oct 17, 2017 at 11:54 AM, Eric B  wrote:

> Hi,
>
> I recently read something on a Redhat tech doc (https://access.redhat.com/
> solutions/328513) indicating that as of AspectJ 1.8.7, one can enable LTW
> without using the javaagent on JVM startup.  I've done a quick google
> search to see if I can find additional documentation/references to this,
> but can't seem to find relevant links for it.
>
> *Note:* The AspectJ 1.8.7 loadtime weaving agent can now be dynamically
> attached to a JVM after it has started no need to use -javaagent just add
> the AspectJ libs to the war lib folder.
>
> Can anyone provide me with more information as to what is required to
> enable LTW in an EAR project?  Do I just have to drop the aspectjweaver.jar
> in the EAR/lib folder?  What mechanism is being used to inject the weaving
> agent?  Is there additional documentation in the AJ docs that pertains to
> this that I missed?  I don't see anything on: https://www.eclipse.org/
> aspectj/doc/released/devguide/ltw-configuration.html#
> enabling-load-time-weaving
>
> 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] Enabling LTW dynamically without the -javaagent?

[Eric B]

Hi,

I recently read something on a Redhat tech doc (
https://access.redhat.com/solutions/328513) indicating that as of AspectJ
1.8.7, one can enable LTW without using the javaagent on JVM startup.  I've
done a quick google search to see if I can find additional
documentation/references to this, but can't seem to find relevant links for
it.

*Note:* The AspectJ 1.8.7 loadtime weaving agent can now be dynamically
attached to a JVM after it has started no need to use -javaagent just add
the AspectJ libs to the war lib folder.

Can anyone provide me with more information as to what is required to
enable LTW in an EAR project?  Do I just have to drop the aspectjweaver.jar
in the EAR/lib folder?  What mechanism is being used to inject the weaving
agent?  Is there additional documentation in the AJ docs that pertains to
this that I missed?  I don't see anything on:
https://www.eclipse.org/aspectj/doc/released/devguide/ltw-configuration.html#enabling-load-time-weaving

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] Where is the recommended place to put aspectjweaver.jar - web container or application or both?

[Eric B]

I'm trying to use LTW in Wildfly 10, and running into an interesting
quandry with the classloader/module structure.  In WF10, class loading is
based on modules that have to define explicit dependencies on other modules
(similar in concept to Jigsaw classloader I believe).

So in order to launch my EAR with LTW enabled, I need to first define the
javaagent as a JAVA_OPTS passed to Wildfly on startup.  Which means the
aspectjweaver.jar has to be available somewhere.

However, when my application itself loads, the classloader also needs a
visibility on the aspectjweaver.jar file.  Without it, I get the following
error message.

15:13:36,849 ERROR [stderr] (MSC service thread 1-1)
[ModuleClassLoader@17d1e6a3] warning define generated class failed --
(NoClassDefFoundError) org/aspectj/runtime/internal/AroundClosure
15:13:36,850 ERROR [stderr] (MSC service thread 1-1)
org/aspectj/runtime/internal/AroundClosure
15:13:36,850 ERROR [stderr] (MSC service thread 1-1)
java.lang.NoClassDefFoundError: org/aspectj/runtime/internal/AroundClosure
15:13:36,850 ERROR [stderr] (MSC service thread 1-1)at
java.lang.ClassLoader.defineClass1(Native Method)


That make sense to me, since by default, the classloader for my application
will not have visibility to the container classloader, unless defined
explicitly.  Plus, I do not have the aspectjweaver.jar bundled in my
application.

So I have 2 choices:
1) bundle the ajweaver.jar in my EAR/lib folder
2) add ajweaver.jar as a module in Wildfly and create a dependency on it
for my application


What is the recommended approach?   In case:
1)  I still have to make the jar available to the container for the
javaagent weaver to be available to the JVM on container startup.

2) I could potentially have different EARs each with different AJ versions
bundled


Am I able to use the javaagent of one version of AJ with a different
version of AJ bundled with the EAR?

Does it make more logical sense to have the LTW library (ie: ajweaver.jar)
bundled in the container and exposed, or simply wrapped up in the EAR
itself?

Or am I just splitting hairs?


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

Re: [aspectj-users] Missing stackmap generation for woven code

[Eric B]

Yes - I'm building with JDK 1.8.  If it is helpful, I can try to put
together a POC to demonstrate the issue, but not sure how easy that will be
to do.

I suspect (although not sure why) that AJ is failing might have something
to do with running the entire build with the -noverify flag (so the classes
are generated and enhanced without updating the stackmap, and then AJC is
run within the same -noverify jvm).  If I remove the -noverify flag and
only run the AJC part, the error disappears.  But of course, my problem
stems that I can't compile my persistence layer module without the
-noverify flag (uses Java7+ code) or my persistence enhancer generates
invalid stackmaps that break later processes.

I am working on updating the enhancer library to regenerate the stackmap in
the meantime to "fix it properly" ish.

Thanks,

Eric

On Thu, Oct 12, 2017 at 12:45 PM, Andy Clement 
wrote:

> You are only able to turn off the stackmap generation if targeting 1.6
> because that is the level where they were optional.
> (-Xset:generateStackMaps=false) at targets 1.7 and above your error
> indicates this code is failing:
>
>
> *try* {
>
> Class reader = Class.forName("aj.org.objectweb.asm.ClassReader");
>
> Class visitor = Class.forName("aj.org.objectweb.asm.ClassVisitor");
>
> Method m = reader.getMethod("accept", *new* Class[] { visitor, Integer.
> *TYPE* });
>
> isAsmAround = m != *null*;
>
> } *catch* (Exception e) {
>
> isAsmAround = *false*;
>
> }
>
> For some reason we can't find those classes even though they should be in
> the AspectJ jars you are using? (You could check your 1.8.10 artifacts
> include them... but I can't see why not).  There is a 1.8.11 you could also
> try but the packaging has not changed there. I am confused why the check
> above is failing for you. You could raise an issue but without being able
> to recreate I'm not sure how I'd diagnose things.  What JDK are you running
> the build itself on, 1.8 I presume?
>
> cheers,
> Andy
>
> On 10 October 2017 at 20:06, Eric B  wrote:
>
>> Thanks Andy!
>>
>> I'll take a look into this and see if I can leverage it for my own use
>> case.
>>
>> Also, please let me know if the Error that I am seeing is a bug in AJ, or
>> expected behaviour.  Do you need me to open a ticket for that?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Tue, Oct 10, 2017 at 3:34 PM, Andy Clement 
>> wrote:
>>
>>> The very basic visitor AspectJ uses is here: https://github.com/eclip
>>> se/org.aspectj/blob/6d6738cfece6328027916681e67e54225531db38
>>> /weaver/src/org/aspectj/weaver/bcel/asm/StackMapAdder.java
>>>
>>> cheers,
>>> Andy
>>>
>>> On 10 October 2017 at 12:32, Andy Clement 
>>> wrote:
>>>
>>>> Hey Eric,
>>>>
>>>> The error above is saying it can't find the asm rather than that there
>>>> is an issue with missing stack maps. Although possibly the error is
>>>> occurring because as a side effect of the missing stack maps, I'd need to
>>>> check.
>>>>
>>>> > Are there libraries to manipulate/generate a stackmap?
>>>>
>>>> This is exactly what AspectJ is using Asm for. We weave/modify the
>>>> bytecode and rather than incrementally try and patch up the stack maps, we
>>>> just generate entirely fresh ones at the end of the process. A very basic
>>>> Asm visitor to read/write the bytecode will produce them.  Which is why I'm
>>>> surprised about the message - we aren't looking for existing ones to fix
>>>> up, we are just looking for that version of asm to write out entirely new
>>>> ones.
>>>>
>>>> cheers,
>>>> Andy
>>>>
>>>>
>>>> On 7 October 2017 at 05:49, Eric B  wrote:
>>>>
>>>>> While I don't disagree with your answer, I dont have the first clue
>>>>> how to fix a legacy jdo library (circa 2004) that performs byte 
>>>>> enhancement
>>>>> and does not write the stackmap.Are there libraries to
>>>>> manipulate/generate a stackmap?
>>>>>
>>>>> Is there anything else can I do in the meantime to unblock the
>>>>> situation?
>>>>>
>>>>> Thanks
>>>>> Eric
>>>>>
>>>>>
>>>>> On Oct 7, 2017 12:11 AM, "Alexander Kriegisch" <
>>>>> alexan...@kriegisch.name> wrote:
>>>>>

Re: [aspectj-users] Missing stackmap generation for woven code

[Eric B]

Thanks Andy!

I'll take a look into this and see if I can leverage it for my own use case.

Also, please let me know if the Error that I am seeing is a bug in AJ, or
expected behaviour.  Do you need me to open a ticket for that?

Thanks,

Eric


On Tue, Oct 10, 2017 at 3:34 PM, Andy Clement 
wrote:

> The very basic visitor AspectJ uses is here: https://github.com/
> eclipse/org.aspectj/blob/6d6738cfece6328027916681e67e54
> 225531db38/weaver/src/org/aspectj/weaver/bcel/asm/StackMapAdder.java
>
> cheers,
> Andy
>
> On 10 October 2017 at 12:32, Andy Clement 
> wrote:
>
>> Hey Eric,
>>
>> The error above is saying it can't find the asm rather than that there is
>> an issue with missing stack maps. Although possibly the error is occurring
>> because as a side effect of the missing stack maps, I'd need to check.
>>
>> > Are there libraries to manipulate/generate a stackmap?
>>
>> This is exactly what AspectJ is using Asm for. We weave/modify the
>> bytecode and rather than incrementally try and patch up the stack maps, we
>> just generate entirely fresh ones at the end of the process. A very basic
>> Asm visitor to read/write the bytecode will produce them.  Which is why I'm
>> surprised about the message - we aren't looking for existing ones to fix
>> up, we are just looking for that version of asm to write out entirely new
>> ones.
>>
>> cheers,
>> Andy
>>
>>
>> On 7 October 2017 at 05:49, Eric B  wrote:
>>
>>> While I don't disagree with your answer, I dont have the first clue how
>>> to fix a legacy jdo library (circa 2004) that performs byte enhancement and
>>> does not write the stackmap.Are there libraries to manipulate/generate
>>> a stackmap?
>>>
>>> Is there anything else can I do in the meantime to unblock the
>>> situation?
>>>
>>> Thanks
>>> Eric
>>>
>>>
>>> On Oct 7, 2017 12:11 AM, "Alexander Kriegisch" 
>>> wrote:
>>>
>>> I know that this is not the answer you are looking for, but my
>>> suggestion is to heal the illness instead of taking pills against its
>>> symptoms. Go fix your problem in the other module which requires noverify
>>> in the first place. Generating broken bytecode does not sound like a wise
>>> approach to me.
>>>
>>> --
>>> Alexander Kriegisch
>>>
>>>
>>> > Am 07.10.2017 um 02:55 schrieb Eric B :
>>> >
>>> > I'm running into a problem with AspectJ 1.8.10, and not sure how to
>>> resolve this.
>>> >
>>> > I have a multi-module maven build.  One of my modules requires running
>>> an ant task (using the antrun-maven-plugin) with the jvm -noverify flag.
>>> Consequently, I run the entire maven build using the -noverify flag.
>>> >
>>> > However, my last module in my build is an AspectJ module.  When I try
>>> to compile it using the aspectj-maven-plugin, I get the following error
>>> thrown:
>>> >
>>> > [ERROR] Failed to execute goal 
>>> > org.codehaus.mojo:aspectj-maven-plugin:1.10:compile
>>> (default) on project adams-aspects: AJC compiler errors:
>>> > [ERROR] abort ABORT -- (BCException) Unable to find Asm for stackmap
>>> generation (Looking for 'aj.org.objectweb.asm.ClassReader'). Stackmap
>>> generation for woven code is required to avoid verify errors on a Java 1.7
>>> or higher runtime
>>> > [ERROR] when weaving type webapp.tiles.AthleteBasedForm
>>> > [ERROR] when weaving classes
>>> > [ERROR] when weaving
>>> > [ERROR] when batch building BuildConfig[null] #Files=8 AopXmls=#0
>>> > [ERROR]
>>> >
>>> >
>>> > So I'm a bit in a bind.  I can't figure out any way to reconcile both
>>> requirements - that module1 needs to run a plugin with the -noverify
>>> parameter, and the aspectj plugin that needs to run it without.
>>> >
>>> > Is there anyway I can disable the need for the stackmap generation to
>>> exist in AJ 1.8.10?  I've looked for parameters I can pass to ajc but can't
>>> find any.
>>> >
>>> > Thanks,
>>> >
>>> > Eric
>>> >
>>> > ___
>>> > aspectj-users mailing list
>>> > aspectj-users@eclipse.org
>>> > To change your delivery options, retrieve your passwor

Re: [aspectj-users] Missing stackmap generation for woven code

[Eric B]

In the last couple of days, I've been trying to read up on ASM,
ClassWriter, ClassReader, Visitors (and Visitor pattern), etc.  And
although I'm understanding more about how these things work, I'm still a
little bit at a loss how to write a simple ClassReader and rewrite it with
a proper stackmap.  I've seen that the ClassReader has a parameter to
ignore stackmaps, and ClassWriter has one to write the stackmap, but now I
just have to figure out the missing glue logic - there doesn't seem to be
an obvious way to read and entire class and rewrite it.  I seem to have to
identify each part of the class individually (ie: methods, fields,
constants, etc).  So I'm sure I'm missing something.  I hoped it would be a
lot easier to simply say something like : ClassWriter.write (
ClassReader.readClass( MyClass.class) ), but it doesn't seem to be so
straightforward.

As for the library in question, it's an ancient persistence library called
Kodo.  It uses (is backed?) by OpenJPA 0.9.5-incubating - just to give an
idea how old this product is.  For those who haven't heard of Kodo before
(I had never heard of it before starting on this project), it was a
commercial implementation of JDO before JPA was even released.  Produced by
a company called Solarmetrics, which was then bought by BEA, and then
acquired by Oracle.  The product has been dead for 10 years already.

As part of the JDO build process, there is a class enhancer which updates
all the persistent classes, adding FK fields, mappings between classes,
etc.  This build process is in the form of an ant task.  I have since
managed to wrap the ant process in an antrun plugin to make it "maven-ish",
but haven't been able to properly debug the process to fully understand
what it is doing.  I have dug out what I think is the class though
: org.apache.openjpa.enhance.PCEnhancer.  This class uses Serp (also
produced by BEA, I think) as the bytecode manipualtion library.  Current
version I'm using is Serp 1.13.  I can't tell if newer Serp generates the
stackmap or not, but I did determine that newer versions of OpenJPA (ie:
v2+) introduced ASM to update the stackmap after Serp (kind of like what
I'm looking to do).  I'm trying to copy that magic now, but it's more
involved that I would have liked (includes reverse engineering the ant
plugin to rebuild it as a maven plugin, etc).

If anyone can assist me, I'd be happy to learn more about bytecode
manipulation, etc.  I've been a longtime user of AJ, but I've never really
looked at how it does its magic.

Thanks,

Eric

On Sun, Oct 8, 2017 at 8:26 AM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> I do hope that someone can help you with that, Eric. But just in case
> nobody can, I think a software developer should always strive to improve
> the status quo and always have a plan B.
>
> Having said that, I think that a JDO lib from 2004 sounds like a good
> reason to either upgrade it or get rid of it. The former is probably not an
> option because I assume you would have done so already if it was that
> simple. But maybe it is an option. I also think your odds would be much
> better if you named the library and its version here instead of keeping it
> secret. Maybe someone has migrated it before and can help you with a hint
> on how to do so with as little pain as possible.
>
> Other ways to get rid of the library would be to patch it if you have
> access to the source code. Or maybe the lib itself uses something like asm
> or BCEL under the hood and you can upgrade the dependency, maybe getting
> more standardised class files as a result. Or - my favourite idea because
> it sounds fun to implement - you could consider to reimplement the JDO
> functionalities by yourself via **AspectJ**! You would have ITD and alll
> the other nice tools at your disposal. Hell, if I was not so busy, I would
> even like to give it a try myself. :-)
>
> Good luck
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Am 07.10.2017 um 19:49 schrieb Eric B :
>
> While I don't disagree with your answer, I dont have the first clue how to
> fix a legacy jdo library (circa 2004) that performs byte enhancement and
> does not write the stackmap.Are there libraries to manipulate/generate
> a stackmap?
>
> Is there anything else can I do in the meantime to unblock the situation?
>
> Thanks
> Eric
>
>
> On Oct 7, 2017 12:11 AM, "Alexander Kriegisch" 
> wrote:
>
> I know that this is not the answer you are looking for, but my suggestion
> is to heal the illness instead of taking pills against its symptoms. Go fix
> your problem in the other module which requires noverify in the first
> place. Generating broken bytecode does not sound like a wise approach to me.
>
> --

Re: [aspectj-users] Missing stackmap generation for woven code

[Eric B]

While I don't disagree with your answer, I dont have the first clue how to
fix a legacy jdo library (circa 2004) that performs byte enhancement and
does not write the stackmap.Are there libraries to manipulate/generate
a stackmap?

Is there anything else can I do in the meantime to unblock the situation?

Thanks
Eric


On Oct 7, 2017 12:11 AM, "Alexander Kriegisch" 
wrote:

I know that this is not the answer you are looking for, but my suggestion
is to heal the illness instead of taking pills against its symptoms. Go fix
your problem in the other module which requires noverify in the first
place. Generating broken bytecode does not sound like a wise approach to me.

--
Alexander Kriegisch


> Am 07.10.2017 um 02:55 schrieb Eric B :
>
> I'm running into a problem with AspectJ 1.8.10, and not sure how to
resolve this.
>
> I have a multi-module maven build.  One of my modules requires running an
ant task (using the antrun-maven-plugin) with the jvm -noverify flag.
Consequently, I run the entire maven build using the -noverify flag.
>
> However, my last module in my build is an AspectJ module.  When I try to
compile it using the aspectj-maven-plugin, I get the following error thrown:
>
> [ERROR] Failed to execute goal 
> org.codehaus.mojo:aspectj-maven-plugin:1.10:compile
(default) on project adams-aspects: AJC compiler errors:
> [ERROR] abort ABORT -- (BCException) Unable to find Asm for stackmap
generation (Looking for 'aj.org.objectweb.asm.ClassReader'). Stackmap
generation for woven code is required to avoid verify errors on a Java 1.7
or higher runtime
> [ERROR] when weaving type webapp.tiles.AthleteBasedForm
> [ERROR] when weaving classes
> [ERROR] when weaving
> [ERROR] when batch building BuildConfig[null] #Files=8 AopXmls=#0
> [ERROR]
>
>
> So I'm a bit in a bind.  I can't figure out any way to reconcile both
requirements - that module1 needs to run a plugin with the -noverify
parameter, and the aspectj plugin that needs to run it without.
>
> Is there anyway I can disable the need for the stackmap generation to
exist in AJ 1.8.10?  I've looked for parameters I can pass to ajc but can't
find any.
>
> 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
___
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] Missing stackmap generation for woven code

[Eric B]

I'm running into a problem with AspectJ 1.8.10, and not sure how to resolve
this.

I have a multi-module maven build.  One of my modules requires running an
ant task (using the antrun-maven-plugin) with the jvm -noverify flag.
Consequently, I run the entire maven build using the -noverify flag.

However, my last module in my build is an AspectJ module.  When I try to
compile it using the aspectj-maven-plugin, I get the following error thrown:

[ERROR] Failed to execute goal
org.codehaus.mojo:aspectj-maven-plugin:1.10:compile (default) on project
adams-aspects: AJC compiler errors:
[ERROR] abort ABORT -- (BCException) Unable to find Asm for stackmap
generation (Looking for 'aj.org.objectweb.asm.ClassReader'). Stackmap
generation for woven code is required to avoid verify errors on a Java 1.7
or higher runtime
[ERROR] when weaving type webapp.tiles.AthleteBasedForm
[ERROR] when weaving classes
[ERROR] when weaving
[ERROR] when batch building BuildConfig[null] #Files=8 AopXmls=#0
[ERROR]


So I'm a bit in a bind.  I can't figure out any way to reconcile both
requirements - that module1 needs to run a plugin with the -noverify
parameter, and the aspectj plugin that needs to run it without.

Is there anyway I can disable the need for the stackmap generation to exist
in AJ 1.8.10?  I've looked for parameters I can pass to ajc but can't find
any.

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] Do cflow targets need to be woven?

[Eric B]

I'm trying to use cflow to limit the scope of my pointcut, but it when I
add the cflow argument, the pointcut is not intercepting the call at all.
In my build process, the cflow target is not part of the weaving at all.
Does the cflow target need to be part of the build/weave process?  Or is my
pointcut wrong?

@Aspect
class MultiChoiceNullAspect{
@Pointcut("cflowbelow(execution( void
javax.faces.webapp.FacesServlet.service(..) ) &&
!within(MultiChoiceNullAspect))")
public void facesServletCFlow(){}
@Pointcut("facesServletCFlow() && execution( public
org.model.questionnaire.MultiChoiceItem* get*(..))")
public void multiChoiceObjects() {}
@Around("multiChoiceObjects()")
public Object emptyMultiChoice( final ProceedingJoinPoint pjp) throws
Throwable{
Object o = pjp.proceed();
// if the return object is null, create an empty MultiChoice object instead
if( o == null ){
return new MultiChoiceItem();
}

return o;
}
}



And my build instructions:

org.codehaus.mojo
aspectj-maven-plugin
1.10

true
${java.version}
${java.version}
${java.version}
UTF-8




compile
test-compile





org.aspectj
aspectjtools
${aspectj.version}






Essentially, I'm trying to advise the execution of all getters that return
MultiChoiceItem* when they are as part of the
javax.faces.webapp.FacesServlet.service() method/flow.

Does the FacesServlet class need to be passed to the ajc compiler as well?
Or are the cflow() arguments just evaluated at runtime and don't need to be
present in the compiler?  If the later, what am I doing wrong - why is my
pointcut not triggering?

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

Re: [aspectj-users] AspectJ pointcut matching arguments (args()) is not matching correctly

[Eric B]

Thanks Andy.

Indeed - separate pointcuts is exactly what I ended up doing; it just makes
the code feel a little more cluttered.

A bug has been raised here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=509235

Thanks,

Eric


On Tue, Dec 13, 2016 at 5:36 PM, Andy Clement 
wrote:

> Hi Eric,
>
> I was half surprised you didn't get a compiler warning/error that it
> didn't like your alternatives for binding - to be clear, there is nothing
> wrong with them theoretically, but I thought the compiler would say it
> doesn't support doing that. But I just crafted a small similar program and
> it does what you describe. So definitely an issue - it should either work
> or you get told it isn't supported. But it shouldn't silently do the wrong
> thing.  My test program:
>
> ---
> public class Code {
>   public static void main(String []argv) {
> foo("fooname",1,2,3);
> bar("barone","bartwo","barname",1,2,3);
>   }
>
>   public static void foo(String username, int i, int j, int k) {}
>
>   public static void bar(String a, String b, String username, int i, int
> j, int k) { }
> }
>
> aspect X {
>   before(String username): (execution(public static * foo(..)) &&
> args(username,..)) ||
>(execution(public static * bar(..)) &&
> args(*,*,username,..)) {
> System.out.println("username = "+username);
>   }
> }
> ---
>
> prints
>
> username = fooname
> username = barone
>
> Please raise an issue on: https://bugs.eclipse.org/
> bugs/enter_bug.cgi?product=AspectJ
>
> I'm suspecting the pointcut validation and rewriting that goes on. I'm
> sure you know what the workaround is. Just have two pieces of advice with
> different pointcuts attached.
>
> Andy
>
>
> On 13 December 2016 at 13:02, Eric B  wrote:
>
>> A few more tests and, not surprisingly, I got no further:
>> @Pointcut("execution(public static * business.security.service.Logi
>> nManagerHelper.authenticateUser(..)) && args( username, ..)")
>> public void authenticateUser(String username){}
>>
>> @Pointcut("execution(public static * 
>> webapp.util.LoginManagerAction.loginJAAS(..))
>> && args( *, *, username, ..)" )
>> public void loginJAAS(String username) {}
>> @Before("authenticateUser(username) || loginJAAS(username)" )
>> public void setUsername(JoinPoint jp, String username) {
>> // inject the username into the MDC
>> MDCUtils.setUsername(username);
>> }
>>
>>
>> Not surprisingly, this produces the exact same results.
>>
>> Is this a bug, or just me doing this incorrectly?
>>
>> Thanks,
>> Eric
>>
>>
>> On Tue, Dec 13, 2016 at 3:25 PM, Eric B  wrote:
>>
>>> Hi,
>>>
>>> I just posted this on StackOverflow, but then realized I might have
>>> better success asking a specific question like this here:
>>>
>>> I've got an pointcut that I am trying to use with LTW.  I have 2 methods
>>> that I am trying to advise, each with a different parameter list.  However,
>>> they both have a single common parameter that I want.
>>>
>>> These are the method signatures I want to advise:
>>>
>>>public static WorkflowModifierFlags authenticateUser(String
>>> username, String password, String ip, boolean webGUI, boolean
>>> realAuthentication)
>>>
>>>public static boolean loginJAAS(HttpServletRequest request,
>>> HttpServletResponse response, String username, String password, HttpSession
>>> session)
>>>
>>>
>>> I've tried the following pointcut/advice, but it is failing; the
>>> username variable is sometimes getting injected with the IP address (ie:
>>> the args() from the first pointcut).
>>>
>>> @Before("(execution(public static * business.security.service.Logi
>>> nManagerHelper.authenticateUser(..)) && args( username, ..)) || "
>>> + "(execution(public static * 
>>> webapp.util.LoginManagerAction.loginJAAS(..))
>>> && args( *, *, username, ..))" )
>>> public void setUsername(JoinPoint jp, String username) {
>>> // inject the username into the MDC
>>> MDCUtils.setUsername(username);
>>> }
>>>
>>>
>>> I would have expected that the `args()` parameter is associated to the
>>> execution() method, but sometimes it would appear that it is "confused",
>>> and giv

Re: [aspectj-users] AspectJ pointcut matching arguments (args()) is not matching correctly

[Eric B]

A few more tests and, not surprisingly, I got no further:
@Pointcut("execution(public static *
business.security.service.LoginManagerHelper.authenticateUser(..)) && args(
username, ..)")
public void authenticateUser(String username){}

@Pointcut("execution(public static *
webapp.util.LoginManagerAction.loginJAAS(..)) && args( *, *, username, ..)"
)
public void loginJAAS(String username) {}
@Before("authenticateUser(username) || loginJAAS(username)" )
public void setUsername(JoinPoint jp, String username) {
// inject the username into the MDC
MDCUtils.setUsername(username);
}


Not surprisingly, this produces the exact same results.

Is this a bug, or just me doing this incorrectly?

Thanks,
Eric


On Tue, Dec 13, 2016 at 3:25 PM, Eric B  wrote:

> Hi,
>
> I just posted this on StackOverflow, but then realized I might have better
> success asking a specific question like this here:
>
> I've got an pointcut that I am trying to use with LTW.  I have 2 methods
> that I am trying to advise, each with a different parameter list.  However,
> they both have a single common parameter that I want.
>
> These are the method signatures I want to advise:
>
>public static WorkflowModifierFlags authenticateUser(String
> username, String password, String ip, boolean webGUI, boolean
> realAuthentication)
>
>public static boolean loginJAAS(HttpServletRequest request,
> HttpServletResponse response, String username, String password, HttpSession
> session)
>
>
> I've tried the following pointcut/advice, but it is failing; the username
> variable is sometimes getting injected with the IP address (ie: the args()
> from the first pointcut).
>
> @Before("(execution(public static * business.security.service.
> LoginManagerHelper.authenticateUser(..)) && args( username, ..)) || "
> + "(execution(public static * webapp.util.
> LoginManagerAction.loginJAAS(..)) && args( *, *, username, ..))" )
> public void setUsername(JoinPoint jp, String username) {
> // inject the username into the MDC
> MDCUtils.setUsername(username);
> }
>
>
> I would have expected that the `args()` parameter is associated to the
> execution() method, but sometimes it would appear that it is "confused",
> and gives me the IP instead of the username.
>
> Am I using AspectJ incorrectly, or is this a bug in the LTW?  I'm running
> AspectJ 1.6.13.
>
> 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] AspectJ pointcut matching arguments (args()) is not matching correctly

[Eric B]

Hi,

I just posted this on StackOverflow, but then realized I might have better
success asking a specific question like this here:

I've got an pointcut that I am trying to use with LTW.  I have 2 methods
that I am trying to advise, each with a different parameter list.  However,
they both have a single common parameter that I want.

These are the method signatures I want to advise:

   public static WorkflowModifierFlags authenticateUser(String
username, String password, String ip, boolean webGUI, boolean
realAuthentication)

   public static boolean loginJAAS(HttpServletRequest request,
HttpServletResponse response, String username, String password, HttpSession
session)


I've tried the following pointcut/advice, but it is failing; the username
variable is sometimes getting injected with the IP address (ie: the args()
from the first pointcut).

@Before("(execution(public static *
business.security.service.LoginManagerHelper.authenticateUser(..)) && args(
username, ..)) || "
+ "(execution(public static *
webapp.util.LoginManagerAction.loginJAAS(..)) && args( *, *, username,
..))" )
public void setUsername(JoinPoint jp, String username) {
// inject the username into the MDC
MDCUtils.setUsername(username);
}


I would have expected that the `args()` parameter is associated to the
execution() method, but sometimes it would appear that it is "confused",
and gives me the IP instead of the username.

Am I using AspectJ incorrectly, or is this a bug in the LTW?  I'm running
AspectJ 1.6.13.

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

Re: [aspectj-users] Aspectjweaver.jar outputting on stderr vs stdout

[Eric B]

Ok - thanks for the confirmation.  I will have to let the team know that
all ERROR logs are not actual ERROR logs, but only INFO logs.

Eric

On Thu, Oct 6, 2016 at 3:26 PM, Andy Clement 
wrote:

> First time I've ever looked at that bit of code but I do see the code says
> this in the WeavingAdaptor:
>
> *protected* *void* *createMessageHandler*() {
>
> messageHolder = *new* WeavingAdaptorMessageHolder(*new*
> PrintWriter(System.*err*));
>
> So all messages sent to that message handler will go to System.err,
> regardless of severity. That seems a bit crappy. I guess presumably it was
> done to avoid messages messing up whatever your app was doing on System.out
> (possibly even just to make testing easier - look for app output on
> System.out and look for weaver output on System.err).
>
> It should be configurable but right now I can't see any way you can
> influence it.
>
> cheers,
> Andy
>
>
>
> On 6 October 2016 at 11:36, Eric B  wrote:
>
>> I'm using AspectJ 1.6 with JBoss 4.2.1 configured with LoadTimeWeaving.
>>
>> I have added the aspectjweaver.jar to the startup parameters:
>>  -javaagent:c:/dev/Java/aspectj1.6/lib/aspectjweaver.jar
>>
>> AspectJ is properly loaded and indeed is weaving my classes as
>> desired/expected.  However, any weaveinfo data that it is producing is
>> being logged as an "Error" as it appears in the stderr stream instead of
>> the stdout:
>>
>> 2016-10-06 13:31:40,310 ERROR [STDERR] [UnifiedClassLoader3@333cf5e3]
>> weaveinfo Join point 'method-call(business.impl.BusinessContext
>> business.ejb3.ManagerBean.getBusinessContext(izone.business.BusinessContextInfo))'
>> in Type 'business.ejb3.ManagerBean' (ManagerBean.java:112) advised by
>> afterThrowing advice from 'common.security.logger.AccessDeniedLoggerAspect'
>> (AccessDeniedLoggerAspect.java)
>>
>>
>> According to the JBoss documentation, System.err stream is redirected
>> into a category called STDERR, which is what I see above.
>>
>> Is there a way to configure the weaver to output on stdout instead?  Or
>> is it working this way by design?
>>
>> 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
>
___
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] Aspectjweaver.jar outputting on stderr vs stdout

[Eric B]

I'm using AspectJ 1.6 with JBoss 4.2.1 configured with LoadTimeWeaving.

I have added the aspectjweaver.jar to the startup parameters:
 -javaagent:c:/dev/Java/aspectj1.6/lib/aspectjweaver.jar

AspectJ is properly loaded and indeed is weaving my classes as
desired/expected.  However, any weaveinfo data that it is producing is
being logged as an "Error" as it appears in the stderr stream instead of
the stdout:

2016-10-06 13:31:40,310 ERROR [STDERR] [UnifiedClassLoader3@333cf5e3]
weaveinfo Join point 'method-call(business.impl.BusinessContext
business.ejb3.ManagerBean.getBusinessContext(izone.business.BusinessContextInfo))'
in Type 'business.ejb3.ManagerBean' (ManagerBean.java:112) advised by
afterThrowing advice from 'common.security.logger.AccessDeniedLoggerAspect'
(AccessDeniedLoggerAspect.java)


According to the JBoss documentation, System.err stream is redirected into
a category called STDERR, which is what I see above.

Is there a way to configure the weaver to output on stdout instead?  Or is
it working this way by design?

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

Re: [aspectj-users] How to diagram/document Aspect libs?

[Eric B]

Thanks.  I read through the links you posted and like you said, a lot of it
is theoretical ways of documentation.

I'll try to go through it more carefully and extract some useful points.

Eric


On Tue, Aug 30, 2016 at 4:49 PM,  wrote:

> I am mostly aware of research level suggestions for diagrams. If you
> want to invest the time, to see what works for you, you might have a
> look at:
>
> Dominik Stein, Joint Point Designation Diagrams
> https://www.dawis.wiwi.uni-due.de/forschung/forschungsschwerpunkte/
> aspektorientierte-softwareentwicklung/join-point-designation-diagrams/
>
> Yan Han, Günter Kniesel, Armin B. Cremers:
> A meta model and modeling notation for AspectJ
> https://www.researchgate.net/publication/228889084_A_meta_
> model_and_modeling_notation_for_AspectJ
>
>
> I like as well the ideas in
>
> Ivar Jacobson, Pan-Wei Ng:
> Aspect-Oriented Software Development with Use Cases
>
> The notation of Jacobson and Ng is rather ad-hoc, but I found it
> nevertheless quite useful for some purposes. They list within an aspect
> class the (!) class, to which the aspect applies. Within this class
> advice and inter-type declarations of the aspect are shown.
>
> Of course, an aspect that just advices one class is not that
> cross-cutting. To model cross-cutting they replace class names by
> UML-template variables. So, you have an aspect class that contains a
> base class template that contains advice and inter-type declarations.
>
> In sequence diagrams they add boxes for before and after advice and
> boxes with holes for around advice. If the advice applies to more than
> one class, they use again template variables.
>
>
> For their use case slice approach, advice and inter-type declarations
> targeting just one class are typically enough. To illustrate how a
> larger number of classes work together, I used as well just small
> fragments added to classes to represent the advice and inter-type
> declarations like here:
> https://twitter.com/dsp_de/status/259300354901016579 (Same color means
> belonging to the same use case realization)
>
>
> Google showed me as well the following two resources:
>
> In 2006 there was a discussion about UML and Aspects on this mailing list:
> http://aspectj.2085585.n4.nabble.com/how-to-UML-aspects-td2078998.html
>
> A recent article that I did not yet study is:
> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC4130365/
>
>
> HTH, dsp
>
>
> Am 30.08.2016 um 20:33 schrieb Eric B:
> > Thanks, but unfortunately I fear that this type of question will get
> > slammed on SO as Opinion-based, not a valid-SO-question, etc.
> >
> > Maybe if I can word it appropriately, but not exactly sure how to do even
> > that.
> >
> > Thanks,
> >
> > Eric
> >
> >
> > On Mon, Aug 29, 2016 at 1:13 PM, Andy Clement 
> > wrote:
> >
> >> I'm not aware of anything. I mean we have aspectjdoc but that is more
> >> about modifying javadocs to show where aspects are applying, rather than
> >> for describing the libraries themselves. Have you tried asking on stack
> >> overflow too? That does reach a broader audience.
> >>
> >> cheers,
> >> Andy
> >>
> >> On 26 August 2016 at 18:52, Eric B  wrote:
> >>
> >>> Does anyone have any good examples/references for
> diagrams/documentation
> >>> of Aspect libraries?
> >>>
> >>> I just finished writing a bunch of logging aspects that cross-cut into
> >>> the application and would like to document them as much as possible
> for the
> >>> less knowledgeable.  Although the code itself is well documented, it
> would
> >>> be more for flow diagrams, and how the aspects interact with the
> codebase
> >>> that would be interested to draw out/ map out using UML, etc.
> >>>
> >>> Does anyone have good examples of how to do something like that?
> >>>
> >>> 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

Re: [aspectj-users] How to diagram/document Aspect libs?

[Eric B]

Thanks, but unfortunately I fear that this type of question will get
slammed on SO as Opinion-based, not a valid-SO-question, etc.

Maybe if I can word it appropriately, but not exactly sure how to do even
that.

Thanks,

Eric


On Mon, Aug 29, 2016 at 1:13 PM, Andy Clement 
wrote:

> I'm not aware of anything. I mean we have aspectjdoc but that is more
> about modifying javadocs to show where aspects are applying, rather than
> for describing the libraries themselves. Have you tried asking on stack
> overflow too? That does reach a broader audience.
>
> cheers,
> Andy
>
> On 26 August 2016 at 18:52, Eric B  wrote:
>
>> Does anyone have any good examples/references for diagrams/documentation
>> of Aspect libraries?
>>
>> I just finished writing a bunch of logging aspects that cross-cut into
>> the application and would like to document them as much as possible for the
>> less knowledgeable.  Although the code itself is well documented, it would
>> be more for flow diagrams, and how the aspects interact with the codebase
>> that would be interested to draw out/ map out using UML, etc.
>>
>> Does anyone have good examples of how to do something like that?
>>
>> 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
>
___
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] How to diagram/document Aspect libs?

[Eric B]

Does anyone have any good examples/references for diagrams/documentation of
Aspect libraries?

I just finished writing a bunch of logging aspects that cross-cut into the
application and would like to document them as much as possible for the
less knowledgeable.  Although the code itself is well documented, it would
be more for flow diagrams, and how the aspects interact with the codebase
that would be interested to draw out/ map out using UML, etc.

Does anyone have good examples of how to do something like that?

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

Re: [aspectj-users] Memory errors using iajc

[Eric B]

Thanks.  Pretty much what I did.

I also tried the fork option, which worked as well.  Still not entirely
sure why ajc fails when run within a larger ant build, but I guess it is a
bit of a moot point.

Thanks,

Eric


On Fri, Aug 26, 2016 at 12:34 PM, Andy Clement 
wrote:

> I think if you don't want to fork then you need to just increase the
> memory provided to the overall ant launch.
>
> http://allscm.com/archives/how-to-increase-heap-size-for-
> ants-outofmemory-error-using-ant_opts.html
>
> cheers
> Andy
>
> On 26 August 2016 at 09:23, Eric B  wrote:
>
>> I'm not the biggest fan of Ant, but I need to use if for this project.
>> However, I'm getting the following error message in my build script:
>>
>> _compile:
>> [mkdir] Created dir: C:\dev\Projects\hotfix\aspects\dist\compile
>>  [echo] Java target: 1.6
>>  [iajc] maxMem ignored unless forked: 256m
>>  [iajc] error AspectJ 1.6.13 ran out of memory during compilation:
>>  [iajc]
>>  [iajc] Please increase the memory available to ajc by editing the
>> ajc script
>>  [iajc] found in your AspectJ installation directory. The -Xmx
>> parameter value
>>  [iajc] should be increased from 64M (default) to 128M or even 256M.
>>  [iajc]
>>  [iajc] See the AspectJ FAQ available from the documentation link
>>  [iajc] on the AspectJ home page at http://www.eclipse.org/aspectj
>>
>>
>> My ant script is:
>>
>>
>>
>>  >  resource="org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.pr
>> operties">
>>
>>  
>>
>>  
>>   
>>   
>>
>> 
>> 
>> 
>> 
>> 
>> 
>>
>>   
>>   
>>   > source="${jdk.target}" target="${jdk.target}"
>>  debug="${jdk.debug}" classpathref="compiled.classpath"/>
>>
>>
>>
>>
>> You'll notice I am not even specifying any inpath; I'm just trying to
>> build a jar of aspects to use with the Load-Time-Weaver.  And my entire
>> source dir is a whopping 6 files.
>>
>> This only seems to happen when building as part of a complete project
>> build (ie: ant has already built other jars, and wars).  If I just build
>> this jar by itself, i don't run into errors.
>>
>> Is the only choice running this in a fork?  Can I not specify additional
>> memory to use to the process otherwise?
>>
>> 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
>
___
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] Memory errors using iajc

[Eric B]

I'm not the biggest fan of Ant, but I need to use if for this project.
However, I'm getting the following error message in my build script:

_compile:
[mkdir] Created dir: C:\dev\Projects\hotfix\aspects\dist\compile
 [echo] Java target: 1.6
 [iajc] maxMem ignored unless forked: 256m
 [iajc] error AspectJ 1.6.13 ran out of memory during compilation:
 [iajc]
 [iajc] Please increase the memory available to ajc by editing the ajc
script
 [iajc] found in your AspectJ installation directory. The -Xmx
parameter value
 [iajc] should be increased from 64M (default) to 128M or even 256M.
 [iajc]
 [iajc] See the AspectJ FAQ available from the documentation link
 [iajc] on the AspectJ home page at http://www.eclipse.org/aspectj


My ant script is:

   

 
   
 
   
 
  
  








  
  
  

   


You'll notice I am not even specifying any inpath; I'm just trying to build
a jar of aspects to use with the Load-Time-Weaver.  And my entire source
dir is a whopping 6 files.

This only seems to happen when building as part of a complete project build
(ie: ant has already built other jars, and wars).  If I just build this jar
by itself, i don't run into errors.

Is the only choice running this in a fork?  Can I not specify additional
memory to use to the process otherwise?

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

Re: [aspectj-users] How to advise already loaded classes using LTW?

[Eric B]

So I updated my pointcut to try to advise my EJBs directly (instead of
trying to advise the container's authorization interceptor), but I'm not
having success.

JBoss' own aspect/interceptor seems to be taking precedence over my own
pointcut, which I find hard to explain, and the JBoss aspect is firing
instead of my own.

This is my aspect definition:
@Pointcut("call( @(javax.annotation.security..*) * *.*(..))")
public void securedEJB(){}
@Around( "securedEJB()" )
public Object logEJBAccess( ProceedingJoinPoint pjp ) throws Throwable{
logger.warn("EJB CHECK HERE!!!");
Object o = null;
try {
o = pjp.proceed();
} catch (Throwable e) {
logger.error("EJB Threw Exception " + e );
e.printStackTrace();
throw e;
}
return o;
}


Yet, for all my secured EJB methods, I get the JBoss aspect that is
checking for security rights prior to my own calls to method and hence this
advice is never ever run.

An example of a call is:

OrganizationManager om =
(OrganizationManager)SessionBeanLocator.getSessionBean(OrganizationManager.class);
om.getThirdPartyOrgsForLogin( "asdf", null );
System.out.println( "OM" + om );

Where OM is the interface to the EJB bean:

   @PermitAll
   @TransactionAttribute(TransactionAttributeType.NEVER)
   public List getThirdPartyOrgsForLogin(String username,
BusinessContextInfo contextInfo) throws IzoneBusinessException {
   ...
   ...
   }


Any ideas what I can do?

Thanks,

Eric






On Sun, Aug 21, 2016 at 10:14 PM, Eric B  wrote:

> Hi Alex,
>
> You're right.  There is no real reason other than laziness to try to
> advise container classes.  I'm actually trying to log EJB authorization, so
> instead of advising every EJB method, I was thinking of advising the
> container's authorization interceptor and checking if the interceptor
> throws an exception.  I guess the non-lazy (proper ?:)) way is to advise
> all secured EJB methods.   I'll have to give that a shot tomorrow.  But it
> just made me think/wonder if there was any way to advise classes that were
> already loaded.
>
> It also doesn't address my issue when I am trying to LTW classes that are
> only visible to the child classloader but not the classloader that loaded
> the apsects.  Which means that I still don't know how to access the advised
> parameters/return values.
>
> Any thoughts which flags I should use to get the most info out of the
> advise process?  I have the verbose flag enabled in my aop.xml, but it
> doesn't seem to give me enough details.  I know I get more details out when
> using CTW with ajc, but I suspect that is because it knows exactly which
> methods it can match on compile, vs LTW when it never knows if it matches
> or not until the classes are loaded.  So you never get warnings that
> pointcuts don't match.
>
> Thanks!
>
> Eric
>
>
> On Sun, Aug 21, 2016 at 5:17 PM, Alexander Kriegisch <
> alexan...@kriegisch.name> wrote:
>
>> Hi Eric.
>>
>> I do not really want to imagine what makes you think you need/want to
>> advise container classes. I would assume that there must be a better way to
>> technically achieve what you want. You said the problem was about the
>> legacy application, not about the container.
>>
>> Anyway, for what it is worth, in principal you can, if you can influence
>> how the container is started, apply binary weaving to container classes and
>> put aspectjrt.jar on the JVM boot classpath. As for the third party library
>> (Struts), it would be interesting to find out what causes the class
>> visibility problem you mentioned. But even if you do not find out, you can
>> still apply binary weaving to all JARs in your EAR, repackage the woven
>> version and also use it in connection with aspectjrt.jar. No LTW means no
>> LTW-related problems.
>>
>> I am pretty sure there also is a way to fix the LTW situation, but I can
>> only speculate about it because I am not really a container champion. Maybe
>> if I had the binaries and exact setup to locally reproduce the problem...
>> Maybe you can find out more by setting the appropriate debug logging
>> options in your container as well as in AspectJ itself.
>>
>> As for retransforming already loaded classes, I once tried but failed
>> because either it is not possible or just because I do not know enough
>> about the JVM. In order to manually handle that.
>>
>> As I said: if I were you I would try to reduce the situation's complexity
>> by using binary weaving instead of LTW. Just my two cents. Probably Andy
>> has a much better answer for you, as usual. :-)
>>
>> Regards
>> --
>> Alexander Kriegisch
>> https://scrum-maste

Re: [aspectj-users] How to advise already loaded classes using LTW?

[Eric B]

Hi Alex,

You're right.  There is no real reason other than laziness to try to advise
container classes.  I'm actually trying to log EJB authorization, so
instead of advising every EJB method, I was thinking of advising the
container's authorization interceptor and checking if the interceptor
throws an exception.  I guess the non-lazy (proper ?:)) way is to advise
all secured EJB methods.   I'll have to give that a shot tomorrow.  But it
just made me think/wonder if there was any way to advise classes that were
already loaded.

It also doesn't address my issue when I am trying to LTW classes that are
only visible to the child classloader but not the classloader that loaded
the apsects.  Which means that I still don't know how to access the advised
parameters/return values.

Any thoughts which flags I should use to get the most info out of the
advise process?  I have the verbose flag enabled in my aop.xml, but it
doesn't seem to give me enough details.  I know I get more details out when
using CTW with ajc, but I suspect that is because it knows exactly which
methods it can match on compile, vs LTW when it never knows if it matches
or not until the classes are loaded.  So you never get warnings that
pointcuts don't match.

Thanks!

Eric


On Sun, Aug 21, 2016 at 5:17 PM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Hi Eric.
>
> I do not really want to imagine what makes you think you need/want to
> advise container classes. I would assume that there must be a better way to
> technically achieve what you want. You said the problem was about the
> legacy application, not about the container.
>
> Anyway, for what it is worth, in principal you can, if you can influence
> how the container is started, apply binary weaving to container classes and
> put aspectjrt.jar on the JVM boot classpath. As for the third party library
> (Struts), it would be interesting to find out what causes the class
> visibility problem you mentioned. But even if you do not find out, you can
> still apply binary weaving to all JARs in your EAR, repackage the woven
> version and also use it in connection with aspectjrt.jar. No LTW means no
> LTW-related problems.
>
> I am pretty sure there also is a way to fix the LTW situation, but I can
> only speculate about it because I am not really a container champion. Maybe
> if I had the binaries and exact setup to locally reproduce the problem...
> Maybe you can find out more by setting the appropriate debug logging
> options in your container as well as in AspectJ itself.
>
> As for retransforming already loaded classes, I once tried but failed
> because either it is not possible or just because I do not know enough
> about the JVM. In order to manually handle that.
>
> As I said: if I were you I would try to reduce the situation's complexity
> by using binary weaving instead of LTW. Just my two cents. Probably Andy
> has a much better answer for you, as usual. :-)
>
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
>
> Am 21.08.2016 um 23:01 schrieb Eric B :
>
> Hi Alex,
>
> Actually, there are some struts classes I want to advise.  But I have 2
> issues (related but distinct) with approach #1.
>
> 1) I an able to advise the struts classes, but cannot use any of the
> struts class definitions as they are not exposed to the aspect.  That means
> if I was to access any arguments that are struts classes (parameters or
> return values) as anything more than mere Object,  I can't.  I get
> ClassDefNotFound exceptions.
>
> 2) I would like to advise some container (JEE) classes, but they aren't
> advisable either as they have already been loaded by then time the
> container loads my aspect jar.
>
> I haven't actually tried using call() instead of execution() yet; it only
> occurred to me as I was writing my post.  But I suspect you are court that
> it won't make a significant difference, as the calls are made from within
> the framework itself (which are already loaded).
>
> Is there any way out of this mess? Is there anyway to use something like
> cflow()?  Is there no way to advise an already loaded class?
>
> Thanks
>
> Eric
>
> On Aug 21, 2016 12:46 PM, "Alexander Kriegisch" 
> wrote:
>
>> Hi Eric.
>>
>> What is the problem with approach #1? That Struts classes are not loaded
>> correctly anymore? Do you even want to advse them? If that is not necessary
>> why not just exclude them by !within(org.apache.struts)?
>>
>> Yes, class-loading sequence is relevant for AspectJ LTW.
>>
>> Using call() instead of execution() does not solve the root cause of
>> your problem, I assume. It only bloats the bytecode because many more
&g

Re: [aspectj-users] How to advise already loaded classes using LTW?

[Eric B]

Hi Alex,

Actually, there are some struts classes I want to advise.  But I have 2
issues (related but distinct) with approach #1.

1) I an able to advise the struts classes, but cannot use any of the struts
class definitions as they are not exposed to the aspect.  That means if I
was to access any arguments that are struts classes (parameters or return
values) as anything more than mere Object,  I can't.  I get
ClassDefNotFound exceptions.

2) I would like to advise some container (JEE) classes, but they aren't
advisable either as they have already been loaded by then time the
container loads my aspect jar.

I haven't actually tried using call() instead of execution() yet; it only
occurred to me as I was writing my post.  But I suspect you are court that
it won't make a significant difference, as the calls are made from within
the framework itself (which are already loaded).

Is there any way out of this mess? Is there anyway to use something like
cflow()?  Is there no way to advise an already loaded class?

Thanks

Eric

On Aug 21, 2016 12:46 PM, "Alexander Kriegisch" 
wrote:

> Hi Eric.
>
> What is the problem with approach #1? That Struts classes are not loaded
> correctly anymore? Do you even want to advse them? If that is not necessary
> why not just exclude them by !within(org.apache.struts)?
>
> Yes, class-loading sequence is relevant for AspectJ LTW.
>
> Using call() instead of execution() does not solve the root cause of your
> problem, I assume. It only bloats the bytecode because many more joinpoints
> need to be woven.
> Regards
> --
> Alexander Kriegisch
> https://scrum-master.de
>
> Eric B schrieb am 21.08.2016 15:03:
>
> I have a "fragile" legacy app that is running on JBoss 4.  That is to say,
> that any changes to the app require a full manual regression test which are
> long and expensive.  I'm trying to add some specific logging to the app, so
> I figured that using AOP to intercept method executions would be the
> simplest way without altering the binaries.
>
> But here is where I am running into classloading problems when I am trying
> to advise classes that are already loaded by the classloader by the time my
> ear gets loaded.
>
> My EAR is structured as the follows:
>
> EAR
>  - webapp.war
> \ WEB-INF/lib
> - webstuff.jar
> - WebClasses.jar
> - struts.jar
>  - EJB.jar
>  - utils.jar
>
>
> JBoss is set to load as parent-first, and modifying the sequence isn't an
> option.
>
> So I have a few problems here:
> 1) If I drop my aspect.jar in my EAR/lib folder, and enable LTW on the
> command line, it is able to successfully advise all my classes in EJB.jar,
> utils.jar and webstuff.jar.  I am even able to advise methods in
> struts.jar, but unable to use any struts classes as the classloader for the
> aspect doesn't "see" anything in struts.jar (I get
> ClassDefNotFoundException).
>
> 2) If I move my aspect.jar into my WEB-INF/lib folder, it doesn't
> successfully advise anything in EJB.jar or utils.jar, I suspect b/c they
> are loaded prior to the aspect being loaded by the classloader.
>
> My pointcuts are all "execution" pointcuts.
>
> Similarly if I try to advise container classes with "execution" pointcuts,
> they never seem to trigger.
>
> Is there a simple solution for this?  Does one need to take the
> class-loading sequence into account when using LTW?  Thinking outloud,
> would changing all my "execution" pointcuts to "call" make a difference?
>
> My aop.xml is fairly basic:
>
>
> 
>   
>   
> 
>
> 
> 
>
>
> Do I need to specify  to the aspectj compiler?  I thought all
> classes were "included" by default.
>
> 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

[aspectj-users] How to advise already loaded classes using LTW?

[Eric B]

I have a "fragile" legacy app that is running on JBoss 4.  That is to say,
that any changes to the app require a full manual regression test which are
long and expensive.  I'm trying to add some specific logging to the app, so
I figured that using AOP to intercept method executions would be the
simplest way without altering the binaries.

But here is where I am running into classloading problems when I am trying
to advise classes that are already loaded by the classloader by the time my
ear gets loaded.

My EAR is structured as the follows:

EAR
 - webapp.war
\ WEB-INF/lib
- webstuff.jar
- WebClasses.jar
- struts.jar
 - EJB.jar
 - utils.jar


JBoss is set to load as parent-first, and modifying the sequence isn't an
option.

So I have a few problems here:
1) If I drop my aspect.jar in my EAR/lib folder, and enable LTW on the
command line, it is able to successfully advise all my classes in EJB.jar,
utils.jar and webstuff.jar.  I am even able to advise methods in
struts.jar, but unable to use any struts classes as the classloader for the
aspect doesn't "see" anything in struts.jar (I get
ClassDefNotFoundException).

2) If I move my aspect.jar into my WEB-INF/lib folder, it doesn't
successfully advise anything in EJB.jar or utils.jar, I suspect b/c they
are loaded prior to the aspect being loaded by the classloader.

My pointcuts are all "execution" pointcuts.

Similarly if I try to advise container classes with "execution" pointcuts,
they never seem to trigger.

Is there a simple solution for this?  Does one need to take the
class-loading sequence into account when using LTW?  Thinking outloud,
would changing all my "execution" pointcuts to "call" make a difference?

My aop.xml is fairly basic:

   

  
  




   

Do I need to specify  to the aspectj compiler?  I thought all
classes were "included" by default.

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

Re: [aspectj-users] Problems with AspectJ woven classes in Junit suites - static data hanging around?

[Eric B]

Hi Jaime,

Thanks a bunch!  It's not exactly my situation but it had some great
insight into my issue and a few links that I could drill through to get to
my problem as well.  Turns out that https://jira.spring.io/browse/SPR-5156
already exists for my issue but 6 years later and it's still open!

I've been trying to figure out the exact aspects that are maintaining state
information but having a tough time tracking everything down.

Thanks,

Eric


On Sun, Nov 8, 2015 at 2:47 PM,  wrote:

> Hi Eric,
>
> Maybe not quite your situation, but see #1 in
> http://lagod.id.au/blog/?p=266.  Spring configured aspects pretty much
> blow a hole in the encapsulation of Spring contexts that the Spring test
> framework relies on.
>
> I don’t know if I'd call this a bug on either side. More a leaky
> abstraction.  Spring test makes some promises about encapsulation that it
> can't really keep, but then OTOH any time you bring in byte code
> manipulation all bets are off - after all, that's what byte code
> manipulation is for.
>
> HTH
> Jaime
>
> *From:* Eric B 
> *Sent:* ‎Sunday‎, ‎8‎ ‎November‎ ‎2015 ‎12‎:‎00‎ ‎PM
> *To:* aspectj-users@eclipse.org
>
> I have originally posted this question on StackOverflow (
> http://stackoverflow.com/q/33576324/827480) as a Spring question, but the
> more I investigate the more I feel that it is something due to AspectJ
> weaving.
>
> I have a bunch of JUnit tests that all function individually. Each one is
> a true standalone unit test - single class under test. No contexts are
> required. I can run them all individually or all together either in Eclipse
> or via maven / surefire-plugin.
>
> I have since added a new Integration test which leverages the Spring
> Context, etc and uses the SpringJUnit4ClassRunner. As soon as I add this
> test to my suite, any test cases run after this class fail.
>
> @RunWith(SpringJUnit4ClassRunner.class)@SpringApplicationConfiguration(classes
>  = 
> IntegrationTestConfiguration.class)@DirtiesContext(classMode=ClassMode.AFTER_EACH_TEST_METHOD)@ActiveProfiles("test")public
>  class ImportServiceIntegrationTest {
>...}
>
> I suspect that there is something maintained in the JVM (some static data)
> after the test class is terminated.
>
> I am using Spring Cache annotations with the following config:
>
> @Configuration@EnableCaching(mode=AdviceMode.ASPECTJ)public class CacheConfig 
> extends CachingConfigurerSupport{
>
> /**
>  * EhCache configuration.  Used to minimize calls to Veracode
>  *
>  * @return
>  */
> @Bean(destroyMethod="shutdown")
> public net.sf.ehcache.CacheManager ehCacheManager() {
> ...
> ...
> }
> ...}
>
> As soon as my integration test class finishes, my subsequent test throws
> the following error:
>
> java.lang.IllegalStateException: The workItems Cache is not alive 
> (STATUS_SHUTDOWN)
> at net.sf.ehcache.Cache$CacheStatus.checkAlive(Cache.java:4097)
> at net.sf.ehcache.Cache.checkStatus(Cache.java:2788)
> at net.sf.ehcache.Cache.get(Cache.java:1744)
> at 
> org.springframework.cache.ehcache.EhCacheCache.get(EhCacheCache.java:65)
> at 
> org.springframework.cache.interceptor.AbstractCacheInvoker.doGet(AbstractCacheInvoker.java:68)
> at 
> org.springframework.cache.interceptor.CacheAspectSupport.findInCaches(CacheAspectSupport.java:461)
> at 
> org.springframework.cache.interceptor.CacheAspectSupport.findCachedItem(CacheAspectSupport.java:432)
> at 
> org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:333)
> at 
> org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:299)
> at 
> org.springframework.cache.aspectj.AbstractCacheAspect.ajc$around$org_springframework_cache_aspectj_AbstractCacheAspect$1$2bc714b5(AbstractCacheAspect.aj:74)
> at 
> com.synchronize.repository.rtc.WorkItemRepositoryImpl.findById(WorkItemRepositoryImpl.java:192)
> at 
> com.synchronize.repository.rtc.WorkItemRepositoryImpl.findById(WorkItemRepositoryImpl.java:192)
> at 
> com.synchronize.repository.rtc.WorkItemRepositoryImpl.getState(WorkItemRepositoryImpl.java:179)
> at 
> com.synchronize.repository.rtc.WorkItemRepositoryImplTest.testGetState(WorkItemRepositoryImplTest.java:178)
>
> So it is fairly clear to me that Spring is not cleaning something up after
> it is done (my subsequent class doesn't even load the Spring context - it
> is a plain vanilla Junit test!).
>
> If I look at the compiled Java class, I see that AspectJ has added some
> static fields.  Ex:
>   privat

[aspectj-users] Problems with AspectJ woven classes in Junit suites - static data hanging around?

[Eric B]

I have originally posted this question on StackOverflow (
http://stackoverflow.com/q/33576324/827480) as a Spring question, but the
more I investigate the more I feel that it is something due to AspectJ
weaving.

I have a bunch of JUnit tests that all function individually. Each one is a
true standalone unit test - single class under test. No contexts are
required. I can run them all individually or all together either in Eclipse
or via maven / surefire-plugin.

I have since added a new Integration test which leverages the Spring
Context, etc and uses the SpringJUnit4ClassRunner. As soon as I add this
test to my suite, any test cases run after this class fail.

@RunWith(SpringJUnit4ClassRunner.class)@SpringApplicationConfiguration(classes
= 
IntegrationTestConfiguration.class)@DirtiesContext(classMode=ClassMode.AFTER_EACH_TEST_METHOD)@ActiveProfiles("test")public
class ImportServiceIntegrationTest {
   ...}

I suspect that there is something maintained in the JVM (some static data)
after the test class is terminated.

I am using Spring Cache annotations with the following config:

@Configuration@EnableCaching(mode=AdviceMode.ASPECTJ)public class
CacheConfig extends CachingConfigurerSupport{

/**
 * EhCache configuration.  Used to minimize calls to Veracode
 *
 * @return
 */
@Bean(destroyMethod="shutdown")
public net.sf.ehcache.CacheManager ehCacheManager() {
...
...
}
...}

As soon as my integration test class finishes, my subsequent test throws
the following error:

java.lang.IllegalStateException: The workItems Cache is not alive
(STATUS_SHUTDOWN)
at net.sf.ehcache.Cache$CacheStatus.checkAlive(Cache.java:4097)
at net.sf.ehcache.Cache.checkStatus(Cache.java:2788)
at net.sf.ehcache.Cache.get(Cache.java:1744)
at 
org.springframework.cache.ehcache.EhCacheCache.get(EhCacheCache.java:65)
at 
org.springframework.cache.interceptor.AbstractCacheInvoker.doGet(AbstractCacheInvoker.java:68)
at 
org.springframework.cache.interceptor.CacheAspectSupport.findInCaches(CacheAspectSupport.java:461)
at 
org.springframework.cache.interceptor.CacheAspectSupport.findCachedItem(CacheAspectSupport.java:432)
at 
org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:333)
at 
org.springframework.cache.interceptor.CacheAspectSupport.execute(CacheAspectSupport.java:299)
at 
org.springframework.cache.aspectj.AbstractCacheAspect.ajc$around$org_springframework_cache_aspectj_AbstractCacheAspect$1$2bc714b5(AbstractCacheAspect.aj:74)
at 
com.synchronize.repository.rtc.WorkItemRepositoryImpl.findById(WorkItemRepositoryImpl.java:192)
at 
com.synchronize.repository.rtc.WorkItemRepositoryImpl.findById(WorkItemRepositoryImpl.java:192)
at 
com.synchronize.repository.rtc.WorkItemRepositoryImpl.getState(WorkItemRepositoryImpl.java:179)
at 
com.synchronize.repository.rtc.WorkItemRepositoryImplTest.testGetState(WorkItemRepositoryImplTest.java:178)

So it is fairly clear to me that Spring is not cleaning something up after
it is done (my subsequent class doesn't even load the Spring context - it
is a plain vanilla Junit test!).

If I look at the compiled Java class, I see that AspectJ has added some
static fields.  Ex:
  private static final JoinPoint.StaticPart ajc$tjp_0;
  private static final JoinPoint.StaticPart ajc$tjp_1;
  static
  {
ajc$preClinit();
  }


I suspect that when the Spring context is initialized that some value(s)
are being set in these variables that isn't getting cleared out at the
close of the context.  Given that static data is not eliminated between
JUnit tests, subsequent tests try to access data  previously configured by
Spring but no longer available and consequently the tests fail.

I am not sure if this is an AspectJ Weaving issue, or a Spring issue.  I am
leaning more towards it being an AspectJ issue as it is likely due to the
way that ajc implements/weaves the advice.

There are workarounds to my issue.  Use separate JVM forks for each test,
or put my spring tests in a different test suite, but both workarounds do
not necessarily address the issue at hand; why is this happening in the
first place?

Is this an ajc issue?  Are there known limitations to the way that AspectJ
weaves classes?  Or is this a bug/deficiency in AspectJ?  Is there a way to
avoid this problem in the first place?

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

Re: [aspectj-users] How to weave the method calls inside an war file?

[Eric B]

Each concurrent http request will be served by seperate threads, however,
when a request is finished, the same thread may be reused to serve
additional requests.  This is normal in a webserver.

If you set up a request listener or filter, it will be called at the start
of every request.  In this listener, you can set an id.  Depending on the
technology stack you are using there are different ways of accomplishing
this.
http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequestListener.html
Ex:
public void requestInitialized(ServletRequestEvent sre){
   MDC.put( "userId", new UUID() );
}


or
https://docs.oracle.com/javaee/6/api/javax/servlet/Filter.html

public void doFilter(...){
   MDC.put( "userId", new UUID() );
   MDC.put( ... ... );
   chain.doFilter(args);
}

This UUID can then be accessed in your logging statement automatically.  In
your code, you would use normal logging statements: logger.info("some log
info").

Your Appender would be configured with the particular parameter in its
string.  Ex:


Then your logger would automatically printout your log as something like:
RequestUUID: 12afe1938107 2015-11-04 11:02:03  some.class.Name:159 - some
log info


Since the MDC var is overwritten at the start of every request, you can be
assured that the thread will contain the appropriate value for that
request.  And since all concurrent requests are handled by independent
threads, there will be no overlapping.

You should be able to find plenty of resources/tutorials for ways to use
MDC online (stackoverflow or other).  Here's a quick primer:
http://veerasundar.com/blog/2009/10/log4j-mdc-mapped-diagnostic-context-what-and-why/

Hope this clarifies things a little.  Let me know if anything is still
unclear.

Thanks,

Eric



On Thu, Nov 5, 2015 at 10:59 AM, Anto Aravinth 
wrote:

> Thanks Eric, thats exactly what I was looking for.
>
> A noob question, so if a user hits the webpage, servlet is going to create
> a thread for the same. Now if I do logger after setting up MDC id like this:
>
>logger.info (" Great")
>
> So technically how this can be converted or remembered per thread?
>
> Because imagine I did set the id as 121, and two users are hitting, which
> is going to be altogether different threads, how does this 121 gets binded
> to threads in this case?
>
> From my understanding so if a user going to access the webpage, then he or
> she needs to "somehow" pass on this id to MDC, then I believe it works as
> required.
>
> Correct me if I'm wrong.
>
> Anto.
> On 5 Nov 2015 16:10, "Eric B"  wrote:
>
>> What logging platform are you using?
>>
>> If you are using Log4j, you can use the MappedDiagnosticContext (MDC)
>> class
>> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html.
>> This is managed on a per-thread basis, so you can assign an ID in the MDC
>> as part of a request listener, and any Log4j call that is made in that
>> thread will have access to the id stored in the MDC.  This allows you to
>> recall the id in a logging statement.
>>
>> All logs will still be pushed to the same appender, however you would
>> then be able to sort and/or filter based on the ID.  If memory serves,
>> retrieving the variable for the appender is done via the %X{VarName}.
>>
>> I also believe that Logback has a similar MDC functionality.
>>
>> Thanks,
>>
>> Eric
>>
>>
>>
>> On Thu, Nov 5, 2015 at 9:34 AM, ants  wrote:
>>
>>> I have few questions on this specific task; Now I have written by
>>> monitoring
>>> logic in the aspectj. It works so smoothly and tested in tomcat and other
>>> servers as well.
>>>
>>> I was wondering, if this can be done as well:
>>>
>>> 1. The logging gets started when I turn on few params on my aspectj jar,
>>> which starts logging.
>>> 2. So if possible, when it logs, can I make it to log according to each
>>> thread level?
>>>
>>> What I was thinking over here is this, I will start my logging param in
>>> aspectj, so imagine, when two users access the webpage in the server,
>>> now I
>>> want the trace should be completely isolated from each of the request. I
>>> know HTTP doesn't have states, we can do this in sort of attaching some
>>> "sessionID" to each trace, and then do a batch operation for getting the
>>> result of each thread; so that trace "flow" is perfect.
>>>
>>> I just want to know if there are any other ways of doing this?
>>>
>>> Your thoughts will be really helpful to me.
>>>
>>>
>>>
>>> --
>>> V

Re: [aspectj-users] How to weave the method calls inside an war file?

[Eric B]

What logging platform are you using?

If you are using Log4j, you can use the MappedDiagnosticContext (MDC) class
https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html.
This is managed on a per-thread basis, so you can assign an ID in the MDC
as part of a request listener, and any Log4j call that is made in that
thread will have access to the id stored in the MDC.  This allows you to
recall the id in a logging statement.

All logs will still be pushed to the same appender, however you would then
be able to sort and/or filter based on the ID.  If memory serves,
retrieving the variable for the appender is done via the %X{VarName}.

I also believe that Logback has a similar MDC functionality.

Thanks,

Eric



On Thu, Nov 5, 2015 at 9:34 AM, ants  wrote:

> I have few questions on this specific task; Now I have written by
> monitoring
> logic in the aspectj. It works so smoothly and tested in tomcat and other
> servers as well.
>
> I was wondering, if this can be done as well:
>
> 1. The logging gets started when I turn on few params on my aspectj jar,
> which starts logging.
> 2. So if possible, when it logs, can I make it to log according to each
> thread level?
>
> What I was thinking over here is this, I will start my logging param in
> aspectj, so imagine, when two users access the webpage in the server, now I
> want the trace should be completely isolated from each of the request. I
> know HTTP doesn't have states, we can do this in sort of attaching some
> "sessionID" to each trace, and then do a batch operation for getting the
> result of each thread; so that trace "flow" is perfect.
>
> I just want to know if there are any other ways of doing this?
>
> Your thoughts will be really helpful to me.
>
>
>
> --
> View this message in context:
> http://aspectj.2085585.n4.nabble.com/How-to-weave-the-method-calls-inside-an-war-file-tp4651913p4651968.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> ___
> 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

Re: [aspectj-users] Who is responsible for the Eclipse m2e-connector?

[Eric B]

Thanks Andy.  Unless the version number is the same but the contents are
different, I'm already using Maven Integration for AJDT 0.14.0.201302011330
(as downloaded from the ajdt update site) - which is the same as what is
available on http://dist.springsource.org/release/AJDT/configurator/.

Thanks,

Eric


On Mon, Jun 22, 2015 at 2:00 PM, Andy Clement 
wrote:

> As I got to the end of your thread I was thinking about the AJDT m2e
> connector. We bundle a version inside STS and I observed the other day that
> it didn’t work at all. So I upgraded from the included one and it behaved
> much better. Whether it addresses your issue, not sure but it fixed mine
> (mapping aspect libraries from the maven pom into aspect path on my
> project).
>
> This is the version I was using:
> https://github.com/aeisenberg/m2eclipse-ajdt
>
> which Andrew keeps under his account. Not the right home as he doesn’t
> work on it anymore.
>
> I installed artifact from that using this eclipse update site:
> http://dist.springsource.org/release/AJDT/configurator/ to fix my stuff.
>
> It isn’t considered part of AJDT right now, but arguably could be.
>
> cheers,
> Andy
>
>
> On Jun 22, 2015, at 8:42 AM, Eric B  wrote:
>
> This is a followup to my previous thread:
> https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg14782.html
>
> I think I have found the problem that I am having to be m2e-connector
> related.  This would obviously imply an Eclipse integration issue and not
> an AspectJ issue as such.
>
> But who is responsible for the connector?  From what I can tell, it is
> part of the AJDT project, but am not entirely sure about that.  I was
> directed towards the github project
> https://github.com/tesla/m2eclipse-ajdt, but seeing that there are no
> issues posted there, I am not sure if that is the right site or not.
>
> Does anyone know where to report issues relating to the m2e connector?
> Even the Eclipse AJDT bug site seems to be fairly quiet, so I am not even
> sure that is right either.
>
> 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
>
___
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] Who is responsible for the Eclipse m2e-connector?

[Eric B]

This is a followup to my previous thread:
https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg14782.html

I think I have found the problem that I am having to be m2e-connector
related.  This would obviously imply an Eclipse integration issue and not
an AspectJ issue as such.

But who is responsible for the connector?  From what I can tell, it is part
of the AJDT project, but am not entirely sure about that.  I was directed
towards the github project https://github.com/tesla/m2eclipse-ajdt, but
seeing that there are no issues posted there, I am not sure if that is the
right site or not.

Does anyone know where to report issues relating to the m2e connector?
Even the Eclipse AJDT bug site seems to be fairly quiet, so I am not even
sure that is right either.

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

Re: [aspectj-users] Problems with test aspects in Eclipse

[Eric B]

Thanks - I came to the same conclusion, but figured that I must have been
doing something wrong.  I guess I have to raise this bug on the github
project for AJDT and see if something can be done there.

Thanks,

Eric

On Sun, Jun 21, 2015 at 7:06 AM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Hi Eric.
>
> Please find my answer at http://stackoverflow.com/a/30954233/1082681.
> Basically I have added a default M2E lifecycle mapping for AspectJ Maven
> Plugin and now it works.
>
> Enjoy
> --
> Alexander Kriegisch
> http://scrum-master.de
>
>
> Eric B schrieb am 20.06.2015 21:43:
> >
> > Hi Alexander,
> >
> >
> > Thanks for replying. I have since done additional testing/validation with
> > Eclipse Luna but no additional success.
> >
> >
> > I'm running into a problematic issue with m2e and Eclipse (vs command
> line
> > maven build). I am using a clean installation of Luna WTP 4.4.2 with m2e
> > 1.5.1.
> >
> >
> > I have aspectj-maven-plugin configured in my pom.xml and the connector
> > installed as well.
> >
> >
> > My plugin configuration specifies:
> >
> >
> > 
> >
> > 
> >
> > compile
> >
> > 
> >
> > compile
> >
> > 
> >
> > 
> >
> > 
> >
> > 
> >
> > ${project.build.sourceDirectory}
> >
> > 
> >
> > 
> >
> > 
> >
> > 
> >
> > 
> >
> > test compile
> >
> > 
> >
> > test-compile
> >
> > 
> >
> > 
> >
> > 
> >
> > 
> >
> > ${project.build.testSourceDirectory}
> >
> > 
> >
> > 
> >
> > 
> >
> > ${project.build.outputDirectory}
> >
> > 
> >
> > 
> >
> > 
> >
> > 
> >
> >
> > The goal is to have an aspect from my src/test/java path woven into my
> > classes from src/main/java but output only in my target/test-classes. The
> > reasoning behind this is that the aspect is only used for junit testing
> > and not for normal code compilation/use.
> >
> >
> > When I build from the command line, everything works properly. The
> > "compile" goal compiles & weaves all my src/main/java files to the
> > target/classes output directory and the "test-compile" compiles & weaves
> > all my src/test/java files into target/test-classes.
> >
> >
> > However, when I build from within Eclipse, my Aspects in src/test/java
> are
> > woven into classes in target/classes as well (see
> > target/classes/com/test/ServiceImpl.c
> > <
> https://github.com/benze/aspectj-maven-plugin-defect-example/blob/master/src/main/java/com/test/ServiceImpl.java
> >
> > lass. With the decompiler, I can see the MangleAspect has been woven in.
> > Additionally, only the files from src/test/java are output into
> > target/test-classes while the pom instructs ajc to do otherwise (weave
> all
> > class files from target/classes into target/test-classes).
> >
> >
> > I've enabled debug from cmd line when I build (mvn -X) and I can see
> > appropriate parameters passed to the aspectj-maven-plugin. However when I
> > enable debug logging from
> >
> .metadata/.plugins/org.eclipse.m2e.logback.configuration/logback.${m2e.version}.xml,
> > I do not see the parameters that are being passed to the
> > aspectj-maven-plugin.
> >
> >
> > Does this have something to do with the lifecycle mapping connector? Is
> > there a way to debug how that is working?
> >
> >
> > I uploaded my sample project to my github:
> >
> > https://github.com/benze/aspectj-maven-plugin-defect-example
> >
> >
> > I did notice, however, if I disable the m2e connector and just use
> > lifecycle mapping within my pom directly that instructs the aspectj
> plugin
> > to execute on compile/test-compile goals, my output seems to be as I
> would
> > expect. Can this be an m2e connector issue? I'm not entirely clear on how
> > this connector works, or how it is injected into the m2e maven compile
> > process.
> >
> >
> > Thanks,
> >
> > Eric
> >
> >
> > On Sat, Jun 20, 2015 at 7:53 AM, Alexander Kriegisch
> > mailto:alexan...@kriegisch.name>
> > > wrote:
> >> Hi Eric.
> >>
> >> I cannot reproduce your problem. I have just given it a quick try with
> >> the attached sample project. It contains
> >> - a Maven

Re: [aspectj-users] Problems with test aspects in Eclipse

[Eric B]

Hi Alexander,

Thanks for replying.  I have since done additional testing/validation with
Eclipse Luna but no additional success.

I'm running into a problematic issue with m2e and Eclipse (vs command line
maven build).  I am using a clean installation of Luna WTP 4.4.2 with m2e
1.5.1.

I have aspectj-maven-plugin configured in my pom.xml and the connector
installed as well.

My plugin configuration specifies:

   

 compile

compile



   
   ${project.build.sourceDirectory}
   




 test compile

test-compile



   

${project.build.testSourceDirectory}
   

  
  ${project.build.outputDirectory}
  




The goal is to have an aspect from my src/test/java path woven into my
classes from src/main/java but output only in my target/test-classes.  The
reasoning behind this is that the aspect is only used for junit testing and
not for normal code compilation/use.

When I build from the command line, everything works properly.  The
"compile" goal compiles & weaves all my src/main/java files to the
target/classes output directory and the "test-compile" compiles & weaves
all my src/test/java files into target/test-classes.

However, when I build from within Eclipse, my Aspects in src/test/java are
woven into classes in target/classes as well (see target/classes/com/test/
ServiceImpl.c
<https://github.com/benze/aspectj-maven-plugin-defect-example/blob/master/src/main/java/com/test/ServiceImpl.java>
lass.  With the decompiler, I can see the MangleAspect has been woven in.
Additionally, only the files from src/test/java are output into
target/test-classes while the pom instructs ajc to do otherwise (weave all
class files from target/classes into target/test-classes).

I've enabled debug from cmd line when I build (mvn -X) and I can see
appropriate parameters passed to the aspectj-maven-plugin.  However when I
enable debug logging from
.metadata/.plugins/org.eclipse.m2e.logback.configuration/logback.${m2e.version}.xml,
I do not see the parameters that are being passed to the
aspectj-maven-plugin.

Does this have something to do with the lifecycle mapping connector? Is
there a way to debug how that is working?

I uploaded my sample project to my github:
https://github.com/benze/aspectj-maven-plugin-defect-example


I did notice, however, if I disable the m2e connector and just use
lifecycle mapping within my pom directly that instructs the aspectj plugin
to execute on compile/test-compile goals, my output seems to be as I would
expect. Can this be an m2e connector issue? I'm not entirely clear on how
this connector works, or how it is injected into the m2e maven compile
process.

Thanks,
Eric

On Sat, Jun 20, 2015 at 7:53 AM, Alexander Kriegisch <
alexan...@kriegisch.name> wrote:

> Hi Eric.
>
> I cannot reproduce your problem. I have just given it a quick try with the
> attached sample project. It contains
>   - a Maven build,
>   - a corresponding IntelliJ IDEA 14 Maven project,
>   - a corresponding Eclipse Luna SR1 (4.4.1) project, imported from Maven.
>
> Both in IDEA and Eclipse the result is the same with Maven 3: The test
> aspect only applies to the sample JUnit test, *not* to the main class. When
> running the main class from either IDE, the aspect is not applied.
>
> Maybe you have made a mistake setting up your Eclipse project. I recommend
> you to import your Maven build into a fresh Eclipse project. I also
> recommend to use a recent Maven AspectJ Plugin (1.7 instead of 1.2) and a
> recent AspectJ version (1.8.6, not 1.7.0, or at least
> the latest 1.7 versiobn 1.7.4).
>
> Feel free to ask follow-up questions.
>
> Regards
> --
> Alexander Kriegisch
> http://scrum-master.de
>
>
> Eric B schrieb am 18.06.2015 20:25:
>
> > I posted a question on StackOverflow, but haven't received much traction
> there, so I thought I would check with people on this list as well.
> >
> >
> > I'm having trouble with Eclipse weaving aspects from my test folder into
> my target/classes folder (as opposed to putting the woven classes into
> target/test-classes)
> >
> >
> > I've got a maven project in which I have @Aspect classes in my
> src/test/java folder.  If I build from comma

Re: [aspectj-users] Problems with test aspects in Eclipse

[Eric B]

I've been trying to work the m2e plugin to only weave the test aspect into
my test classes, but it just doesn't seem to allow me.

My problem with updating the pointcuts is that this is an aspect I need for
my junit tests.  Essentially I need to intercept calls to a service and
provide some external logic "mocking" a live connection.

So I can't see how to update the pointcuts.  It isn't the test code that is
being intercepted - it's the production code.  Even changing an "execution"
pointcut to a "call" one won't help since it looks like the aspect will be
woven into calls on the production code as well.

Is there no way in Eclipse to differentiate which files are tests and which
are src?

Tx,

Eric

On Fri, Jun 19, 2015 at 9:32 PM, Eric B  wrote:

> Hi Andy,
>
> Thanks for the reply.  Are you saying that there is no way in Eclipse to
> differentiate which are test classes and which are source classes?
>
> I'm actually seeing a  behaviour that I find troubling.
>
> If I compile my code from the command line, I get a
> [Xlint:adviceDidNotMatch] when ajc runs my test-classes.  Consequently, my
> aspect is never woven into my class.  But when I compile from within
> Eclipse, the aspect is woven in.
>
> I suspect that it has something to do with the classpath that maven is
> presenting to ajc; indeed when I enable debug information, I see that the
> /src/main/java classes are not on the path to ajc as they are during the
> regular compilation, and only the src/test/java classes are present.
>
> I don't know if this is a limitation of the ajc compiler, or if there is a
> way to tell it to additionally (re)compile / weave classes into the output
> folder only if they are affected.  I see the '-inpath' argument to ajc, but
> will dump everything in the inpath to the output directory, or only the
> changed classes?  Is there a way to tell it only to put the classes into
> the output directory if they are changed/modified?
>
> Thanks,
>
> Eric
>
> On Fri, Jun 19, 2015 at 12:19 PM, Andy Clement 
> wrote:
>
>> Are you simply hitting the problem that in Eclipse a project does not
>> support separate compilation of src/main and src/test trees. When you
>> import your project into eclipse those things get merged together, and all
>> built together. You could perhaps get around this by adjusting your
>> pointcuts in your aspect to only match the test code - not ideal I know.
>>
>> cheers,
>> Andy
>>
>> > On Jun 18, 2015, at 11:25 AM, Eric B  wrote:
>> >
>> > I posted a question on StackOverflow, but haven't received much
>> traction there, so I thought I would check with people on this list as well.
>> >
>> > I'm having trouble with Eclipse weaving aspects from my test folder
>> into my target/classes folder (as opposed to putting the woven classes into
>> target/test-classes)
>> >
>> > I've got a maven project in which I have @Aspect classes in my
>> src/test/java folder.  If I build from command line, everything runs
>> properly.  If however, I build from within Eclipse, the compiler weaves my
>> aspects into my target class files and puts them in target/classes.
>> >
>> > This obviously causes me troubles as the JVM tries to find the woven
>> Aspect and throws NoClassDefFoundError (since the actual aspect.class is
>> only in target/test-classes).
>> >
>> > Has anyone encountered this before?  Is there a way to instruct
>> ajc/Eclipse/maven/m2e to put the woven class file into target/test-classes
>> and not target/classes when it is due to an aspect from the test folder?
>> >
>> >
>> > My pom defn shows the following for the ajc plugin:
>> >   
>> > org.codehaus.mojo
>> > aspectj-maven-plugin
>> > 1.2
>> > 
>> >   
>> > 
>> >   compile
>> >   test-compile
>> > 
>> > 
>> >   true
>> >   
>> > 
>> >   org.springframework
>> >   spring-aspects
>> > 
>> >   
>> >   7
>> >   7
>> > 
>> >   
>> > 
>> > 
>> >   
>> > org.aspectj
>> > aspectjrt
>> > 1.7.0
>> > compile
>> >   
>> >   
>> &g

Re: [aspectj-users] Problems with test aspects in Eclipse

[Eric B]

Hi Andy,

Thanks for the reply.  Are you saying that there is no way in Eclipse to
differentiate which are test classes and which are source classes?

I'm actually seeing a  behaviour that I find troubling.

If I compile my code from the command line, I get a
[Xlint:adviceDidNotMatch] when ajc runs my test-classes.  Consequently, my
aspect is never woven into my class.  But when I compile from within
Eclipse, the aspect is woven in.

I suspect that it has something to do with the classpath that maven is
presenting to ajc; indeed when I enable debug information, I see that the
/src/main/java classes are not on the path to ajc as they are during the
regular compilation, and only the src/test/java classes are present.

I don't know if this is a limitation of the ajc compiler, or if there is a
way to tell it to additionally (re)compile / weave classes into the output
folder only if they are affected.  I see the '-inpath' argument to ajc, but
will dump everything in the inpath to the output directory, or only the
changed classes?  Is there a way to tell it only to put the classes into
the output directory if they are changed/modified?

Thanks,

Eric

On Fri, Jun 19, 2015 at 12:19 PM, Andy Clement 
wrote:

> Are you simply hitting the problem that in Eclipse a project does not
> support separate compilation of src/main and src/test trees. When you
> import your project into eclipse those things get merged together, and all
> built together. You could perhaps get around this by adjusting your
> pointcuts in your aspect to only match the test code - not ideal I know.
>
> cheers,
> Andy
>
> > On Jun 18, 2015, at 11:25 AM, Eric B  wrote:
> >
> > I posted a question on StackOverflow, but haven't received much traction
> there, so I thought I would check with people on this list as well.
> >
> > I'm having trouble with Eclipse weaving aspects from my test folder into
> my target/classes folder (as opposed to putting the woven classes into
> target/test-classes)
> >
> > I've got a maven project in which I have @Aspect classes in my
> src/test/java folder.  If I build from command line, everything runs
> properly.  If however, I build from within Eclipse, the compiler weaves my
> aspects into my target class files and puts them in target/classes.
> >
> > This obviously causes me troubles as the JVM tries to find the woven
> Aspect and throws NoClassDefFoundError (since the actual aspect.class is
> only in target/test-classes).
> >
> > Has anyone encountered this before?  Is there a way to instruct
> ajc/Eclipse/maven/m2e to put the woven class file into target/test-classes
> and not target/classes when it is due to an aspect from the test folder?
> >
> >
> > My pom defn shows the following for the ajc plugin:
> >   
> > org.codehaus.mojo
> > aspectj-maven-plugin
> > 1.2
> > 
> >   
> > 
> >   compile
> >   test-compile
> > 
> > 
> >   true
> >   
> > 
> >   org.springframework
> >   spring-aspects
> > 
> >   
> >   7
> >   7
> > 
> >   
> > 
> > 
> >   
> > org.aspectj
> > aspectjrt
> > 1.7.0
> > compile
> >   
> >   
> > org.aspectj
> > aspectjtools
> > 1.7.0
> > compile
> >   
> > 
> > 
> >   true
> >   
> > 
> >   org.springframework
> >   spring-aspects
> > 
> >   
> >   7
> >   7
> > 
> >   
> >
> >
> > I've tried running maven 3.0.4 and 3.2.5, but no difference.
> >
> > 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
>
___
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] Problems with test aspects in Eclipse

[Eric B]

I posted a question on StackOverflow, but haven't received much traction
there, so I thought I would check with people on this list as well.

I'm having trouble with Eclipse weaving aspects from my test folder into my
target/classes folder (as opposed to putting the woven classes into
target/test-classes)

I've got a maven project in which I have @Aspect classes in my
src/test/java folder.  If I build from command line, everything runs
properly.  If however, I build from within Eclipse, the compiler weaves my
aspects into my target class files and puts them in target/classes.

This obviously causes me troubles as the JVM tries to find the woven Aspect
and throws NoClassDefFoundError (since the actual aspect.class is only in
target/test-classes).

Has anyone encountered this before?  Is there a way to instruct
ajc/Eclipse/maven/m2e to put the woven class file into target/test-classes
and not target/classes when it is due to an aspect from the test folder?


My pom defn shows the following for the ajc plugin:
  
org.codehaus.mojo
aspectj-maven-plugin
1.2

  

  compile
  test-compile


  true
  

  org.springframework
  spring-aspects

  
  7
  7

  


  
org.aspectj
aspectjrt
1.7.0
compile
  
  
org.aspectj
aspectjtools
1.7.0
compile
  


  true
  

  org.springframework
  spring-aspects

  
  7
  7

  


I've tried running maven 3.0.4 and 3.2.5, but no difference.

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] How to use @DeclareMixin when using generics?

[Eric B]

Hi,

I've got the following base class that I would like to change to a Mixin
aspect instead.

abstract public class BaseServiceImpl implements BaseService {

abstract protected BaseRepository getRepo();

public void save(T entity) {

getRepo().save(entity);

}

public List findAll() {

return getRepo().getAll();

}

public T findById(String id) {

return getRepo().get(id);

}

public void deleteEntity(T entity) {

getRepo().remove(entity);

}

}


But given the fact that it uses a generic, I'm not quite sure how to
declare my mixin.  I'm looking to do this for a general case for all
classes in a particular path where each 'T'ype is different, so am not sure
how to write the declaration


@DeclareMixin("com.ia.server.*Impl")

public BaseService baseServiceMixin(){

return new BaseServiceImpl();

   }


At the moment, this is an abstract class as I need the child class to
determine the BaseRepo, but is there a way of getting this info from the
child class itself?  Or at the very least, have it @Inject'ed?


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

Re: [aspectj-users] Fwd: AspectJ with Lombok?

[Eric B]

Hi Andy,

Just to keep you updated, I managed to get a debug session working with a
remote debugger.  Indeed, I had incorrectly jarjar'ed the aj lib, and once
I re jarjar'ed it, I got lombok to recognize it.  Unfortunately though, it
still is not lombok'ing.

That being said, I'm having a lot of difficulty in debugging the lombok
code.  It uses a bunch of jdt libs to compile, but they aren't the actual
ones being used during the debug process (I presume it is using different
versions), so stepping through code is a nightmare as the source lines
don't actually match up with the remote process being debugged.  I have to
dig around a little more there and see if I can find out why.

In the meantime, I've posted some questions to the lombok list hoping
others can point me in a helpful debug process, but so far am awaiting a
response.

The only thing I noticed from a quick look is the entry point into the
lombok lib from ajc and from javac seem to be from two different places.
Is that possible?  Lombok process gets bootstrapped  via APT (from what I
can tell).  Is it possible that ajc launches the APT process from a
different point than javac?

Thanks,

Eric


On Fri, Sep 19, 2014 at 10:00 PM, Eric Benzacar  wrote:

> Thanks - that'll give me something to play with over the weekend if I get
> some time.   It never occurred to me to try remote debugging on a local
> process.  Will give that a shot as well.
>
> I'll keep you posted on my results.
>
> Thanks,
>
> Eric
>
> On Fri, Sep 19, 2014 at 4:19 PM, Andy Clement 
> wrote:
>
>> The three jars are supersets of one another. If you jarjar aspectjtools
>> and just use that, it has everything in (including weaver/runtime). In fact
>> the compiler classes are only in aspectjtools.
>>
>> For debugging, can you just use JVM remote debugging? Set that -Xdebug
>> etc when launching (or in JVM_OPTS if using a script) and then attach the
>> eclipse debugger to it?
>>
>> > [WARNING] You aren't using a compiler supported by lombok, so lombok
>> will not work and has been disabled.
>> > Your processor is:
>> org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.BatchProcessingEnvImpl
>>
>> That does sound like jarjar didn't behave. Did you 'jar -tvf' your jar
>> and check everything had been changed back to org.eclipse.jdt?
>>
>> In theory it would also be possible to build an AspectJ package that
>> included those additional bundles lombok wants from eclipse, and jarjar
>> those too so the prefixes are all in agreement
>> (org.aspectj.org.eclipse.jdt).  Then once that package name was supported
>> throughout lombok it ought to all work - that is probably what would need
>> doing to get it behaving in the Eclipse IDE too. Create an extra bundle
>> with the prefixed forms of the JDT UI packages for use just in this context.
>>
>> cheers,
>> Andy
>>
>> On 19 September 2014 11:10, Eric B  wrote:
>>
>>> No only a couple of places that use it.  I think the biggest problem is
>>> in a single class which is related to the agent for Eclipse - I think.  I
>>> temporarily commented it out.
>>>
>>> But even with the problem class removed, it isn't generating the correct
>>> sources.  And I am having a lot of difficulty figuring out how to debug
>>> this when I run it command line, so it's not a very effective debugging
>>> process adding in printlns as I go along but without being able to inspect
>>> any vars, or even know which implementations are being called for what.
>>>
>>> I like your suggesting of trying to jarjar aspectj, but not sure which
>>> pkgs need to be modified: aspectjrt, aspectjtools, or aspectjweaver?  I
>>> actually tried to jarjar all 3, just to be safe, but when I run ajc with
>>> lombok, I get the following error:
>>>
>>> [WARNING] You aren't using a compiler supported by lombok, so lombok
>>> will not work and has been disabled.
>>> Your processor is:
>>> org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.BatchProcessingEnvImpl
>>> Lombok supports: sun/apple javac 1.6, ECJ
>>>
>>> Which to me looks like I missed something when I jarjar'ed the pkgs.
>>>
>>> But my rule was pretty basic:
>>> rule org.aspectj.org.eclipse.jdt.* org.eclipse.jdt.@1
>>> java -jar ~/Documents/Dev/libs/jarjar/jarjar-1.4.jar process
>>> lombok.jarjar.txt ../1.8.2/aspectjtools-1.8.2.jar
>>> aspectjtools-1.8.2_lombok.jar
>>>
>>> And then pointed to the newly created 1.8.2_lombok version in my maven
>>&

[aspectj-users] AspectJ / AJDT / ajc compilation error with @DeclareMixin

[Eric B]

I'm trying to use @DeclareMixin for the first time, and either I am doing
something incorrect, or there is a bug somewhere.

I've published my sample code to github:
https://github.com/benze/AspectJError.git.  I'm pasting the little bits
here as well.

If I look at the compiled code of ApplyAspect.class using a decompiler, I
can see that ajc has properly added in the implemented interface.
However, the compiler complains in Test that ApplyAspect does not have the
setCreated() or the getCreated() methods.

Additionally, if I try to compile the project from the command line, I get
compilation errors as well.

I'm not sure what I am doing wrong, or if there is a bug somewhere else
with @DeclareMixin directive.


Interface CreatedBean.java:
public interface CreatedBean {
public Object getCreated();
public void setCreated(final Object created);
}


Implementation CreatedBeanImpl.java:
public class CreatedBeanImpl implements CreatedBean{
private Object created;

public Object getCreated(){
return this.created;
}

public void setCreated(final Object created ){
this.created = created;
}
}


Aspect definition:
@Aspect
public class DeclareMixinAspect {
@DeclareMixin("com.benze.bo.ApplyAspect")
public CreatedBean auditableBeanMixin(){
return new CreatedBeanImpl();
}
}


Class being advised (com.benze.bo pkg):
public class ApplyAspect {
private String name = "test class";
}


Class trying to use ApplyAspect:
public class Test {

public static void main(String[] args) {
ApplyAspect aa = new ApplyAspect();
aa.setCreated(new Date());
System.out.println( aa.getCreated().toString());
System.out.println(aa.toString());
System.out.println("all done");
}
}




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

Re: [aspectj-users] Fwd: AspectJ with Lombok?

[Eric B]

No only a couple of places that use it.  I think the biggest problem is in
a single class which is related to the agent for Eclipse - I think.  I
temporarily commented it out.

But even with the problem class removed, it isn't generating the correct
sources.  And I am having a lot of difficulty figuring out how to debug
this when I run it command line, so it's not a very effective debugging
process adding in printlns as I go along but without being able to inspect
any vars, or even know which implementations are being called for what.

I like your suggesting of trying to jarjar aspectj, but not sure which pkgs
need to be modified: aspectjrt, aspectjtools, or aspectjweaver?  I actually
tried to jarjar all 3, just to be safe, but when I run ajc with lombok, I
get the following error:

[WARNING] You aren't using a compiler supported by lombok, so lombok will
not work and has been disabled.
Your processor is:
org.aspectj.org.eclipse.jdt.internal.compiler.apt.dispatch.BatchProcessingEnvImpl
Lombok supports: sun/apple javac 1.6, ECJ

Which to me looks like I missed something when I jarjar'ed the pkgs.

But my rule was pretty basic:
rule org.aspectj.org.eclipse.jdt.* org.eclipse.jdt.@1
java -jar ~/Documents/Dev/libs/jarjar/jarjar-1.4.jar process
lombok.jarjar.txt ../1.8.2/aspectjtools-1.8.2.jar
aspectjtools-1.8.2_lombok.jar

And then pointed to the newly created 1.8.2_lombok version in my maven pom.

So I'm a little lost/confused at this point.  Not sure what/where to try to
tackle next.  Was hoping to get some more direction from Reinier
Zwitserloot or Roel Spilker (the lead devs) but haven't heard anything back
from them yet.

Am open to any suggestions.  I was really hoping to use Lombok instead of
Roo (had an unpleasant Roo experience) and not using any spring-data stuff,
so figured lombok would be easier.  But I don't know if I'll ever get there.

Thanks,

Eric

On Fri, Sep 19, 2014 at 12:19 PM, Andy Clement 
wrote:

> For AspectJ we only repackage the minimum we have to do get the compiler
> going. That is JDT Core plus the annotations support (for annotation
> processing) and the dependencies of that. We don't touch JDT UI.  This does
> mean that AJDT does some mapping between the two - fixing exactly the
> problem you described of having a org.eclipse.jdt.XXX and needing a
> org.aspectj.org.eclipse.jdt.XXX.  I can see that those UI ones do relate to
> source manipulation/refactoring (which arguably is not actually a UI
> concern - but that's another story).
>
> Is it a lot of places where you get that problem in lombok?
>
> On the command line I could maybe imagine a 'hack' to test whether this
> thing will work at all by jarjar'ing aspectj and converting it back to just
> org.eclipse.jdt - but that solution wouldn't fly in Eclipse where we rely
> on the different package names to avoid tripping over real jdt.
>
> cheers,
> Andy
>
> On 18 September 2014 18:57, Eric B  wrote:
>
>> I've been working on it, but it isn't as obvious as I hoped/thought.  I
>> quickly tried to JarJar the compiled package but it didn't work.  So I
>> started manually renaming everything in the packages by hand in the lombok
>> sources.  However, I ran into a problem that I am not sure how to resolve.
>>  Some of Lombok relies on some non-aspectj rebranded packages,
>> specifically:
>>org.eclipse.jdt.internal.corext
>>org.eclipse.jdt.internal.ui
>>
>>
>> The biggest problem I have is that Lombok uses classes from these
>> packages and tries to pass org.aspectj.xxx classes as arguments to their
>> methods.  Since the classes are original org.eclipse.jdt packages,
>> obviously the arguments do not match the expected type.  ie: passed an
>> org.aspectj.org.eclipse.jdt argument but expecting a org.eclispe.jdt
>> argument.
>>
>>
>> I tried searching the org.aspectj github site, but can't find either of
>> those two packages having been re-branded.  More importantly, I don't know
>> if/how Lombok hooks into Eclipse; where it relies on original source pkg
>> naming.
>>
>> Do either of the packages mean anything to you?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> On Thu, Sep 18, 2014 at 2:16 PM, Andy Clement 
>> wrote:
>>
>>> The ECJ packages are renamed but there are also numerous extensions here
>>> and there to support the likes of ITDs which affect type/method resolution.
>>> If you clone the AspectJ repo: https://github.com/eclipse/org.aspectj
>>> you will see the compiler in the org.eclipse.jdt.core module - the binary
>>> and src are in there. That module is actually built from the repo
>>> org.aspectj.shadows - browsing t

Re: [aspectj-users] Fwd: AspectJ with Lombok?

[Eric B]

I've been working on it, but it isn't as obvious as I hoped/thought.  I
quickly tried to JarJar the compiled package but it didn't work.  So I
started manually renaming everything in the packages by hand in the lombok
sources.  However, I ran into a problem that I am not sure how to resolve.
 Some of Lombok relies on some non-aspectj rebranded packages,
specifically:
   org.eclipse.jdt.internal.corext
   org.eclipse.jdt.internal.ui


The biggest problem I have is that Lombok uses classes from these packages
and tries to pass org.aspectj.xxx classes as arguments to their methods.
 Since the classes are original org.eclipse.jdt packages, obviously the
arguments do not match the expected type.  ie: passed an
org.aspectj.org.eclipse.jdt argument but expecting a org.eclispe.jdt
argument.


I tried searching the org.aspectj github site, but can't find either of
those two packages having been re-branded.  More importantly, I don't know
if/how Lombok hooks into Eclipse; where it relies on original source pkg
naming.

Do either of the packages mean anything to you?

Thanks,

Eric


On Thu, Sep 18, 2014 at 2:16 PM, Andy Clement 
wrote:

> The ECJ packages are renamed but there are also numerous extensions here
> and there to support the likes of ITDs which affect type/method resolution.
> If you clone the AspectJ repo: https://github.com/eclipse/org.aspectj you
> will see the compiler in the org.eclipse.jdt.core module - the binary and
> src are in there. That module is actually built from the repo
> org.aspectj.shadows - browsing that is more complicated so I'd say glance
> into the src/zip. I can't say whether lombok would be compatible apart from
> the package prefix but my gut feeling would be that it would just work.  I
> wonder if running a jarjar on the lombok code to replace occurrences org
> org.eclipse.jdt. with org.aspectj.org.eclipse.jdt. might get it into a
> working state.
>
> cheers,
> Andy
>
> On 18 September 2014 09:41, Eric B  wrote:
>
>> Hi Andy,
>>
>> Your reply just came in as I was writing my addendum.  I ran across the
>> following post on SO that could hopefully help (
>> http://stackoverflow.com/questions/6107197/how-does-lombok-work).
>>
>> Lombok codes against a) internal javac apis and b) internal eclipse apis
>> (in a separate processor). JSR 269 does not let you modify existing source
>> code, but when you cast an Element
>> <http://download.oracle.com/javase/6/docs/api/javax/lang/model/element/Element.html>
>>  to
>> the underlying AST node, you can actually modify the AST (which is what
>> project Lombok does).
>>
>> I'm not entirely sure how much ajc deviates from ejc.  Have you just
>> renamed all the packages to be org.aspectj?  Where would I find the sources
>> for EJC to see how much/where AJC deviates?
>>
>> Thanks,
>>
>> Eric
>>
>>
>>
>> On Thu, Sep 18, 2014 at 11:25 AM, Andy Clement 
>> wrote:
>>
>>> I had a brief look at this when we added annotation processing support
>>> to AspectJ as that is what I thought Lombok was doing. But then I
>>> discovered that I think it wanted to be run as an agent when using the
>>> Eclipse Java Compiler (on which AspectJ is based). If I recall correctly
>>> lombok had hardcoded classnames for ECJ classes in it and in AspectJ we
>>> prefix those with "org.aspectj." - that is as far as I got looking though,
>>> I'm afraid.  It would be great if someone had a bit more time than me to
>>> dig into it.  Possibly you just need a lombok that recognizes this variant
>>> of ECJ.
>>>
>>> I think within eclipse some people have been turning on both java and
>>> aspectj builders to get it to work a little better. the java builder
>>> allowing lombok to run then AspectJ running afterwards but that sounds
>>> pretty ugly so I've never tried it.
>>>
>>> cheers,
>>> Andy
>>>
>>> On 17 September 2014 20:27, Eric B  wrote:
>>>
>>>> I'm trying to use Lombok (http://projectlombok.org/) in an AspectJ
>>>> project, but when I enable AspectJ, none of my generated lombok code is
>>>> added to my byte code.
>>>>
>>>> I'm not entirely sure how lombok interacts with Javac, but my guess is
>>>> that the ajc compiler does not recognize lombok the way javac does.
>>>>
>>>> Is there anyway to make these two play nicely?  Can I configure ajc to
>>>> use/recognize lombok properly?  Or am I forced to pick only one of the two
>>>> technologies?
>>>>
>

[aspectj-users] Fwd: AspectJ with Lombok?

[Eric B]

Hi Andy,

Your reply just came in as I was writing my addendum.  I ran across the
following post on SO that could hopefully help (
http://stackoverflow.com/questions/6107197/how-does-lombok-work).

Lombok codes against a) internal javac apis and b) internal eclipse apis
(in a separate processor). JSR 269 does not let you modify existing source
code, but when you cast an Element
<http://download.oracle.com/javase/6/docs/api/javax/lang/model/element/Element.html>
to
the underlying AST node, you can actually modify the AST (which is what
project Lombok does).

I'm not entirely sure how much ajc deviates from ejc.  Have you just
renamed all the packages to be org.aspectj?  Where would I find the sources
for EJC to see how much/where AJC deviates?

Thanks,

Eric



On Thu, Sep 18, 2014 at 11:25 AM, Andy Clement 
wrote:

> I had a brief look at this when we added annotation processing support to
> AspectJ as that is what I thought Lombok was doing. But then I discovered
> that I think it wanted to be run as an agent when using the Eclipse Java
> Compiler (on which AspectJ is based). If I recall correctly lombok had
> hardcoded classnames for ECJ classes in it and in AspectJ we prefix those
> with "org.aspectj." - that is as far as I got looking though, I'm afraid.
>  It would be great if someone had a bit more time than me to dig into it.
>  Possibly you just need a lombok that recognizes this variant of ECJ.
>
> I think within eclipse some people have been turning on both java and
> aspectj builders to get it to work a little better. the java builder
> allowing lombok to run then AspectJ running afterwards but that sounds
> pretty ugly so I've never tried it.
>
> cheers,
> Andy
>
> On 17 September 2014 20:27, Eric B  wrote:
>
>> I'm trying to use Lombok (http://projectlombok.org/) in an AspectJ
>> project, but when I enable AspectJ, none of my generated lombok code is
>> added to my byte code.
>>
>> I'm not entirely sure how lombok interacts with Javac, but my guess is
>> that the ajc compiler does not recognize lombok the way javac does.
>>
>> Is there anyway to make these two play nicely?  Can I configure ajc to
>> use/recognize lombok properly?  Or am I forced to pick only one of the two
>> technologies?
>>
>> 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
>
___
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

Re: [aspectj-users] AspectJ with Lombok?

[Eric B]

As a followup, I posted the question on SO (
http://stackoverflow.com/q/25903686/827480) and emailed the Lombok list as
well.  Both places pointed me to the following blog:
https://weblogs.java.net/blog/fabriziogiudici/archive/2011/07/19/making-lombok-aspectj-and-maven-co-exist

Fabrizio suggests having javac compile the sources first, and then have ajc
weave using the javac byte code as the input and not the source code.  This
would avoid requiring ajc to understand Lombok annotations b/c the javac
would have already compiled in the necessary methods.

For basic around/etc pointcut aspects, I see that as a feasible workaround.
 However, I don't see that working with ITD aspects (member
injection/interface implementation/etc).  Javac will never properly finish
compiling code that relys on ITD members since as far as javac is
concerned, they don't exist yet.

Which makes this sound like a pretty nasty race condition.

I'm not quite sure which team to discuss this with - if it is an ajc issue,
or a lombok issue.

Thanks,

Eric



On Wed, Sep 17, 2014 at 11:27 PM, Eric B  wrote:

> I'm trying to use Lombok (http://projectlombok.org/) in an AspectJ
> project, but when I enable AspectJ, none of my generated lombok code is
> added to my byte code.
>
> I'm not entirely sure how lombok interacts with Javac, but my guess is
> that the ajc compiler does not recognize lombok the way javac does.
>
> Is there anyway to make these two play nicely?  Can I configure ajc to
> use/recognize lombok properly?  Or am I forced to pick only one of the two
> technologies?
>
> 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] AspectJ with Lombok?

[Eric B]

I'm trying to use Lombok (http://projectlombok.org/) in an AspectJ project,
but when I enable AspectJ, none of my generated lombok code is added to my
byte code.

I'm not entirely sure how lombok interacts with Javac, but my guess is that
the ajc compiler does not recognize lombok the way javac does.

Is there anyway to make these two play nicely?  Can I configure ajc to
use/recognize lombok properly?  Or am I forced to pick only one of the two
technologies?

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] AspectJ 1.8 for Luna?

[Eric B]

With AJ 1.8 released and Luna released, is there a new AJ development tools
plugin released for Luna as well?

I checked the AJDT site (http://www.eclipse.org/ajdt/downloads/) and it
only lists AJDT 2.2 for Kepler (4.3) and nothing for Luna.

Is AJDT 2.2 sufficient to work with AJ1.8?

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

Re: [aspectj-users] Pointcut to a Collection.add() method on a particular type of argument?

[Eric B]

Thanks.  What if want to advise based on an annotation rather than a type?
I tried

pointcut addEntity(@MyAnnotation * s):
call( * java.util.Collection+.add( * ))
&& args(s);

But got syntax error that @MyAnnotation is not allowed.

Thx
Eric
 On Jul 17, 2014 1:05 AM, "Ulises Juárez Martínez" 
wrote:

> Hi Eric,
>
> add() signature is:
>
> add(E e)
>
> Thus, * matches anything, but java.lang.String is not E.
>
> Change your pointcut to:
>
> pointcut addEntity(String s):
> call( * java.util.Collection+.add( * ))
> && args(s);
>
> Best regards.
>
> Ulises
>
>
> On Wed, Jul 16, 2014 at 10:31 PM, Eric B  wrote:
> > I'm trying to write a pointcut against a Collection.add() method given a
> > specific type of argument, but everytime I specify the argument type the
> > pointcut fails to advise.
> >
> > Given the following code:
> > List x = new ArrayList();
> > x.add("Some String)";
> >
> > This works:
> >
> > pointcut addEntity():  call( * java.util.Collection+.add( * ));
> >
> > However, this does not:
> >
> > pointcut addEntity():  call( * java.util.Collection+.add(
> java.util.String
> > ));
> >
> >
> > Is there a specific reason why I cannot specify the type of argument I
> want
> > to advise against?
> >
> > 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
>
___
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] Pointcut to a Collection.add() method on a particular type of argument?

[Eric B]

I'm trying to write a pointcut against a Collection.add() method given a
specific type of argument, but everytime I specify the argument type the
pointcut fails to advise.

Given the following code:
List x = new ArrayList();
x.add("Some String)";

This works:

pointcut addEntity():  call( * java.util.Collection+.add( * ));

However, this does not:

 pointcut addEntity():  call( * java.util.Collection+.add( java.util.String
));


Is there a specific reason why I cannot specify the type of argument I want
to advise against?

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] How to advise setters in JPA entities using AOP?

[Eric B]

I've posted this question on StackOverflow (
http://stackoverflow.com/q/24786391/827480), but am sending it here as well
as not everyone monitors StackOverflow.

 have the need to log any changes to fields in an entity - whether it is a
String change, or addition/deletion to a collection/map.

Given a JPA entity with a bunch of primitive fields, it is fairly trivial
to write an pointcut that will intercept any set(..) methods on the fields.

However, where I am stuck is how to write the pointcut to handle
Collections/Sets/Embedded/etc.

Given the following entity:

@Entitypublic class Provider implements Serializable {

@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = "id")
private Long id;


private String name;

@Column(name="type", nullable=false)
@Enumerated(EnumType.STRING)
private ProviderType providerType;


@ManyToMany
private List contacts;

@Embedded
private Validity validity;

   // setters and getters omitted for brevity
}

where Contact is a simple entity with a bunch of primitive fields and
Validity is a non-entity object with some primitive fields.

The following pointcut will intercept all set() methods in the class:

pointcut fieldSetter() : set(!static !final !transient * *.Provider)
&& args(val) && target(o);

 to which I can write a before/after/around advice.

before( Object val, Object o) : fieldSetter{
  String fieldName = thisJoinPointStaticPart.getSignature().getName();
  System.out.println( "Object being changed: " + o.toString() );
  System.out.println( "New Value for: " + fieldname + " is: " + v.toString() );}

But how do I handle that case for an Embedded object or a Collection? For
an Embedded object, if I just put my advice around the setter method in the
object, how do I know which is the parent object that is actually being
modified/persisted?

And in the case of collections/sets/maps/etc, how do I advise against the
add/remove methods? What I need to end up doing is advising the
getCollection().add() methods as well as the getCollection.remove()
methods. But I can't seem to figure out a good way.


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

Re: [aspectj-users] Pointcut to execution within execution

[Eric B]

I'm not 100% sure of this, but you would be using a call pointcut - not an
execution pointcut.

So something like call( * A.doA(..) ).

This would advise any calls to A.doA() method from the call location (ie:
B.doB().doA()). An execution pointcut would advise A.doA().

Eric



On Wed, Jul 9, 2014 at 12:59 PM, vach  wrote:

> Is it possible to match execution within execution?
>
> class A{
> doA(){}
> }
>
> class B{
> doB{
> doA(); // < how to point at this execution?
> }
> }
>
>
>
> --
> View this message in context:
> http://aspectj.2085585.n4.nabble.com/Pointcut-to-execution-within-execution-tp4651472.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> ___
> 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

Re: [aspectj-users] How to access advice aspect's fields without reflection?

[Eric B]

Yes I can.  I was busy searching for something way more complicated than it
had to be!

Thanks for pointing out the obvious, but was too blind to see! :)

Eric



On Tue, Jul 8, 2014 at 11:49 AM, Archie Cobbs  wrote:

> Can't you just use field.getType() to get the field's type?
>
> -Archie
>
>
> On Tue, Jul 8, 2014 at 10:35 AM, Eric B  wrote:
>
>> Thanks Andy,
>>
>> That's what I was thinking as well.  However, one thing that I haven't
>> been able to find is how to get the type of obj that needs to be
>> instantiated.
>> Currently, it is a Validity object.  However, if I wanted to do this more
>> generically, I would want to do something like:
>>
>> value = thisJoinPoint.getSignature().fieldType.newInstance()
>>
>> However, I can't seem to find any way to get "fieldType".
>>
>> Is that information not accessible anywhere?  If not, is there a way to
>> get the expected return type of the get() pointcut?
>>
>> Tx,
>>
>> Eric
>>
>>
>> On Tue, Jul 8, 2014 at 5:26 AM, Andy Clement 
>> wrote:
>>
>>> I only had a couple of mins to play but if you went with around advice
>>> you could make the reflection only run if initialization is required:
>>>
>>>  Object *around*(): embeddedGetter() {
>>>
>>> Object value = *proceed*();
>>>
>>> *if* (value == *null*) {
>>>
>>> String fieldName = *thisJoinPoint*.getSignature().getName();
>>>
>>> Object obj = *thisJoinPoint*.getThis();
>>>
>>>  *try*{
>>>
>>> Field field = obj.getClass().getDeclaredField(fieldName);
>>>
>>> field.setAccessible(*true*);
>>>
>>> field.set(obj, value = *new* Validity() );
>>>
>>> }
>>>
>>> *catch*( IllegalAccessException | NoSuchFieldException
>>> e){e.printStackTrace();}
>>>
>>> }
>>>
>>> *return* value;
>>>
>>> }
>>>
>>>
>>> Andy
>>>
>>>
>>> On 8 July 2014 04:34, Eric B  wrote:
>>>
>>>> I've got the following issue that I am trying to solve with AspectJ.
>>>>
>>>> Given an entity class with a null @Embedded field, when trying to
>>>> access it with a getter, instantiate it first if it is null.
>>>>
>>>> For example:
>>>>
>>>> @Entity
>>>> public class MyClass {
>>>>
>>>> @Id
>>>> private long id;
>>>>
>>>> @Embedded
>>>> private Validity validity;
>>>> }
>>>>
>>>>
>>>> And Validity:
>>>>
>>>> @Embeddable
>>>> public class Validity{
>>>> private long from;
>>>> private long to;
>>>> }
>>>>
>>>> I'm having trouble figuring out how to best write the before() advice
>>>> however.  Ideally, I'm trying to avoid using reflection for fear of slowing
>>>> things down, but so far, the best I have been able to come up with is the
>>>> following:
>>>>
>>>> // define a pointcut for any getter method of a field with @Embedded of
>>>> type Validity with any name in com.ia.domain package
>>>> pointcut embeddedGetter() : get( @javax.persistence.Embedded
>>>> com.ia.domain.Validity com.ia.domain..* );
>>>>  before() : embeddedGetter(){
>>>> String fieldName = thisJoinPoint.getSignature().getName();
>>>>  Object obj = thisJoinPoint.getThis();
>>>>  // check to see if the obj has the field already defined or is null
>>>>  try{
>>>> Field field = obj.getClass().getDeclaredField(fieldName);
>>>> field.setAccessible(true);
>>>>  if( field.get(obj) == null )
>>>> field.set(obj, new com.ia.domain.Validity() );
>>>> }
>>>>  catch( IllegalAccessException | NoSuchFieldException e){}
>>>> }
>>>>
>>>>
>>>> Is there a better way?
>>>>
>>>> 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
>>>
>>
>>
>> ___
>> 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
>>
>
>
>
> --
> Archie L. Cobbs
>
> ___
> 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

Re: [aspectj-users] How to access advice aspect's fields without reflection?

[Eric B]

Thanks Andy,

That's what I was thinking as well.  However, one thing that I haven't been
able to find is how to get the type of obj that needs to be instantiated.
Currently, it is a Validity object.  However, if I wanted to do this more
generically, I would want to do something like:

value = thisJoinPoint.getSignature().fieldType.newInstance()

However, I can't seem to find any way to get "fieldType".

Is that information not accessible anywhere?  If not, is there a way to get
the expected return type of the get() pointcut?

Tx,

Eric


On Tue, Jul 8, 2014 at 5:26 AM, Andy Clement 
wrote:

> I only had a couple of mins to play but if you went with around advice you
> could make the reflection only run if initialization is required:
>
>  Object *around*(): embeddedGetter() {
>
> Object value = *proceed*();
>
> *if* (value == *null*) {
>
> String fieldName = *thisJoinPoint*.getSignature().getName();
>
> Object obj = *thisJoinPoint*.getThis();
>
>  *try*{
>
> Field field = obj.getClass().getDeclaredField(fieldName);
>
> field.setAccessible(*true*);
>
> field.set(obj, value = *new* Validity() );
>
> }
>
> *catch*( IllegalAccessException | NoSuchFieldException
> e){e.printStackTrace();}
>
> }
>
> *return* value;
>
> }
>
>
> Andy
>
>
> On 8 July 2014 04:34, Eric B  wrote:
>
>> I've got the following issue that I am trying to solve with AspectJ.
>>
>> Given an entity class with a null @Embedded field, when trying to access
>> it with a getter, instantiate it first if it is null.
>>
>> For example:
>>
>> @Entity
>> public class MyClass {
>>
>> @Id
>> private long id;
>>
>> @Embedded
>> private Validity validity;
>> }
>>
>>
>> And Validity:
>>
>> @Embeddable
>> public class Validity{
>> private long from;
>> private long to;
>> }
>>
>> I'm having trouble figuring out how to best write the before() advice
>> however.  Ideally, I'm trying to avoid using reflection for fear of slowing
>> things down, but so far, the best I have been able to come up with is the
>> following:
>>
>> // define a pointcut for any getter method of a field with @Embedded of
>> type Validity with any name in com.ia.domain package
>> pointcut embeddedGetter() : get( @javax.persistence.Embedded
>> com.ia.domain.Validity com.ia.domain..* );
>>  before() : embeddedGetter(){
>> String fieldName = thisJoinPoint.getSignature().getName();
>>  Object obj = thisJoinPoint.getThis();
>>  // check to see if the obj has the field already defined or is null
>>  try{
>> Field field = obj.getClass().getDeclaredField(fieldName);
>> field.setAccessible(true);
>>  if( field.get(obj) == null )
>> field.set(obj, new com.ia.domain.Validity() );
>> }
>>  catch( IllegalAccessException | NoSuchFieldException e){}
>> }
>>
>>
>> Is there a better way?
>>
>> 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
>
___
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] How to access advice aspect's fields without reflection?

[Eric B]

I've got the following issue that I am trying to solve with AspectJ.

Given an entity class with a null @Embedded field, when trying to access it
with a getter, instantiate it first if it is null.

For example:

@Entity
public class MyClass {

@Id
private long id;

@Embedded
private Validity validity;
}


And Validity:

@Embeddable
public class Validity{
private long from;
private long to;
}

I'm having trouble figuring out how to best write the before() advice
however.  Ideally, I'm trying to avoid using reflection for fear of slowing
things down, but so far, the best I have been able to come up with is the
following:

// define a pointcut for any getter method of a field with @Embedded of
type Validity with any name in com.ia.domain package
pointcut embeddedGetter() : get( @javax.persistence.Embedded
com.ia.domain.Validity com.ia.domain..* );
 before() : embeddedGetter(){
String fieldName = thisJoinPoint.getSignature().getName();
 Object obj = thisJoinPoint.getThis();
 // check to see if the obj has the field already defined or is null
 try{
Field field = obj.getClass().getDeclaredField(fieldName);
field.setAccessible(true);
 if( field.get(obj) == null )
field.set(obj, new com.ia.domain.Validity() );
}
 catch( IllegalAccessException | NoSuchFieldException e){}
}


Is there a better way?

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

Re: [aspectj-users] How to write a pointcut for getters of an annotated field?

[Eric B]

After playing around with AspectJ, I finally rediscovered the join point I
was looking for:

pointcut embeddedGetter() : get( @MyAnnotation Validity *..* );

Thanks,

Eric



On Mon, Jul 7, 2014 at 9:38 PM, Eric B  wrote:

> I'm trying to write a pointcut which will intercept getters for annotated
> members.
>
> public class MyClass {
>
> private String volume;
>
> @MyAttribute
> private Validity validity;
>
>
> public void setValidity( Validity obj ){
> validity = obj;
> }
>
> public Validity getValidity(){
> return validity;
> }}
>
> Is there a way to write a pointcut that will intercept all calls to
> getValidity() based on validity being annotated with @MyAttribute?
> Written differently, I'm looking to create a pointcut for any getter of a
> member field that is annotated with @MyAttribute.
>
> Is this feasible?
>
> 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] How to write a pointcut for getters of an annotated field?

[Eric B]

I'm trying to write a pointcut which will intercept getters for annotated
members.

public class MyClass {

private String volume;

@MyAttribute
private Validity validity;


public void setValidity( Validity obj ){
validity = obj;
}

public Validity getValidity(){
return validity;
}}

Is there a way to write a pointcut that will intercept all calls to
getValidity() based on validity being annotated with @MyAttribute? Written
differently, I'm looking to create a pointcut for any getter of a member
field that is annotated with @MyAttribute.

Is this feasible?

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] Fwd: Injecting a component in a non-spring environment

[Eric B]

Hi Erik,

I hope you don't mind, but I've copied my answer to this in StackOverflow
b/c I think you might get more extra traction there than you will in this
mailing list.

(
http://stackoverflow.com/questions/23511287/injecting-a-component-in-an-aspect-in-a-non-spring-environment
)


Without understanding the exact internals of what you are doing (or perhaps
rather why), what you can do is something like the following in your
aspect. (Not the cleanest option, but at least a starting point)

If BusinessRuleManager is a singleton, how do you instantiate it/retrieve
it from elsewhere in the non-Spring application? Or is it used only within
the aspect?

 after(PersistentObject persistentObject) :
persistentObjectPropertySetter(persistentObject)
{

if(businessRuleManager!=null)

   businessRuleManager = BusinessRuleManager.getInstance();


if(businessRuleManager!=null)
{
businessRuleManager.execute(persistentObject,
thisJoinPoint.getSignature().getName());
}
}

And in your BusinessRuleManager:

class BusinessRuleManager{
   ...
   static private BusinessRuleManager instance;

   static public BusinessRuleManager getInstance(){
 if( instance == null )
 instance = new BusinessRuleManager();

 return instance;
   }

   ...}

This should allow you to use the mix of Spring injection as well as a
non-spring container.


Thanks,

Eric


On May 8, 2014 9:34 AM, "erik"  wrote:

> Hello Eric,
>
> The answers to your questions are as follows:
> (1) Are you trying to get access to a Java bean from within your Aspect?
> It's more a service than a java bean. We are having trouble debugging our
> aspects in eclipse, and decided to delegate the real advise implementation
> to a helper component (which is easy to debug) as soon as we can. In my
> example i'm trying to 'inject' the helper component in one of our aspects.
> It's easy to configure with spring, but not without it.
> (2) Can you not use a factory-style approach to access it?
> I suppose we can do that, but assumed we followed a 'best practice' (?) in
> spring with the
>  class="com.fugro.gwf.domain.rules.aspects.BusinessRuleAspect"
> factory-method="aspectOf">
>  ref="businessRuleManager" />
> 
> If we introduce some extra code in the aspect for the
> factory-style-approach, spring won't be used on either side. I'm not
> against
> that, just looking for opinions ... A question that still remains for me,
> even with the factory-style approach is: how is the aspect itself
> instantiated when I'm not using the spring configuration mentioned above?
> (3) Is the bean a singleton?
> Yes it is. Because that happened to be the standard for a spring managed
> bean ...
>
>
>
> --
> View this message in context:
> http://aspectj.2085585.n4.nabble.com/Injecting-a-component-in-a-non-spring-environment-tp4651384p4651391.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> ___
> 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

Re: [aspectj-users] Injecting a component in a non-spring environment

[Eric B]

Hi Erik,

I'm a little confused as to what you are trying to accomplish.  Are you
trying to get access to a Java bean from within your Aspect?  Can you not
use a factory-style approach to access it?  Is the bean a singleton?

The aspect isn't anything magical; from what I know, you have to use normal
java constructs to get access to the Java bean.

Thanks,

Eric



On Thu, May 8, 2014 at 8:26 AM, erik  wrote:

> Hello,
>
> I tried to do what you suggest, and came up with the following code:
>
> public aspect BusinessRuleAspectConfigurer
> {
>   before(BusinessRuleAspect obj):
> execution(BusinessRuleAspect.new(..)) &&
> this(obj) {
>  obj.businessRuleManager =
> BusinessRuleAspect.aspectOf();
>   }
> }
>
> There are a few things I still don 't understand (please be patient with me
> ;-) ):
> 1) the code doesn't compile because BusinessRuleAspect.aspectOf() produces
> something with a type of BusinessRuleAspect, which is not compatible with
> the businessRuleManager on the left
> 2) What mechanism is supposed to create the aspect, when I don't have
> spring
> creating it from the application context?
>
>
>
> --
> View this message in context:
> http://aspectj.2085585.n4.nabble.com/Injecting-a-component-in-a-non-spring-environment-tp4651384p4651388.html
> Sent from the AspectJ - users mailing list archive at Nabble.com.
> ___
> 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] Fwd: Why is my pointcut not advising methods declared in a another aspect?

[Eric B]

Hi Andy,

> Now instead of that what you can do is not use @within - this is not
ideal but I'm just mentioning it - change annotatedClass() to:

> "execution(* (@RequiredUserDetails *).*(..))"

Seems to work great.  Although I have to admit that I am not entirely sure
as to why/how that pointcut works.  How is that picking up everything that
is in an annotated class?

I'm not sure what or how (@RequiredUserDetails *) picks up the right
pointcut?

Thanks,

Eric



On Mon, Apr 21, 2014 at 7:28 PM, Andy Clement wrote:

> I found a few mins.
>
> So within() is a lexical thing. Your pointcut is:
>
> "testMethod() && (annotatedClass() || annotatedMethod()"
>
> The testMethod() part is matching but neither of the other two are. That
> is because the ITD'd method is not within the target, it is 'within' the
> declared aspect.  So doing @within(RequiredUserDetails) isn't going to
> match because the aspect doesn't have @RequiredUserDetails on.  Now you
> could add it to confirm what I'm saying but then you'll hit a real bug if
> you try. The use of privileged in the aspect declaration is breaking
> support for annotations on the aspect, so to confirm what I'm saying, add
> @RequiredUserDetails and remove the 'privileged' word.
>
> Now instead of that what you can do is not use @within - this is not ideal
> but I'm just mentioning it - change annotatedClass() to:
>
> "execution(* (@RequiredUserDetails *).*(..))"
>
> cheers,
> Andy
>
>
>
> On 21 April 2014 14:42, Andy Clement  wrote:
>
>> Hi,
>>
>> Sorry, I just haven't had a chance to have a look. Probably worth logging
>> an AspectJ bug in bugzilla so it is appropriately tracked as an issue.
>>
>> cheers,
>> Andy
>>
>>
>> On 17 April 2014 21:44, Eric B  wrote:
>>
>>> Hi Andy,
>>>
>>> Have you had a chance to look at this at the sample application at all (
>>> https://github.com/benze/AspectJUnitTestError)?  Is this an aspectJ bug
>>> or a limitation?  Or am I doing something wrong?
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>>
>>> On Thu, Apr 10, 2014 at 3:08 PM, Eric B  wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> I've created a sample application that demonstrates this problem.  I've
>>>> uploaded it to GitHub.  I pulled this from a working project, but have
>>>> tried to make it as simple & basic as possible to illustrated the problem.
>>>>  You can find it here:
>>>> https://github.com/benze/AspectJUnitTestError.git
>>>>
>>>> Basically, the pointcut is supposed to advise any methods in a class
>>>> that is annotated with my custom annotation and the @Test annotation.  In
>>>> the *Roo*.aj aspect, a @Test method is crosscut into the class and yet the
>>>> advice is not called for that method.
>>>>
>>>> You can quickly see that the test for the crosscut method fails.
>>>>
>>>> Please let me know if you have any questions.
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> On Fri, Apr 4, 2014 at 2:17 PM, Andy Clement 
>>>> wrote:
>>>>
>>>>> I presume all these aspects are being compiled together with the code.
>>>>> You shouldn't have to worry about that order the aspects are applied in -
>>>>> yes there are ITDs but the weaver considers the system as a whole and will
>>>>> apply the aspects to ITD'd methods as well as existing methods:
>>>>>
>>>>> public class Code {
>>>>>   public void moo(String s) {}
>>>>> }
>>>>>
>>>>> aspect X {
>>>>>   public void Code.boo(String s) {}
>>>>> }
>>>>>
>>>>> aspect Y {
>>>>>   before(): execution(* *(String)) {}
>>>>> }
>>>>>
>>>>> > ajc -showWeaveInfo Code.java X.java Y.java
>>>>>
>>>>> Join point 'method-execution(void Code.boo(java.lang.String))' in Type
>>>>> 'X' (X.java:2) advised by before advice from 'Y' (Y.java:2)
>>>>> Type 'Code' (Code.java) has intertyped method from 'X' (X.java:'void
>>>>> Code.boo(java.lang.String)')
>>>>> Join point 'method-execution(void Code.moo(java.lang.String))' in Type
>>

Re: [aspectj-users] Why is my pointcut not advising methods declared in a another aspect?

[Eric B]

Thanks Andy,

I will try out a few different things and let you know.  I guess I had
figured since this was all being done at compile time, it would look at the
compiled class (once the ITD was already woven in) and then see that the
compiled class had the @RequiredUserDetails in it.  I didn't realize that
it was looking at the aspect first to determine how/where to weave in the
extra code.

Thanks,

Eric



On Mon, Apr 21, 2014 at 7:28 PM, Andy Clement wrote:

> I found a few mins.
>
> So within() is a lexical thing. Your pointcut is:
>
> "testMethod() && (annotatedClass() || annotatedMethod()"
>
> The testMethod() part is matching but neither of the other two are. That
> is because the ITD'd method is not within the target, it is 'within' the
> declared aspect.  So doing @within(RequiredUserDetails) isn't going to
> match because the aspect doesn't have @RequiredUserDetails on.  Now you
> could add it to confirm what I'm saying but then you'll hit a real bug if
> you try. The use of privileged in the aspect declaration is breaking
> support for annotations on the aspect, so to confirm what I'm saying, add
> @RequiredUserDetails and remove the 'privileged' word.
>
> Now instead of that what you can do is not use @within - this is not ideal
> but I'm just mentioning it - change annotatedClass() to:
>
> "execution(* (@RequiredUserDetails *).*(..))"
>
> cheers,
> Andy
>
>
>
> On 21 April 2014 14:42, Andy Clement  wrote:
>
>> Hi,
>>
>> Sorry, I just haven't had a chance to have a look. Probably worth logging
>> an AspectJ bug in bugzilla so it is appropriately tracked as an issue.
>>
>> cheers,
>> Andy
>>
>>
>> On 17 April 2014 21:44, Eric B  wrote:
>>
>>> Hi Andy,
>>>
>>> Have you had a chance to look at this at the sample application at all (
>>> https://github.com/benze/AspectJUnitTestError)?  Is this an aspectJ bug
>>> or a limitation?  Or am I doing something wrong?
>>>
>>> Thanks,
>>>
>>> Eric
>>>
>>>
>>> On Thu, Apr 10, 2014 at 3:08 PM, Eric B  wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> I've created a sample application that demonstrates this problem.  I've
>>>> uploaded it to GitHub.  I pulled this from a working project, but have
>>>> tried to make it as simple & basic as possible to illustrated the problem.
>>>>  You can find it here:
>>>> https://github.com/benze/AspectJUnitTestError.git
>>>>
>>>> Basically, the pointcut is supposed to advise any methods in a class
>>>> that is annotated with my custom annotation and the @Test annotation.  In
>>>> the *Roo*.aj aspect, a @Test method is crosscut into the class and yet the
>>>> advice is not called for that method.
>>>>
>>>> You can quickly see that the test for the crosscut method fails.
>>>>
>>>> Please let me know if you have any questions.
>>>>
>>>> Thanks,
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> On Fri, Apr 4, 2014 at 2:17 PM, Andy Clement 
>>>> wrote:
>>>>
>>>>> I presume all these aspects are being compiled together with the code.
>>>>> You shouldn't have to worry about that order the aspects are applied in -
>>>>> yes there are ITDs but the weaver considers the system as a whole and will
>>>>> apply the aspects to ITD'd methods as well as existing methods:
>>>>>
>>>>> public class Code {
>>>>>   public void moo(String s) {}
>>>>> }
>>>>>
>>>>> aspect X {
>>>>>   public void Code.boo(String s) {}
>>>>> }
>>>>>
>>>>> aspect Y {
>>>>>   before(): execution(* *(String)) {}
>>>>> }
>>>>>
>>>>> > ajc -showWeaveInfo Code.java X.java Y.java
>>>>>
>>>>> Join point 'method-execution(void Code.boo(java.lang.String))' in Type
>>>>> 'X' (X.java:2) advised by before advice from 'Y' (Y.java:2)
>>>>> Type 'Code' (Code.java) has intertyped method from 'X' (X.java:'void
>>>>> Code.boo(java.lang.String)')
>>>>> Join point 'method-execution(void Code.moo(java.lang.String))' in Type
>>>>> 'Code' (Code.java:2) advised by before advice from '

Re: [aspectj-users] Why is my pointcut not advising methods declared in a another aspect?

[Eric B]

Hi Andy,

Have you had a chance to look at this at the sample application at all (
https://github.com/benze/AspectJUnitTestError)?  Is this an aspectJ bug or
a limitation?  Or am I doing something wrong?

Thanks,

Eric


On Thu, Apr 10, 2014 at 3:08 PM, Eric B  wrote:

> Hi Andy,
>
> I've created a sample application that demonstrates this problem.  I've
> uploaded it to GitHub.  I pulled this from a working project, but have
> tried to make it as simple & basic as possible to illustrated the problem.
>  You can find it here: https://github.com/benze/AspectJUnitTestError.git
>
> Basically, the pointcut is supposed to advise any methods in a class that
> is annotated with my custom annotation and the @Test annotation.  In the
> *Roo*.aj aspect, a @Test method is crosscut into the class and yet the
> advice is not called for that method.
>
> You can quickly see that the test for the crosscut method fails.
>
> Please let me know if you have any questions.
>
> Thanks,
>
> Eric
>
>
>
> On Fri, Apr 4, 2014 at 2:17 PM, Andy Clement wrote:
>
>> I presume all these aspects are being compiled together with the code.
>> You shouldn't have to worry about that order the aspects are applied in -
>> yes there are ITDs but the weaver considers the system as a whole and will
>> apply the aspects to ITD'd methods as well as existing methods:
>>
>> public class Code {
>>   public void moo(String s) {}
>> }
>>
>> aspect X {
>>   public void Code.boo(String s) {}
>> }
>>
>> aspect Y {
>>   before(): execution(* *(String)) {}
>> }
>>
>> > ajc -showWeaveInfo Code.java X.java Y.java
>>
>> Join point 'method-execution(void Code.boo(java.lang.String))' in Type
>> 'X' (X.java:2) advised by before advice from 'Y' (Y.java:2)
>> Type 'Code' (Code.java) has intertyped method from 'X' (X.java:'void
>> Code.boo(java.lang.String)')
>> Join point 'method-execution(void Code.moo(java.lang.String))' in Type
>> 'Code' (Code.java:2) advised by before advice from 'Y' (Y.java:2)
>>
>> Precedence only affects advice, not ITDs. The advice is being applied to
>> the ITDs, not to what you imagine is happening under the covers (the
>> methods being stuffed into the target, hence you think you need to get that
>> done first). All ITDs (and declares) are processed to ensure the type
>> system is coherent and then the advice is applied.
>>
>> I feel like we used to have problems in this area but I thought they were
>> all fixed up.  Worth raising an AspectJ issue. If you can provide a simple
>> test case that shows it failing (unlike mine which shows it working) that
>> would be really useful.  Maybe if any of the annotations you are triggering
>> on are being applied by declare, try putting them directly on the methods
>> of interest and temporarily removing the declare - does that make a
>> difference. It may be the interplay between declare/itd and advice.
>>
>> cheers,
>> Andy
>>
>>
>>
>> On 3 April 2014 18:37, Eric B  wrote:
>>
>>> I'm using Roo and Compile Time Weaving for my application.  One of the
>>> classes that Roo has generated is my `UserIntegrationTest`:
>>>
>>> @RooIntegrationTest(entity = User.class)
>>> @WebAppConfiguration
>>> @ActiveProfiles("test")
>>> @DirtiesContext
>>> @RequiredUserDetails(roles=Role.ROOT)
>>> public class UserIntegrationTest {
>>> @Test
>>> public void myTestMethod(){
>>>
>>> }
>>> }
>>>
>>>
>>> Most of the code is all in the Roo generated ITD:
>>>
>>> privileged aspect UserIntegrationTest_Roo_IntegrationTest {
>>>
>>> declare @type: UserIntegrationTest:
>>> @RunWith(SpringJUnit4ClassRunner.class);
>>>
>>> declare @type: UserIntegrationTest:
>>> @ContextConfiguration(locations =
>>> "classpath*:/META-INF/spring/applicationContext*.xml");
>>>
>>> declare @type: UserIntegrationTest: @Transactional;
>>>
>>> @Autowired
>>> UserDataOnDemand UserIntegrationTest.dod;
>>>
>>> @Autowired
>>> UserService UserIntegrationTest.userService;
>>>
>>> @Autowired
>>> UserRepository UserIntegrationTest.userRepository;
>>>
>>> @Test
>>>

Re: [aspectj-users] Why is my pointcut not advising methods declared in a another aspect?

[Eric B]

Hi Andy,

I've created a sample application that demonstrates this problem.  I've
uploaded it to GitHub.  I pulled this from a working project, but have
tried to make it as simple & basic as possible to illustrated the problem.
 You can find it here: https://github.com/benze/AspectJUnitTestError.git

Basically, the pointcut is supposed to advise any methods in a class that
is annotated with my custom annotation and the @Test annotation.  In the
*Roo*.aj aspect, a @Test method is crosscut into the class and yet the
advice is not called for that method.

You can quickly see that the test for the crosscut method fails.

Please let me know if you have any questions.

Thanks,

Eric



On Fri, Apr 4, 2014 at 2:17 PM, Andy Clement wrote:

> I presume all these aspects are being compiled together with the code. You
> shouldn't have to worry about that order the aspects are applied in - yes
> there are ITDs but the weaver considers the system as a whole and will
> apply the aspects to ITD'd methods as well as existing methods:
>
> public class Code {
>   public void moo(String s) {}
> }
>
> aspect X {
>   public void Code.boo(String s) {}
> }
>
> aspect Y {
>   before(): execution(* *(String)) {}
> }
>
> > ajc -showWeaveInfo Code.java X.java Y.java
>
> Join point 'method-execution(void Code.boo(java.lang.String))' in Type 'X'
> (X.java:2) advised by before advice from 'Y' (Y.java:2)
> Type 'Code' (Code.java) has intertyped method from 'X' (X.java:'void
> Code.boo(java.lang.String)')
> Join point 'method-execution(void Code.moo(java.lang.String))' in Type
> 'Code' (Code.java:2) advised by before advice from 'Y' (Y.java:2)
>
> Precedence only affects advice, not ITDs. The advice is being applied to
> the ITDs, not to what you imagine is happening under the covers (the
> methods being stuffed into the target, hence you think you need to get that
> done first). All ITDs (and declares) are processed to ensure the type
> system is coherent and then the advice is applied.
>
> I feel like we used to have problems in this area but I thought they were
> all fixed up.  Worth raising an AspectJ issue. If you can provide a simple
> test case that shows it failing (unlike mine which shows it working) that
> would be really useful.  Maybe if any of the annotations you are triggering
> on are being applied by declare, try putting them directly on the methods
> of interest and temporarily removing the declare - does that make a
> difference. It may be the interplay between declare/itd and advice.
>
> cheers,
> Andy
>
>
>
> On 3 April 2014 18:37, Eric B  wrote:
>
>> I'm using Roo and Compile Time Weaving for my application.  One of the
>> classes that Roo has generated is my `UserIntegrationTest`:
>>
>> @RooIntegrationTest(entity = User.class)
>> @WebAppConfiguration
>> @ActiveProfiles("test")
>> @DirtiesContext
>> @RequiredUserDetails(roles=Role.ROOT)
>> public class UserIntegrationTest {
>> @Test
>> public void myTestMethod(){
>>
>> }
>> }
>>
>>
>> Most of the code is all in the Roo generated ITD:
>>
>> privileged aspect UserIntegrationTest_Roo_IntegrationTest {
>>
>> declare @type: UserIntegrationTest:
>> @RunWith(SpringJUnit4ClassRunner.class);
>>
>> declare @type: UserIntegrationTest:
>> @ContextConfiguration(locations =
>> "classpath*:/META-INF/spring/applicationContext*.xml");
>>
>> declare @type: UserIntegrationTest: @Transactional;
>>
>> @Autowired
>> UserDataOnDemand UserIntegrationTest.dod;
>>
>> @Autowired
>> UserService UserIntegrationTest.userService;
>>
>> @Autowired
>> UserRepository UserIntegrationTest.userRepository;
>>
>> @Test
>> public void UserIntegrationTest.testCountAllUsers() {
>> Assert.assertNotNull("Data on demand for 'User' failed to
>> initialize correctly", dod.getRandomUser());
>> long count = userService.countAllUsers();
>> Assert.assertTrue("Counter for 'User' incorrectly reported
>> there were no entries", count > 0);
>> }
>>
>> ...
>> ...
>> ...
>>
>> }
>>
>>
>> I've written my own aspect to handle my `@RequiredUserDetails`
>> annotation.  My pointcut specifies any `@Test` method in a class that is
>> annotated with `@

Re: [aspectj-users] Configuring AspectJ aspects using Spring IoC with JavaConfig?

[Eric B]

Perfect!  Works as described.

Thanks,

Eric



On Fri, Apr 4, 2014 at 2:21 PM, Andy Clement wrote:

> Try the "Aspects" class, I can't find the javadoc for it right now online
> but see this for Aspects14 (
> http://eclipse.org/aspectj/doc/released/runtime-api/index.html) that was
> the pre java5 form of the class. Those helper methods just call the real
> aspectOf() under the covers which should have been added via LTW by the
> time you make the invocation.
>
> cheers,
> Andy
>
>
> On 3 April 2014 21:16, Eric B  wrote:
>
>> This is both a Spring and AspectJ question.  I'm having trouble
>> configuring AspectJ aspects with Spring and JavaConfig.  According to
>> Spring's Documentation (
>> http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/aop.html#aop-aj-configure)
>> in order to configure an aspect for Spring IOC, the following has to be
>> added to the xml configuration:
>>
>> >   factory-method="aspectOf">
>>   
>> 
>>
>>
>> An equivalent in JavaConfig would be:
>>
>> @Bean
>> public com.xyz.profiler.Profiler profiler() {
>> com.xyz.profiler.Profiler profiler =
>> com.xyz.profiler.Profiler.aspectOf();
>> profiler.setProfilingStrategy(jamonProfilingStrategy());
>> return profiler;
>> }
>>
>>
>> However, this only seems to work if the `Profiler` aspect is written in
>> native aspectj `.aj` syntax.  If it is written in Java and annotated with
>> `@Aspect`, I get the following error message:
>>
>> The method aspectOf() is undefined for the type Profiler
>>
>>
>> Is there an equivalent way of writing this using JavaConfig for aspects
>> written with @AspectJ syntax?
>>
>> I suspect that there is some conflict between the java compiler and ajc
>> where it is not seeing the properly compiled version of the aspect.  But I
>> have checked the .class file for the aspect and see that the `aspectOf`
>> method is indeed present.
>>
>> Any ideas what this is happening with the @AspectJ coding style?
>>
>> Thanks,
>>
>> Eric
>>
>>
>> ___
>> 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] Configuring AspectJ aspects using Spring IoC with JavaConfig?

[Eric B]

This is both a Spring and AspectJ question.  I'm having trouble configuring
AspectJ aspects with Spring and JavaConfig.  According to Spring's
Documentation (
http://docs.spring.io/spring/docs/3.2.x/spring-framework-reference/html/aop.html#aop-aj-configure)
in order to configure an aspect for Spring IOC, the following has to be
added to the xml configuration:


  



An equivalent in JavaConfig would be:

@Bean
public com.xyz.profiler.Profiler profiler() {
com.xyz.profiler.Profiler profiler =
com.xyz.profiler.Profiler.aspectOf();
profiler.setProfilingStrategy(jamonProfilingStrategy());
return profiler;
}


However, this only seems to work if the `Profiler` aspect is written in
native aspectj `.aj` syntax.  If it is written in Java and annotated with
`@Aspect`, I get the following error message:

The method aspectOf() is undefined for the type Profiler


Is there an equivalent way of writing this using JavaConfig for aspects
written with @AspectJ syntax?

I suspect that there is some conflict between the java compiler and ajc
where it is not seeing the properly compiled version of the aspect.  But I
have checked the .class file for the aspect and see that the `aspectOf`
method is indeed present.

Any ideas what this is happening with the @AspectJ coding style?

Thanks,

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] Why is my pointcut not advising methods declared in a another aspect?

[Eric B]

I'm using Roo and Compile Time Weaving for my application.  One of the
classes that Roo has generated is my `UserIntegrationTest`:

@RooIntegrationTest(entity = User.class)
@WebAppConfiguration
@ActiveProfiles("test")
@DirtiesContext
@RequiredUserDetails(roles=Role.ROOT)
public class UserIntegrationTest {
@Test
public void myTestMethod(){

}
}


Most of the code is all in the Roo generated ITD:

privileged aspect UserIntegrationTest_Roo_IntegrationTest {

declare @type: UserIntegrationTest:
@RunWith(SpringJUnit4ClassRunner.class);

declare @type: UserIntegrationTest: @ContextConfiguration(locations
= "classpath*:/META-INF/spring/applicationContext*.xml");

declare @type: UserIntegrationTest: @Transactional;

@Autowired
UserDataOnDemand UserIntegrationTest.dod;

@Autowired
UserService UserIntegrationTest.userService;

@Autowired
UserRepository UserIntegrationTest.userRepository;

@Test
public void UserIntegrationTest.testCountAllUsers() {
Assert.assertNotNull("Data on demand for 'User' failed to
initialize correctly", dod.getRandomUser());
long count = userService.countAllUsers();
Assert.assertTrue("Counter for 'User' incorrectly reported
there were no entries", count > 0);
}

...
...
...

}


I've written my own aspect to handle my `@RequiredUserDetails` annotation.
 My pointcut specifies any `@Test` method in a class that is annotated with
`@RequiredUserDetails`.  Although the pointcut works fine for any methods
declared in the main class (ie: `MyTestMethod()`), it does not pick up any
of the methods in the ITD.

@Aspect
public class RequiredUserDetailsAspect {
/**
 * Defines any public @Test method
 */
@Pointcut("execution(public * *(..)) && @annotation(org.junit.Test)")
public void testMethod() {};

/**
 * Anything with the {@link RequiredUserDetails} annotation on the
method
 */
@Pointcut("@annotation(RequiredUserDetails)")
public void annotatedMethod(){};

/**
 * Anything with the {@link RequiredUserDetails} annotation on the class
 */
@Pointcut("@within(RequiredUserDetails)")
public void annotatedClass(){};


@Before("testMethod() && (annotatedClass() || annotatedMethod())")
public void authenticateUser(JoinPoint jp){
// check for any class annotations
}
}


I would have expected that given Roo ITDs are being CTW, my aspect would
apply to those methods as well.  I am presuming that my aspect is woven
before the Roo aspect and consequently doesn't see Roo's ITDs as part of my
class.

Is there a way to either ensure that Roo's ITDs are woven before my own
aspects or to ensure that my pointcut applies to the Roo ITDs as well?

I've tried adding `@DeclarePrecedence` to the top of the aspect, but either
it is not working as I hoped, or I have it defined incorrectly as it has
made no difference.

@Aspect
@DeclarePrecedence("**.*Roo*, RequiredUserDetailsAspect")
public class RequiredUserDetailsAspect {
  ...
  ...
}


Thanks!

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Can I use an annotation as a type-pattern when introducing annotations to the class type?

[Eric B]

On Tue, Mar 11, 2014 at 3:41 PM, Matthew Adams wrote:

> I think what you mean on the declare @type is the following.  I don't have
> an IDE in front of me right now, but I think you're missing the rest of the
> type pattern.  Notice the missing * (highlighted).
>
>  declare @type : @Auditable *: 
> @EntityListeners(com.ia.persistence.AuditEventListener.class);
>
> Yup - that's exactly what it is/was.  I figured it was something fairly
silly, but just couldn't see it.

Thanks!

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] Can I use an annotation as a type-pattern when introducing annotations to the class type?

[Eric B]

I'm trying to add JPA EntityListeners to my Entities via AspectJ.  However,
I am either doing something wrong, or I am potentially running into an AJ
bug.

I have the following aspect declaration:

public aspect AutoAuditEventAspect {

 declare parents : @Auditable * implements com.ia.persistence.AutoAuditable;

 declare @type : @Auditable : @EntityListeners
(com.ia.persistence.AuditEventListener.class);

}


Where @Auditable is my own annotation

and AutoAuditable is an interface with a static Aspect Implementation.


However, when I try to compile my project I get the following error:

[ERROR] error at declare @type : @Auditable :
@EntityListeners(com.ia.persistence.AuditEventListener.class);

[ERROR] ^^

[ERROR]
webapp/src/main/java/com/ia/persistence/AutoAuditEventAspect.aj:9:0::0 The
annotation @EntityListeners is disallowed for this location

[ERROR] error at declare @type : @Auditable :
@EntityListeners(com.ia.persistence.AuditEventListener.class);

[ERROR]

[ERROR]
webapp/src/main/java/com/ia/persistence/AutoAuditEventAspect.aj:9:0::0
Syntax error on token ";", "name pattern" expected


If I try to remove the @Auditable as the  and replace with
"com.ia.domain.*", then it compiles fine.

Am I not allowed to use an annotation as a type specifier when trying to
introduce an annotation to the class type?

Thanks,

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Unit tests not "seeing" aspects in Eclipse

[Eric B]

Hi Andy,

I do not think that it is anything particularly special.  I did catch onto
one thing, although I do not know if this is intentional design, or
problematic, but when my Java code is opened in a Java editor, I get
everything redlined (ie: flagged as error, but no Problem generated).
 However, if I open the same file in a AspectJ/Java editor, the redlines
disappear, however code completion still completely fails.

I have tried the same project in IntelliJ (v13) to see if their editor
functions differently, and again the intertype declarations are not being
shown in the code completion, but at least the non-intertype generated
aspect injections (ie: methods from Roo) are still appearing.

I will try the dev version of 2.2.4, but I suspect the same thing.  It
appears that as soon as AJDT sees intertype declarations on a file, that it
drops code completion for anything defined in any aspects.

Would providing a sample project help, or is this something easily enough
reproducible?  Who/where/how would I report this issue to AJDT?  I looked
at the AJDT mailing list, but it looks fairly dead.

Thanks,

Eric



On Fri, Dec 6, 2013 at 2:30 PM, Andy Clement wrote:

> Sorry I didn't reply sooner Eric. You could try a dev build of AJDT (a
> release is only a blessed dev build, nothing more than that, so it
> shouldn't introduce instabilities). However, I'm not sure any changes have
> gone in that will adjust what you are seeing.
>
> Is there anything unusual about the extra thing you are introducing that
> appears to be breaking things? I presume all the code is compiling clean
> (i.e. no errors in the problems view).  Certainly what you are describing
> is an AJDT issue - if there were inexplicable things in the problems view
> it is AspectJ that would be at fault but nothing in the problems view and
> errors in the editor indicate it is AJDT.
>
> Andy
>
>
> On 4 December 2013 08:51, Eric B  wrote:
>
>> On 13-12-04 11:24 AM, Eric B wrote:
>>
>>> I'm trying to attach a screenshot of my eclipse window to illustrate
>>>> what I mean.  I don't know if the mailing list accepts attachments, 
>>>> however.
>>>>
>>>> As you can see in the screenshot, methods added in via aspects
>>>> (setLastModified, setAutoUpdateLastModified, setAddress, getId, etc) are
>>>> all flagged as
>>>> being errors.  However, the Problem view shows no errors.  The most
>>>> frustrating part of this, of course, is that there is no auto-complete in
>>>> the
>>>> editor when coding.
>>>>
>>>
>>> Sorry - my mistake actually.  The editor is not even proposing my
>>> autocomplete in regular classes either.  I mistakenly thought it was.  Is
>>> this a
>>> problem with AJDT in eclipse?  Are there any newer builds that resolve
>>> these issues?
>>>
>>
>>
>> Apologies for the multiple postings; I'm slowly starting to understand
>> what has happened.  I have recently added an default Interface
>> implementation via an aspect which seems to be causing the issues in these
>> classes.  By adding these intertype declarations, it appears that all the
>> code completion for the classes in question is aborted, such that even the
>> Roo generated aspects (non-intertype declarations) no longer work.
>>
>> This is somewhat difficult to deal with; are there any updates to AJDT
>> that will allow for the auto-complete to work?  I'm running AJDT 2.2.3.
>>
>>
>> Thanks,
>>
>> Eric
>>
>>
>> ___
>> 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

Re: [aspectj-users] Unit tests not "seeing" aspects in Eclipse

[Eric B]

On 13-12-04 11:24 AM, Eric B wrote:

I'm trying to attach a screenshot of my eclipse window to illustrate what I 
mean.  I don't know if the mailing list accepts attachments, however.

As you can see in the screenshot, methods added in via aspects 
(setLastModified, setAutoUpdateLastModified, setAddress, getId, etc) are all 
flagged as
being errors.  However, the Problem view shows no errors.  The most frustrating 
part of this, of course, is that there is no auto-complete in the
editor when coding.


Sorry - my mistake actually.  The editor is not even proposing my autocomplete 
in regular classes either.  I mistakenly thought it was.  Is this a
problem with AJDT in eclipse?  Are there any newer builds that resolve these 
issues?



Apologies for the multiple postings; I'm slowly starting to understand what has happened.  I have recently added an default Interface implementation 
via an aspect which seems to be causing the issues in these classes.  By adding these intertype declarations, it appears that all the code completion 
for the classes in question is aborted, such that even the Roo generated aspects (non-intertype declarations) no longer work.


This is somewhat difficult to deal with; are there any updates to AJDT that 
will allow for the auto-complete to work?  I'm running AJDT 2.2.3.

Thanks,

Eric


___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] Unit tests not "seeing" aspects in Eclipse

[Eric B]

On 13-12-04 11:06 AM, Eric B wrote:

On 13-12-03 11:03 PM, Eric B wrote:

I'm using Roo 1.2.4 which has generated a bunch of aspects for my entities.  
Everything compiles properly and works as expected.  Code completion
while editing my main classes works properly.

However, whenever I try to work in my unit tests, Eclipse does not seem to pick 
up any of the aspects.  None of the setters or getters (as defined in
an aspect) are recognized, and consequently code completion fails.  If I 
manually type in a getter or setter, Eclipse highlights it as an error,
although the "Problems" view remains blank.  However, if I launch the unit 
test, it works as expected.

I've tried this with both Eclipse Juno and Spring STS 3.4.0 (which is based on 
Eclipse 4.3.1).

Is this a configuration issue, or a problem with the Eclipse plugin(s)?  Is 
there anything I need to do to have Eclipse recognize the aspects in my
unit tests?


I'm trying to attach a screenshot of my eclipse window to illustrate what I 
mean.  I don't know if the mailing list accepts attachments, however.

As you can see in the screenshot, methods added in via aspects 
(setLastModified, setAutoUpdateLastModified, setAddress, getId, etc) are all 
flagged as
being errors.  However, the Problem view shows no errors.  The most frustrating 
part of this, of course, is that there is no auto-complete in the
editor when coding.


Sorry - my mistake actually.  The editor is not even proposing my autocomplete in regular classes either.  I mistakenly thought it was.  Is this a 
problem with AJDT in eclipse?  Are there any newer builds that resolve these issues?


Thanks,

Eric




___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] Unit tests not "seeing" aspects in Eclipse

[Eric B]

I'm using Roo 1.2.4 which has generated a bunch of aspects for my entities.
 Everything compiles properly and works as expected.  Code completion while
editing my main classes works properly.

However, whenever I try to work in my unit tests, Eclipse does not seem to
pick up any of the aspects.  None of the setters or getters (as defined in
an aspect) are recognized, and consequently code completion fails.  If I
manually type in a getter or setter, Eclipse highlights it as an error,
although the "Problems" view remains blank.  However, if I launch the unit
test, it works as expected.

I've tried this with both Eclipse Juno and Spring STS 3.4.0 (which is based
on Eclipse 4.3.1).

Is this a configuration issue, or a problem with the Eclipse plugin(s)?  Is
there anything I need to do to have Eclipse recognize the aspects in my
unit tests?

Thanks,

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

Re: [aspectj-users] AspectJ CTW failing when weaving Spring-MVC library

[Eric B]

I am weaving the spring-mvc jar, as the code I am trying to wrap is from
the Spring-MVC jar.  I believe the equivalent of the maven configuration
parameters



 org.springframework
spring-webmvc
 


is: ajc -inpath .

So, I am expecting it to be weaving the Spring libraries.  I just do not
understand why it is failing on those classes which do not call
*.getResources().


I do not seem to be able to properly figure out how to code the within()
clause appropriately.  Can you please advise?  I am trying to create a
pointcut
around 
org.springframework..SpringWildcardServletTilesApplicationContext.getResources(..)
when called from within org.apache.tiles.extras.renderer.OptionsRenderer
class.

At the moment, my ugly if() condition checks the stacktrace to validate
that OptionsRenderer is the calling method, as I was unable to figure out
the correct syntax for getting the within() clause to work appropriately.

I thought it would be:
@Pointcut("within(org.apache.tiles.extras.renderer.OptionsRenderer)
&& call( *
org.springframework..SpringWildcardServletTilesApplicationContext.getResources(..))")
but that does not seem to be accurate.

Any advice would be appreciated.

Thanks,

Eric


On Tue, Nov 19, 2013 at 8:40 PM, Andy Clement wrote:

> Seems a little odd it is saying it is weaving into Spring classes:
>
> "   when weaving type org.springframework.web.servlet.view.document.
> AbstractPdfView"
>
> Are you somehow passing in more than the application? I don't speak maven
> so can't comment directly on the pom contents.  You could include a
> within() clause in your pointcut to limit it to the packages you really
> know contain the calls then it won't be looking at all the calls made
> everywhere.
>
> cheers,
> Andy
>
>
>
> On 14 November 2013 19:58, Eric B  wrote:
>
>> I've got a Spring-MVC 3.2.4 mavenized project, where I've run into the
>> need to weave an Aspect into a Spring-MVC class.  I'm able to run the
>> aspect and the webapp through Eclipse without any problems (Tomcat), but
>> when I try to package the war from the command line, AspectJ throws a whole
>> bunch of weaving errors:
>>
>> mvn compile
>> ...
>> ...
>> [ERROR] can't determine superclass of missing type
>> com.lowagie.text.Document
>> when weaving type
>> org.springframework.web.servlet.view.document.AbstractPdfView
>> when weaving classes
>> when weaving
>> when batch building BuildConfig[null] #Files=75 AopXmls=#0
>>  [Xlint:cantFindType]
>> [ERROR] can't determine superclass of missing type
>> com.lowagie.text.Document
>> when weaving type
>> org.springframework.web.servlet.view.document.AbstractPdfView
>> when weaving classes
>> when weaving
>> when batch building BuildConfig[null] #Files=75 AopXmls=#0
>>  [Xlint:cantFindType]
>> ...
>> ...
>> ...
>>
>> I have no com.lowagie.text.* dependencies listed in my pom, as I am not
>> using and PDF stuff.  What I don't understand is why AspectJ can properly
>> weave the class when running through Eclipse, but not when I try to compile
>> it from the command line.
>>
>>
>> pom.xml (relevant snippets - using aspectJ 1.7.3):
>>
>> 
>> org.aspectj
>>  aspectjrt
>> ${aspectj.version}
>>  
>>  
>> org.aspectj
>> aspectjweaver
>>  ${aspectj.version}
>> 
>>
>> 
>> 
>>
>> 
>> org.codehaus.mojo
>>  aspectj-maven-plugin
>> 1.2
>> 
>> 
>> 
>> 
>> org.aspectj
>>  aspectjrt
>> ${aspectj.version}
>>  
>> 
>> org.aspectj
>>  aspectjtools
>> ${aspectj.version}
>>  
>> 
>> 
>>  
>> 
>> compile
>>  test-compile
>> 
>> 
>>  
>> 
>> true
>>  
>> 
>> org.springframework
>>  spring-aspects
>> 
>> 
>>  
>> 
>> org.springframework
>>  spring-webmvc
>> 
>> 
>>  ${java.version}
>> ${java.version}
>> 
>>  
>>
>>
>>
>> The Aspect declaraion:
>>
>> @Aspect
>> public class OptionsPatch {
>> @Pointcut("call( *
>> org.springframework..SpringWildcardServletTilesApplicationContext.getResources(..))
>> && if()")
>> public static boolean getResources(JoinPoint.EnclosingStaticPart
>> esp) {
>> if( /* some condition here */ )
>> return true;
>> else
>> return false;
>> }
>

[aspectj-users] AspectJ CTW failing when weaving Spring-MVC library

[Eric B]

I've got a Spring-MVC 3.2.4 mavenized project, where I've run into the need
to weave an Aspect into a Spring-MVC class.  I'm able to run the aspect and
the webapp through Eclipse without any problems (Tomcat), but when I try to
package the war from the command line, AspectJ throws a whole bunch of
weaving errors:

mvn compile
...
...
[ERROR] can't determine superclass of missing type
com.lowagie.text.Document
when weaving type
org.springframework.web.servlet.view.document.AbstractPdfView
when weaving classes
when weaving
when batch building BuildConfig[null] #Files=75 AopXmls=#0
 [Xlint:cantFindType]
[ERROR] can't determine superclass of missing type
com.lowagie.text.Document
when weaving type
org.springframework.web.servlet.view.document.AbstractPdfView
when weaving classes
when weaving
when batch building BuildConfig[null] #Files=75 AopXmls=#0
 [Xlint:cantFindType]
...
...
...

I have no com.lowagie.text.* dependencies listed in my pom, as I am not
using and PDF stuff.  What I don't understand is why AspectJ can properly
weave the class when running through Eclipse, but not when I try to compile
it from the command line.


pom.xml (relevant snippets - using aspectJ 1.7.3):


org.aspectj
 aspectjrt
${aspectj.version}

 
org.aspectj
aspectjweaver
 ${aspectj.version}






org.codehaus.mojo
 aspectj-maven-plugin
1.2




org.aspectj
 aspectjrt
${aspectj.version}
 

org.aspectj
 aspectjtools
${aspectj.version}
 


 

compile
 test-compile


 

true
 

org.springframework
 spring-aspects


 

org.springframework
 spring-webmvc


 ${java.version}
${java.version}

 



The Aspect declaraion:

@Aspect
public class OptionsPatch {
@Pointcut("call( *
org.springframework..SpringWildcardServletTilesApplicationContext.getResources(..))
&& if()")
public static boolean getResources(JoinPoint.EnclosingStaticPart esp) {
if( /* some condition here */ )
return true;
else
return false;
}


@Around("getResources(enc)")
public Object unboxIOException(ProceedingJoinPoint pjp,
JoinPoint.EnclosingStaticPart enc) throws Throwable {
try {
return pjp.proceed();
} catch (IllegalArgumentException e) {
throw e;
}
}
}



Do I have to write the pointcut in a more precise manner to avoid this
problem?  Why does it work within the editor but not from the cmd line?


Thanks,

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[aspectj-users] LTW probem with Tomcat / Felix classloader

[Eric B]

Hi,

I'm trying to wrap a LTW aspect around a third-party webapp to do some
debugging/profiling.  I have no access to change/modify the code, but at
least I was hoping to see where/why some things were happening.   The
webapp is running under a Tomcat 6.0.35 server.

I tried to write up a small, very innocuous aspect (ie: just prints the
name of the method that is being executed) and tested it out with a
HelloWorld servlet/webapp .  Everything worked as expected.

When I tried to use it with the third-party app, things seem to be working
properly at first:

WebappClassLoader@1c23f1bb] info AspectJ Weaver Version 1.7.3 built on
Thursday Jun 13, 2013 at 19:41:31 GMT
[WebappClassLoader@1c23f1bb] info register classloader
org.apache.catalina.loader.WebappClassLoader@1c23f1bb
[WebappClassLoader@1c23f1bb] info using configuration
file:/Library/Tomcat/apache-tomcat-6.0.35-jira/webapps/jira/WEB-INF/lib/ia-aspects-0.0.1-SNAPSHOT.jar!/META-INF/aop.xml
[WebappClassLoader@1c23f1bb] info register aspect com.ia.UseProfiler

[WebappClassLoader@1c23f1bb] weaveinfo Join point 'method-execution(int
com.credo.linker.user.util.DefaultUserManager.getTotalUserCount())' in Type
'com.credo.linker.user.util.DefaultUserManager'
(DefaultUserManager.java:81) advised by after advice from
'com.ia.UseProfiler' (UseProfiler.aj:20)
[WebappClassLoader@1c23f1bb] weaveinfo Join point
'method-execution(java.util.Collection
com.credo.linker.user.util.DefaultUserManager.getUsers())' in Type
'com.credo.linker.user.util.DefaultUserManager'
(DefaultUserManager.java:88) advised by after advice from
'com.ia.UseProfiler' (UseProfiler.aj:20)



However, shortly after, I see the following show up in catalina.out:
[ModuleClassLoader@4e730222] info AspectJ Weaver Version 1.7.3 built on
Thursday Jun 13, 2013 at 19:41:31 GMT
[ModuleClassLoader@4e730222] info register classloader
org.apache.felix.framework.ModuleImpl$ModuleClassLoader@4e730222
[ModuleClassLoader@4e730222] info using configuration
file:/Library/Tomcat/apache-tomcat-6.0.35-jira/webapps/jira/WEB-INF/lib/ia-aspects-0.0.1-SNAPSHOT.jar!/META-INF/aop.xml
[ModuleClassLoader@4e730222] info register aspect com.ia.UseProfiler
Jul 29, 2013 1:48:25 PM org.aspectj.weaver.tools.Jdk14Trace error
SEVERE: register definition failed
java.lang.RuntimeException: Cannot register non aspect: com$ia$UseProfiler
, com.ia.UseProfiler
 at org.aspectj.weaver.bcel.BcelWeaver.addLibraryAspect(BcelWeaver.java:221)
at
org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerAspects(ClassLoaderWeavingAdaptor.java:478)
 at
org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.registerDefinitions(ClassLoaderWeavingAdaptor.java:303)
at
org.aspectj.weaver.loadtime.ClassLoaderWeavingAdaptor.initialize(ClassLoaderWeavingAdaptor.java:170)
 at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.initialize(Aj.java:313)
at
org.aspectj.weaver.loadtime.Aj$ExplicitlyInitializedClassLoaderWeavingAdaptor.getWeavingAdaptor(Aj.java:318)
 at org.aspectj.weaver.loadtime.Aj$WeaverContainer.getWeaver(Aj.java:292)
at org.aspectj.weaver.loadtime.Aj.preProcess(Aj.java:103)
 at
org.aspectj.weaver.loadtime.ClassPreProcessorAgentAdapter.transform(ClassPreProcessorAgentAdapter.java:54)
at sun.instrument.TransformerManager.transform(TransformerManager.java:169)
 at
sun.instrument.InstrumentationImpl.transform(InstrumentationImpl.java:365)
at java.lang.ClassLoader.defineClass1(Native Method)
 at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
 at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.findClass(ModuleImpl.java:1829)
at
org.apache.felix.framework.ModuleImpl.findClassOrResourceByDelegation(ModuleImpl.java:716)
 at org.apache.felix.framework.ModuleImpl.access$200(ModuleImpl.java:73)
at
org.apache.felix.framework.ModuleImpl$ModuleClassLoader.loadClass(ModuleImpl.java:1690)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.apache.felix.framework.ModuleImpl.getClassByDelegation(ModuleImpl.java:634)
 at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:3653)
at org.apache.felix.framework.Felix.activateBundle(Felix.java:1812)
 at org.apache.felix.framework.Felix.startBundle(Felix.java:1734)
at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1143)
 at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264)
at java.lang.Thread.run(Thread.java:680)


I'm not entirely sure what is happening, but it appears that the webapp is
loading its own classloader (Felix) for use in the application, and that
the Felix classloader does not know how to register the aspects.

I am starting tomcat with -javaagent:/path/to/aspectjweaver-1.7.3.jar

Is this a class loader issue in which the Felix classloader does not have
access to the aspectjweaver classes?
How do I get around the problem?

My aop.xml is pretty mundane as well:

  

  

  

  



Thanks!

Eric

[aspectj-users] AJDT and m2e?

[Eric B]

Hi,

I'm running into an odd problem with m2e and AJDT.  With Andy's help on the
SpringSource STS forum, I think I have managed to isolate the problem a
little better, but not sure if I am encountering a bug, or if there is
something I am missing in my Eclipse configuration.

My original thread can be found at:
http://forum.springsource.org/showthread.php?125470-How-to-enable-AspectJ-nature-in-a-Spring-project-with-annotated-and-aj-aspects

In a nutshell, I have a Maven based Spring project.  I'm using Eclispe 3.7
with the following m2e plugins
m2e: 1.0.100.20110804-1717
maven for AJDT: 0.13.0.2011.07281640
maven for WTP: 0.14.0.20110928-2045

I have some Spring aspects defined with AspectJ annotations.  By
themselves, they work fine.  I then added some .aj aspects and enabled
AspectJ Capabilities on the project.  Suddenly my Spring aspects are
instantiated twice in my junit tests - once by Spring, and once (I believe)
by some CTW of the AJ compiler.  (Note that these are junits run within
Eclipse).

If I use the -xmlConfigured flag on AJ project properties and specify my
own aop.xml file with only my .aj aspect listed there the junits work fine.

I have tried added an  tag in my aspectj-maven-plugin, excluding
the Spring aspects, but they are still run twice.

Is this a bug in m2e?  Or is there a problem with AJDT?  Or am I doing
something wrong, or missing some configuration somewhere?

My pom has the following aj-related things


org.springframework
spring-aop
${org.springframework.version}




org.aspectj
aspectjweaver
${org.aspectj}




org.aspectj
aspectjrt
${org.aspectj}

 
org.aspectj
aspectjtools
${org.aspectj}


...
...
 
org.codehaus.mojo
aspectj-maven-plugin
1.4

true
1.6
1.6


commons-pool
commons-pool


 

**/*Interceptor.java





compile
test-compile






Thanks,

Eric
___
aspectj-users mailing list
aspectj-users@eclipse.org
https://dev.eclipse.org/mailman/listinfo/aspectj-users