You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Pierre-Arnaud Marcelot <pa...@marcelot.net> on 2008/09/08 14:37:48 UTC
[Studio] [Shared] New low-level LDAP Protocol Connection Wrapper for Studio using the Shared classes?
Hi all,
I'd like to share a few discussions I've had these days with Stefan S. and
Emmanuel.
I was talking to Stefan on IM on friday and we were wondering how we could
improve the LDAP Browser and the Connection plugin.
Stefan would like to get rid of the use of JNDI in Studio because of the
problems we have with this API.
He enumerated a number of benefits to using a client "LDAP protocol"
oriented connection wrapper instead of the JNDI one:
- Direct access to the LDAP protocol
- Direct access to the result codes (we now must parse the
NamingException message)
- Access to the message ID
- Network settings (timeouts, etc.)
- Threading
- Referral handling (JNDI tries to be clever to manage referrals
internally, but we want to manage them manually)
- LdapDN handling is poor in JNDI
- You have to set weird environment variables to make it working properly
- JNDI has no cancel operation, you must use ctx.close() to cancel an
operation
We were wondering if the "Codec" classes in Shared would allow us to do such
a thing.
In the afternoon, I talked about this with Emmanuel who told me that most of
the classes of Shared could be reused easily but also that we might need to
add new ones (for SSL/SASL client authentication, or controls/extensions for
example).
He advised me to ask on the ML, so we can discuss things further and see
what can be done with what we have today, and what we nee to work on to
build this low-level LDAP protocol connection wrapper.
WDYT?
Thanks
Pierre-Arnaud
Re: [Studio] [Shared] New low-level LDAP Protocol Connection Wrapper
for Studio using the Shared classes?
Posted by Stefan Seelmann <se...@apache.org>.
Pierre-Arnaud Marcelot wrote:
> Hi guys,
>
> Yesterday, there was an interesting discussion with an Eclipse commiter
> (tech lead for PDE) about an LDAP communication layer on IRC
> (#apache_directory_dev).
>
> He wanted to know what kind of communication layer we are using in Studio.
> I told him we were using JNDI at the moment but we plan to move to a
> low-level LDAP Communication Layer.
>
> He explained that Eclipse has its own communications framework (ECF [1])
> and that ECF may take advantage of that as a provider implementation. It
> could be interesting to have a look at that for our both communities.
That's great, thanks for sharing this info.
Regards,
Stefan
Re: [Studio] [Shared] New low-level LDAP Protocol Connection Wrapper for Studio using the Shared classes?
Posted by Pierre-Arnaud Marcelot <pa...@marcelot.net>.
Hi guys,
Yesterday, there was an interesting discussion with an Eclipse commiter
(tech lead for PDE) about an LDAP communication layer on IRC
(#apache_directory_dev).
He wanted to know what kind of communication layer we are using in Studio.
I told him we were using JNDI at the moment but we plan to move to a
low-level LDAP Communication Layer.
He explained that Eclipse has its own communications framework (ECF [1]) and
that ECF may take advantage of that as a provider implementation. It could
be interesting to have a look at that for our both communities.
Here's the complete log of the conversation:
================================================================================
[19:00] zx: which LDAP library does Apache DS use to communicate with LDAP
servers?
[19:00] zx: I ask because some Eclipse.org projects are interested in the
communication layer used by Apache DS, we would like to reuse this library
if possible
[19:01] pajbam: by Apache DS you mean Studio or Server ?
[19:01] pajbam: Actually Apache DS is more the name of the server...
[19:02] zx: oh, Studio
[19:02] zx: I assume the library is available as a plug-in within Studio
since Studio is based on Eclipse RCP
[19:03] pajbam: Where using JNDI in Studio to communicate with LDAP servers
[19:03] pajbam: s/where/we're
[19:03] pajbam: that's the standard library bundled with the JVM
[19:04] pajbam: If you're looking for the code, it's in the connection-core
plugin (project)
[19:04] pajbam: we're planning to write a new low-level LDAP Protocol
communication Layer
[19:04] zx: excellent, I can browse there. I was under the assumption there
was something more magical at work here than just using standard JNDI
[19:05] pajbam: because JNDI has a few drawbacks
[19:05] pajbam: this new communication layer will be based on some classes
developped for Apache DS (the server)
[19:06] zx: very cool, we have a communications framework in Eclipse called
ECF that may take advantage of that as a provider implementation.
[19:06] pajbam: If you're instered, I started a thread about that on our Dev
ML
[19:06] pajbam: http://markmail.org/message/xr3lbkaozxx6tyvy
[19:06] zx: Thanks for your help
[19:07] zx: keep up the good work, you guys are one of the best Eclipse RCP
apps I've seen out there
[19:07] pajbam: "we" means you're from the Eclipse Foundation?
[19:08] pajbam: hehe thanks...
[19:08] zx: I'm an Eclipse committer (tech lead for PDE)
[19:08] zx: and amongst other things at Eclipse
[19:08] pajbam: cool
[19:09] pajbam: It's great to see you looking at what we're doing
[19:09] zx: you guys should reapply for the best open-source RCP app for
EclipseCon 2008 when the time comes
[19:09] zx: you were close last year
[19:09] pajbam: yeah,but we can't unfortunately
[19:09] pajbam: it's in the rules...
[19:09] zx: we will see about that
[19:10] pajbam: looool
[19:10] zx: I thought you couldn't win more than once :P, we'll see
[19:10] zx: we are doing planning for EclipseCon now and the topic will come
up in the future
[19:11] pajbam: Don't hesitate to come on our ML, I think we'd love to
collaborate more together
[19:11] pajbam: especially if Eclipse is interested in some kind of LDAP
Communication Layer
[19:11] elecharny: zx, is there a plan to integrate Studio in a future
eclipse package ?
[19:12] zx: pajbam: I will touch base with Scott Lewis from ECF (
http://www.eclipse.org/ecf/) , he would be interested in that topic as he is
the ECF lead
[19:12] zx: elecharny: we were interested in the LDAP communications piece
of Studio in some projects, but it seems everyone just uses standard JNDI
with the same weaknesses
[19:13] elecharny: yeah
[19:13] elecharny: I think we will switch to something more powerfull in the
next few months, as pajbam said
[19:13] elecharny: JNDI is so crappy ...
[19:13] pajbam: zx: OK, feel free to do it
[19:13] zx: elecharny: well, that would be up to you, I think if Apache
wanted to have a package at Eclipse.org for some of the tools relevant to
Apache than they can... or just DS in this case
[19:14] elecharny: zx, this is something we have to think about
================================================================================
Regards,
Pierre-Arnaud
[1] - http://www.eclipse.org/ecf/
On Mon, Sep 8, 2008 at 4:51 PM, Emmanuel Lecharny <el...@gmail.com>wrote:
> Hi guys,
>
> comments inline
>
> Alex Karasulu wrote:
>
>> Hi,
>>
>> On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <pa@marcelot.net
>> >wrote:
>>
>>
>>
>>> Hi all,
>>>
>>> I'd like to share a few discussions I've had these days with Stefan S.
>>> and
>>> Emmanuel.
>>>
>>>
>> We also have some discussion with Alex, and also Howard Chu during the
> last LdapCon in Köln last year, about a new Ldap API. Not to mention the
> convos we had with soem Sun peeps 2 years ago about a new JNDI-v2.
>
> It's cool to see that we are having this convo again !
>
>> I was talking to Stefan on IM on friday and we were wondering how we could
>>> improve the LDAP Browser and the Connection plugin.
>>> Stefan would like to get rid of the use of JNDI in Studio because of the
>>> problems we have with this API.
>>>
>>>
>> +1
>
>> He enumerated a number of benefits to using a client "LDAP protocol"
>>> oriented connection wrapper instead of the JNDI one:
>>>
>>> - Direct access to the LDAP protocol
>>> - Direct access to the result codes (we now must parse the
>>> NamingException message)
>>> - Access to the message ID
>>> - Network settings (timeouts, etc.)
>>> - Threading
>>> - Referral handling (JNDI tries to be clever to manage referrals
>>> internally, but we want to manage them manually)
>>> - LdapDN handling is poor in JNDI
>>> - You have to set weird environment variables to make it working
>>> properly
>>> - JNDI has no cancel operation, you must use ctx.close() to cancel an
>>> operation
>>>
>>>
>> plus poor Controls handling, poor Extended Operation handling, messy
> semantic for operation (JNDI Bind != LDAP Bind)...
>
>> We were wondering if the "Codec" classes in Shared would allow us to do
>>> such a thing.
>>>
>>>
>> Not pristine, but this is certainly a part of it. You have to combine it
> with the Entry API, a network layer, plus certainly clean these codec
> classes ;)
>
>> In the afternoon, I talked about this with Emmanuel who told me that most
>>> of the classes of Shared could be reused easily but also that we might
>>> need
>>> to add new ones (for SSL/SASL client authentication, or
>>> controls/extensions
>>> for example).
>>>
>>>
>> We must also make it easy to plug extensions and controls. ATM,
> encoding/decoding controls is, to say the least, a PITA. Sadly, I don't see
> how this could be done easily, but we must at least ease the integration of
> a new codec for a control or an extended operation.
>
>>
>>
>>> He advised me to ask on the ML, so we can discuss things further and see
>>> what can be done with what we have today, and what we nee to work on to
>>> build this low-level LDAP protocol connection wrapper.
>>>
>>> WDYT?
>>>
>>>
>>>
>>
>> I think we're talking about writing a modern LDAP API similar in nature to
>> the Netscape API to replace JNDI. JNDI could use this API if it wanted to
>> as well but this is a less abstract, more specific API for LDAP. The more
>> specific the API is the less surface area it will have. The better it is
>> to
>> comprehend and test.
>>
>>
> yep.
>
>> I like the idea of doing this and leveraging the Entry API Emmanuel has
>> written to do so. It will be nice to have it align with things we use in
>> Shared to save us the head ache and overhead of converting from one object
>> type to another for example.
>>
>>
> Certainly ! And will help also to get more people around this portion of
> the code.
>
>> This is value. If you guys decide to embark on it then I would like to
>> help
>> and get involved too.
>>
>>
> me too.
>
>> We might have some issues with the codec but we can fix that as we go.
>>
>>
> Yep.
>
> I would also add that there are a few things around there which could be
> looked at :
>
> https://opends.dev.java.net/public/standards/draft-ietf-ldapext-ldap-java-api.txt
>
> and some discussion with the OpenLdap guys would be very interesting.
>
> Thanks for bringing this subject back on the table !
>
>> Alex
>>
>>
>>
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: [Studio] [Shared] New low-level LDAP Protocol Connection Wrapper
for Studio using the Shared classes?
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi guys,
comments inline
Alex Karasulu wrote:
> Hi,
>
> On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:
>
>
>> Hi all,
>>
>> I'd like to share a few discussions I've had these days with Stefan S. and
>> Emmanuel.
>>
We also have some discussion with Alex, and also Howard Chu during the
last LdapCon in Köln last year, about a new Ldap API. Not to mention the
convos we had with soem Sun peeps 2 years ago about a new JNDI-v2.
It's cool to see that we are having this convo again !
>> I was talking to Stefan on IM on friday and we were wondering how we could
>> improve the LDAP Browser and the Connection plugin.
>> Stefan would like to get rid of the use of JNDI in Studio because of the
>> problems we have with this API.
>>
+1
>> He enumerated a number of benefits to using a client "LDAP protocol"
>> oriented connection wrapper instead of the JNDI one:
>>
>> - Direct access to the LDAP protocol
>> - Direct access to the result codes (we now must parse the
>> NamingException message)
>> - Access to the message ID
>> - Network settings (timeouts, etc.)
>> - Threading
>> - Referral handling (JNDI tries to be clever to manage referrals
>> internally, but we want to manage them manually)
>> - LdapDN handling is poor in JNDI
>> - You have to set weird environment variables to make it working
>> properly
>> - JNDI has no cancel operation, you must use ctx.close() to cancel an
>> operation
>>
plus poor Controls handling, poor Extended Operation handling, messy
semantic for operation (JNDI Bind != LDAP Bind)...
>> We were wondering if the "Codec" classes in Shared would allow us to do
>> such a thing.
>>
Not pristine, but this is certainly a part of it. You have to combine it
with the Entry API, a network layer, plus certainly clean these codec
classes ;)
>> In the afternoon, I talked about this with Emmanuel who told me that most
>> of the classes of Shared could be reused easily but also that we might need
>> to add new ones (for SSL/SASL client authentication, or controls/extensions
>> for example).
>>
We must also make it easy to plug extensions and controls. ATM,
encoding/decoding controls is, to say the least, a PITA. Sadly, I don't
see how this could be done easily, but we must at least ease the
integration of a new codec for a control or an extended operation.
>
>> He advised me to ask on the ML, so we can discuss things further and see
>> what can be done with what we have today, and what we nee to work on to
>> build this low-level LDAP protocol connection wrapper.
>>
>> WDYT?
>>
>>
>
> I think we're talking about writing a modern LDAP API similar in nature to
> the Netscape API to replace JNDI. JNDI could use this API if it wanted to
> as well but this is a less abstract, more specific API for LDAP. The more
> specific the API is the less surface area it will have. The better it is to
> comprehend and test.
>
yep.
> I like the idea of doing this and leveraging the Entry API Emmanuel has
> written to do so. It will be nice to have it align with things we use in
> Shared to save us the head ache and overhead of converting from one object
> type to another for example.
>
Certainly ! And will help also to get more people around this portion of
the code.
> This is value. If you guys decide to embark on it then I would like to help
> and get involved too.
>
me too.
> We might have some issues with the codec but we can fix that as we go.
>
Yep.
I would also add that there are a few things around there which could be
looked at :
https://opends.dev.java.net/public/standards/draft-ietf-ldapext-ldap-java-api.txt
and some discussion with the OpenLdap guys would be very interesting.
Thanks for bringing this subject back on the table !
> Alex
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: [Studio] [Shared] New low-level LDAP Protocol Connection Wrapper for Studio using the Shared classes?
Posted by Alex Karasulu <ak...@apache.org>.
Hi,
On Mon, Sep 8, 2008 at 8:37 AM, Pierre-Arnaud Marcelot <pa...@marcelot.net>wrote:
> Hi all,
>
> I'd like to share a few discussions I've had these days with Stefan S. and
> Emmanuel.
>
> I was talking to Stefan on IM on friday and we were wondering how we could
> improve the LDAP Browser and the Connection plugin.
> Stefan would like to get rid of the use of JNDI in Studio because of the
> problems we have with this API.
> He enumerated a number of benefits to using a client "LDAP protocol"
> oriented connection wrapper instead of the JNDI one:
>
> - Direct access to the LDAP protocol
> - Direct access to the result codes (we now must parse the
> NamingException message)
> - Access to the message ID
> - Network settings (timeouts, etc.)
> - Threading
> - Referral handling (JNDI tries to be clever to manage referrals
> internally, but we want to manage them manually)
> - LdapDN handling is poor in JNDI
> - You have to set weird environment variables to make it working
> properly
> - JNDI has no cancel operation, you must use ctx.close() to cancel an
> operation
>
> We were wondering if the "Codec" classes in Shared would allow us to do
> such a thing.
>
Great because we need this API for virtualization and possibly delegated
authentication as well within the server.
>
> In the afternoon, I talked about this with Emmanuel who told me that most
> of the classes of Shared could be reused easily but also that we might need
> to add new ones (for SSL/SASL client authentication, or controls/extensions
> for example).
>
Yeah.
>
> He advised me to ask on the ML, so we can discuss things further and see
> what can be done with what we have today, and what we nee to work on to
> build this low-level LDAP protocol connection wrapper.
>
> WDYT?
>
I think we're talking about writing a modern LDAP API similar in nature to
the Netscape API to replace JNDI. JNDI could use this API if it wanted to
as well but this is a less abstract, more specific API for LDAP. The more
specific the API is the less surface area it will have. The better it is to
comprehend and test.
I like the idea of doing this and leveraging the Entry API Emmanuel has
written to do so. It will be nice to have it align with things we use in
Shared to save us the head ache and overhead of converting from one object
type to another for example.
This is value. If you guys decide to embark on it then I would like to help
and get involved too.
We might have some issues with the codec but we can fix that as we go.
Alex