python-ldap-dev — discussion among developers

Re: python-ldap and asyncore

[Hiroki S. <sak...@gm...>]

On 3/1/07, "Michael Str=F6der" <mi...@st...> wrote:
> On 5:55:55 pm 2007-02-28 "Hiroki Sakagami" <sak...@gm...> wrote:
> >
> > Thank you for your reply.  So, I can get the socket object by adding
> > such a method manually. Is there any chance there will be support for
> > LDAP_OPT_DESC in future python-ldap?
>
> Feel free to submit a patch.

OK, I'm going to try to implement it.

--
Hiroki Sakagami

Re: python-ldap and asyncore

[<mi...@st...>]

Hiroki Sakagami wrote:
> 
> Thank you for your reply.  So, I can get the socket object by adding
> such a method manually. Is there any chance there will be support for
> LDAP_OPT_DESC in future python-ldap?

Not sure what you mean with "socket object". Let's read
http://www.openldap.org/lists/openldap-software/200102/msg00290.html
once again:

"You can use ldap_get_option(ld, LDAP_OPT_DESC, &sd) to access
the primary file descriptor associated with a session handle."

This function of the OpenLDAP C SDK returns just the OS' file
descriptor. I never worked with asyncore. Not sure what you need.

Ciao, Michael.

Re: python-ldap and asyncore

[<mi...@st...>]

On 5:55:55 pm 2007-02-28 "Hiroki Sakagami" <sak...@gm...> wrote:
>
> Thank you for your reply.  So, I can get the socket object by adding
> such a method manually. Is there any chance there will be support for
> LDAP_OPT_DESC in future python-ldap?

Feel free to submit a patch.

Ciao, Michael.

Re: python-ldap and asyncore

[Hiroki S. <sak...@gm...>]

Hi,

Thank you for your reply.  So, I can get the socket object by adding
such a method manually. Is there any chance there will be support for
LDAP_OPT_DESC in future python-ldap?

--
Hiroki Sakagami

On 2/27/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> > On 2/20/07, Hiroki Sakagami <sak...@gm...> wrote:
> >> Hi,
> >>
> >> I'm trying to use python-ldap with asyncore event loop.  Since
> >> asyncore's event source is a socket object, I can't use search() and
> >> result() style polling.  Is it possible to access a socket object in
> >> the LDAPObject instance?
> >
> > http://www.openldap.org/lists/openldap-software/200102/msg00290.html
> >
> > hope this help
>
> One would have to patch Modules/options.c and Modules/constants.c for
> this to theoretically work.
>
> Ciao, Michael.
>

Re: peculiar problem

[<mi...@st...>]

