Sahoo,
>You are specifically referring to GlassFish3.1/OSGi project page.
>Since that release is over long back, is there a good reason to
>update the Wiki page?
I am sorry for not stating my motive of looking back at 3.1OSGi clearly.
Just as you said, Glassfish 3.1/OSGi needs not be updated and I agree
with you.
My motive is that because currently I have not seen future plan of
Glassfish OSGi from wiki, based on 3.1OSGi and my understanding, I wrote
the thread. Although previously you gave me kind of things related to
directions based on jira, I think that if having a more clear plan for
4.0OSGi, I believe that more contributors can join the field.
On the other hand, as to 3.1OSGi, although some tasks have been
completed, for their backgrounds, maybe some contributors(eg. me) are
interested in them, so I wish that if having more time, their
backgrounds can be added on too, for example jira number in order to let
us know more.
>> ・Provide an API to handle META-INF/services in OSGi context
> See https://wikis.oracle.com/display/GlassFish/JdkSpiOsgi
Thanks.
As a whole, thanks your reply very much! and I have known much.
--Tang
Sahoo wrote:
> Tang,
>
>
>
> On Monday 24 September 2012 09:24 AM, Tang Yong wrote:
>> Dear Sahoo,Siva
>>
>> About current implementation status of 3.1OSGi[1], I have some
>> suggestions and questions, and want to discuss with you.
>> [1]： https://wikis.oracle.com/display/GlassFish/3.1OSGi
>>
>> 【Suggestions】
>>
> You are specifically referring to GlassFish3.1/OSGi project page. Since
> that release is over long back, is there a good reason to update the
> Wiki page?
>
>
>> S1: About "Upgrading core OSGi runtime (OSGi-01)"
>> Currently, Glassfish has used felix 4.x as default OSGi runtime, so
>> please update the section, and updatding maybe should put into 4.0OSGi.
>>
>> S2: About "Implementation of Enterprise OSGi Specs (OSGi-03)"
>> ・OSGi/HTTP Service
>> Although not finding rfc number, liking other specs, you maybe write the
>> following:
>>
>> OSGi EE Spec 102(OSGi/HTTP Service)
>>
>> S3: About "Generic OSGi Features (OSGi-05)"
>> Once accepting ancoron's patch, the description maybe should be updated.
>>
>> S4: About "Task List"
>> ・Improve module metadata
>> On the column of "Status / Comments", wish to add a jira number in
>> order to make others know detailed status.
>>
>> ・RFC #122 CT
>> On the column of "Status / Comments", for general, we can not access the
>> link of CT issue 1841 because only OSGi Contributing Associates member
>> or higher can access the link. So, whether should have a corresponding
>> gf jira or not?
>>
>> ・RFC #98 CT
>> On the column of "Status / Comments", the links of 13321 and 13325 have
>> been out of date, so please update them.
>>
>> ・Explore use of CDI in hybrid applications
>> As to 3.1OSGi, I think that this is enough. However, with constant
>> updating OSGi RFP 146 OSGi/CDI Integration[2], more features of OSGi/CDI
>> may should be implemented on 4.0OSGi.
>> [2]: https://www.osgi.org/bugzilla/show_bug.cgi?id=141
>>
>> ・Provide an API to handle META-INF/services in OSGi context
>> Although having been completed, I wish sahoo can offer a jira number or
>> link to make us know more contents.
>>
> See https://wikis.oracle.com/display/GlassFish/JdkSpiOsgi
>
>> ・Better integration with OSGi Web Console and GF Admin Console
>> On the column of "Status / Comments", the link of "usage" is unavailable.
>>
>> 【Questions】
>>
>> Q1: About "Implementation of Enterprise OSGi Specs (OSGi-03)"
>> ・RFC #142 (OSGi/JNDI)
>> Because OSGi/JNDI has been put in OSGi EE Spec 126, I want to know the
>> reason of "Due to lack of resource" and whether having a plan to
>> implement it on 4.0 or not?
> It is not in my priority list. I had already told you kind of things we
> are looking at now when you wanted direction.
>> Q2: About "Task List"
>> ・RFC #66 CT
>> On the column of "Status / Comments", is current status still "Started -
>> Need to investigate test failures "?
> You are looking at 3.1 page. We are now fully compliant.
>> ・Support multiple JPA providers for OSGi enterprise applications
>> Currently, whether having a plan to support it or not?
> No plans.
>> ・Stop relying on Thread context class loader for META-INF/services
>> Current status?
>>
> We are still relying on it. It requires a lot of changes in lots of places.
>> ・Integration of OBR with deployment backend
>> I want to know the means of "Dropped - lack of resource" and now whether
>> being still the phrase of collecting user reqirements or not?
>>
> We want to do it
>> ・Provide a la carte access to GF modules via OBR
>> The same as above.
> Being addressed as part of on-demand.
>> Thanks!
>> --Tang
>>
>>
>>
>>
>
>
>