You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Simon Chemouil <sc...@gmail.com> on 2016/05/20 20:48:17 UTC

Aspecio, an aspect framework for OSGi r6

(hijacking this Felix ML for a community announcement since I believe it
is the one place where most OSGi devs gather)
----------------------------------------------------------------------

Aspecio[1] (prounounced 'aspekio) is an aspect framework designed and
written from scratch to be OSGi compliant and take advantage of the OSGi
service model.

With Aspecio, we can publish aspects as OSGi services ; an aspect can
have several implementations (interceptors), but only the highest-ranked
is active at any given time.

It is then possible for any OSGi service to ask, through its service
properties, to be "woven" with a given aspect.

By default, Aspecio uses ServiceHook APIs (in their updated r6 form) to
hide woven services from all bundles except the system bundle and
itself. Instead, it registers a public service with similar properties
that acts as a proxy to its delegate woven service and allow method
interception.

Consumers of woven services thus obtain the proxy instance, and all
calls issued through the service interfaces are potentially intercepted.

Aspecio's advice API allows interceptors to skip the intercepted method
invocation either by returning a custom value or throwing an exception,
to obtain a cacheable instance of the arguments passed for a given
method invocation, to update the said arguments, to be notified or alter
exceptions thrown by the intercepted method, and to retrieve and change
the return value of the call. Advices can expose precisely what they
need so that they don't pay any cost for callbacks or code generation
they don't use.

Aspecio generates its proxies and argument classes in bytecode with ASM,
on demand, and does not do any kind of primitive boxing. Aspecio proxies
expose the same metadata as the class it proxies, from implemented
interfaces, generic signatures to annotations, so frameworks inspecting
service objects should work just fine. All public methods are delegated,
even those not in an implemented interface (this is useful for methods
found through reflection).

Aspecio focuses on performance, control and predictability. It has no
dependency except for OSGi core, but it can use Slf4J (optionally) if it
is present when it is resolved. Service dynamics work fine, whether
woven services come and go, have bundle or prototype scope, or whether
interceptors leave (a service can ask for mandatory or optional weaving,
and it will affect its status).

Obviously, the approach Aspecio takes is not fool-proof. First, it will
ignore services registered as classes and not interfaces (this is not
really an issue). Second, if you call a method you expect to be
intercepted from the woven service object using "this", then the call
will not be intercepted. I am experimenting on prototypes to overcome
that downside, but Java 8 default methods can already work around this
nicely.

Because of using Service Hooks and the lack of "unwiring API / service
event spoofing" in OSGi APIs (so far), Aspecio has to be installed and
started early in the framework, before bundles using it are started.

Aspecio is licensed under ASL2 and available on Maven Central:
<dependency>
	<groupId>io.lambdacube.aspecio</groupId>
	<artifactId>aspecio-core</artifactId>
	<version>1.0</version>
</dependency>

You will find more information on Aspecio's webpage[1] and javadoc[2],
but the best way is to try it. To get started, you just have to start
Aspecio in your favorite OSGi r6 container (tested with Felix 5.4.0),
and then register services with the right properties (see
documentation). It should be pretty straightforward, but if you have
questions please let me know (here or on Twitter, I'm @simach). I would
appreciate any feedback.

I have proposed a talk[3] about Aspecio to the OSGi Community Event 2016
in Ludwigsburg, Germany. If it is selected, it will be an opportunity
for me to show it in action and discuss the reasons for my design
choices. I will also attend to EclipseCon France early June in Toulouse,
France, so if anyone wants to meet and talk about this, or OSGi, or
software don't hesitate to poke me.

Bugs reports on Github issues. PRs appreciated. And most of all,
comments very welcome!

[1] http://lambdacube.github.com/aspecio
[2] http://lambdacube.github.io/aspecio/javadoc/
[3]
https://www.eclipsecon.org/europe2016/session/aspecio-aspect-oriented-programming-meets-osgi-service-model

-- 
Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org