Anil Jangity wrote:
> I notice this in other areas of my code as well.
> 
> Here is a trace of a modify:
> 
> *** ldap://host:389 - SimpleLDAPObject.modify_ext (('cn=Shilpa J,
> uid=anilj, ou=People, o=entic.net', [(0, 'mail',
> [u'shi...@so...'])], None, None),{})
> Error - <type 'exceptions.TypeError'>: ('expected a string in the
> list', u'shi...@so...')
> 
> 
> The problem is, it seems work on and off. When the modifications or
> searches are done without the unicode string,  it works. But later
> when I try to do the same thing again for some reason it trys to do
> the LDAP operation using unicode lists: [u'abc']
> 
> Thats when it fails.

You have to pass solely raw strings to python-ldap since the API does
not handle Unicode strings automatically.

 u'shi...@so...'.encode('utf-8')

Ciao, Michael.

Re: peculiar problem

[Anil J. <an...@en...>]

I notice this in other areas of my code as well.

Here is a trace of a modify:

*** ldap://host:389 - SimpleLDAPObject.modify_ext (('cn=3DShilpa J,
uid=3Danilj, ou=3DPeople, o=3Dentic.net', [(0, 'mail',
[u'shi...@so...'])], None, None),{})
Error - <type 'exceptions.TypeError'>: ('expected a string in the
list', u'shi...@so...')


The problem is, it seems work on and off. When the modifications or
searches are done without the unicode string,  it works. But later
when I try to do the same thing again for some reason it trys to do
the LDAP operation using unicode lists: [u'abc']

Thats when it fails.

Is it something else in my code that is causing it or is something
else wrong in the python-ldap?

I'll see if I can find more details/code. I was just wondering if you
guys knew off the top of your heads...





On 2/25/07, Michael Str=F6der <mi...@st...> wrote:
> Anil Jangity wrote:
> >
> > url =3D ''.join((self.server, base, '?', attr, '?', scope, '?', filter,=
 '?'))
> > try:
> >     print url
> >     ldap_url =3D ldapurl.LDAPUrl(url)
>
> BTW: See also 2nd example on
>
> http://python-ldap.sourceforge.net/doc/python-ldap/ldapurl-example.html
>
> Ciao, Michael.
>

Re: python-ldap and asyncore

[<mi...@st...>]

Alain Spineux wrote:
> On 2/20/07, Hiroki Sakagami <sak...@gm...> wrote:
>> Hi,
>>
>> I'm trying to use python-ldap with asyncore event loop.  Since
>> asyncore's event source is a socket object, I can't use search() and
>> result() style polling.  Is it possible to access a socket object in
>> the LDAPObject instance?
>
> http://www.openldap.org/lists/openldap-software/200102/msg00290.html
>
> hope this help

One would have to patch Modules/options.c and Modules/constants.c for
this to theoretically work.

Ciao, Michael.

Re: peculiar problem

[<mi...@st...>]

Anil Jangity wrote:
> 
> url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?'))
> try:
>     print url
>     ldap_url = ldapurl.LDAPUrl(url)

BTW: See also 2nd example on

http://python-ldap.sourceforge.net/doc/python-ldap/ldapurl-example.html

Ciao, Michael.

Re: peculiar problem

[<mi...@st...>]

Anil Jangity wrote:
> (thanks for all the help in my previous posts)
> 
> Hi,
> 
> I am seeing a peculiar problem in this area of the code. I don't know
> exactly how to reproduce it. It almost like I have to wait a while and
> I see this problem.
> 
> url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?'))
> try:
>     print url
>     ldap_url = ldapurl.LDAPUrl(url)
>     print ldap_url.attrs
>     print attr
> except ValueError:
>     print "Bad URL"
> 
> The output is:
> 
> ldap://somehost.com:389/ou=People, o=entic.net?uid?one?mail=an...@en...?
> [u'uid']
> uid
> Error - <type 'exceptions.TypeError'>: ('expected string in list', u'uid')

I can't reproduce the error since you didn't provide enough code.

But this simply works regarding module ldapurl:

>>> u=u'ldap://somehost.com:389/ou=People,
o=entic.net?uid?one?mail=an...@en...?'
>>> ldap_url=ldapurl.LDAPUrl(u)
>>> ldap_url.attrs
[u'uid']

Ciao, Michael.

peculiar problem

[Anil J. <an...@en...>]

(thanks for all the help in my previous posts)

Hi,

I am seeing a peculiar problem in this area of the code. I don't know
exactly how to reproduce it. It almost like I have to wait a while and
I see this problem.

url = ''.join((self.server, base, '?', attr, '?', scope, '?', filter, '?'))
try:
    print url
    ldap_url = ldapurl.LDAPUrl(url)
    print ldap_url.attrs
    print attr
except ValueError:
    print "Bad URL"

The output is:

ldap://somehost.com:389/ou=People, o=entic.net?uid?one?mail=an...@en...?
[u'uid']
uid
Error - <type 'exceptions.TypeError'>: ('expected string in list', u'uid')


I am not sure if this is with my Pylons (web development framework) or
something specific to python-ldap.

Let me know if you can give me pointers on how I can try to troubleshoot this.

Thanks,
Anil

Re: python-ldap and asyncore

[Alain S. <asp...@gm...>]

http://www.openldap.org/lists/openldap-software/200102/msg00290.html

hope this help

On 2/20/07, Hiroki Sakagami <sak...@gm...> wrote:
> Hi,
>
> I'm trying to use python-ldap with asyncore event loop.  Since
> asyncore's event source is a socket object, I can't use search() and
> result() style polling.  Is it possible to access a socket object in
> the LDAPObject instance?
>
> Regards,
>
> --
> Hiroki Sakagami
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>


-- 
--
Alain Spineux
aspineux gmail com
May the sources be with you

python-ldap and asyncore

[Hiroki S. <sak...@gm...>]

Hi,

I'm trying to use python-ldap with asyncore event loop.  Since
asyncore's event source is a socket object, I can't use search() and
result() style polling.  Is it possible to access a socket object in
the LDAPObject instance?

Regards,

--
Hiroki Sakagami

Re: Newbie and encoding

[Jean-Philippe T. <jph...@fr...>]

On Mon, 19 Feb 2007 12:04:46 +0100
Michael Ströder <mi...@st...> wrote:

> jph...@fr... wrote:
> > 
> > I can not use 8 bits chars in search or add functions while I
> > have no issue with these characters in Luma :-( It seems to be related to string
> > encoding. Luma makes an intensive use of the "unicode" function. So I tried that
> > piece of code but without success:
> > 
> >>>> import ldap
> >>>> CON=ldap.open('localhost.localdomain')
> >>>> CON.simple_bind_s('','')
> >>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th�*)')
> 
> You have to pass raw strings to python-ldap since the API does not
> handle Unicode strings automatically.
> 
> So something like u'(cn=th�*)'.encode('utf-8').
> 
> Not sure what the � is in your e-mail though. Therefore I'd recommend
> not to directly write 8-bit chars into the Python source code. Rather
> use the escaping \x..
> 
> Complete example with my last name within Python shell and shell charset
> being UTF-8.
> 
> Python 2.5 (r25:51908, Nov 27 2006, 19:14:46)
> [GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> ustr=unicode('Ströder','utf-8')
> >>> ustr
> u'Str\xf6der'
> >>> ustr.encode('utf-8')
> 'Str\xc3\xb6der'
> >>>
> 
> Ciao, Michael.
> 
Thanks to you (and Bjorn ;-)). It works far better now. Life would have been far easier if English was full of strange chars :-)

