Emmanuel,
no worries, as far as I can tell, your code is correct ;). The attribute
xsi:type="xsd:base64Binary" is generated correctly in the request I sent
[2]. However, the simulator seems to ignore/drop this attribute [1] when
interpreting the request, which should bug in the simulator. I'd share a
link to that discussion, but unfortunately it is not public :/.
Even though your solution is correct, I'd like to know if you can
imagine to preserve the original string, because in this specific case
the api call
SearchRequestDsml searchRequest = new
SearchRequestDsml(LdapApiServiceFactory.getSingleton());
searchRequest.setFilter("(memberOf=cn=MercyCenterHospitalGroup,ou=Relationship,dc=HPD,o=IHE-Europe,c=FRA)");
leads to
<value
xsi:type="xsd:base64Binary">Y249TWVyY3lDZW50ZXJIb3NwaXRhbEdyb3VwLG91PVJlbGF0aW9uc2hpcCxkYz1IUEQsbz1JSEUtRXVyb3BlLGM9RlJB</value>
in the request.
In other words, do you think the conversion to a byte array within the
library (and consequently the base64 encoding) could be avoided for
string filters?
Thanks,
Patrick
[1]
https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572 <https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572>
[2]
<?xml version="1.0" encoding="UTF-8" standalone="no"?><env:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope
<http://www.w3.org/2003/05/soap-envelope>">
<env:Header>
<wsa:To xmlns:wsa="http://www.w3.org/2005/08/addressing
<http://www.w3.org/2005/08/addressing>">https://gazelle.synedra.lan/HPDSimulator-ejb/ProviderInformationDirectory_Service/ProviderInformationDirectory_PortType <https://gazelle.synedra.lan/HPDSimulator-ejb/ProviderInformationDirectory_Service/ProviderInformationDirectory_PortType></wsa:To>
<wsa:MessageID xmlns:wsa="http://www.w3.org/2005/08/addressing
<http://www.w3.org/2005/08/addressing>">urn:uuid:3498c2e0-45c0-402a-bfc3-e289ee3afaef</wsa:MessageID>
<wsa:ReplyTo xmlns:wsa="http://www.w3.org/2005/08/addressing
<http://www.w3.org/2005/08/addressing>">
<wsa:Address>"
title="http://www.w3.org/2005/08/addressing/anonymous
<http://www.w3.org/2005/08/addressing/anonymous>"
target="_blank">http://www.w3.org/2005/08/addressing/anonymous
<http://www.w3.org/2005/08/addressing/anonymous></wsa:Address>;
</wsa:ReplyTo>
<wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing
<http://www.w3.org/2005/08/addressing>"
env:mustUnderstand="1">urn:ihe:iti:2010:ProviderInformationQuery</wsa:Action>
</env:Header>
<env:Body>
<batchRequest xmlns="urn:oasis:names:tc:DSML:2:0:core"
xmlns:xsd="http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>">
<searchRequest derefAliases="derefAlways"
dn="ou=HCProfessional,dc=HPD,o=gazelle,c=IHE" requestID="1"
scope="wholeSubtree">
<filter>
<equalityMatch name="memberOf">
<value
xsi:type="xsd:base64Binary">Y249TWVyY3lDZW50ZXJIb3NwaXRhbEdyb3VwLG91PVJlbGF0aW9uc2hpcCxkYz1IUEQsbz1JSEUtRXVyb3BlLGM9RlJB</value>
</equalityMatch>
</filter>
<attributes>
<attribute name="cn"/>
<attribute name="objectClass"/>
<attribute name="hcIdentifier"/>
<attribute name="o"/>
<attribute name="hcRegisteredName"/>
<attribute name="hpdProviderPracticeAddress"/>
<attribute name="displayName"/>
<attribute name="physicalDeliveryOfficeName"/>
<attribute name="uid"/>
<attribute name="individualProviders"/>
<attribute name="prRelationId"/>
<attribute name="prHasAProviderFrom"/>
<attribute name="prHasAProviderTo"/>
<attribute name="prRelationRole"/>
</attributes>
</searchRequest>
</batchRequest>
</env:Body>
</env:Envelope>
Am Do., 8. Feb. 2024 um 20:24 Uhr schrieb Emmanuel Lécharny
<[email protected] <mailto:[email protected]>>:
Ok so some more info:
The memberOf attribute is a bit special. It's first a AcriveDirectory
Attribute and its syntax is Distinguish Name Syntax. Which means it's
not purely a String, which is the reason it's base64 encoded.
Whe it comes to encode values, the following rule should apply:
"When creating DSML messages, all Attributes whose value is Java byte
array are Base64 encoded to String before being written in the DSML
message.
If when creating a DSML message an Attribute is passed whose value's
type is neither String nor Java byte array, the value is converted to
String by calling the object's "toString()" method and this String
value
is written in the DSML message.
"
(that is from IBM).
OASIS is a bit more light when it comes to tell what should be base64
encoded or not:
"The definition of DsmlValue permits the following types: UTF-8,
base64Binary, and any URI."
Now, to be able to know what would be the value type, there is some
attribute that needs to be added:
xsi:type="xsd:base64Binary"
Like in :
<control type="1.2.840.113556.1.4.612" criticality="true">
<controlValue xsi:type="xsd:base64Binary">
U2VhcmNoIFJlcXVlc3QgRXhhbXBsZQ==
</controlValue>
</control>
So I guess we should avoid ommitting this attribute when base64
encoding
a value.
On 08/02/2024 18:11, Emmanuel Lecharny wrote:
> Hi Patrick,
>
> I have to check why the value gets base64 encoded. I thought the
issue
> was already properly addressed (see
>
https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369
<https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369>
>
<https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369
<https://issues.apache.org/jira/plugins/servlet/mobile#issue/DIRAPI-369>>)
>
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com <http://www.iktek.com> <http://www.iktek.com
<http://www.iktek.com>>
>
>
> Le jeu. 8 févr. 2024 à 16:22, Patrick Peer <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>> a écrit :
>
> Hi Emmanuel!
>
> I finally got around to upgrading to the newest version. The good
> news: The value for the equalityMatch is generated
successfully. The
> bad news: IHE's HPD simulator [1] seems to have problems with the
> base64 encoding. It seems as if the xsi:type-Attribute is not
> recognized and/or dropped [2].
> Now, I think the request should be correct in the context of
> HPD-queries, and that the simulator is clumsy. I will hash
that out
> with the folks at IHE. However, this leads me to think that other
> "real" implementations of HPDs will have problems with
base64, too.
>
> I will now have to decide with my colleagues how to handle
this. One
> possibility would be to generate the normal strings again. To do
> that, I could compile a modified version of the library myself
> (luckily I could get away with breaking the code for parsing
> requests, should that be an issue, as you hinted before).
Still, I'd
> like to know how you think about reverting to generating
strings in
> the official library again. At least for the case, when the
value is
> a string to begin with, and a conversion to base64 would not be
> required.
>
> In any case, thanks for the fix :)!
>
> Cheers,
> Patrick
>
> [1] https://gazelle.ihe.net/HPDSimulator/home.seam
<https://gazelle.ihe.net/HPDSimulator/home.seam>
> <https://gazelle.ihe.net/HPDSimulator/home.seam
<https://gazelle.ihe.net/HPDSimulator/home.seam>>
> [2]
>
https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572
<https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572>
<https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572
<https://gazelle.ihe.net/HPDSimulator/messages/messageDisplay.seam?id=35572>>
>
> Am Di., 6. Feb. 2024 um 08:52 Uhr schrieb Emmanuel Lécharny
> <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>:
>
> Hi,
>
> the release has been voted. It's available. Enjoy!
>
> On 02/02/2024 12:05, Patrick Peer wrote:
> > Thank you very much! Much appreciated :).
> >
> > Am Fr., 2. Feb. 2024 um 10:41 Uhr schrieb Emmanuel
Lécharny
> > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>:
> >
> > The release is being voted. I expect to be out at the
> beginning of next
> > week.
> >
> > On 29/01/2024 14:03, Patrick Peer wrote:
> > > Emmanuel,
> > >
> > > can you give me a rough estimate on when a new
version
> with the
> > fixes
> > > will be available? I need to upgrade due to
CVEs for
> dependencies of
> > > older versions of org.apache.directory.api:api-all,
> for the
> > release of
> > > our own software. Thus I need to know whether I can
> wait for your
> > > release, or need to compile the library myself.
> > >
> > > Cheers,
> > > Patrick
> > >
> > > Am Mi., 6. Dez. 2023 um 09:26 Uhr schrieb
Patrick Peer
> > > <[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>>:
> > >
> > > Hi Emmanuel!
> > >
> > > > Side note: I'd be interested to know what is
> your usage of the
> > > LDAP API
> > > > and why you picked it against other
libs. Just
> for my
> > personnal
> > > interest!
> > > I inherited the code using the LDAP API, so my
> best guess is:
> > When
> > > Apache provides a library for the thing you
want
> to do, you
> > use it :).
> > > As for the actual use case, we want to query
> Healthcare Provider
> > > Directories (HPDs) [1].
> > >
> > > > Btw, I now realize that the output is
> incorrect, even after my
> > > fix. The
> > > > produced DSML should still contain the
Base64
> value, which is
> > > currently
> > > > not. I'll fix that.
> > > Given that this was a bug, and the filter
values
> will be
> > generated
> > > again, setFilter(String) _should_ work
after the fix.
> > However, given
> > > my experience in the field, I fear there
will be
> problems
> > with HPDs
> > > that are not prepared to handle base64
values. I
> might be
> > wrong on
> > > that though, and as long as IHE's HPD
simulator is
> happy, I
> > think I
> > > will use the simpler (for me) base64
filters. On
> that note,
> > do you
> > > have an estimate on when a new version will be
> released?
> > >
> > > Cheers,
> > > Patrick
> > >
> > >
> > >
> > > [1]
> > >
> >
>
https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>
<https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>
<https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>
<https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>>
<https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>
<https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>
<https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>
<https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf <https://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_Suppl_HPD.pdf>>>> -
3.58 Provider Information Query
> > >
> > > Am Di., 5. Dez. 2023 um 23:02 Uhr schrieb
Emmanuel
> Lécharny
> > > <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>>:
> > >
> > > Ok, I get a fixed version of the setFilter(
> String ) that
> > > produces this
> > > output:
> > >
> > > <?xml version="1.0" encoding="UTF-8"?>
> > > <batchRequest
> xmlns:xsd="http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>
> <http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>>
> > <http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>
> <http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>>>
> > > <http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>
> <http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>>
> > <http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>
> <http://www.w3.org/2001/XMLSchema
<http://www.w3.org/2001/XMLSchema>>>>"
> > >
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>
> <http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>>
> > <http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>
> <http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>>>
> > >
<http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>
> <http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>>
> > <http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>
> <http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>>>>">
> > > <searchRequest
derefAliases="derefAlways">
> > > <filter>
> > > <equalityMatch name="uid">
> > > <value/>
> > > </equalityMatch>
> > > <equalityMatch name="uid">
> > > <value
> > >
> >
>
xsi:type="xsd:base64Binary">U29tZUFyYml0cmFyeUJlbmlnblN0cmluZw==</value>
> > > </equalityMatch>
> > > </filter>
> > > </searchRequest>
> > > </batchRequest>
> > >
> > > As youc an imagine,
> "U29tZUFyYml0cmFyeUJlbmlnblN0cmluZw==" is
> > > "SomeArbitraryBenignString" base 64
encoded.
> > >
> > >
> > > Should it do the trick?
> > >
> > > On 05/12/2023 15:43, Patrick Peer wrote:
> > > > Thanks Emmanuel!
> > > >
> > > > Using a SchemaManager solved my
immediate
> problem.
> > However,
> > > now I need
> > > > to provide a custom Schema, since I
need to
> query domain
> > > specific OIDs.
> > > > Before, the library was happy with
> arbitrary OIDs, and
> > so was
> > > I :).
> > > >
> > > > Addressing the easy API life,
> > > >
> > >
> >
>
org.apache.directory.api.dsmlv2.request.SearchRequestDsml.setFilter(String) seems broken to me, as this code path does not produce the expected output, and this is not obvious in any way, not to say that the semantic of this method changed without notice. Ideally, this method would not exist, but since it is required by the implemented interface, that is not easily achieved, and a bigger refactoring would be needed. That said, I, of course, do not have a deep understanding of your code base, so please take my suggestion with a grain of salt ;).
> > > >
> > > > Thanks for the improved
> setFilter(SchemaManager, String)
> > > method, albeit
> > > > it is secondary to me, compared to
the changed
> > semantics of
> > > > setFilter(String), and the extra setup
> needed to be
> > able to
> > > query
> > > > arbitrary OIDs. To better illustrate
what I
> mean, here
> > is one
> > > of the
> > > > filters which is currently broken
for me:
> > > >
> >
>
"(hcIdentifier=*1.3.6.1.4.1.21367.1776:IHENA:A-919191:Active*)"
> > > >
> > > > I am currently in the process of
figuring
> out an easy
> > way to
> > > add the
> > > > required OIDs to the SchemaManager, and
> will eventually
> > > figure it out,
> > > > but if you have any hints, I'd be
grateful :).
> > > >
> > > > Cheers,
> > > > Patrick
> > > >
> > > > Am Di., 5. Dez. 2023 um 13:48 Uhr
schrieb
> Emmanuel
> > Lécharny
> > > > <[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>
> > > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>>>>>:
> > > >
> > > > Hi again!
> > > >
> > > > I have modified the LDAP API to
be able
> to deal
> > with the
> > > attributeType
> > > > properly when we have a
SchemaManager,
> and to do
> > so in a
> > > more user
> > > > friendly way.
> > > >
> > > > Here is thge modified original test:
> > > >
> > > > @Test
> > > > public void
> testMinimalEqualityRequest() throws
> > > Exception {
> > > > SearchRequestDsml
> searchRequest = new
> > > >
> >
SearchRequestDsml(LdapApiServiceFactory.getSingleton());
> > > >
> > > > // Create the SchemaManager
> instance
> > > > SchemaManager
schemaManager = new
> > > DefaultSchemaManager();
> > > >
> > > > // Use it as a parameter so
> that the
> > filter get
> > > properly parsed
> > > > searchRequest.setFilter(
> schemaManager,
> > > > "(uid=SomeArbitraryBenignString)" );
> > > >
> > > >
> > > > BatchRequestDsml
batchRequest
> = new
> > > BatchRequestDsml();
> > > >
> batchRequest.addRequest(searchRequest);
> > > > String dsmlString =
> batchRequest.toDsml();
> > > >
> > > > System.out.print(
dsmlString );
> > > > }
> > > >
> > > > which prints out the expected
result:
> > > >
> > > > <?xml version="1.0"
encoding="UTF-8"?>
> > > > <batchRequest>
> > > > <searchRequest
> derefAliases="derefAlways">
> > > > <filter>
> > > > <equalityMatch
name="uid">
> > > >
> <value>SomeArbitraryBenignString</value>
> > > > </equalityMatch>
> > > > </filter>
> > > > </searchRequest>
> > > > </batchRequest>
> > > >
> > > > It will most certainly be
included in
> 2.1.6.
> > > >
> > > >
> > > > On 04/12/2023 21:18, Patrick
Peer wrote:
> > > > > Hello!
> > > > >
> > > > > I recently upgraded the version
> > > >
of org.apache.directory.api:api-all from
> > > > > 2.1.0 to 2.1.5 in the
dependencies
> of our product,
> > > which resulted in
> > > > > some test failures on my end.
As it
> seems,
> > values for
> > > equality
> > > > filters
> > > > > are not set in the request
anymore.
> For your
> > > convenience, I cobbled
> > > > > together a minimal test case to
> reproduce the
> > > condition [1].
> > > > It works
> > > > > with Version 2.1.0 and does
not work
> with 2.1.5.
> > > > >
> > > > > Upon further investigation, I
think
> I found
> > some issues
> > > > >
> > > >
> > >
> >
>
in org.apache.directory.api.dsmlv2.request.SearchRequestDsml.toDsml(Element, ExprNode)@2.1.5:
> > > > > + On line
559 value.isHumanReadable() is
> > queried to decide
> > > > whether to
> > > > > use the value as is, or to
encode it
> in base64. =>
> > > This seems
> > > > broken,
> > > > > since, as far as I can tell,
> > > > >
> > >
> the org.apache.directory.api.ldap.model.entry.Value.isHR
> > flag is
> > > > always
> > > > > false at this particular point in
> the code.
> > > > >
> > > >
> > >
> >
>
+ org.apache.directory.api.dsmlv2.ParserUtils.base64Encode(Object)
> > only
> > > > > yields base64 values
for byte[] and
> String,
> > however here a
> > > > >
> org.apache.directory.api.ldap.model.entry.Value is
> > > passed, which
> > > > will
> > > > > always result in an empty String.
> > > > >
> > > > > The corresponding commit
should be [2].
> > > > >
> > > > > Do you agree that this is a
bug, and
> should I jump
> > > through the
> > > > hoops to
> > > > > open a Jira issue, or is there an
> > alternative/intended
> > > way to work
> > > > > around this?
> > > > >
> > > > > Cheers,
> > > > > Patrick Peer
> > > > >
> > > > >
> > > > >
> > > > > [1]
> > > > > @Test
> > > > > public void
> testMinimalEqualityRequest() throws
> > > Exception {
> > > > > SearchRequestDsml
searchRequest
> = new
> > > > >
> >
SearchRequestDsml(LdapApiServiceFactory.getSingleton());
> > > > >
> > >
> searchRequest.setFilter("(uid=SomeArbitraryBenignString)");
> > > > >
> > > > > BatchRequestDsml
batchRequest = new
> > > BatchRequestDsml();
> > > > >
> batchRequest.addRequest(searchRequest);
> > > > > String dsmlString =
> batchRequest.toDsml();
> > > > >
> > > > >
> > >
>
assertThat(dsmlString).contains("SomeArbitraryBenignString");
> > > > > }
> > > > >
> > > > > [2]
> > > > >
> > > >
> > >
> >
>
https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>
<https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859> <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859 <https://github.com/apache/directory-ldap-api/commit/1dd1248d33ffed80cc225e76b2769e4558bbc859>>>>>>
> > > >
> > > > --
> > > > *Emmanuel Lécharny* P. +33 (0)6
08 33 32 61
> > > > [email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>
> > > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>
> > <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>>>
> > > >
> > >
> > > --
> > > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > > [email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> > <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected]
<mailto:[email protected]>> <mailto:[email protected]
<mailto:[email protected]>
> <mailto:[email protected] <mailto:[email protected]>>>>
> > >
> >
> > --
> > *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> > [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
> >
>
>
> --
> *Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
>
--
*Emmanuel Lécharny* P. +33 (0)6 08 33 32 61
[email protected] <mailto:[email protected]>
