On 10/20/11 12:06 PM, Alex Karasulu wrote:
On Thu, Oct 20, 2011 at 12:43 PM, Guillaume Nodet<[email protected]> 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.
Those codec are not supposed to be written by external users. This is
just fine to keep them as they are. We can even make them plain OSGi
services at some point. In any case, this is a non issue.
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?
Correct, sir !
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?
Aye aye, sir !
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?
Nope, this is exactly the problem we have : be able to class-load those
schema extensions the ol' Java way (ie, class.forName() )
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.
Seems currently to be the only path we can use. We may ask on Felix's
mailing list to see if there is some other way, but I trust Guillaume here.
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.
Yeah...
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.
can you be a bit more explicit here, for people like me who ae
semi-OSGi-agnostic ?
(damn, I *knew* I should have jumped into the OSGi wagon one year ago,
at least... That's the problem when beig lazzy :/ )
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 ;).
Purity is good for virgins. We aren't...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