Jean-Philippe

Re: Newbie and encoding

[<mi...@st...>]

jph...@fr... wrote:
> 
> I can not use 8 bits chars in search or add functions while I
> have no issue with these characters in Luma :-( It seems to be related to string
> encoding. Luma makes an intensive use of the "unicode" function. So I tried that
> piece of code but without success:
> 
>>>> import ldap
>>>> CON=ldap.open('localhost.localdomain')
>>>> CON.simple_bind_s('','')
>>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th�*)')

You have to pass raw strings to python-ldap since the API does not
handle Unicode strings automatically.

So something like u'(cn=th�*)'.encode('utf-8').

Not sure what the � is in your e-mail though. Therefore I'd recommend
not to directly write 8-bit chars into the Python source code. Rather
use the escaping \x..

Complete example with my last name within Python shell and shell charset
being UTF-8.

Python 2.5 (r25:51908, Nov 27 2006, 19:14:46)
[GCC 4.1.2 20061115 (prerelease) (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> ustr=unicode('Ströder','utf-8')
>>> ustr
u'Str\xf6der'
>>> ustr.encode('utf-8')
'Str\xc3\xb6der'
>>>

Ciao, Michael.

Re: Newbie and encoding

[Bjorn O. G. <bjo...@it...>]

jph...@fr...:
> Hi,
> 
> I was used to work with phpldapadmin, then discovered luma. Now I need something
> more specific to my needs, and thus interested in python-ldap.
> 
> Starting was really easy :-) Unfortunately, I discovered a bug in my application
> this week-end: I can not use 8 bits chars in search or add functions while I
> have no issue with these characters in Luma :-( It seems to be related to string
> encoding. Luma makes an intensive use of the "unicode" function. So I tried that
> piece of code but without success:
> 
> >>> import ldap
> >>> CON=ldap.open('localhost.localdomain')
> >>> CON.simple_bind_s('','')
> >>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th?)')

<snip>

> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6:
> ordinal not in range(128)

LDAP uses utf8 - so convert any umlauts or whatever to utf8 before doing a query.
Mostly anything can be converted _to_ utf8, but not will convert back to the 
encoding you came from. 

def utf8_encode(str):
    return unicode(str, "iso-8859-1").encode("utf-8")

def utf8_decode(str):
    return unicode(str, "utf-8").encode("iso-8859-1")

Usage:
filter = utf8_encode('cn=Bjørn Ove Grøtan')

Just change from iso-8859-1 to whatever encoding you use by default.

--
Regards
 
Bjørn Ove Grøtan
Luma Debian Maintainer

Newbie and encoding

[<jph...@fr...>]

Hi,

I was used to work with phpldapadmin, then discovered luma. Now I need something
more specific to my needs, and thus interested in python-ldap.

Starting was really easy :-) Unfortunately, I discovered a bug in my application
this week-end: I can not use 8 bits chars in search or add functions while I
have no issue with these characters in Luma :-( It seems to be related to string
encoding. Luma makes an intensive use of the "unicode" function. So I tried that
piece of code but without success:

>>> import ldap
>>> CON=ldap.open('localhost.localdomain')
>>> CON.simple_bind_s('','')
>>> CON.search_s('ou=amis,dc=localdomain',ldap.SCOPE_SUBTREE,u'(cn=th')

exceptions.UnicodeEncodeError                        Traceback (most recent call
last)

/home/jpht/informatique/programmation/python/scripts/under_development/<console>

/usr/lib/python2.3/site-packages/ldap/ldapobject.py in search_s(self, base,
scope, filterstr, attrlist, attrsonly)
    466
    467   def
search_s(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0):
--> 468     return
self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,timeout=self.timeout)
    469
    470   def
