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.
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.
Secondly, let us see the current status of CDI/OSGi integration.
Currently, there are two projects which are doing CDI/OSGi-related
things, one is Weld-OSGi(plan to merge into WELD 2.x) and the other is
Pax CDI.In addition, OSGi RFP 146 is collecting user's feedbacks and
requirements.
I have found that some GF's
rfcs(GLASSFISH-16805,GLASSFISH-15265,GLASSFISH-18896,GLASSFISH-15365...)
are related to the CDI/OSGi integration. I think that firstly, we
should collect user cases , and evaluate the statuses of other CDI/OSGi
implematations, and then implements these requirements.
Nowadays, I am evaluating WELD-OSGi implementation.
Any other ideas and plans?
--Best Regard!
--Tang