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.
Unless I misunderstood, the OSGi container is only used for
classloading and want to hide it. However, if you try to hide the
OSGi stuff, the first time you'll have a resolution problem for a
bundle, you'll have a hard time explaining that to the user.
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.
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 ? 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, 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 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.
Usually, we are just hiding it if the user does not have its own OSGi
container.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
