Am 28.06.2011 05:11, schrieb Sahoo:
> On Tuesday 28 June 2011 12:44 AM, Harald Wellmann wrote:
>> Yes, so it seems my glue stuff is not needed to load the application
>> class by name. But it also lets you look up the application from the
>> OSGi service registry instead of creating a new instance, which is
>> handy if you need to inject required services via DS or Blueprint.
>>
> This is a different feature of your glue code than earlier stated.
> Although it is not related to the class loading issue you initially
> raised, can you elaborate a bit more about this glue code? What exactly
> it is bridging?
>
Ok, I hope I'm not getting off topic too much, but since you're asking:
I'm trying to make Apache Wicket play nicely with OSGi WABs, and one
part of the story is injecting OSGi services into Wicket components.
The point is, Wicket components are unmanaged POJOs instantiated by
application code, there is no OSGi or Blueprint or CDI lifecycle.
Wicket has an add-on lib called wicket-ioc which provides some generic
support for dependency injection, wrapping the injected objects in
proxies to support wicket page deserialization.
Using the OsgiComponentInjector, which is part of my glue code, you can
annotate component fields with JSR-330 @Inject to inject an OSGi service
of the required type by lookup from the registry. (The next logical step
will be to support the @OSGiService qualifier from GlassFish which you
kindly put into an API bundle of its own so it can be easily used
outside of GlassFish.)
wicket-ioc has different specializations, for Spring, for Java EE 5 @EJB
and @Resource injection, for CDI, and my "bridge" is just another
specialization for OSGi.
All of this is work in progress, the source code is here:
https://github.com/wicketstuff/core/tree/master/jdk-1.5-parent/wicket-osgi-parent/wicket-osgi
...and there is a Wiki page (admittedly rather sketchy):
https://github.com/wicketstuff/core/wiki/Osgi
See also this thread on the Wicket Users mailing list:
http://apache-wicket.1842946.n4.nabble.com/Wicket-and-OSGi-tp3617698p3617698.html
Regards,
Harald