Peaberry - Blending Services And Extensions

download Peaberry - Blending Services And Extensions

If you can't read please download the document

description

peaberry extends Guice to support injection of dynamic services. It provides OSGi integration out of the box and has plug-in support for other registry-based service frameworks. This talk introduces peaberry and shows how it can be used to seamlessly blend both OSGi services and Eclipse extensions in the same application, as well as help switch between the two approaches.

Transcript of Peaberry - Blending Services And Extensions

  • 1. peaberry Stuart McCulloch

2. Today's menu Origin of peaberry OSGi-fying Guice Service providers Service registry abstraction Blending services & extensions Future ideas 3. Origin Began as lab project at community site new annotations @Inject @OSGiService("(Currency=GBP)") StockQuote quote; patched Guice to support service auto-binding @OSGiService(...) StockQuote quote; // magically added for you bind(StockQuote.class)... 4. Simplification Auto-binding introduced too much magic @Inject @OSGiService("(Currency=GBP)") StockQuote quote; NO new annotations service bindings now explicit, just like pure Guiceaim to be a true extension to Guice no patches! so... 5. Squeezing Guice into a bundle Guice now has OSGi metadata thanks to Guice's type-safety meant no major classloading issues ... but AOP proxies initially didn't work in OSGi AOP proxies need to see client types AOP support types BND internal & 6. Bridge class loader Don't want to expose AOP internals (repackaged CGLIB) parent parent com.google.inject.internal.* loadClass loadClass so load proxy classes using bridge class loaders 7. Bridge class loader (2) No dependency on OSGi ! only used when needed of bridge classloaders allows re-use ... as well as eager unloading of proxy classes BUT cannot apply bridging topackage-privatetypes as not visible from other classloaders weak cache 8. Why peaberry? Guice can now be used in OSGi so what's missing? no support for dynamic OSGi services! each injector uses immutable set of explicit bindings so ... newInjectoron every service change? or ...Providerthat returns dynamic proxies? :( :) 9. Service Provider @Inject StockQuote quote; quote.price(JAVA); get unget price injector get K P K P K P P Service Registry p r o x y p r o x y 10. Service binding Fluent API helps you get the right serviceProvider bind( iterable( A.class ) ).toProvider( service( A.class ).multiple() ); @Inject A bestService; @Inject Iterable allServices; // each element is a proxy import static org.ops4j.peaberry.Peaberry.service; import static org.ops4j.peaberry.util.TypeLiterals.iterable; * bind( A.class ).toProvider( service( A.class ).single() ); 11. Service binding (2) So is that it? s: 12. Service binding (2) So is that it? ... no, you can also service( A.class ).filter( /* apply a filter */ )... service( A.class ).in( /* query a specific registry */ )... service( A.class ).out( /* watch for service changes */ )... service( A.class ).decoratedWith( /* apply decoration */ )... each stage of the builder creates an immutable copy which means you can share and re-use builders 13. Service Registry public interfaceServiceRegistry { Iterable> lookup(Class clazz, AttributeFilter filter); voidwatch(Class clazz, AttributeFilter filter, ServiceWatcher