OK, I just realised I asked this question before but this is now
a NEW problem:
The problem was fixed before by specifiying a BER provider... but now we
don't specify one, the environment is not be passed down to the new improved
provider.
Can someone comment on this before I raise a JIRA issue?
Thanks Again
>
>I think I've tracked it down... sorry to bother you with this.
>
>I forgot to add
>
>
>asn.1.berlib.provider=org.apache.ldap.common.berlib.asn1.SnickersProvider
>
>
>>Oh yes that makes a difference. Perhaps once we consolidate all these
>>providers in to one fast robust one there will be no need for this.
>I think I've tracked it down... sorry to bother you with this.
>
>I forgot to add
>
>
>asn.1.berlib.provider=org.apache.ldap.common.berlib.asn1.SnickersProvider
>
>
>>Oh yes that makes a difference. Perhaps once we consolidate all these
>>providers in to one fast robust one there will be no need for this.
>I guess the default provider mechanism doesn't pass down the
whole
>environment...?
>environment...?
08 February 2006 13:15
To: [email protected]
cc:
From: [EMAIL PROTECTED]
Subject: Problem Attaching Binary Data
To: [email protected]
cc:
From: [EMAIL PROTECTED]
Subject: Problem Attaching Binary Data
Does
anyone know of a problem attaching binary attributes (jpegPhoto etc)? I
thourght this was all fixed in 0.9.x?
I can attach/detach a serialised java object fine
using the in-VM connector but if I try to use an out-of-VM connection, the
serialised object becomes corrupt when it is attached (has its first few
bytes messed up).
I also fail to attach/detach photo attributes
using JXplorer - again an out-of-vm connection.
This is the latest 0.9.4 trunk
(V1RC1)
Each time an out-of-VM connection is made I get
this warning:
2006-02-08 12:44:53,390 WARN
[org.apache.ldap.common.message.MessageDecoder](IoThreadPool-2) Could not find
java.naming.ldap.attributes.binary key in environment. Using empty set for
binaries.
This seems related to me...
TIA
SimonT
