Even if that syntax were supported, I'm not sure I'd see the point since
generics are a compile time only construct. What would you have blueprint
do with the generic data at runtime in terms of instantiating and
registering the service?
If the main issue is you need to insure the injected Supplier service
reference returns SiteCatalog objects, you could have the Supplier
registered with a service property, then have the consumer look only for a
Supplier with that property and value.
<bean id="xmiSiteCatalogSupplier"
class="org.soluvas.commons.XmiObjectLoader">
<!-- I'm assuming the following three arguments are sufficient for letting
the XmiObjectLoader know which type to return. -->
<argument value="org.soluvas.web.site.SitePackage" />
<argument value="id.co.bippo.common.PersonRef" />
<argument value="bippo.SiteCatalog.xmi" />
</bean>
<service ref="xmiSiteCatalogSupplier"
interface="com.google.common.base.Supplier">
<service-properties>
<entry key="supplied" value="
org.soluvas.web.site.SiteCatalog"/>
</service-properties>
</service>
<reference interface="com.google.common.base.Supplier" filter="(supplied=
org.soluvas.web.site.SiteCatalog)"/>
John
>
> Cannot create and publish beans with Java5 generics in Aries Blueprint
>
> Hi Aries developers,
>
> This Blueprint :
>
> <bean id="xmiSiteCatalogSupplier"
>
class="org.soluvas.commons.XmiObjectLoader<org.soluvas.web.site.SiteCatalog>">
> <argument value="org.soluvas.web.site.SitePackage" />
> <argument value="id.co.bippo.common.PersonRef" />
> <argument value="bippo.SiteCatalog.xmi" />
> </bean>
> <service ref="xmiSiteCatalogSupplier"
>
interface="com.google.common.base.Supplier<org.soluvas.web.site.SiteCatalog>"/>
>
> Gives this error:
>
> 2012-10-20 13:59:28,275 | WARN | ce5/karaf/deploy | fileinstall
> | ? ? | 6 -
> org.apache.felix.fileinstall - 3.2.6 | Error while starting bundle:
> blueprint:file:/home/ceefour/git/bippo-commerce5/karaf/deploy/
> berbatik_dev_app.xml
> org.osgi.framework.BundleException: Unresolved constraint in bundle
> berbatik_dev_app.xml [2110]: Unable to resolve 2110.4: missing
> requirement [2110.4] osgi.wiring.package;
> (osgi.wiring.package=id.co.bippo.app) [caused by: Unable to resolve
> 2425.2: missing requirement [2425.2] osgi.wiring.package; (&
> (osgi.wiring.package=id.co.bippo.common)(version>=5.0.0)(!
> (version>=6.0.0))) [caused by: Unable to resolve 2415.13: missing
> requirement [2415.13] osgi.wiring.package;
>
(osgi.wiring.package=com.google.common.base.Supplier<org.soluvas.web.site)]]
> at org.apache.felix.framework.Felix.resolveBundleRevision
> (Felix.java:3826)[org.apache.felix.framework-4.0.3.jar:]
> at org.apache.felix.framework.Felix.startBundle(Felix.java:
> 1868)[org.apache.felix.framework-4.0.3.jar:]
> at org.apache.felix.framework.BundleImpl.start
> (BundleImpl.java:944)[org.apache.felix.framework-4.0.3.jar:]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundle
> (DirectoryWatcher.java:1247)[6:org.apache.felix.fileinstall:3.2.6]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.startBundles
> (DirectoryWatcher.java:1219)[6:org.apache.felix.fileinstall:3.2.6]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.startAllBundles
> (DirectoryWatcher.java:1208)[6:org.apache.felix.fileinstall:3.2.6]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process
> (DirectoryWatcher.java:503)[6:org.apache.felix.fileinstall:3.2.6]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run
> (DirectoryWatcher.java:291)[6:org.apache.felix.fileinstall:3.2.6]
>
> My use case is:
> - The needed service is a Supplier<SiteCatalog>, it supplies
> SiteCatalog objects. The supplier can dynamically return a
> SiteCatalog, and the SiteCatalog must not be proxied.
> - A Supplier implementation can use generics,
> e.g. org.soluvas.commons.XmiObjectLoader<T> in this case
>
> What I'd like to do is register the equivalent of:
>
> new XmiObjectLoader<SiteCatalog>( ............ );
>
> However Blueprint seems to not allow creating objects with generics,
> and also not publish services with generics.
>
> A workaround is to create a wrapper supplier decorator class for
> each data, i.e.:
>
> new SiteCatalogSupplier( <original supplier here> )
>
> but this is ugly when there are lots of data classes.
>
> Any suggestions? Is this a bug ?
>
> --
> Hendy Irawan - on Twitter - on LinkedIn
> Web Developer | Bippo Indonesia | Akselerator Bisnis | Bandung
