dev@glassfish.java.net

Re: [Glassfish CDI/OSGi Integration]About _at_Publish Feature

From: Sahoo <sanjeeb.sahoo_at_oracle.com>
Date: Thu, 09 Aug 2012 21:06:24 +0530

Tang,

1. I think you should explore EJBTracker in osgi-ejb-container to see
how it registers EJBs as OSGi services.

2. The service properties look good to me to start with.

3. What I meant by configurable service property in GLASSFISH-18896 is
that instead of hard coding the serviceCriteria if developer can use
tokens which can get replaced by values set during deployment, that will
be more flexible.

Thanks,
Sahoo

On Friday 03 August 2012 04:55 PM, Tang Yong wrote:
> Hi Sahoo, Siva
>
> I created a subTask(GLASSFISH-18972) of GLASSFISH-18938 in order to
> make @Publish to support filter properties, and Now, I have implemented
> it.
>
> [Current Using Way]
> 1 Service Publishing
>
> @publish({ @property(name="country", value="CN") })
> public class SimpleStockQuoteServiceImpl implements StockQuoteService
> ....
>
> 2 Service Consuming
>
> @WebServlet(urlPatterns = "/list")
> public class StockQuoteServlet extends HttpServlet {
> @Inject
> @OSGiService(serviceCriteria="(country=CN)", dynamic = true,
> waitTimeout=30*1000)
> StockQuoteService sqs;
> .....
>
> [Request]
> I wish that sahoo can explain GLASSFISH-18896 in detail and what is mean
> of "Allow criteria to be configurable" , becasue GLASSFISH-18896 also
> relates to this thread's topic.
>
> [ToDo]
> In according to my evaluation, I will implement the GLASSFISH-16805
> firstly, then, implement the integration between CDI Event and OSGi
> Event. In addition, I will re-create threads about GLASSFISH-16805 and
> CDI Event Integration.
>
> --Thanks!
> --Tang
>
> Tang Yong wrote:
>> Hi Sahoo, Siva, Hong
>>
>> I have made some improvements on my prototype,
>>
>> [Improvements]
>> 1) While starting a plain osgi bundle having beans.xml, registering
>> osgi services which are exposed using @Publish annotation
>>
>> 2) Within the seconds set on wait timeouts attribute of @OSGiService,
>> if user starts the service bundle with @Publish again, the service
>> client will access services successfully again.
>>
>> [Using Way]
>> 1) building and deploying stockquote_service_usingcdi
>> - cd stockquote-cdi-osgi-sample\stockquote_service_usingcdi
>> - maven clean install
>> - asadmin deploy --type=osgi stockquote_service_usingcdi.jar
>>
>> 2) building and deploying stockquote_cdi_wab
>> - cd stockquote-cdi-osgi-sample\stockquote_cdi_wab
>> - maven clean install
>> - asadmin deploy --type=osgi stockquote_cdi_wab.war
>>
>> 3) access "http://localhost:8080/stockquote/list"
>> OK!
>>
>> 4) telnet localhost 6666
>>
>> 5) stopping stockquote_service_usingcdi bundle (etc. stop 341)
>>
>> ! stop 341
>>
>> 6) access "http://localhost:8080/stockquote/list" again, at the moment,
>> if user starts 341 again within 30 seconds, stockquote_cdi_wab will be
>> accessed successfully, otherwise, service will be unavailable.
>>
>> [ToDo List]
>> 1) while using felix shell to install bundle with beans.xml, also making
>> weld container to scan @Publish annotation and register osgi services.
>>
>> 2) validate a hybrid javaee app among which if a module uses @Publish
>> annotation, whether to support it or not?
>>
>> --Best Regard!
>> --Tang
>>
>> Tang Yong wrote:
>>> Hi Sahoo, Siva, Hong
>>>
>>> Now, A plain OSGi bundle can use @Publish annotation to
>>> register service into OSGi world not using BundleActivator.
>>> Taking a stockquote-cdi as a example, user can use the following way
>>> to publish a osgi service which can be consumed by a servlet of WAB
>>>
>>> @Publish
>>> public class SimpleStockQuoteServiceImpl implements StockQuoteService{
>>> ...
>>> }
>>>
>>> then, he/she can use "deploy --type=osgi XXX" to publish the service.
>>>
>>> ToDo: I will implment the service's publishing on bundle's start rather
>>> than on deployment.
>>>
>>> I have the basic prototype of the feature although still having
>>> some problems needed to resolve.
>>>
>>> The prototype is on https://github.com/tangyong/gf-cdi-osgi-integration
>>>
>>> Let me to say integration idea.
>>>
>>> 1) getting WeldSniffer if current plain bundle contains beans.xml on
>>> deploying
>>>
>>> I modified the ApplicationLifecycle.prepareSniffersForOSGiDeployment
>>> method to get WeldSniffer.
>>>
>>> 2) adding @Publish Qualifier into osgi-cdi-api module
>>>
>>> I evaluated WELD/OSGi project and OSGi RFP 146, and decided to use
>>> @Publish Qualifier.
>>>
>>> ToDo: lately, maybe add some additional properties into @Publish
>>>
>>> 3) Making Weld can deploy plain bundle(jar) as BeanDeploymentArchiveImpl
>>> not only for JavaEE application.
>>>
>>> The critical point is that making Weld can load the plain bundle(jar)
>>> classes and resources, so, I modified
>>> BeanDeploymentArchiveImpl.getClassLoader() method.
>>>
>>> 4) letting Weld BeanManager to discovery bean classes with @Publish
>>>
>>> Adding the discovering logic into OSGiServiceExtension.afterProcessBean
>>> method on osgi-cdi module, and then, registering service into OSGi world.
>>>
>>> If you having time, please discuss and review it.
>>>
>>> I will continue to improve the prototype and resolve some problems, and
>>> implement other features such as event integration between osgi and cdi.
>>>
>>> --Best Regard!
>>> --Tang
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>