Thanks All,
We decided only to support osgi:service and osgi:framework/bundlecontext
from the OSGi URL Scheme section of the OSGi JNDI Services specification.
We are not going to support osgi:servicelist in the first phase.
Thanks,
Sameera.
On Mon, Apr 4, 2016 at 5:16 PM, Peter Kriens <peter.kri...@aqute.biz> wrote:
> Christian,
> WSO2 is a provider of infrastructure, not an application developer. I
> guess they need to provide the OSGi specification implementations to their
> customers.
>
> Kind regards,
>
> Peter Kriens
>
>
> On 4 apr. 2016, at 08:19, Christian Schneider <ch...@die-schneider.net>
> wrote:
>
> If you are developing a pure OSGi solution then you should think twice
> about using jndi. Jndi is not very well suited for a dynamic environment.
> So for example
> you do not get a notification when a jndi resource becomes available and
> there is no way to remove a jndi resource.
>
> The old Aries JPA implementation used Aries jndi to resolve the
> DataSources. This was not very reliable. It simply waited until a timeout
> for the DataSource to become available and threw an exception if not. It
> also was not able to cope with dyanamic changes in the DataSource service
> or a removal.
>
> So for the new Aries JPA implementation I kept the jndi url syntax but on
> the Aries JPA side I implemented it with a service tracker for the
> DataSource. So it was able to react on changes, removal and also could
> handle a new DataSource that arrives at any late time.
>
> Christian
>
>
> 2016-04-04 6:50 GMT+02:00 Nipuni Piyabasi Perera <nipuni880...@gmail.com>:
>
>> Hi Christian,
>>
>> Thanks for your suggestions.
>>
>> I will try to reach Jarek Gawor regarding the Apache Aries implementation
>> issues.
>>
>> We (WSO2) use OSGi environment in our products and we utilize JNDI within
>> the OSGi framework. In order to achieve that we are in the process of
>> implementing JNDI services following OSGi specification. As a result we
>> have already implemented JNDI-Context Manager Service (section 126.3 in
>> specification).
>>
>> Next we hope to continue implementation to JNDI-Provider Admin service
>> and OSGi URL scheme. While implementing the OSGI-URL scheme (section
>> 126.6), I came across issues I have raised earlier in the mailing list.
>>
>> Thanks,
>> Nipuni
>>
>> On Thu, Mar 31, 2016 at 12:12 PM, Nipuni Piyabasi Perera <
>> nipuni880...@gmail.com> wrote:
>>
>>> Hi Christian,
>>>
>>> Thanks for the replies. (I received replies through the osgi-digest
>>> mail).
>>>
>>> Yes. I went through the Apache Aries implementation and I found some
>>> confusions and I wanted to clarify them with osgi-dev. Some of the examples
>>> are as follows:
>>>
>>> 1. Using osgi: scheme and servicelist path. "If this
>>> osgi:servicelist scheme is used from a lookup method then a Context
>>> object
>>> is returned instead of a service object" - specification page 508. Say we
>>> got a Context object from a URL (eg:
>>> context.lookup("osgi:servicelist/<interface-name>")). We again can call a
>>> lookup using the received context as below:
>>>
>>> *Context listContext =
>>> context.lookup("osgi:servicelist/<interface-name>");*
>>> *Object service = listContext.lookup(<some-parameter>)
>>> //what should be the parameters passed here?*
>>>
>>>
>>> As per the Apache Aries implementation, the parameters of the second
>>> lookup() method is a service id. So the OSGi service query will be perform
>>> reading the interface from the first URL (i.e
>>> *"osgi:servicelist/<interface-name>"*) and the service id from the
>>> second URL (i.e "*<some-parameter>*"). I could not find such
>>> description from the specification. (Correct me if I am wrong).
>>>
>>> 2. As per the Apache Aries implementation you can call list() and
>>> listbindings() methods for both "service" and "servicelist" paths. Both
>>> method calls directs to a same method which passes an empty string as the
>>> parameter to list() method [1]. Is this the expected behavior? (Or
>>> specification
>>> may not provide each and every implementation detail and developers might
>>> have to taken decisions while implementing.)
>>>
>>> [1]
>>> https://github.com/apache/aries/blob/trunk/jndi/jndi-url/src/main/java/org/apache/aries/jndi/url/ServiceRegistryContext.java#L63
>>>
>>> Thanks,
>>> Nipuni
>>>
>>> On Thu, Mar 31, 2016 at 9:40 AM, Nipuni Piyabasi Perera <
>>> nipuni880...@gmail.com> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Thanks for the replies. (I received replies through the osgi-digest
>>>> mail).
>>>>
>>>> Seems my second question is not much clear. Hence adding the same
>>>> question with more details below:
>>>>
>>>> 2. As per the specification, listBindings() and list() methods will
>>>> return NamingEnumeration objects. Do both "service" and "servicelist" paths
>>>> need to support aforementioned methods?
>>>> a. eg: context.list("osgi:service/<query>") is this a valid
>>>> statement ?
>>>> b. eg: context.list("osgi:servicelist/<query>") is this a valid
>>>> statement ?
>>>> c. If this(above (b)) is a valid scenario, does the Context object
>>>> need to obtain first, before doing list() and listbinding() queries?
>>>> (Please find a sample code below)
>>>>
>>>> Context context = jndiContextManager.newInitialContext();
>>>> Context listContext =
>>>> context.lookup("osgi:servicelist/org.my.jndi.osgi.services.FooService")
>>>>
>>>> - In a scenario as above, is it valid to pass two different names to
>>>> list() and lookup() methods (i.e
>>>> context.lookup("osgi:servicelist/SERVICE-A") and do a
>>>> context.list(osgi:servicelist/SERVICE-B)) ?
>>>> NamingEnumeration<NameClassPair> namingEnumeration =
>>>> listContext.list("osgi:service/org.my.jndi.osgi.services.FooService");
>>>>
>>>> - In a scenario as above say we received a context object with lookup
>>>> method.
>>>> Context listContext =
>>>> context.lookup("osgi:servicelist/<service-name>");
>>>>
>>>> We should be able to do lookup() calls with this received context
>>>> object. In such cases what should pass as the URL.
>>>> eg: is it "listContext.lookup("osgi:servicelist/<service-name>") or
>>>> listContext.lookup("<service-name>|<service-id>")"
>>>>
>>>> (I also have raised the queries in OSGi public Bugzilla)
>>>>
>>>> Thanks,
>>>> Nipuni
>>>>
>>>> On Wed, Mar 30, 2016 at 9:37 AM, Nipuni Piyabasi Perera <
>>>> nipuni880...@gmail.com> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Appreciate any response on the above questions.
>>>>>
>>>>> Thanks,
>>>>> Nipuni
>>>>>
>>>>> On Thu, Mar 24, 2016 at 8:05 PM, Nipuni Piyabasi Perera <
>>>>> nipuni880...@gmail.com> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I am trying to implement OSGI URL scheme support for JNDI following
>>>>>> the OSGI service specification[1]. While implementing the OSGI URL
>>>>>> scheme I
>>>>>> encountered following issues.
>>>>>> As per the specification, Following are the confusions I have:
>>>>>>
>>>>>> 1. A lookup with osgi:service path will return a service while a
>>>>>> servicelist path returns an context object. Does a query
>>>>>> "osgi:servicelist/" is valid? Or is it mandatory to have a query
>>>>>> followed
>>>>>> by the osgi:servicelist/ ?
>>>>>> 2. As per the specification, listBindings() and list() methods
>>>>>> will return NamingEnumeration objects. Do both "service" and
>>>>>> "servicelist"
>>>>>> paths need to support aforementioned methods?
>>>>>> 1. context.list("osgi:service/<qname>") is this a valid URL ?
>>>>>> 2. context.list(osgi:servicelist/<qname>) is this a valid URL ?
>>>>>> 1. If this is a valid scenario, does the Context object
>>>>>> need to obtain first before doing list() and listbinding()
>>>>>> queries? (Please
>>>>>> find a sample code below)
>>>>>> 2.
>>>>>>
>>>>>> Context context = jndiContextManager.newInitialContext();
>>>>>>
>>>>>> Context listContext =
>>>>>> context.lookup("osgi:servicelist/org.my.jndi.osgi.services.FooService")
>>>>>>
>>>>>> NamingEnumeration<NameClassPair> namingEnumeration =
>>>>>>
>>>>>>
>>>>>> listContext.list("osgi:service/org.wso2.carbon.jndi.osgi.services.FooService");
>>>>>>
>>>>>> 3.
>>>>>>
>>>>>> In a scenario as above, is it valid to pass two different names
>>>>>> to list() and lookup() methods (i.e
>>>>>> context.lookup("osgi:servicelist/SERVICE-A") and do a
>>>>>> context.list(osgi:servicelist/SERVICE-B)) ?
>>>>>>
>>>>>> 3. As per the specification we mainly support list(),
>>>>>> listbindings(), and lookup() methods. Can we consider the other
>>>>>> methods
>>>>>> such as bind(), rebind() , unbind() , rename() as operations that
>>>>>> are not
>>>>>> supported with the provider?
>>>>>>
>>>>>> Appreciate any input on above queries.
>>>>>>
>>>>>> [1] https://osgi.org/download/r6/osgi.enterprise-6.0.0.pdf
>>>>>> <https://www.osgi.org/developer/downloads/release-6/release-6-download/>
>>>>>>
>>>>>> Thanks,
>>>>>> Nipuni
>>>>>>
>>>>>> --
>>>>>> Nipuni Perera
>>>>>> Software Engineer; WSO2 Inc.; http://wso2.com
>>>>>> Email: nip...@wso2.com
>>>>>> Git hub profile: https://github.com/nipuni
>>>>>> Blog : http://nipunipererablog.blogspot.com/
>>>>>> Mobile: +94 (71) 5626680
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nipuni Perera
>>>>> Software Engineer; WSO2 Inc.; http://wso2.com
>>>>> Email: nip...@wso2.com
>>>>> Git hub profile: https://github.com/nipuni
>>>>> Blog : http://nipunipererablog.blogspot.com/
>>>>> Mobile: +94 (71) 5626680
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nipuni Perera
>>>> Software Engineer; WSO2 Inc.; http://wso2.com
>>>> Email: nip...@wso2.com
>>>> Git hub profile: https://github.com/nipuni
>>>> Blog : http://nipunipererablog.blogspot.com/
>>>> Mobile: +94 (71) 5626680
>>>>
>>>
>>>
>>>
>>> --
>>> Nipuni Perera
>>> Software Engineer; WSO2 Inc.; http://wso2.com
>>> Email: nip...@wso2.com
>>> Git hub profile: https://github.com/nipuni
>>> Blog : http://nipunipererablog.blogspot.com/
>>> Mobile: +94 (71) 5626680
>>>
>>
>>
>>
>> --
>> Nipuni Perera
>> Software Engineer; WSO2 Inc.; http://wso2.com
>> Email: nip...@wso2.com
>> Git hub profile: https://github.com/nipuni
>> Blog : http://nipunipererablog.blogspot.com/
>> Mobile: +94 (71) 5626680
>>
>> _______________________________________________
>> OSGi Developer Mail List
>> osgi-dev@mail.osgi.org
>> https://mail.osgi.org/mailman/listinfo/osgi-dev
>>
>
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.liquid-reality.de>
>
> Open Source Architect
> http://www.talend.com
> <https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
>
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
--
Sameera Jayasoma
blog: http://sameera.adahas.org
twitter: https://twitter.com/sameerajayasoma
flickr: http://www.flickr.com/photos/sameera-jayasoma/
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
