On 10/20/11 1:19 PM, Göktürk Gezer wrote:
Hi All,
I see lots of discussions took place. So i would like to say some more.
On Thu, Oct 20, 2011 at 1:58 PM, Emmanuel Lécharny<[email protected]>wrote:
On 10/20/11 12:33 PM, Alex Karasulu wrote:
On Thu, Oct 20, 2011 at 1:18 PM, Emmanuel Lecharny<[email protected]>**
wrote:
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.
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.
It didn't take much attention as i see, but we handled that topic yesterday
:) I think preserving the shared api ıs a must. And if we want to provide a
mechanism that can work on both OSGI and nonOSGI environment, fragments is
not an option, it is a must too. But everybody is missing something here. By
using fragments, we're not adding any new extension point other than it
already provided. It is just a way to polish our looking in OSGI
environment.for nonOSGI environment everything will be just same,hard.
So the aim of the code i currently patched is to show we can seperate OSGI
and nonOSGI environments.
When launched inside an OSGI, that code creates the necessary listeners for
new Comparator addition, in OSGI way using Service registrations. And use
them internally.
When it is launched outsıde the OSGI, it does not change anything and
somebody can provide their extension as fragment or plain jar at all.
So while providing fragment extensions out of the box, we also create an
extra OSGI extension point right now(for Comparators) So we provide 2 main
way. Its developer's choice to choose which one.
Ok, get it now. Thanks for the clarification.
I must suggest some other idea that will change the way we think. We can
embed OSGI inside shared. By embedding i really mean embedding. So our
shared api launchs its own OSGI framework and its own extension points. so
whether it is launched in or out of OSGI environment, it will have its own
execution context. And we provide that context just for extensions. It might
work like that too. But if you ask me, i say it is not necessary.
We did that months a go, intergrating Felix in the API. We decided it
was not a good idea (don't remember extacly why). In any case, we
removed felix from the API.Göktürk
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