search_st(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0,timeout=-1):

/usr/lib/python2.3/site-packages/ldap/ldapobject.py in search_ext_s(self, base,
scope, filterstr, attrlist, attrsonly, serverctrls, clientctrls, timeout,
sizelimit)
    459
    460   def
search_ext_s(self,base,scope,filterstr='(objectClass=*)',attrlist=None,attrsonly=0,serverctrls=None,clientctrls=None,timeout=-1,sizelimit=0):
--> 461     msgid =
self._ldap_call(self._l.search_ext,base,scope,filterstr,attrlist,attrsonly,serverctrls,clientctrls,timeout,sizelimit)
    462     return self.result(msgid,all=1,timeout=timeout)[1]
    463

/usr/lib/python2.3/site-packages/ldap/ldapobject.py in _ldap_call(self, func,
*args, **kwargs)
     92     try:
     93       try:
---> 94         result = func(*args,**kwargs)
     95       finally:
     96         self._ldap_object_lock.release()

UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 6:
ordinal not in range(128)

I went quickly through this list, but was not sure of understanding the answer
;-( Could someone help me?

Jean-Philippe

P.S.: I am running slapd 2.2.23 and python-ldap 2.0.4 (debian sarge)

Re: Compiling on windows

[Jonathan B. <bo...@us...>]

Yes, exactly. While we are at it, can we try to compile in sasl
support? The catch, so far, is, again, heimdal. It is not winsock
aware.

However, I have heard that it can be done. I am just stuck as to how.

Perhaps I should just ask a couple simple questions:

Should we use heimdal or MIT kerberos? I have been assuming heimdal,
as MIT kerberos does not compile with mingw/msys.

Should we use mingw/msys, or vc++? I have been assuming mingw/msys.

Is there a way to get mingw to use MIT kerberos libraries compiled with vc++?

If anyone can point me in the right direction, I would be grateful.

Thanks,
Jonathan Bowman

On 2/10/07, Anil Jangity <an...@en...> wrote:
> There is a windows python-ldap (2.0.6 py 2.4) available here:
> http://www.agescibs.org/mauro/
>
> But its a little old...
>
> Anyone working on getting one up for python 2.5 and latest python-ldap release?
>
> On 2/10/07, Jonathan Bowman <bo...@us...> wrote:
> > I have been trying to build python-ldap on Windows. First, I need to
> > build openldap on Windows using openssl, heimdal (kerberos 5, gssapi,
> > etc.), and cyrus-sasl. I am doing this using mingw (as I assume that
> > is what python-ldap uses).
> >
> > OpenSSL is not a problem, but then I get stuck on heimdal, which keeps
> > me from compiling cyrus-sasl. Should I be using MIT Kerberos instead?
> > (I do not know how to build MIT Kerberos using mingw). I am using
> > MSYS, heimdal has a problem with sockets on Windows.
> >
> > Can anyone give me any hints at all? At this point, I do not know how
> > to do this without getting involved in altering significant source
> > code in heimdal, which is beyond my means.
> >
> > Thanks for any response,
> > Jonathan Bowman
> >
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job easier.
> > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > Python-LDAP-dev mailing list
> > Pyt...@li...
> > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
> >
>

Re: Compiling on windows

[Anil J. <an...@en...>]

There is a windows python-ldap (2.0.6 py 2.4) available here:
http://www.agescibs.org/mauro/

But its a little old...

Anyone working on getting one up for python 2.5 and latest python-ldap release?

On 2/10/07, Jonathan Bowman <bo...@us...> wrote:
> I have been trying to build python-ldap on Windows. First, I need to
> build openldap on Windows using openssl, heimdal (kerberos 5, gssapi,
> etc.), and cyrus-sasl. I am doing this using mingw (as I assume that
> is what python-ldap uses).
>
> OpenSSL is not a problem, but then I get stuck on heimdal, which keeps
> me from compiling cyrus-sasl. Should I be using MIT Kerberos instead?
> (I do not know how to build MIT Kerberos using mingw). I am using
> MSYS, heimdal has a problem with sockets on Windows.
>
> Can anyone give me any hints at all? At this point, I do not know how
> to do this without getting involved in altering significant source
> code in heimdal, which is beyond my means.
>
> Thanks for any response,
> Jonathan Bowman
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier.
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
>

Compiling on windows

[Jonathan B. <bo...@us...>]

I have been trying to build python-ldap on Windows. First, I need to
build openldap on Windows using openssl, heimdal (kerberos 5, gssapi,
etc.), and cyrus-sasl. I am doing this using mingw (as I assume that
is what python-ldap uses).

OpenSSL is not a problem, but then I get stuck on heimdal, which keeps
me from compiling cyrus-sasl. Should I be using MIT Kerberos instead?
(I do not know how to build MIT Kerberos using mingw). I am using
MSYS, heimdal has a problem with sockets on Windows.

Can anyone give me any hints at all? At this point, I do not know how
to do this without getting involved in altering significant source
code in heimdal, which is beyond my means.

Thanks for any response,
Jonathan Bowman

Re: ReconnectLDAPObject doesn't reconnect after main failure

[Alain S. <asp...@gm...>]

Convinced :-)

