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
