directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: [API] Experimenting OSGI fragments to solve the extensibility issue
Date Thu, 20 Oct 2011 10:06:46 GMT
On Thu, Oct 20, 2011 at 12:43 PM, Guillaume Nodet <gnodet@gmail.com> wrote:

> I think you first need to define your constraints and what you want to
> focus on.
>

Excellent point so let's recap a little. In the API we have certain
functionality extension points:

1). Codec Extensions

These extension points are for adding support LDAP extended operation and
LDAP control support so the API can handle them explicitly as structured
elements rather than opaque unstructured data. This is pretty well defined
and understood by the Directory Team I think and we opted for using a
non-OSGi based ClassLoader mechanism. If this has changed please correct me.

2). LDAP Schema

Now from what I understand enabling new schema on clients via the API is the
main issue introducing additional constraints requiring us to consider the
use of fragments.

Is this correct?

Another part of the problem is making this work in both a non-OSGi client
side API environment in addition to an OSGi based environment in both
ApacheDS and Studio.

Is this correct?

Also we had some conversations in the past of not actually using OSGi to
load schema into the API. Sorry I don't have a email reference to the past
thread. Did our position change on this topic in the recent past?

If you want someone to be able to write a jar to extend the api which will
> work in a non osgi environment and (with minimal changes) in an osgi
> environment, go for fragments.
>

Forgive me, but the fragment approach seems like a hack. Fragments were
created in OSGi to handle intractable problems with split packages where you
had no way to merge the split. Now we're using it as a main stream feature
to work around these hairy issues. Please note that I am not saying we
should abandon it, just playing devil's advocate here. We obviously need
more thought on the constraints which you've made very apparent here in your
post. Thanks for it.

If you want to go a cleaner osgi way, go for services, but forget about
> class names in the schema directly, and you need to define two different
> ways, one for osgi and one in a non osgi environment (as you won't have osgi
> services at all in a flat classloader).
>
> It's all about trade-offs.
>
>
Right.


> When talking with Emmanuel this week, it seems to me that for the api,
> extending the api was not a very common operation and did not really require
> the osgi dynamism.  Fragments are perfect for those simple use cases.
>

Yes but the extension should not happen in the same package. Hence we're
using this feature for something it was not intended for. Again just
pointing this out, not saying it's not ideal. Perhaps this is fact is not at
all that important in the end.


> But for sure, if you ask an OSGi purist, the recommandation will be to not
> use fragments.
>
>
Right and maybe we should not be purists ;).

Regards,
Alex


> On Thu, Oct 20, 2011 at 11:29, Alex Karasulu <akarasulu@apache.org> wrote:
>
>> Excuse the pre post but my comment is somewhat general. Overall the Felix
>> and general OSGi community considers fragments as a problematic construct in
>> the specification: something they recommend you avoid but if stuck you can
>> use. It's use is discouraged.
>>
>>
>> On Wed, Oct 19, 2011 at 6:36 PM, Pierre-Arnaud Marcelot <pa@marcelot.net>wrote:
>>
>>> Hi Dev,
>>>
>>> Following our efforts on the OSGI side, I took some time to think about
>>> (and experiment) how we could solve our extensibility issue on the LDAP API,
>>> where we want our users to be able to provide their own custom
>>> implementation of various schema objects like comparators, normalizers, etc.
>>>
>>> After a quick discussion with Emmanuel and Guillaume Nodet, it turned out
>>> using OSGI fragments bundles could probably be our best solution.
>>>
>>> Here's a definition of what an OSGI fragment bundle is (more information
>>> available at [1]):
>>> "An OSGi fragment is a Java archive file with specific manifest headers
>>> that enable it to attach to a specified host bundle or specified host
>>> bundles in order to function.
>>> Fragments are treated as part of the host bundles. Relevant definitions
>>> of the fragment are merged with the host bundles definitions before the host
>>> is resolved, as long as the information does not conflict.
>>> Fragment dependencies are resolved if possible. If the fragment
>>> dependencies can not be resolved, the fragment does not attach to the host
>>> bundle.
>>> A fragment can not have its own class loader or bundle activator. It can
>>> not override the information present in the host bundles. Fragments extend
>>> bundles with resources, classes, and permitted headers enabling you to
>>> customize your bundles."
>>>
>>> The great thing about fragments is that they *share* the same class
>>> loader as their host bundle. Which was pretty much the kind of issue we were
>>> having with classloaders being differents from one bundle to the other.
>>>
>>> The other great thing I see with this approach, it that it would also
>>> work great outside of an OSGI container application (which is a strong
>>> requirement for the LDAP API). A fragment bundle is nothing else than a
>>> regular bundle with a specific OSGI directive (Fragment-Host) added to its
>>> MANIFEST.MF file, and a bundle behaves exactly like a plain jar file when
>>> it's not included in an OSGI container. Thus, it would allow us to support
>>> third parties extensions.
>>>
>>> I have done a small experiment in my Eclipse workspace with two bundles
>>> (one being the host and the other being the fragment ) and I was able to
>>> classload, without any classloader issue, a class defined in the fragment
>>> bundle from another class inside the host bundle.
>>>
>>> I'd like to go a step further and experiment this on the API itself.
>>>
>>> Ideally, I'd like to use the 'shared-ldap-model' module
>>> ('org.apache.directory.shared.ldap.model' bundle) as a host for all our
>>> schema objects implementations and move these implementations into a
>>> specific fragment bundle containing them all.
>>> Users would have to do the same to include their extensions. A simple
>>> fragment bundle with the 'org.apache.directory.shared.ldap.model' bundle as
>>> host and it works.
>>>
>>> One other thing that should be done, is to let the 'shared-ldap-model'
>>> module do the instanciation of the schema elements. At the moment, two
>>> classes from the 'shared-ldap-schema-data' module are responsible for this,
>>> 'org.apache.directory.shared.ldap.schemaloader.SchemaEntityFactory' and
>>> 'org.apache.directory.shared.ldap.schemaloader.AttributeClassLoader'. We
>>> would need to move these classes to the 'shared-ldap-model' module, for them
>>> to have access to the right class loader.
>>>
>>> All in all, I think that's the only things we need to do to get the
>>> extensibility we wanted inside and outside an OSGI container.
>>>
>>> What do you think of this plan?
>>>
>>> Regards,
>>> Pierre-Arnaud
>>>
>>> [1] -
>>> http://publib.boulder.ibm.com/infocenter/radhelp/v8/index.jsp?topic=/com.ibm.osgi.common.doc/topics/cbundlefragment.html
>>>
>>
>>
>>
>> --
>> Best Regards,
>> -- Alex
>>
>>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>


-- 
Best Regards,
-- Alex

Mime
View raw message