Best regards.

On 1/29/07, Michael Str=F6der <mi...@st...> wrote:
> Alain Spineux wrote:
> >
> > Python is a language made to help and facilitate the developer work :
> > - the developer dont need to test the result of any function, python
> > (or the library) raise an exception if something is wrong.
> > - the developer dont need to worry about the memory allocation, the
> > garbage collector do it for him.
> > - the developer dont need to close a file, the system do it for him
> > when the object is released
> > - the developer don't need to worry for long living LDAP connection,
> > ReconnectLDAPObject  auto reconnect automatically for him :-)
> > - python-ldap is also thread safe .....
>
> Your list rather arguments for adding SimpleLDAPObject.__del__() if not
> implemented yet (I have to look at it).
>
> > Then why does the developer have to encapsulate any ldap statement into=
 a
> >
> > try:
> > except ldap.SERVER_DOWN,e:
> >    SimpleLDAPObject.unbind_s(self)
>
> Because in case of ldap.SERVER_DOWN the application might have some
> means for fail-over, smart error handling or similar. python-ldap is
> rather low-level. I expect application developers to wrap something
> around SimpleLDAPObject which better suits there needs.
>
> And I'd like to avoid breaking existing code. Calling unbind_s() twice
> raises
> ldap.LDAPError: LDAP connection invalid
>
> Do you have an overview how other database modules handle such cases?
>
> Ciao, Michael.
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: ReconnectLDAPObject doesn't reconnect after main failure

