On Tuesday 24 July 2012 08:35 PM, Tang Yong wrote:
> Dear Sahoo, CDI-related Leader/Experts
>
> Although I have known that recently shaoo is very busy,
> I still decided to send the thread about CDI/OSGi.
>
> Fistly, let us see the GLASSFISH-17155.
>
> The use case of GLASSFISH-17155 is as following:
>
> After deploying a WAB using cdi to inject osgi's ServiceListener
> implemetation which will listen osgi service registion and unregistion,
> once a new service is registered, a cdi event will be fired. Then,
> the WAB wants to trigger the @observers methods to add the service.
>
> After my investigation, I have found that GLASSFISH-17155 has two problems.
>
> 1) About ACLSingleton.getClassLoader()
> If store hashtable does not contain
> Thread.currentThread().getContextClassLoader(), the exception on
> GLASSFISH-17155 must happen. So, sahoo gave a solution. However, I have
> confirmed that even if user set the current thread context classload on
> serviceChanged method, the exception still existed. Why？ Becasue the
> key put in store hashtable is WebappClassLoader(for the WAB app) and the
> WebappClassLoader is set on WAB deploying, so, for the user, he/she can
> not have chance to set the current thread context classload into the
> WebappClassLoader.
>
> I will continue to investigate the proper revise way.
>
So, are you saying that the suggested work around does not work any
longer? I think your analysis is correct as well. I think a proper way
to solve would be to set the class loader as an attribute in
ServletContext during WAB deployment so that an application programmer
can retrieve it inside serviceChanged() method and set it as the TCL
temporarily.
> 2) About CDI/OSGi Event
> I have found that real problem on GLASSFISH-17155 is that currently,GF
> has not implemented the CDI/OSGi Event Integration.
>
> I made a confirmation that even if I made the exception on
> GLASSFISH-17155 disappeared using a temp revise way, the sample can not
> still work. Why? When a new service is registered, although cdi event
> has been fired and WAB @observers method is also triggered, but on the
> WAB, there are two @Observes, one is to add the service and the other is
> to delete the service. When cdi event is fired, both the two @Observes
> are triggered.So, the service is not still added finally. That is to
> say, the @Observes can not judge the type of current OSGi Event.
I think this is because the test application attached to the issue is
not firing events correctly. It needs to fire events using BeanManager
and use proper qualifiers such that methods will receive events they are
interested in. See ServletContextBridgeListener.java in the test app for
more details.
Sahoo