Am 29.06.2011 04:45, schrieb Sahoo:
>>
> 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.
Yes, I do think that would work, but it would be a rather heavyweight
and indirect solution involving
weld-osgi-bundle
osgi-cdi
wicket-cdi
instead of simply using
wicket-ioc-bundle
wicket-osgi
wicket-osgi is just 5 rather trivial classes.
GlassFish is not my main target for these experiments, I was coming from
the OSGi side this time, working with Pax Web, Apache Aries and Eclipse
Gemini.
Regards,
Harald
Am 29.06.2011 04:45, schrieb Sahoo:
> 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
>