On Wednesday 29 June 2011 01:10 AM, Harald Wellmann wrote:
> 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
>
>
I have not gone through these references yet, nor am I a CDI expert, but
I would be surprised if CDI could not be used more effectively to solve
this problem. If wicket-ioc already has a specialization for CDI, why do
you have to do anything extra to use @OSGiService? @OSGiService should
simply work, because it's a portable CDI extension.
Thanks,
Sahoo