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 >> >> >> >> >> >