[<mi...@st...>]

Alain Spineux wrote:
> 
> Python is a language made to help and facilitate the developer work :
> - the developer dont need to test the result of any function, python
> (or the library) raise an exception if something is wrong.
> - the developer dont need to worry about the memory allocation, the
> garbage collector do it for him.
> - the developer dont need to close a file, the system do it for him
> when the object is released
> - the developer don't need to worry for long living LDAP connection,
> ReconnectLDAPObject  auto reconnect automatically for him :-)
> - python-ldap is also thread safe .....

Your list rather arguments for adding SimpleLDAPObject.__del__() if not
implemented yet (I have to look at it).

> Then why does the developer have to encapsulate any ldap statement into a
> 
> try:
> except ldap.SERVER_DOWN,e:
>    SimpleLDAPObject.unbind_s(self)

Because in case of ldap.SERVER_DOWN the application might have some
means for fail-over, smart error handling or similar. python-ldap is
rather low-level. I expect application developers to wrap something
around SimpleLDAPObject which better suits there needs.

And I'd like to avoid breaking existing code. Calling unbind_s() twice
raises
ldap.LDAPError: LDAP connection invalid

Do you have an overview how other database modules handle such cases?

Ciao, Michael.

Re: about how python-ldap is trade safe.

[<mi...@st...>]

Alain,

thanks for reviewing the code of ldapobject.py thoroughly.

Alain Spineux wrote:
> 
> Finally I found every object contains its own lock ! (if the used ldap
> library is reentrant)
> and their was no bottleneck. I was happy :-)

Yes, if linked against libldap_r (check your setup.cfg).

> But _ldap_function_call is still used to call _ldap.initialize at some place
> 
> [root@fc6-eg ldap]# grep _ldap.initialize *.py
> ldapobject.py:    self._l =
> ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
> ldapobject.py:        self._l =
> ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
> ldapobject.py:      self._l = self._ldap_call(_ldap.initialize,self._uri)
> 
> why not to replace the use of _ldap_function_call by the more
> appropriate _ldap_call, already used in the last line !

Hmm, IMO it's the other way round. I'd rather consider it a stupid
copy&paste bug that self._ldap_call() is invoked for wrapping
_ldap.initialize() within SmartLDAPObject. I've fixed and committed this.

Please review OpenLDAP's ldap.h. You'll find that ldap_initialize() is a
completely different thing.

> And that way
> debugging will provide and uri for initialise call!

ldap.functions._ldap_function_call() also can produce debug output.

But you have to explicitly set module vars ldap._trace_level,
ldap._trace_file and ldap._trace_stack_limit to enable it. The latter
two being optional off course.

Ciao, Michael.

about how python-ldap is trade safe.

[Alain S. <asp...@gm...>]

Hello

I was a little afraid by the advertisement I found

Thread-lock:
Basically calls into the LDAP lib are serialized by the module-wide
lock _ldapmodule_lock.

and wanted to know more about this.
Finally I found every object contains its own lock ! (if the used ldap
library is reentrant)
and their was no bottleneck. I was happy :-)

But _ldap_function_call is still used to call _ldap.initialize at some place

