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:23:39 GMT
And btw, disabling the bundle cache by using reference:xxx urls in the
activator should help to speed up the boot time and avoid most of the
disk writes (though not all I guess).

On Wed, May 11, 2011 at 16:14, Guillaume Nodet <gnodet@gmail.com> wrote:
> 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/
>



-- 
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