directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: OSGi startup and shutdown problems
Date Wed, 11 May 2011 14:14:08 GMT
On Wed, May 11, 2011 at 15:42, Alex Karasulu <akarasulu@apache.org> wrote:
> Thanks Guillaume for your thoughts. Responding in this post to both of you
> in line ...
>
> On Wed, May 11, 2011 at 12:19 PM, Emmanuel Lecharny <elecharny@gmail.com>
> wrote:
>>
>> On 5/11/11 10:47 AM, Guillaume Nodet wrote:
>>>
>>> Just my thoughts, as I had a discussion with Emmanuel yesterday on
>>> this subject.  I must admit I don't know directory very much, so maybe
>>> I'm off track.
>>>
>
> No worries, we work with ApacheDS a lot and sometimes we're really off track
> :).
>
>>>
>>> Unless I misunderstood, the OSGi container is only used for
>>> classloading and want to hide it.
>
> I don't think we want to hide it.
> I guess to put it as simply as possible, we want to make it so users can
> extend the API to add new controls and extended requests. We need a
> modularity layer for this.
>
>>>
>>> However, if you try to hide the
>>> OSGi stuff,
>
> By "hide the OSGi stuff", do you mean embed the OSGi container in the
> application?

Looking at the current api, an average user that does not use OSGi
won't see the fact that an embedded Felix is launched and it has no
access to it anyway, so that's what I mean by hidden.

>>>
>>> the first time you'll have a resolution problem for a
>>> bundle, you'll have a hard time explaining that to the user.
>>>
>
> Yep.
>
>>>
>>> Let's take a simple example.  I see in your code at
>>>
>>> https://github.com/apache/directory-shared/blob/trunk/ldap/codec/standalone/src/main/java/org/apache/directory/shared/ldap/codec/standalone/StandaloneLdapCodecService.java
>>
>> This part of the code is really a bad hack, we are supposed to deduce the
>> versions to use from some configuration file.
>
> Yes this needs some TLC. It was more an experiment to see how embedding the
> container will manifest itself. We need some more precautionary code and
> better handling treating the system packages exported to a minimum.
>
>>>
>>> that you export the slf4j pacakge in version 1.6.0 from the system
>>> bundle.   What if a user start using a [1.6.1,2) range when importing
>>> that package ?
>
> Do you mean to say the user, writes and added a new bundle for an extension,
> and the extension bundle depends on slf4j 1.6.1 for example?

Yes

>
>>>
>>> That will happen as soon as he's using the latest
>>> version of slf4j in its maven dependencies (and people tend to upgrade
>>> to latest version).    In that case, felix will start up correctly and
>>> you won't see any problem,
>
> Should we see a problem in the scenario you're describing?

If you load the above bundle, it will be missing the slf4j 1.6.1
package (as the system bundle only provides 1.6.0).  So the resolution
will fail.
But reading the code again, I think an exception should be thrown when
in #setupFelix() when executing the activator, right ?

>
>>>
>>> unless you're monitoring the bundles state
>>> to check that everything has been resolved, etc...
>>
>> Plain agree. We have to fix this part.
>
> I'm not sure I fully understand this scenario yet.


>>>
>>> I'm not saying OSGi is bad, I'm using it everyday and it's really
>>> powerful.  But I've also learned that it's not a simple container to
>>> manage.   I'm not sure hiding it will really work at the end.
>
>
> Again do you [Guillaume] mean embedding a OSGi container when you say
> hiding?

Yes, embedding but not giving the user access to it.

Other possible problems are that OSGi does not work in some
environments like Google App Engine for example, because it needs
access to the file system.

I'm quite sure I haven't fully grasped what the use case is (i.e. when
/ how / who will people develop and use those bundles / extensions),
but a simple URLClassLoader would look like a way easier solution to
me when not in OSGi.   If that cause problem, you could always say:
well, OSGi solves those problems so you should use it and the code is
able to leverage it.

I guess I'm just missing the use cases to understand that this could
be a good solution, as I don't even see where the bundles loaded are
used at all


>>
>> Usually, we are just hiding it if the user does not have its own OSGi
>> container.
>>
>
> Please clarify.
> Thanks,
> Alex



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Connect at CamelOne May 24-26
The Open Source Integration Conference
http://camelone.com/

Mime
View raw message