[root@fc6-eg ldap]# grep _ldap.initialize *.py
ldapobject.py:    self._l =
ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
ldapobject.py:        self._l =
ldap.functions._ldap_function_call(_ldap.initialize,self._ldap_object_lock,uri)
ldapobject.py:      self._l = self._ldap_call(_ldap.initialize,self._uri)

why not to replace the use of _ldap_function_call by the more
appropriate _ldap_call, already used in the last line ! And that way
debugging will provide and uri for initialise call!

here is the patch

*** ldap.orig/ldapobject.py     Sat Jan 27 01:57:50 2007
--- ldap/ldapobject.py  Sun Jan 28 02:34:56 2007
***************
*** 66,72 ****
      self._trace_stack_limit = trace_stack_limit
      self._uri = uri
      self._ldap_object_lock = self._ldap_lock()
!     self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri)
      self.timeout = -1
      self.protocol_version = ldap.VERSION3

--- 66,73 ----
      self._trace_stack_limit = trace_stack_limit
      self._uri = uri
      self._ldap_object_lock = self._ldap_lock()
!     self._l = self._ldap_call(_ldap.initialize,self._uri)
!
      self.timeout = -1
      self.protocol_version = ldap.VERSION3

***************
*** 732,738 ****
          ))
        try:
          # Do the connect
!         self._l = ldap.functions._ldap_function_call(_ldap.initialize,uri)
          self._restore_options()
          # StartTLS extended operation in case this was called before
          if self._start_tls:
--- 733,740 ----
          ))
        try:
          # Do the connect
!         self._l = self._ldap_call(_ldap.initialize,self._uri)
!
          self._restore_options()
          # StartTLS extended operation in case this was called before
          if self._start_tls:





--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: ReconnectLDAPObject doesn't reconnect after main failure

[Alain S. <asp...@gm...>]

This is a good point of view!
Anyway I try my _LAST_ arguments.

Python is a language made to help and facilitate the developer work :
- the developer dont need to test the result of any function, python
(or the library) raise an exception if something is wrong.
- the developer dont need to worry about the memory allocation, the
garbage collector do it for him.
- the developer dont need to close a file, the system do it for him
when the object is released
- the developer don't need to worry for long living LDAP connection,
ReconnectLDAPObject  auto reconnect automatically for him :-)
- python-ldap is also thread safe .....

Then why does the developer have to encapsulate any ldap statement into a

try:
except ldap.SERVER_DOWN,e:
    SimpleLDAPObject.unbind_s(self)

whereas=09the library can do it for him

Anyway we made a good job !

Tanks for your support.

On 1/27/07, "Michael Str=F6der" <mi...@st...> wrote:
> On 12:59:58 pm 2007-01-27 "Alain Spineux" <asp...@gm...> wrote:
> >
> > And what about the idea to put the
> >
> > try:
> > except ldap.SERVER_DOWN,e:
> >    SimpleLDAPObject.unbind_s(self)
> >
> > in the function _ldap_call too ?
> > This will correct also SimpleLDAPObject ?
>
> There is nothing wrong with SimpleLDAPObject. The application is supposed
> to catch and handle ldap.SERVER_DOWN. Additionally SimpleLDAPObject and
> ReconnectLDAPObject shall behave in the same way. And IMO they do now.
>
> Ciao, Michael.
>
>


--=20
--
Alain Spineux
aspineux gmail com
May the sources be with you

Re: ReconnectLDAPObject doesn't reconnect after main failure

[<mi...@st...>]

On 12:59:58 pm 2007-01-27 "Alain Spineux" <asp...@gm...> wrote:
>
> And what about the idea to put the
>
> try:
> except ldap.SERVER_DOWN,e:
>    SimpleLDAPObject.unbind_s(self)
>
> in the function _ldap_call too ?
> This will correct also SimpleLDAPObject ?

There is nothing wrong with SimpleLDAPObject. The application is supposed
to catch and handle ldap.SERVER_DOWN. Additionally SimpleLDAPObject and
ReconnectLDAPObject shall behave in the same way. And IMO they do now.

Ciao, Michael.