You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by Cristiano Costantini <cr...@gmail.com> on 2014/01/06 23:39:23 UTC

AspectJ in Servicemix and OSGi Imports

Hi All,
I'm testing using AspectJ in ServiceMix (I need it in a Spring Security's
"protect-pointcut" expression that put security rules on method of a bean).

It works, but when I add a pointcut expression, I need to add to my bundle
a lot more package imports to make it work...

To understand what I mean, take a look at the following commit:
https://github.com/cristcost/springsec/commit/073887d2487ba11f0eebaa011f79d3a9f2c95edd
(the commit add an aspectj pointcut expression and add the Import-Package
instructions required to make it work).

I don't like the final result: managing the Import-Package is too much
complex with aspectj enabled...

Anyone have experience on using it in ServiceMix and can give any
suggestion on how it is best to handle OSGi's import-pacakge when using
AspectJ?
Can you point me to good examples of ServiceMix or Karaf + AspectJ where I
can get some inspiration?

Thank you very much,
(and happy new year to all of you!)

Cristiano

Re: AspectJ in Servicemix and OSGi Imports

Posted by Cristiano Costantini <cr...@gmail.com>.
Hi Lukasz,
that's a road that may attract me if the it "bypass" the OSGi class loading
(of course in an elegant way that not compromise security or performance!),
but it takes long time to study.

I will try to spend some time on it and if I get significant results I will
not forget to report them here.

In the meanwhile, I'm happy to receive other suggestions and point of view
;-)

Cristiano





2014/1/9 Łukasz Dywicki <lu...@code-house.org>

> 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 <
> cristiano.costantini@gmail.com> 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 <kr...@gmail.com>
> >
> >> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
>
>

Re: AspectJ in Servicemix and OSGi Imports

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
Hallo Lukasz

I tried to find any implementation of AspectJ integration using OSGi 
WeavingHook with no result. I have found some posts from Eclipse people 
writing they are going to implement it in Equinox Aspects project but I 
couldn't find any changes in this direction in the Eclipse repositories. 
Perhaps should we start (in Karaf or Aries) own implementation of 
ApsectJ LTV using the OSGi specification. But we really need an AspectJ 
specialist.

Regards
Krzysztof

On 09.01.2014 12:16, Łukasz Dywicki wrote:
> 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 <cr...@gmail.com> w dniu 8 sty 2014, o godz. 08:44:
>


-- 
Krzysztof Sobkowiak

JEE & OSS Architect | Technical Architect @ Capgemini
Capgemini <http://www.pl.capgemini.com/> | Software Solutions Center 
<http://www.pl.capgemini-sdm.com/> | Wroclaw
e-mail: krzys.sobkowiak@gmail.com <ma...@gmail.com> | 
Twitter: @KSobkowiak

Re: AspectJ in Servicemix and OSGi Imports

Posted by Łukasz Dywicki <lu...@code-house.org>.
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 <cr...@gmail.com> 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 <kr...@gmail.com>
> 
>> 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
>>> 
>>> 
>>> 
>>> 
>>> 
>> 


Re: AspectJ in Servicemix and OSGi Imports

Posted by Cristiano Costantini <cr...@gmail.com>.
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 <kr...@gmail.com>

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

Re: AspectJ in Servicemix and OSGi Imports

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
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
>
>
>
>


Re: AspectJ in Servicemix and OSGi Imports

Posted by Cristiano Costantini <cr...@gmail.com>.
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



Il giorno martedì 7 gennaio 2014, Filippo Balicchia ha scritto:

> Hi,
> I have nodirect experience but there is a good article
> http://dywicki.pl/2011/11/running-aspects-under-osgi-4-2-with-karaf/
> I hope you can help
> Regards
> --Filippo
>
>
> 2014/1/6 Cristiano Costantini <cr...@gmail.com>
>
> > Hi All,
> > I'm testing using AspectJ in ServiceMix (I need it in a Spring Security's
> > "protect-pointcut" expression that put security rules on method of a
> bean).
> >
> > It works, but when I add a pointcut expression, I need to add to my
> bundle
> > a lot more package imports to make it work...
> >
> > To understand what I mean, take a look at the following commit:
> >
> >
> https://github.com/cristcost/springsec/commit/073887d2487ba11f0eebaa011f79d3a9f2c95edd
> > (the commit add an aspectj pointcut expression and add the Import-Package
> > instructions required to make it work).
> >
> > I don't like the final result: managing the Import-Package is too much
> > complex with aspectj enabled...
> >
> > Anyone have experience on using it in ServiceMix and can give any
> > suggestion on how it is best to handle OSGi's import-pacakge when using
> > AspectJ?
> > Can you point me to good examples of ServiceMix or Karaf + AspectJ where
> I
> > can get some inspiration?
> >
> > Thank you very much,
> > (and happy new year to all of you!)
> >
> > Cristiano
> >
>

Re: AspectJ in Servicemix and OSGi Imports

Posted by Filippo Balicchia <fb...@gmail.com>.
Hi,
I have nodirect experience but there is a good article
http://dywicki.pl/2011/11/running-aspects-under-osgi-4-2-with-karaf/
I hope you can help
Regards
--Filippo


2014/1/6 Cristiano Costantini <cr...@gmail.com>

> Hi All,
> I'm testing using AspectJ in ServiceMix (I need it in a Spring Security's
> "protect-pointcut" expression that put security rules on method of a bean).
>
> It works, but when I add a pointcut expression, I need to add to my bundle
> a lot more package imports to make it work...
>
> To understand what I mean, take a look at the following commit:
>
> https://github.com/cristcost/springsec/commit/073887d2487ba11f0eebaa011f79d3a9f2c95edd
> (the commit add an aspectj pointcut expression and add the Import-Package
> instructions required to make it work).
>
> I don't like the final result: managing the Import-Package is too much
> complex with aspectj enabled...
>
> Anyone have experience on using it in ServiceMix and can give any
> suggestion on how it is best to handle OSGi's import-pacakge when using
> AspectJ?
> Can you point me to good examples of ServiceMix or Karaf + AspectJ where I
> can get some inspiration?
>
> Thank you very much,
> (and happy new year to all of you!)
>
> Cristiano
>