On 10/20/11 12:33 PM, Alex Karasulu wrote:
On Thu, Oct 20, 2011 at 1:18 PM, Emmanuel Lecharny<elecha...@gmail.com>wrote:
On 10/20/11 12:06 PM, Alex Karasulu wrote:
On Thu, Oct 20, 2011 at 12:43 PM, Guillaume Nodet<gno...@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.
Those codec are not supposed to be written by external users.
I disagree with the this statement above. If codec extensions are not to be
written by non-API committers then why are we going to all this trouble
class loading them and making them pluggable?
That's a good question. The problem is that in some case, and mostly on
the API, one codec for an extended operation *might* have different
implementations depending on the targeted software (and we probably can
thank M$ for such a mess).
Our users might want to implement a control using our API for an LDAP server
which exposes controls or extended operations which we have not supported.
This provides a means for them to extend our API and achieve their goals.
Well, assuming that writing a codec is not frankly easy, I'd rather have
a request and write it myself...
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 !
Since when was I knighted by the Queen :-D.
Well, I was more thinking about Full Metal Jacket, here :)
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() )
Sorry to beat a dead horse here but OK so we are not trying to use OSGi for
loading schema in all environments: client API, apacheds, and studio?
If we can have a solution that cover the three cases, I buy it. If we
have to class load the Java way schema element because the API will be
used outside of an OSGi container, then be it.
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.
This is not a trust issue with anyone.
Well, when I wrote 'I trust Guillaume', that does not mean I don't trsut
you. It's just that I have not the background to dispute his knowledge.
It's a matter of exploration and lack
of being up to date on my part. Hope no one misinterprets my questions as a
lack of trust. I'm finding discrepancies in what I learned in the past with
the proposed direction today and asking about it.
I must admit that I'm more a lurker than an actor of this discussion. I
can just brng some light on what we currently have, and the needs that
we have.
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 :/ )
> From my limited understanding the fragments feature was created to handle
situations when you had split packages but could not merge those packages
because you did not have access to the code or some sh*t like that.
These extensions should not be in the same package space. Those adding
schema or other extensions should not be adding them into the same packages
used by the API. In that case my logic leads me to the question: why use
fragments?
I'm not sure that simply declaring extensions in a different package is
enough. It seems more like a class-loader and visibility issue in this
case, AFAIU.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
