Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sisu-users] Sisu in OSGi
On 30 Aug 2013, at 09:44, gian.maria.romanato@xxxxxxxxxxxx wrote:

Hello,

I need some information about Sisu, to understand if it could be a good fit for my needs. This will be a rather long email, sorry about that.

No worries, I'm working on updating the FAQ at the moment so this is actually very timely :)

First a few details about my requirements that will help understand my questions.
  • I'm looking for a DI framework like Guice that provide means of implementing easily AOP and that works in OSGi, with support for dynamic modules.
  • I also want to achieve a good level of portability between JavaSE/JavaEE and OSGi, meaning that my application, while designed to run in an OSGi container and to leverage dynamic modules, should be portable with a reasonable effort to JavaSE/JavaEE (clearly at the expense of some dynamicity) and probably after replacing some key classes with an alternative implementation for JavaSE. This is one of the reasons I am not using the OSGi service registry directly for DI and would rather use Guice. But the rich feature set of Guice and its simpler API for the end user is also another reason (if portability was the only concern I would have evaluated PojoSR).

While searching for an OSGi integration for Guice I stumbled upon Peaberry first, and then Sisu, and if I am not mistaken the author of the two projects is the same.

Now the questions.
  • My understanding is that Sisu allows using the Guice API directly, it just requires you to bootstrap Guice using Sisu specific modules, but then you can use the Injector as usual. Is this correct?
Yes, Sisu is made up of modules that work off the official Guice SPI (http://code.google.com/p/google-guice/wiki/ExtendingGuice)

    *  the SpaceModule lets you scan a given class space (based on URLs or bundles, etc.) for components and automatically bind them
    *  the WireModule lets you analyze a collection of modules and automatically wire missing dependencies - by default via the BeanLocator
    *  the BeanLocator lets you search/watch for components over a list of injectors - it dynamically updates results as injectors come and go

You can use these modules independently or together.
  • Can I bootstrap the Injector passing in additional modules besides the Sisu ones to register custom type listeners, providers and so on?
Yes - note that any modules that require auto-wiring should be wrapped inside a WireModule, so a typical bootstrap line might look like:

    Guice.createInjector(
        new WireModule( someBootModule, new myAppModule(params), new SpaceModule(new URLClassSpace(myClassLoader)) )
    );

Note that if you're creating a child injector then you should use the ChildWireModule.
  • Does it support Guice AOP?
Yes
  • Does it support OSGi dynamicity in a way similar to Peaberry, i.e. using an Extender? If so, is there any documentation/sample code/testcase about that I can look at?
Sisu takes a more generic, modular approach than Peaberry by separating the wiring of missing dependencies from the finding of components.

The example extender bundle uses Sisu to scan bundles for components as they are started:


It automatically bootstraps an injector per-bundle (with component scanning and auto-wiring) and registers it with the OSGi registry:


The extender bundle also watches for these injector services and uses them to update the list of injectors in the shared BeanLocator:


So as bundles start and stop, their injectors come and go from the BeanLocator, and the dynamic collections that delegate to the BeanLocator automatically update.

You can use Sisu to write a dynamic OSGi-based application today, but you should be aware of these missing features that are still in-progress:

    *  extend dynamic updates to apply to injected instances, not just injected collections (https://bugs.eclipse.org/bugs/show_bug.cgi?id=386430)
    *  provide a more granular import/export of individual components to the OSGi registry (https://bugs.eclipse.org/bugs/show_bug.cgi?id=386435)

A lot of the groundwork for 386435 is in place, it's mostly a matter of providing a BindingPublisher implementation backed by the OSGi service registry. 

Also note the main Sisu-Inject bundle is now purely a library (no activator) so you can always choose to not deploy the extender bundle and use your own bootstrap/extender bundle instead.
  • I noticed that there is a github project called sisu-guice which is a fork of Guice with some patches applied. Does Sisu depend on it or does it works with plain Guice?
Sisu-Guice arose from two needs: a more frequent release cycle, and a place to try out community patches. You don't need these patches to use Sisu-Inject, it builds and runs against a minimum of Guice 3.0
  • Peaberry seems more mature, but Sisu looks more interesting, and I believe it's already quite stable since it's used in Maven 3 and Nexus. If I am not mistaken, Peaberry requires you to write Guice modules in a special way which would affect my portability goal or at least increase the effor of the porting, while Sisu seems to impose no special condition on module implementations, is that right?
You can use Peaberry without its activation extension, it just means you need to write your own explicit bindings to import or export OSGi services:


So you can use Peaberry in your own injector and mix Peaberry modules with your own application modules without imposing special requirements. One way to improve portability is to keep these Peaberry-bindings in a separate module away from your application modules, so you can swap it with a non-OSGi module that provides the same bindings except to concrete implementations. Then you just need to choose the appropriate modules when bootstrapping the injector (ie. appModule+peaberryModule vs. appModule+classicModule).

BTW, you can also use Peaberry with Sisu (see an example from the old pre-Eclipse repository https://github.com/sonatype/sisu/tree/master/examples/sisu-peaberry)
  • I found an old example of the usage of an earlier version of Sisu on github. The author was not declaring any module at all and Sisu was auto-binding all @Named classes. Is that still the case? If so, may I ask how classes are located in OSGi? And does it come with a performance penalty? I am afraid that the application boot time could increase.
Sisu provides two main approaches to finding components in a given class space: classpath scanning and a simple index. Both approaches use the ClassSpace abstraction (use URLClassSpace for classic URL classpaths and BundleClassSpace for OSGi bundle classpaths). For large applications an index will be faster, and if you're using Java6 then there's an annotation processor built into Sisu that should generate the @Named index file (under META-INF/sisu/javax.inject.Named) as part of the compilation process when you build against the Sisu library. There's also a command-line utility:


And a Maven plugin that can generate either a local or global index (useful when creating global indexes for WARs, etc.)


If you're using the example extender bundle you can use the 'org.eclipse.sisu.space.BeanScanning' bundle property to select between ON (classpath scanning) OFF (no scanning) or INDEX (indexed scanning).

You can also supply your own ClassFinder approach to the SpaceModule if you're doing your own bootstrapping.
  • I read that one of the Sisu goals is integration with Equinox registry and OSGi registry. That's not super urgent for me, but it's a feature I'd really like. Is there any planned release date for those improvements?
Now the API refactoring/clean-up is done we'll be making our first official release from the Eclipse incubator very soon - the registry integration work is scheduled for the subsequent release.

I'm updating the release plan this week as part of getting everything ready for our first release review: http://projects.eclipse.org/projects/technology.sisu/releases 

More documentation will also be appearing over the coming months, I'll send out an announcement when the next tutorial is ready.

Thanks in advance
GianMaria Romanato._______________________________________________
sisu-users mailing list
sisu-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/sisu-users

Back to the top