[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] Generalized OSGi transformations


While the Aspects project could be viewed as a "transformer" this is really an implementation detail: AspectJ developers should be expressing themselves in Java/AspectJ completely independently of the deployment platform. Also the project's primary purpose is to exploit rather than affect OSGi meta-data apart from the implementation of the co-opt model which essentially adds entries to the Require-Bundle header in the manifest for target bundles. In short users of the Aspects project should not really be aware of what is going on at a low level.

>been looking at the Aspect code a lot for inspiration and I think  
>that the current Aspect code could be migrated to a generalized  
>solution pretty easily.

Could you elaborate a little? The only reason I use framework hooks is to intercept class loading and definition. This allows me to call AspectJ in pretty much the same way that our JVMTI agent does but without the need for Java 5. It also allows the possibility of implementing some sophisticated and transparent byte-code caching to improve performance. Are you thinking that the org.aspectj.osgi extension could be implemented as a general purpose transformer?

Reading the Wiki has given me an idea of how I might implement co-opt support without having to change the Equinox resolver so this has been useful.


Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx

Kimberly Horne <kim@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

14/11/2006 21:02

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
[equinox-dev] Generalized OSGi transformations

I've begun to outline a possible generalized OSGi transformation  
solution at http://wiki.eclipse.org/index.php/Product_Customization.  
It's a bit skeletal at the moment but should be much more readable in  
the next day or so.  I'd be interested in input from any interested  
parties, particularly those developing the Aspect J service.  I've  
been looking at the Aspect code a lot for inspiration and I think  
that the current Aspect code could be migrated to a generalized  
solution pretty easily.
equinox-dev mailing list