On 06/01/2008, Alessandro Mottadelli <[EMAIL PROTECTED]> wrote: > > I have spent a couple of days looking into guice-osgi (download from > http://wiki.ops4j.org/confluence/display/ops4j/Guice-OSGi).
Hi Alessandro, The Guice-OSGi code on OPS4J is a research project, which I used to discover which parts of Guice needed patching to work with OSGi classloading, and to experiment with different ways of using Guice to inject OSGi services. Since it was published (mainly to gather feedback like this) the concept and design has changed quite a lot, and is being re-developed as the 'peaberry' project over at google-code. The first thing was to make the Guice patches less intrusive and more generic - this has been done, and the two patches (one for container classloading and one for binding factories) have been submitted to the Guice team. The next step is to rework the OSGi integration on top of the patched library, while still providing access to Guice and OSGi primitives. Unfortunately I have not had much spare time to work on it recently, so this is still in progress... I find the proposed guice-osgi integration a bit invasive on both osgi > and guice. Well with peaberry, the patches for Guice are very clean and will hopefully make it into a future release of Guice. The OSGi integration is a separate layer on top, and will be much more flexible. For example, instead of: > > @Inject > @OSGiService > MyService unaryProxy; > > @Inject > @OSGiService > Iterable<MyService> multipleProxy; <off-tangent> For some reason annotations get a bad press these days :) Remember that they only add a compile-time dependency, not a runtime dependency - you could easily use your class without requiring the @OSGiService class or the Guice-OSGi library, just as you could use @Inject decorated classes with an XML configuration and classic Spring libraries... </off-tangent> The consumer could just declare: > > @Inject > MyService unaryProxy; > > @Inject > Iterable<MyService> multipleProxy; > > if appropriate providers for the OSGi services are bound (just like the > jndi integration works)...... Yes! - the key is "if appropriate providers for the OSGi services are bound". In one iteration of the Guice-OSGi code, it was possible to do your own binding of the dynamic OSGi service proxies to your own types (ie. if you didn't want to add @OSGiService) - the annotation is just a meta-binding to save typing :) peaberry will let you do your own bindings to the service proxies, thanks to the improved binding factory patch. There'll also be no need to extend the abstract bundle activator (another concern raised). I'm also not able to understand the advantages of using > @OSGiServiceRegistration instead of the standard OSGi registration > syntax.... (why tying the registration to an injection?) You can still use the standard registration calls (and consume those services with @OSGiService, etc.) The reason for providing @OSGiServiceRegistration was to see if the management side could be simplified. For example, using plain Guice with plain OSGi you'd use "registerService" to register an implementation. That implementation would probably be injected by Guice... so why not combine the two and have peaberry register it on your behalf when it's injected? Of course you'll lose some flexibility, but a lot of the time that's not required. Also, because we inject a proxy instance with the implementation and service registration "mixed" together, you can start/stop/update the service using just the one field - no need to manage the ServiceRegistration instance yourself. The idea behind the annotations was to provide a simple and orthogonal way to split a Guice application across different bundles (hence the 2 annotations). ie. use @OSGiService to consume, and @OSGiServiceRegistration to publish. As mentioned before, you won't be forced to use the annotations in peaberry - and you'll be able to drop into plain Guice and plain OSGi whenever you want. But the annotations will still be there for the people who'd prefer a simple tag to writing an explicit binding.... HTH Best regards, > Alessandro Mottadelli > > _______________________________________________ > general mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/general > -- Cheers, Stuart
_______________________________________________ general mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/general
