Hey Cristiano, The quick summary of my old blog post is that you can run aspectj weaver under OSGi, however it required extra steps to prepare container. This was necessary v4.2 of OSGi container. Starting from 4.3 there is possibility to use hooks in OSGi framework. WeavingHook allows you to modify class contents (load time weaving). However the AspectJ at the time the old article was written did not provide any integration with new specification and it still might be absent. Please try to find something about AspectJ Weaving Hook. I’ve tried to implement it but I’ve failed since I don’t know aspectj weaver internals.
Cheers, Lukasz Wiadomość napisana przez Cristiano Costantini <[email protected]> w dniu 8 sty 2014, o godz. 08:44: > Hi Krzysztof, hi all, > > I was using the same approach as you with dynamic imports but it gave a me > totally different import footprint, so started investigating a little more. > I tried to compare the imports added after turning on dev:dynamic-imports > on the same bundle, once using a pointcut expression like "execution(* > net.cristcost.study.TestServiceImpl.*(..))" and the second time using > "bean(testService)". > > Using "bean(...)" expression it is sufficient to add the following > additional imports: > org.springframework.security.access.expression.method, > org.springframework.aop, > org.springframework.aop.framework, > org.aopalliance.aop, > > But using "execution(...)" you see that the bundle searches for a lot more > packages (see https://gist.github.com/cristcost/8312917) like AOP is > scanning half of my classpath! > > Unfortunately, <security:protect-pointcut> tags does not support the > "bean(...)" expression and I cannot use it. > But my expected result is exactly to extend the behavior of a specific bean > without having an aspect oriented framework being so invasive on my > classpath... > It seems that when using pointcuts, the required imports change depending > on how you write the expression, I don't like this behavior and I need to > understand more what is happening under the hood of AOP in Servicemix if I > want to find an alternative approach (it is the first time I use it and I'm > coming from the need to use AOP for Spring Security). > > So at first, I need to understand exactly what am I using: am I using > Spring AOP or AspectJ? > > For sure, I need the bundle > "mvn:org.apache.servicemix.bundles/org.apache.servicemix.bundles.aspectj/1.7.4_1" > or my application would fail to find org.aspectj.lang.JoinPoint class, but > in my bundle I do not add specifically any import on org.aspectj.* (like > you Krzysztof did in your code snippet). > Instead I see AspectJ is used by the bundle "org.springframework.aop" (here > it's OSGi headers: https://gist.github.com/cristcost/8313004). > I guess now that I am in fact using Spring AOP but it requires AspectJ for > pointcuts. Could someone tell me if my guess is wrong? > > > In the end, I'm anyway happy of the level of control you get on > dependencies when using OSGi: so I can fight to reduce them. > > But for the moment I don't have any other idea on how restricting classpath > needed for AOP... so any suggestion from you is really welcome! > I'll continue researching a solution and I'll update on my progresses or > ask for new question here in this thread, I hope to get more feedback from > all of you. > > Regards, > Cristiano > > > > 2014/1/7 Krzysztof Sobkowiak <[email protected]> > >> Hi Cristiano >> >> I have implemented once a small application using Spring AOP running on >> Karaf 2.3.x. I used the dynamic imports for the bundle using Spring AOP and >> after starting the bundle checked with imports command which packages were >> really imported. Next I have disabled dynamic imports and used the packages >> from the imports commands. My configuration for the bundle imports looks >> like this >> >> <!-- necessary for @Transactional --> >> org.aopalliance.aop, >> org.springframework.transaction, >> org.springframework.aop, >> org.springframework.aop.framework, >> >> >> <!-- necessary for Spring AOP --> >> org.springframework.core, >> org.springframework.aop.config, >> org.springframework.aop.aspectj, >> org.springframework.aop.aspectj.annotation, >> org.springframework.context.config, >> org.springframework.transaction.interceptor, >> org.springframework.beans.factory, >> org.springframework.beans.factory.xml, >> org.springframework.osgi.context, >> org.springframework.osgi.service.exporter.support, >> org.springframework.osgi.service.importer, >> >> <!-- import all packages from aspectjweaver instead of using >> Require-Bundle --> >> aj.org.objectweb.asm, >> aj.org.objectweb.asm.signature, >> org.aspectj.apache.bcel, >> org.aspectj.apache.bcel.classfile, >> org.aspectj.apache.bcel.classfile.annotation, >> org.aspectj.apache.bcel.generic, >> org.aspectj.apache.bcel.util, >> org.aspectj.asm, >> org.aspectj.asm.internal, >> org.aspectj.bridge, >> org.aspectj.bridge.context, >> org.aspectj.internal.lang.annotation, >> org.aspectj.internal.lang.reflect, >> org.aspectj.lang, >> org.aspectj.lang.annotation, >> org.aspectj.lang.internal.lang, >> org.aspectj.lang.reflect, >> org.aspectj.runtime, >> org.aspectj.runtime.internal, >> org.aspectj.runtime.internal.cflowstack, >> org.aspectj.runtime.reflect, >> org.aspectj.util, >> org.aspectj.weaver, >> org.aspectj.weaver.ast, >> org.aspectj.weaver.bcel, >> org.aspectj.weaver.bcel.asm, >> org.aspectj.weaver.internal.tools, >> org.aspectj.weaver.loadtime, >> org.aspectj.weaver.loadtime.definition, >> org.aspectj.weaver.ltw, >> org.aspectj.weaver.model, >> org.aspectj.weaver.patterns, >> org.aspectj.weaver.reflect, >> org.aspectj.weaver.tools, >> >> >> <!-- necessary when using proxy-target-class="true" --> >> <!-- net.sf.cglib.proxy, >> net.sf.cglib.core, >> net.sf.cglib.reflect, --> >> >> <!-- Necessary for schema based AOP --> >> org.springframework.aop.aspectj.autoproxy, >> >> I think, you don't need the imports for aspectj, because you will use only >> Spring AOP (but I am not quite sure). My demo uses also the compile time >> weaving with AspectJ. For this purpose I had to include the AspectJ >> packages. >> >> I can't publish the whole code because this is my company code. I'll try >> to prepare a simple sample in the near future. >> I hope it helps you. >> >> Best regards >> Krzysztof >> >> >> >> >> >> >> On 07.01.2014 11:46, Cristiano Costantini wrote: >> >>> Thank you very much Filippo! >>> it is an interesting use case and I will check it out, >>> >>> however I search for experience of using it with Felix and using in Spring >>> XML bean definition files, if someone else has more direct suggestions for >>> my use case I would be glad to know how you did used it. >>> >>> Cristiano >>> >>> >>> >>> >>> >>
