Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sisu-users] Sisu documentation 
On 28 Sep 2012, at 18:37, Gernot Kvas wrote:

> On 09/27/2012 07:29 PM, Stuart McCulloch wrote:
>> One of the original use-cases for Sisu was wiring up an RCP application, so this is definitely in scope (though there are still some rough edges to smooth out).
>> 
>>> Wrt. bootstrapping. Given an RCP application, the "start" method of the
>>> IApplication would be the right place to have a
>>> "SisuGuice.inject(MyClass.class)" ?
>> The SisuGuice.inject method expects an existing instance that needs field/setter injection (btw, this class is expected to change in the API cleanup).
>> 
>> To ask Sisu to construct (and inject) a component you can use the SisuGuice.lookup method, which takes a Guice key such as Key.get( MyClass.class ).
>> 
>> One of the other tasks on the road-map is to reduce this dependency/use of Guice-specific types to make it easier to re-use the code elsewhere.
> 
> Hi Stuart,
> 
> I'm currently struggling a bit with getting things running, but some progress is there.
> 
> I've started of with a small app (two bundles, where one bundle injects a service from the other). Insights I've gained so far:
> 
> * Sisu relies on "import javax.inject" to determine which bundles to scan. That took a while for me to notice, because I defining a dependency to javax.inject rather than importing the package.

Yes, that's just to avoid scanning everything in the system (which end up being a lot of resources) - up to now the focus has been on the classic classpath case as used in Maven and Nexus which have been the primary consumers of Sisu, so the activator hasn't yet been tuned to look for the optional index file "META-INF/sisu/javax.inject.Named" which is another way to notify that a bundle contains components and a way to avoid eager classpath scanning (yet another item to be documented).

> * What kills me currently is a missing dependency to javax.enterprise.inject.Typed, which appears to be required although being only marked as optional in the MANIFEST.MF of org.eclipse.sisu.inject. This causes a ClassNotFoundException somewhere in

We used to embed this in the bundle, so this wasn't noticed before (the Eclipse packaging is still being worked on, for example there's no feature yet) - you can deploy the cdi-api bundle from Eclipse/Orbit as a workaround.

> java.lang.NoClassDefFoundError: javax/enterprise/inject/Typed
>    at org.eclipse.sisu.binders.QualifiedTypeBinder.getBindingTypes(QualifiedTypeBinder.java:332)
>    at org.eclipse.sisu.binders.QualifiedTypeBinder.bindQualifiedType(QualifiedTypeBinder.java:228)
>    at org.eclipse.sisu.binders.QualifiedTypeBinder.hear(QualifiedTypeBinder.java:111)
>    at org.eclipse.sisu.scanners.QualifiedTypeVisitor.visitEnd(QualifiedTypeVisitor.java:118)
>    at org.objectweb.asm.ClassReader.accept(Unknown Source)
>    at org.objectweb.asm.ClassReader.accept(Unknown Source)
>    at org.eclipse.sisu.scanners.ClassSpaceScanner.accept(ClassSpaceScanner.java:102)
>    at org.eclipse.sisu.scanners.ClassSpaceScanner.accept(ClassSpaceScanner.java:78)
>    at org.eclipse.sisu.binders.SpaceModule.configure(SpaceModule.java:92)
>    at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:230)
>    at com.google.inject.spi.Elements.getElements(Elements.java:103)
>    at com.google.inject.spi.Elements.getElements(Elements.java:80)
>    at org.eclipse.sisu.binders.WireModule.configure(WireModule.java:60)
>    at com.google.inject.spi.Elements$RecordingBinder.install(Elements.java:230)
>    at com.google.inject.spi.Elements.getElements(Elements.java:103)
>    at com.google.inject.internal.InjectorShell$Builder.build(InjectorShell.java:136)
>    at com.google.inject.internal.InternalInjectorCreator.build(InternalInjectorCreator.java:104)
>    at com.google.inject.Guice.createInjector(Guice.java:96)
>    at com.google.inject.Guice.createInjector(Guice.java:73)
>    at com.google.inject.Guice.createInjector(Guice.java:62)
>    at org.eclipse.sisu.containers.SisuActivator$BundleInjector.<init>(SisuActivator.java:221)
>    at org.eclipse.sisu.containers.SisuActivator.addingBundle(SisuActivator.java:105)
> 
> * Another issue that arises is within the "SisuActivator". In line 97, there is a check to avoid scanning org.eclipse.sisu itself. Is this check correct? The symbolic name of the sisu bundle in my case is "org.eclipse.sisu.inject", rather than "org.eclipse.sisu".

This should be fixed in the latest code (and the 0.0.0.M0 milestone):

   http://git.eclipse.org/c/sisu/org.eclipse.sisu.inject.git/tree/org.eclipse.sisu.inject/src/org/eclipse/sisu/containers/SisuActivator.java#n55

> * I'm currently using sisu-guice, but could I use vanilla Guice without any problemes?

Yes, either can be used for JSR330 mode - it's only the Plexus adaptor that relies on a feature that's in Guice trunk (yet to be released)

For the exact patches in Sisu-Guice see https://github.com/sonatype/sisu-guice/tree/master/PATCHES - all have been reported upstream

> Cheers,
> 
> Gernot
> _______________________________________________
> sisu-users mailing list
> sisu-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/sisu-users

Back to the top