Hi sahoo,
> 1. I think you should explore EJBTracker in osgi-ejb-container to see
> how it registers EJBs as OSGi services.
OK, I will see it. thanks your suggestion.
BTW: currently, osgi alliance has a rfp (RFP 152 EJB Integration) and am
receiving feedback.
https://www.osgi.org/bugzilla/show_bug.cgi?id=148
> 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.
Good idea! I will consider it.
--Tang
Sahoo wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>
>
>