On 5 mai 2011, at 11:40, Kiran Ayyagari wrote: > On Thu, May 5, 2011 at 1:16 PM, Pierre-Arnaud Marcelot <[email protected]> > wrote: >> Hi Kiran, >> >> On 4 mai 2011, at 17:13, Kiran Ayyagari wrote: >> >>> On Wed, May 4, 2011 at 8:24 PM, Daniel Fisher <[email protected]> wrote: >>>> On Tue, May 3, 2011 at 4:07 PM, Kiran Ayyagari <[email protected]> >>>> wrote: >>>>> Hi Daniel, >>>>> >>>>> On Wed, May 4, 2011 at 12:33 AM, Daniel Fisher <[email protected]> wrote: >>>>>> Hello, >>>>>> I'm doing some testing with 1.0.0-M3 and I'm having trouble reading >>>>>> binary attributes. >>>>>> Specifically for jpegPhoto in OpenLDAP 2.4.23: >>>>>> >>>>>> # jpegPhoto >>>>>> # Used to store one or more images of a person using the JPEG File >>>>>> # Interchange Format [JFIF]. >>>>>> attributetype ( 0.9.2342.19200300.100.1.60 >>>>>> NAME 'jpegPhoto' >>>>>> DESC 'RFC2798: a JPEG image' >>>>>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.28 ) >>>>>> >>>>>> the byte[] I get from Attribute#get()#getBytes() is about twice as big >>>>>> as I expect. Attribute#isHumanReadable() also returns true. Which >>>>>> makes me think the value has been encoded. >>>>>> Code snippet of what I'm doing: >>>>>> while (cursor.next()) { >>>>>> SearchResultEntry result = (SearchResultEntry) cursor.get(); >>>>>> Entry e = result.getEntry(); >>>>>> Attribute photo = e.get("jpegPhoto"); >>>>>> if (photo != null) { >>>>>> byte[] bytes = photo.get().getBytes(); >>>>>> FileOutputStream fos = new FileOutputStream("photo.jpg"); >>>>>> fos.write(bytes); >>>>>> fos.close(); >>>>>> } >>>>>> } >>>>>> >>>>>> ldapsearch returns the value I expect. Is there some special syntax >>>>>> for binary values I'm missing? Thanks >>>>>> >>>>> this is due to the fact that by default the client connection is not >>>>> schema aware, to make it schema aware call loadSchema() method >>>>> of the connection before performing any operations. >>>>> Let us know if you still have any issues. >>>>> Thank you for testing. >>>> >>>> Thanks. After reviewing the source it appears that binary attributes >>>> are only supported with a schema aware connection. If you expose the >>>> BinaryAttributeDetector (maybe on LdapConnection) then clients could >>>> have some control without dealing with schemas. This would afford the >>>> same functionality that JNDI provides via the >>>> 'java.naming.ldap.attributes.binary' property. Just a thought. >>>> >>> don't know how JNDI detects the binary attributes, but in our case it is >>> done completely with the help of schema manager >>>> I also looked at the NetwokSchemaLoader and it uses a hard coded >>>> baseDn and filter. With a litte refactoring that class could also work >>>> against OpenLDAP, but currently it looks ApacheDS specific. >>>> >>> yes it is completely tied to the ApacheDS, the idea behind this loader is to >>> have the same schema elements that the server currently uses instead >>> of loading a >>> set of default schemas. >>> >>> Another schema loader based on the data returned after querying >>> cn=subschema (this is the technique >>> which Apache Directory Studio uses) is ideal to make the client schema >>> aware while working with other servers. >>> >>> May be we can port that code from Studio to API, studio folks wdyt? :) >> >> Unfortunately Studio does not use (yet) the API on this part of the code. >> Although a complete Connection Wrapper as been created using the API and >> works great, the code responsible for Schema loading in the LDAP Browser is >> still our older base source code, when the API didn't exist. >> >> We should really introduce a "generic" schema loader, based on the >> NetworkSchemaLoader, but which first looks into the RootDSE to find the >> location of the schema (the value of the 'subSchemaSubentry' attribute), and >> then, on that DN loads all definitions of schema elements. >> This would allow to make the LdapConnection schema aware on servers >> publishing their schema that way (most of them). >> Definitely, a must have before releasing a final version of the API. >> >> I created a JIRA for this, DIRAPI-46: >> https://issues.apache.org/jira/browse/DIRAPI-46 >> > great, thanks >> Specifying BinaryAttributeDetectors might also be interesting in the case >> where the server does not advertise the location of the its schema in the >> RootDSE. But it would leave the connection being halfway schema aware, which >> might be complicated to handle at first sight. >> Something we can discuss about though. >> > yeah, the problem here is to link such a mechanism into the schema > manager, but honestly I don't think it is a good > idea to let user define some behavior to handle the attribute type > apart from what is already defined in the schema through syntax.
Yeah, I agree. The only problem is when the connection does not expose its schema. I understand that some users will want to define, at least, their binary attributes, like Daniel. Not the most common use-case but something we really something we need to consider... > OTOH this conversation makes me think that we should also make > connection schema aware by default, instead of the current choice > of letting users call loadSchema() to make it schema aware. Hum... That's a good question. It raises other questions like: - When do we trigger the load of the schema? On first bind? - Loading the schema will generate extra search requests (at least two), is that an issue? Regards, Pierre-Arnaud
