Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

[Stefan Seelmann]

On 7/4/21 8:03 PM, Shawn McKinney wrote:
> 
>> On Jul 4, 2021, at 9:12 AM, Shawn McKinney  wrote:
>>
>> I don’t think it’s server dependent as I’ve noticed the TLS connection and 
>> binds are successful with OpenLDAP before the timeout in the API.
>>
> 
> Should know by now not to ‘think’ and just test.  Don’t know how many times 
> I’ve been burned by assumptions.  :/
> 
>>
>> But, testing latest w/ LDAPS and ApacheDS is on my list of todos.
> 
> 
> After enabling LDAPS on ApacheDS, connections with TLSv3 allowed as an 
> enabled protocol work fine.
> 
> So, for some reason OpenLDAP and the LDAP API’s TLS 1.3 as an enabled 
> protocol don’t get along.

Oh sorry, my question regarding ApacheDS didn't make sense because in
ApacheDS only TLSv1.2 is enabled so the negotiation chose 1.2 event if
1.3 is enabled in the API.



-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

[Stefan Seelmann]

Hi again,

On 7/3/21 7:26 PM, Shawn McKinney wrote:
> That is when TLSv1.3 was added as a default enabled protocol in the API, 
> fortress started having LDAPS connections problems.
> 
> Specifically, connections hang during bind ops, as they’re retrieved from the 
> pool.
> 
> Looking at the server log, the bind was successful, but the API's async 
> handler (ignores?) times out.

Can you please explain the steps to reproduce this issue? Does it happen
when running the Fortress integration tests? Or the load tests? And only
when testing against OpenDLAP or also when testing against ApacheDS?

Kind Regards,
Stefan

[1]
https://github.com/apache/directory-fortress-core#section-9-instructions-to-integration-test
[2]
https://github.com/apache/directory-fortress-core/blob/master/README-LOAD-TESTING.md




-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: [REPOSTED FROM DEV]Issue related to TLSv3 in the LDAP API

[Stefan Seelmann]

Hi Shawn,

I added TLSv1.3 to the default protocols in [1]. There is an open issue
for Mina [2] that describes timeouts when using v1.3, please see my
comment there. When used in Studio I didn't encounter any issue in tests
against OpenLDAP or 389ds, only when using it in ApacheDS, so I assumed
it's only a server-side problem. But your observations proves that my
assumption was wrong.

Which Java version are you using? I ask because I only tested with Java
11 and 17-ea, but not with Java 8.

Otherwise I think you aren't doing anything wrong. Either continue with
your workaround, or we need to revert that change in the LDAP API until
the problem is fixed in Mina.

Kind Regards,
Stefan

[1] https://issues.apache.org/jira/browse/DIRAPI-375
[2] https://issues.apache.org/jira/browse/DIRMINA-1132


On 7/3/21 7:26 PM, Shawn McKinney wrote:
> Hello,
> 
> A problem with Fortress using LDAPS in the API.  It was brought on by this 
> commit:
> 
> https://github.com/apache/directory-ldap-api/commit/4322886f8ed9fe0d2c588f0c557e92e4d160149f
> 
> 
> ```
> public class LdapNetworkConnection
> …
> 
> // Default to TLS sslFilter.setEnabledProtocols( new String[]
> - { "TLSv1", "TLSv1.1", "TLSv1.2" } );
> + { "TLSv1", "TLSv1.1", "TLSv1.2", "TLSv1.3" } );
> ```
> 
> That is when TLSv1.3 was added as a default enabled protocol in the API, 
> fortress started having LDAPS connections problems.
> 
> Specifically, connections hang during bind ops, as they’re retrieved from the 
> pool.
> 
> Looking at the server log, the bind was successful, but the API's async 
> handler (ignores?) times out.
> 
> When I add this to the Fortress connection pool initialization:
> 
> ```
> config.setEnabledProtocols( new String[] { "TLSv1", "TLSv1.1", "TLSv1.2" } );
> ```
> 
> Everything then works again as it should.  In other words, when bypassing 
> TLSv1.3 on the client side, it works again.
> 
> Not sure what’s going on, or if my workaround is the best way to handle this 
> situation.
> 
> Any ideas on what I'm doing wrong?
> 
> Thanks,
> 
> —
> Shawn
> -
> To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
> For additional commands, e-mail: api-h...@directory.apache.org
> 


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Apache Directory LDAP API 2.1.0 released

[Stefan Seelmann]

The Apache Directory Team is proud to announce the availability of
version 2.1.0 of the Apache Directory LDAP API.

The Apache Directory LDAP API is an ongoing effort to provide an
enhanced LDAP API, as a replacement for JNDI and the existing LDAP API
(jLdap and Mozilla LDAP API).

This is a schema aware API, with some convenient ways to access a LDAP
server. This API is not only targeting the Apache Directory Server, but
should work pristine with any LDAP server.

It’s also an extensible API : new Controls, schema elements and network
layer could be added or used in the near future. It’s also OSGi capable.

This is a security enhancement release. Most notable are support for
TLSv1.3 and addition of the SASL integrity and confidentiality layer.

Website : https://directory.apache.org/api
Download : https://directory.apache.org/api/downloads-2.html
User's Guide : http://directory.apache.org/api/user-guide.html

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Migrate to 2.0 API

[Stefan Seelmann]

On 6/22/21 3:47 PM, Shawn McKinney wrote:
> I switched from this://PoolableObjectFactory 
> poolFactory = new ValidatingPoolableLdapConnectionFactory( config );
> 
> To:
> PooledObjectFactory poolFactory = new 
> ValidatingPoolableLdapConnectionFactory( config );
> 

> But can’t use these://adminPool.setWhenExhaustedAction( 
> GenericObjectPool.WHEN_EXHAUSTED_GROW );

I the changelog
https://commons.apache.org/proper/commons-pool/changes-report.html I found

> Remove WhenExhuastedAction.GROW since it is equivalent to
WhenExhuastedAction.FAIL with a maxActive value of Integer.MAX_VALUE.

> //adminPool.setMaxActive( max );

According to the git log this was rnamed to maxTotal

https://github.com/apache/commons-pool/commit/c7d527543868ea2835e609e072b8a6423d4d99cb


If I understand correctly the new way it set maxTotal to a large number
(Integer.MAX_VALUE).

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapNetworkConnection. add eating exceptions

[Stefan Seelmann]

Hi Shawn,

I can only speak for API V2 but I think for V1 it's similar.

I also was surprised by that behavior, but it's "as designed" and makes
sense and is consistent :)

The LdapConnection methods that take a raw XyzRequest object also return
a raw XyzResponse object. Those only throw an exception if a network
level exceptions happens. But if the LDAP server properly returns a
response (be is positive or negative) the raw response is returned to
the caller and the caller has to inspect it.

There are other methods like add(Entry) or delete(Dn) or modify(Dn,
Modification) which return void. For those methods it's different and
the response from the server is processed by
ResultCodeEnum.processResponse() which throws LDAP specific exceptions
for non-successfule responses.

If you use the raw request/response methods you can use that utility
method too if you like.

I agree that it looks surprising, propbably we should improve the javadoc?

Kind Regards,
Stefan


On 4/5/21 8:30 PM, Shawn McKinney wrote:
> Hello,
> 
> Stumbled on this today.  The error occurs adding entry to directory and 
> constraint violation occurs.  The error is expected as I’m manipulating an pw 
> policy attribute that is DSA controlled.  
> 
> I’ve changed the code on adds to be able to forward the DSA control:
> 
> ```
> AddRequest addRequest = new AddRequestImpl();
> addRequest.setEntry( entry );
> if ( setManagedDsa )
> {
>ManageDsaIT mControl =  new ManageDsaITImpl();
>mControl.setCritical( true );
>addRequest.addControl( mControl );
> }
> AddResponse response = connection.add( addRequest );
> ```
> 
> FWIW I’ve also done it this way:
> 
> ```
> addRequest.addControl( new ManageDsaITImpl(); );
> ```
> 
> With this newly modified code I wouldn’t expect to get an error from server, 
> but let’s set that concern aside for a moment.
> 
> What I REALLY don't expect is for the server exception to be eaten by the 
> API. 
> 
> It happens line 566 of class (v1.3):
> 
> 
>   } else {
>   LOG.debug("Add failed : {}", addResponse);
> }
> 
> I’ve stepped through it, the server returns in response to the add (with 
> pwpolicy operational attr):
> 
> ```
> Ldap Result
> Result code : (CONSTRAINT_VIOLATION) constraintViolation
> Matched Dn : ''
> Diagnostic message : 'pwdPolicySubentry: no user modification allowed’
> ```
> 
> A more complete excerpt of LDAP API code add method:
> 
> 
> ```
> LdapNetworkConnection
> public AddResponse add(AddRequest addRequest) throws LdapException {
>   ...
>   
> try {
> AddResponse addResponse = (AddResponse)addFuture.get(this.timeout, 
> TimeUnit.MILLISECONDS);
> if (addResponse == null) {
> LOG.error("Add failed : timeout occurred");
> throw new LdapException("TimeOut occurred");
> } else {
> if (addResponse.getLdapResult().getResultCode() == 
> ResultCodeEnum.SUCCESS) {
> LOG.debug("Add successful : {}", addResponse);
> } else {
> LOG.debug("Add failed : {}", addResponse);
> }
> 
> return addResponse;
> }
> …
> ```
> 
> Please advise on if you think this is a bug (eating exception).  I’ll 
> follow-up with another thread on the *why* the server's returning the 
> exception in the first place but I need to investigate a bit more (may be 
> problem on server OpenLDAP 2.5.3 beta).
> 
> —
> Shawn
> 
> 
> -
> To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
> For additional commands, e-mail: api-h...@directory.apache.org
> 


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: LdapConnectionPool.getConnection doing extraneous search?

[Stefan Seelmann]

Would a Java Dynamic Proxy help?

It would implement the LdapConnection interface.

When a method is invoked it borrows a connection from the pool (without
testing it), executes the method, returns the connection to the pool,
and returns the result.

When the method execution fails with a specific error (connection error)
it invalidates the object in the pool, borrows a new one, and retries.

Kind Regards,
Stefan

-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: Is it time to release apacheds-test-framework

[Stefan Seelmann]

Let's discuss what's missing to get the next LDAP API and Server release
out, I should have some free time to help.

Kind Regards,
stefan

On 10/15/19 5:15 PM, Richard Sand wrote:
> I second the motion! Can't use the latest API because now the embedded
> DS tests fail.
> 
> -Richard
> 
> 
> -- Original Message --
> From: "Maxim Solodovnik" 
> To: "Emmanuel Lécharny" 
> Cc: api@directory.apache.org
> Sent: 10/15/2019 11:06:39 AM
> Subject: Re: Is it time to release apacheds-test-framework
> 
>> Hello Emmanuel,
>>
>> Are there any plans for release? :))
>>
>> On Thu, 5 Sep 2019 at 15:58, Maxim Solodovnik 
>> wrote:
>>
>>>  Thanks for the update :)
>>>
>>>  last release was about a year ago :(
>>>
>>> https://en.wikipedia.org/wiki/Release_early,_release_often :
>>>
>>>  On Thu, 5 Sep 2019 at 15:54, Emmanuel Lécharny 
>>>  wrote:
>>>
  Hi Maxim !

  Sadly, august was very unproductive :/


  I do think that we may force a release no matter what, even if we have
  some features we would like to add into the package, by just
 post-poning
  those features to a new release.

  I'll have a thought about this option this week-end.

  On 05/09/2019 10:36, Maxim Solodovnik wrote:
  > Hello Emmanuel,
  >
  > Any plans on this release?
  >
  > On Tue, 16 Jul 2019 at 13:54, Emmanuel Lécharny >>>  > > wrote:
  >
  > Hi Maxim,
  >
  >
  > we have to deal with some changes in the Mac OSX packaging. This
  > is the
  > one last show stopper atm.
  >
  > On 16/07/2019 08:25, Maxim Solodovnik wrote:
  > > Hello All,
  > >
  > > Are there any ETA for `apacheds-test-framework` release?
  > >
  > > On Tue, 21 May 2019 at 16:49, Maxim Solodovnik
  > mailto:solomax...@gmail.com>> wrote:
  > >> Hello,
  > >>
  > >> directory API 2.0.0.AM3 has been released and introduce an
 API
  > break: method Value.getValue() has been replaced with
 getString()
  > >>
  > >> Could you please release apacheds-test-framework ?
  > >> Right now I'm getting "No such method error" during test
  > execution :(
  > >>
  > >> --
  > >> WBR
  > >> Maxim aka solomax
  > >
  > >
  >
  >
   -
  > To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
  > 
  > For additional commands, e-mail: api-h...@directory.apache.org
  > 
  >
  >
  >
  > --
  > WBR
  > Maxim aka solomax

>>>
>>>
>>>  --
>>>  WBR
>>>  Maxim aka solomax
>>>
>>
>>
>> -- 
>> WBR
>> Maxim aka solomax
> 
> 
> -
> To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
> For additional commands, e-mail: api-h...@directory.apache.org
> 


-
To unsubscribe, e-mail: api-unsubscr...@directory.apache.org
For additional commands, e-mail: api-h...@directory.apache.org

Re: NPE in ERR_04122_SSL_CONTEXT_INIT_FAILURE Failed to initialize the SSL context

[Stefan Seelmann]

On 4/26/19 7:09 AM, Emmanuel Lecharny wrote:
>> ERR_04122_SSL_CONTEXT_INIT_FAILURE Failed to initialize the SSL context
>>
>> java.lang.NullPointerException: null
>> at
>>
>> org.apache.directory.ldap.client.api.LdapNetworkConnection.connect(LdapNetworkConnection.java:689)
> 
> 
> It seems, from the code, that the connection times out. The NPE is
> infortunate -and we will fix it- but it’s just masking the real cause: the
> handshake never ends.
> 
> What is the scenario you are running?

Especially, which LDAP server do you use?

In error3.txt and error4.txt I see multiple logs messages "User "userX"
successfully authenticated". Does that mean in those cases the
connection to LDAP worked and it only fails randomly? It seems there are
multiple threads involved, so maybe it's a concurrency issue...

Re: Toward a 2.0 GA

[Stefan Seelmann]

On 1/11/19 11:09 AM, Emmanuel Lécharny wrote:
> Hi guys,
> 
> 
> I'm currently checking all the pending JIRAs, trying to evaluate those
> that need to be closed in the coming release, those that are invalid,
> and those that need to be postponed.
> 
> While doing that, I see there are quite a few important ones related to
> TLS and security checks that probably need to be addressed before we cut
> a 2.0 GA (which means the next release with still be a milestone).
> 
> Here are the JIRA I'm interested in, ordered accordingly to some release
> roadmap (mine ;-) :
> 
> To be fixed for the next milestone
> --
> DIRAPI-69, API does not allow StartTLS hostname verification
> DIRAPI-72, Provide a default TrustManager for hostname verification to
> comply with RFC 2830 Section 3.6
> DIRAPI-298, Inconsistent SASL bind API : add the missing bindGssApi()
> method
> DIRAPI-299, Unable to change expired password unless logging in as admin.

I promised a mail regarding TLS some while ago but never wrote it. But
that are the points.

DIRAPI-301 you already fixed, so now the default JVM trust manager is
just, thanks for that.

The hostname verification should also be implemented, I agree. In Studio
that is implemented [1] by using DefaultHostnameVerifier from Apache
HTTP client library which is anyway included in Eclipse. This class does
not exacly what is defined in the LDAP RFC but better than nothing. If
we implement our own verifier in the LDAP API we can change it.

[1]
https://github.com/apache/directory-studio/blob/remove-jndi-provider-and-jndi-layer/plugins/connection.core/src/main/java/org/apache/directory/studio/connection/core/io/StudioTrustManager.java#L157

> To be fixed for 2.0GA
> -
> DIRAPI-136, Add the TLS closure alert support in the API
> DIRAPI-149, LdapNetworkConnection should not create user-Threads
> DIRAPI-202, Can't get LdapConnectionTemplate working
> DIRAPI-237, Make the API threadsafe
> DIRAPI-299, Unable to change expired password unless logging in as admin.
> DIRAPI-300, Weird batchResponse when batchRequest contains grammar error
> DIRAPI-320, ClassCastException on Objects.equals(Value,Value) for
> userPassword attribute

Sounds good. I don't plan beyond that :)

Re: Qustion regarding schema quirk mode

[Stefan Seelmann]

On 04/16/2018 11:40 PM, Emmanuel Lécharny wrote:
> Hi guys,
> 
> I'm trying to speedup the schema parsing (it's currently quite slow, due
> to the 3 embedded Antlr parsers we use).
> 
> We use a quirksMode to be able to process more than just the RFC 4512
> syntax. AFAICT, here are the relaxed rules :
> 
> o Allow prefixed numericOID, like attributeType ( DUAConfSchemaOID:1.0
> NAME 'defaultServerList' (assuming we have a DUAConfSchemaOID
> definedusing an objectidentifier definition)

I think that's for OpenLDAP OID macros

> o Avoid checking references (SUP, SYNTAX) between schema elements
> 
> o Allow the presence of special chars like '.', '_', ';', ':' and '#' in
> a NAME

Yes, because some LDAP servers allow such characters in names

> o Null OID are accepted for DitStructureRules

Hm, this is not quirk mode, DitStructureRules don't have an OID, right?

> Is there anything I'm missing ?
I think that's it. I hope we have tests to cover all those special cases.

Thanks,
Stefan

Re: Ldap API Custom Controls

[Stefan Seelmann]

On 10/05/2017 10:08 PM, Emmanuel Lécharny wrote:
> 
> 
> Le 05/10/2017 à 21:18, Chris Pike a écrit :
>> Emmanuel,
>>
>> We got this working. Is there a git repo for the directory api, or do we 
>> have to use subversion to provide the code back?
> 
> The API is in GIT now !
> 
> https://gitbox.apache.org/repos/asf?p=directory-ldap-api.git;a=summary
> 
> You can also use Github :
> 
> https://github.com/apache/directory-shared

Well, that's the old svn mirrored github repo.

I think the new gitbox mirrored one is
https://github.com/apache/directory-ldap-api

Once the other repos are migrated to git we need to request cleanup of
the github repos...

Re: Immutable SyntexCheckers

[Stefan Seelmann]

On 03/20/2017 08:12 AM, Emmanuel Lécharny wrote:
> 
> 
> Le 20/03/2017 à 07:37, Stefan Seelmann a écrit :
>> On 03/20/2017 02:10 AM, Emmanuel Lécharny wrote:
>>> public class BooleanSyntaxChecker extends SyntaxChecker
>>> {
>>> /**
>>>  * A static instance of BooleanSyntaxChecker
>>>  */
>>> public static final BooleanSyntaxChecker INSTANCE = new
>>> BooleanSyntaxChecker( SchemaConstants.BOOLEAN_SYNTAX );
>>>
>>> /** A static instance of the builder */
>>> private static final Builder BUILDER_INSTANCE = new Builder();
>>> /**
>>>  * @return An instance of the Builder for this class
>>>  */
>>> public static Builder builder()
>>> {
>>> return BUILDER_INSTANCE;
>>> }
>> Hm, why a static builder? As it is not immutable there's a chance of
>> race condition in case two threads use it concurrently.
> 
> That can't happen, because we have :
> 
> private static final Builder BUILDER_INSTANCE = new Builder();
> 
> that is guaranteed to be built during the class loading.

I agree about the creation of the builder instance.

But if two threads *use* it:
1. thread 1 calls builder()
2. thread 2 calls builder() and gets the same builder instance
3. thread 1 calls setOid("1.1.1")
4. thread 2 calls setOid("2.2.2")
5. thread 1 calls build() and may get an SC with OID "2.2.2"!

Re: Immutable SyntexCheckers

[Stefan Seelmann]

On 03/20/2017 02:10 AM, Emmanuel Lécharny wrote:
> public class BooleanSyntaxChecker extends SyntaxChecker
> {
> /**
>  * A static instance of BooleanSyntaxChecker
>  */
> public static final BooleanSyntaxChecker INSTANCE = new
> BooleanSyntaxChecker( SchemaConstants.BOOLEAN_SYNTAX );
>
> /** A static instance of the builder */
> private static final Builder BUILDER_INSTANCE = new Builder();

> /**
>  * @return An instance of the Builder for this class
>  */
> public static Builder builder()
> {
> return BUILDER_INSTANCE;
> }

Hm, why a static builder? As it is not immutable there's a chance of
race condition in case two threads use it concurrently.

Re: Immutable SyntexCheckers

[Stefan Seelmann]

On 03/17/2017 11:00 AM, Emmanuel Lécharny wrote:
> The only requirement is that each SC has its own builder (we can't put
> this code in the abstract SC, because it's abstract...)

With some generics magic it should at least be possible to move common
stuff (setOid) to the parent.

Otherwise, I'm not sure if it's worth to create builders for all the
"simple" syntax checkers (Boolean, DirectoryString, etc.) or if just a
singleton immutable instance is sufficient.

But in general it makes sense to have immutable syntax checkers :)

Re: Dn/Rdn/Ava refactoring : results

[Stefan Seelmann]

Many thanks Emmanuel, I'm looking forward t see it in trunk :)

On 05/09/2016 12:38 PM, Emmanuel Lécharny wrote:
> Hi !
> 
> that's it, I'm done with the refactoring. All tests are now passing
> green, even some that were ignored in trunk (typically things like DN
> with multiple Avas).
> 
> I have ran a small test, parsing various DN with 1 to 4 RDNs on trunks
> and on my branch, here are the results on 10 000 000 iterations each time :
> 
>  trunk branch
>  Nb secs   DN/sNb secs   DN/s Ratio
> 1 RDN  : 25.787  387,7928.852  1,129,688  x2.91
> 2 RDNs : 42.046  237,835   13.686730,674  x3.07
> 3 RDNs : 54.950  181,984   18.376544,188  x2.99
> 4 RDNs : 71.361  140,133   24.289411,709  x2.94
> 
> 
> Those benchmarks were conducted with a SchemaManager.
> 
> Bottom line, this is a x3 speed up ! I never expected that... OTIH, that
> means what we were doing was frankly bad :/
> 
> I'll commit the branch, and then work on ApacheDS and Studio to have
> them working well with the branch (all of that will be done in branches
> too).
> 
> I'll come with a list of changes I have done in the APi for you guys to
> review them and provide some feedback.
> 

Re: Prepare String

[Stefan Seelmann]

On 04/06/2016 01:05 AM, Emmanuel Lécharny wrote:
> So for the record, after a couple of hours working on it tonite, I get
> the DeepTrimToLowerNormalizer() working fine, with tests passing.
> 
> I was also able to improve the performances of the beast : from 20
> seconds to normalize 10 000 000 or String like "xs crvtbynU 
> Jikl7897790", down to 4.3s. I just assumed that most of the time, we
> will deal with chars between 0x00 and 0x7F, and wrote a specific
> function for that. If we have chars above 0x7F, then an exception is
> thrown and we fell back to the complexe process, which will then take
> 47s instead of 20s.
> 
> So this is a balance :
> - we have an implementation that covers all the chars, and takes 20s for
> 10M Strings
> - we have an implementation that tries to process the String if chars
> are in [0c00, 0x7F] and takes 4.3 s for 10M Strings, but takes 47
> seconds if we have a char outside this range.
> 
> Beside the obvious gain, there is another reason why I wanted to do that
> : processing IA5String values will benefit from this separation, and
> that covers numerous AttributeTypes (like mail, homeDirectory,
> memberUid, krb5principalname, krb5Realmname, and a lot more.
> 
> wdyt ? Going for an average of 20s no matter what, or accepting a huge
> penalty when the String does not contain ASCII chars ?

I'd go for the 2nd optimized way.

Is the cause of the penalty only the exception-throw-catch? Then maybe
it's worth to test if it improves when not throwing an excption but
returning a special flag (like null) and checking for that?

Kind Regards,
Stefan

Re: Prepare String

[Stefan Seelmann]

On 04/05/2016 10:48 AM, Emmanuel Lécharny wrote:
> One more step !
> 
> Yesterday evening, I as able to work on the DeepTrimToLowerNormalizer
> class, which is used to deal with the caseIgnoreMatch MatchingRule (the
> most crequent Matching Rule), and I discovered that the java
> Normalizer.normalize() method was already handling the combining
> characters, which is otherwise a nightmare to handle (well, not that
> much, but still). That will simplify the insignificantSpaceHandling
> process a LOT.
> 
> Here is what will look like the DeepTrimToLowerNormalizer.normalize(
> Value ) method :
> 
> public Value normalize( Value value, PrepareString.AssertionType
> assertionType ) throws LdapException
> {
> if ( value == null )
> {
> return null;
> }
> 
> try
> {
> // Transcoding
> String transcoded = PrepareString.transcode( value.getBytes() );
> 
> // Map
> String mapped = PrepareString.map( value,
> PrepareString.IGNORE_CASE );
>
> // Normalize
> String normalized = PrepareString.normalize( mapped );
>
> // Prohibit
> PrepareString.checkProhibited( normalized );
>
> // Bidi is ignored
>
> // Insignificant Characters Handling
> String normValue = PrepareString.insignificantSpaceHandling(
> normalized, assertionType );
> 
> return new Value( value.getAttributeType(),
> value.getValue(), normalized );
> }
> catch ( IOException ioe )
> {
> throw new LdapInvalidAttributeValueException(
> ResultCodeEnum.INVALID_ATTRIBUTE_SYNTAX, I18n.err(
> I18n.ERR_04224, value ), ioe );
> }
> }
> 
> Note that this method work only for Values or non-substrings assertions
> (ie, assertions used in a filter that is not a SubstringFilter). For
> substrings assertions (Initial, Any or Final, like the strings in a
> filter '(cn=test*abc*end)'), we have to add a new parameter to the
> normalize method. I'll deal with that later.
> 
> As you can see, this is all but simple... Making my way through the
> jungle though ;-)

Thanks Emmanuel for the update and the effort. It makes totally sense to
do it right, I'm sure we will benefit from it.

Kind Regards,
Stefan

Re: Upgrade Issues / Dealing with OSGI

[Stefan Seelmann]

In an OSGi environment the StandaloneLdapApiService (module
api-ldap-codec-standalone) should not be used at all.

Instead the bundle activator
org.apache.directory.api.ldap.codec.osgi.DefaultActivator creates and
registers the DefaultLdapCodecService.

Kind Regards,
Stefan

On 04/24/2015 01:25 AM, Gregory Chanan wrote:
 I wanted to upgrade the LDAP API version of my application to pick up
 https://issues.apache.org/jira/browse/DIRAPI-219.  Unfortunately, I hit
 some problems, namely:
 
  java.lang.IllegalAccessError: tried to access field
 org.apache.directory.api.ldap.codec.osgi.DefaultLdapCodecService.controlFactories
 from class
 org.apache.directory.api.ldap.codec.standalone.StandaloneLdapApiService
 
 I tracked this down to upgrading from M21 to M22 (i.e. my code works with
 M21, doesn't work with M22), where it looks like DefaultLdapCodecService is
 now a superclass of StandaloneLdapApiService.  StackOverflow suggests this
 can be caused by different class loaders:
 http://stackoverflow.com/questions/3386662/illegalaccesserror-accessing-a-protected-method/3387520#3387520
 
 Has anyone seen this?  Is there a suggested workaround?
 
 FWIW I was able to get my application to work by adding:
 
 DefaultLdapCodecService dlcs = new DefaultLdapCodecService();
 LdapApiServiceFactory.initialize(dlcs);
 before the problematic line:
 ds = new DefaultDirectoryService();
 but I'm not sure what the implication of using DefaultLdapCodecService
 compared to StandaloneLdapApiService (which is what gets loaded if you
 don't manually initialize the LdapApiServiceFactory.
 
 The application is Hadoop MiniKdc, see here:
 https://github.com/apache/hadoop/blob/e3496499ecb8d220fba99dc5ed4c99c8f9e33bb1/hadoop-common-project/hadoop-minikdc/src/main/java/org/apache/hadoop/minikdc/MiniKdc.java#L324
 
 Here's the entire stack trace (this is running in maven surefire):
 java.lang.IllegalAccessError: tried to access field
 org.apache.directory.api.ldap.codec.osgi.DefaultLdapCodecService.controlFactories
 from class
 org.apache.directory.api.ldap.codec.standalone.StandaloneLdapApiService
 at
 org.apache.directory.api.ldap.codec.standalone.StandaloneLdapApiService.init(StandaloneLdapApiService.java:148)
 at
 org.apache.directory.api.ldap.codec.standalone.StandaloneLdapApiService.init(StandaloneLdapApiService.java:142)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
 at java.lang.Class.newInstance0(Class.java:374)
 at java.lang.Class.newInstance(Class.java:327)
 at
 org.apache.directory.api.ldap.codec.api.LdapApiServiceFactory.initialize(LdapApiServiceFactory.java:127)
 at
 org.apache.directory.api.ldap.codec.api.LdapApiServiceFactory.getSingleton(LdapApiServiceFactory.java:89)
 at
 org.apache.directory.server.core.DefaultDirectoryService.init(DefaultDirectoryService.java:150)
 at
 org.apache.hadoop.minikdc.MiniKdc.initDirectoryService(MiniKdc.java:335)
 at org.apache.hadoop.minikdc.MiniKdc.start(MiniKdc.java:327)
 at
 org.apache.hadoop.minikdc.KerberosSecurityTestcase.startMiniKdc(KerberosSecurityTestcase.java:49)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
 at
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
 at
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
 at
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
 at
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
 at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
 at
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
 at
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
 at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
 at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
 at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
 at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
 at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
 at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
 at
 org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:254)
 at
 

Re: Request for slf4j import package in API bundles changes

[Stefan Seelmann]

On 04/15/2015 08:43 AM, Stefan Seelmann wrote:
 On 04/08/2015 10:57 PM, Benjamin Abernathy wrote:
 Stefan,

 I think I have found a reasonable solution. I implemented it and it
 passes the integration tests as well as solves the problem I am
 experiencing in OSGi. Here is what I did.

 1. I updated the parent pom by adding the following properties:

 slf4j.api.version.min1.7/slf4j.api.version.min
 slf4j.api.version.max1.8/slf4j.api.version.max

 2. Then in each child pom that had an import declaration for org.slf4j,
 I changed the import statement from:

 org.slf4j;version=${slf4j.api.version},

 to: 

 org.slf4j;version=[${slf4j.api.version.min},${slf4j.api.version.max}),


 This approach has some drawbacks:

 1. You now have three places that may need to be updated when the
 version of slf4j is updated. 
 2. BND (which is called by maven-bundle-plugin) is not the one deciding
 the what version should be used.

 Now, supposedly BND can choose a version range, but I could not get
 consistent behavior from the build using that approach.
 
 You mean the following? I tried to use BND range macro which magically
 works:
 
 org.slf4j;version=$«range;[==,=+)»,
 
 The result in mainifest is then org.slf4j;version=[1.7,1.8)
 
 But I didn't find lot of documenation why it works. And the maven build
 prints out a warning (but still it works):
 
 [INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @
 api-ldap-model ---
 [WARNING] Bundle
 org.apache.directory.api:api-ldap-model:bundle:1.0.0-M30-SNAPSHOT : No
 translation found for macro: range;[==,=+), in
 

I think I finally found a good solution.

In parent pom I added a property that defines the range macro

  slf4j.api.bundleversion$«range;[==,=+)»/slf4j.api.bundleversion

And in the actual poms the Import-Package instruction just looks like this

  org.slf4j;version=${slf4j.api.bundleversion},

So in case the macro magic makes problems we just have to change the
property in parent pom. All tests (API, ApacheDS, Studio) work fine,
I'll commit the changes tomorrow.

Kind Regards,
Stefan

Re: Request for slf4j import package in API bundles changes

[Stefan Seelmann]

On 04/08/2015 10:57 PM, Benjamin Abernathy wrote:
 Stefan,
 
 I think I have found a reasonable solution. I implemented it and it
 passes the integration tests as well as solves the problem I am
 experiencing in OSGi. Here is what I did.
 
 1. I updated the parent pom by adding the following properties:
 
 slf4j.api.version.min1.7/slf4j.api.version.min
 slf4j.api.version.max1.8/slf4j.api.version.max
 
 2. Then in each child pom that had an import declaration for org.slf4j,
 I changed the import statement from:
 
 org.slf4j;version=${slf4j.api.version},
 
 to: 
 
 org.slf4j;version=[${slf4j.api.version.min},${slf4j.api.version.max}),
 
 
 This approach has some drawbacks:
 
 1. You now have three places that may need to be updated when the
 version of slf4j is updated. 
 2. BND (which is called by maven-bundle-plugin) is not the one deciding
 the what version should be used.
 
 Now, supposedly BND can choose a version range, but I could not get
 consistent behavior from the build using that approach.

You mean the following? I tried to use BND range macro which magically
works:

org.slf4j;version=$«range;[==,=+)»,

The result in mainifest is then org.slf4j;version=[1.7,1.8)

But I didn't find lot of documenation why it works. And the maven build
prints out a warning (but still it works):

[INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @
api-ldap-model ---
[WARNING] Bundle
org.apache.directory.api:api-ldap-model:bundle:1.0.0-M30-SNAPSHOT : No
translation found for macro: range;[==,=+), in

 The changes are pretty simple, although it does touch the majority of
 the POMs. Let me know if you'd like to me submit a patch.
 
 Thanks,
 
 Ben
 

Re: Request for slf4j import package in API bundles changes

[Stefan Seelmann]

On 04/06/2015 11:26 PM, Benjamin Abernathy wrote:
 Hello,
 
 I need to deploy version 1.0.0-M30 of the API bundles into an instance
 of ServiceMix 5.3.0. Unfortunately ServiceMix (actually Karaf I think)
 includes slf4j as a system bundle so its headers are made available to
 all bundles. This makes it not possible to install the LDAP API bundles
 because the system exports version 1.7.7 and the API bundles require
 1.7.10. 
 
 Would it be possible to open up the import version to import a wider
 range of versions? For example, perhaps [1.7.0,1.8.0).

We use maven-bundle-plugin to generate the manifest.mf. I think I read
that it is possible to use some expression that generates such a range.
I have to investigate on that. If you have any useful pointers would be
helpful.

Kind Regards,
Stefan

Re: Client API Schema support

[Stefan Seelmann]

On 02/06/2015 10:35 PM, Stefan Seelmann wrote:
 On 02/06/2015 04:17 PM, Radovan Semancik wrote:
 Hi,

 After some delay I finally found a time to work on this. After few
 simple fixes I got to this:

 java.text.ParseException: ERR_04243 Parser failure on matching rule
 description:
 ( 1.3.6.1.4.1.26027.1.4.6 NAME ( 'relativeTimeLTOrderingMatch'
 'relativeTimeOrderingMatch.lt' ) SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 )
 Antlr message: unexpected token:
 Antlr column: 33

  I'm quite new to antlr and I'm still tring to find my way around. But
 I'm sure that there is someone on the list that can save me a huge
 amount of time. I do not expect anyone to fix this for me ... but ...
 the grammar is not trivial and it is difficult to figure out what
 exactly is wrong. How do you usually debug the antlr rule? Is there any
 logging mode that can be turned on and which will dump the tokens and
 rules that antlr encoures? Or some other trick?
 
 Short answer: for all the schema parsers (in this case
 MatchingRuleDescriptionSchemaParser) enable the quirks mode with
 setQuirksMode(true). The 2nd name contains a dot which is not allowed
 according to RFC 4512, but the quirks mode relaxes that rule.
 
 I don't think there is a way to dump the antlr state. In general you
 need to debug through the generated AntlrSchemaParser. Please look into
 MatchingRuleDescriptionSchemaParser line 99. There we catch the original
 exception thrown by antlr which contains the detailed stack trace,
 probably it's not good to swallow the original exception and stack trace.

Current trunk improves this a bit, the original exception is not added
as cause. But the error message is still not always very helpful...

Kind Regards,
Stefan

Re: Proper use of LdapConnectionPool

[Stefan Seelmann]

Hi Harris,

can you tell a bit about your directory structure? Do you have a flat
directory i.e. all Persons you are query for are below one OU, our do
you have a nested hierarchical directory structure?

Looking at the code I guess the latter is the case, and then it is clear
that onelevel search isn't working.

* You get the entry of the CEO.
* You get the directreports attribute which seems to contain DNs
* For each of those DNs you construct a new search, with the same search
base, the search filter includes the one DN.

== In that case I think you can use the DN directly as search base and
search scope object, because you already know the DN. The LDAP API
also contains a lookup method that you can use.

Kind Regards,
Stefan


 ... 
   SearchRequest sr = new SearchRequestImpl();
   sr.setBase(new Dn(searchBase));
 ...
   sb.append(((objectClass=person)(distinguishedName=)
 
 .append(replaceFilterSpecialCharactersWithHexRepresentation(distinguishedName))
 .append()));
 ...   
   .setDirectReports(entry.get( 
 directreports ))

Re: [Shared] API Design Questionnaire #1

[Stefan Seelmann]

On Sun, Jan 30, 2011 at 5:11 PM, Alex Karasulu akaras...@apache.org wrote:
 On Sun, Jan 30, 2011 at 3:17 AM, Emmanuel Lecharny elecha...@gmail.comwrote:

 On 1/29/11 10:38 PM, Stefan Seelmann wrote:


  [X] - (c)
            interface                                 = AddRequest
            simple API exposed implementation         = AddRequest*Impl*
            not so simple internal use implementation =
 AddRequest*Decoder*
 We're applying option 'C' right now. I'm torn but think A might suite us
 better for the long term, and for any situation. You also know what's an
 interface and what's not although the IDE automatically shows you this
 stuff
 on the package/class browser.

 This is my opinion for a low-level API, which 1:1 maps LDAP
 terminology to the Java API. I think we should additional have a
 simplified API where the user don't need to deal with request and
 response objects at all.

 BTW: We have this discussion again and again ;-) We really need to
 decide a consistent naming.


 I think we already discussed it more than once, and we all agreed on this
 convention.

 I'm not sure we want to rehash this again every 2 years :/


 When there's a push to release a 1.0 of an API, we need to make the API
 consistent. I can do this myself but the community way is to have a
 discussion. If  you do not want to discuss this feel free not to
 participate, or say you don't care.

I don't see that anyone said that the API development should not be
community driven.

In shared and apacheds we currently us a mix of the *Impl* suffix and
the *Default/whatever* prefix for classes. I only count two
interfaces with the *I* prefix, that is probably caused because they
were moved from studio to shared. In studio there are many more *I*
prefixed interfaces, which was inspired by the Eclipse naming
conventions. But afaik we never used *I* prefix in shared or apacheds.

Oh, I just searched for *I* prefixed files, and now there are 14 more, why that?

$ find shared -name I[A-Z]*.java | cut -d / -f 9-
shared/dsmlv2/IAction.java
shared/dsmlv2/IGrammar.java
shared/ldap/codec/controls/ppolicy/IPasswordPolicyRequest.java
shared/ldap/codec/controls/ppolicy/IPasswordPolicyResponse.java
shared/ldap/codec/controls/replication/syncDoneValue/ISyncDoneValue.java
shared/ldap/codec/controls/replication/syncInfoValue/ISyncInfoValue.java
shared/ldap/codec/controls/replication/syncmodifydn/ISyncModifyDn.java
shared/ldap/codec/controls/replication/syncRequestValue/ISyncRequestValue.java
shared/ldap/codec/controls/replication/syncStateValue/ISyncStateValue.java
shared/ldap/codec/ICodecControl.java
shared/ldap/codec/IControlFactory.java
shared/ldap/codec/IDecorator.java
shared/ldap/codec/IExtendedOpFactory.java
shared/ldap/codec/ILdapCodecService.java
shared/ldap/codec/ITestCodecControl.java
shared/ldap/codec/ITestControl.java

Kind Regards,
Stefan

Re: [Shared] API Design Questionnaire #1

[Stefan Seelmann]

On Fri, Jan 28, 2011 at 5:58 PM, Alex Karasulu akaras...@apache.org wrote:
 Hi community,

 Now that we're coming close to finishing up the shared refactoring we have
 to make some choices. Not all these choices have major impacts but some
 might. In the past we could do what we liked and change our minds etc. Now
 with a 1.0 of the shared libraries as the future mother of all Java LDAP
 APIs we're going to have to live with our choices.

 To opine, just place an 'X' in an option [  ] box.


 (1) ModifyRequest has a bunch of methods that were recently added to perform
 the same operations that you use the Modification interface for. This is
 redundant in my opinion and adds more unnecessary surface area. We don't
 need it and don't need an optional path to do the same thing confusing our
 users.  I suggest removing them.

 [  ] Yes - get rid of extra optional methods
 [X ] No  - keep the extra optional methods
 [  ] --- - I don't care about this stuff

I think the extra methods makes it much easier to construct a
ModifyRequest, one line of code instead of three lines:

ModifyRequest request = ...;
request.replace(mail, value1, value2, value3);
is equivalent to
ModifyRequest request = ...;
EntryAttribute attribute = new DefaultEntryAttribute((mail,
value1, value2, value3);
Modification mod = new
DefaultModification(ModificationOperation.REPLACE, attribute);
request.addModification(mod);

IMO those are very close to LDIF syntax, I like them.

But it makes sense to rename the methods:
- remove - addRemoveModification
- add - addAddModification
- replace - addReplaceModification
Additional those methods should return the created Modification object.
At last we may remove the addModification() methods.


 (2) Interfaces verses simple/basic classes implementing them have been
 something I've swayed back and forth on. Here are the options but note I am
 just using AddRequest as an example.

 [ ] - (a)
            interface                                 = *I*AddRequest
            simple API exposed implementation         = AddRequest
            not so simple internal use implementation = AddRequest*Decoder*
 [  ] - (b)
            interface                                 = AddRequest
            simple API exposed implementation         = *Simple*AddRequest
            not so simple internal use implementation = AddRequest*Decoder*
 [X] - (c)
            interface                                 = AddRequest
            simple API exposed implementation         = AddRequest*Impl*
            not so simple internal use implementation = AddRequest*Decoder*
 [  ] - (d)
            interface                                 = AddRequest
            simple API exposed implementation         = *Basic*AddRequest
            not so simple internal use implementation = AddRequest*Decoder*

 [  ] - (e) I pick the fat lady with the pink tutu 

 We're applying option 'C' right now. I'm torn but think A might suite us
 better for the long term, and for any situation. You also know what's an
 interface and what's not although the IDE automatically shows you this stuff
 on the package/class browser.

This is my opinion for a low-level API, which 1:1 maps LDAP
terminology to the Java API. I think we should additional have a
simplified API where the user don't need to deal with request and
response objects at all.

BTW: We have this discussion again and again ;-) We really need to
decide a consistent naming.


 (3) JNDI remnants are somewhat still present even if we've gotten rid of
 most of them. In the model interfaces for Control, ExtendedRequest, and
 ExtendedResponse (IntermediateResponse as well but this has nothing to do
 with JNDI) we have exposed access to ASN.1 encoded data. I think this is a
 big mistake to do in the public API.

 Controls and extended operation interfaces should simply expose
 parameters/properties leaving the rest up to the CODEC to handle. There
 should be no need to get or set the entire ASN.1 blob for the control or
 extended operation's request response pair. What good does it do anyway?
 It's just opening the door for users to incorrectly alter properly encoded
 ASN.1 data causing problems. I think the getValue() setValue() methods
 remained after we ran screaming away from JNDI. But it seems these
 interfaces remained and now they're a liability. Where manipulation of the
 binary ASN.1 data is needed we can leave this up to the CODEC under a
 decorator to do.

 I recommend removing these, what do you think?

 [X] Yes - Remove them, they are more bad then good
 [  ] No  - Don't remove them, I like using em
 [  ] --- - I don't give a rat's a**

I see you already removed the methods, sorry for not responding in time...

Kind Regards,
Stefan

[DISCUSS] Close api@ list

[Stefan Seelmann]

Hi guys,

I'd like to propose (again) to close this api@ list.

It was created to work together with the OpenDS guys on a new API. But
unfortunately due to Oracle's acquisition of Sun this doesn't happen
any more. Not sure if there will be a revival with ForgeRock/OpenDJ
folks?

I think it is best to continue discussion about the API design at the
dev@ list for several reasons:
- the aim to create a vendor-neutral API failed, we just work on an
Apache LDAP API
- IMHO the API is/becomes a first-class citizen like ApacheDS or Studio
- currently the API discussion is splitted, some discussion happens
here, other discussions happen on the dev@ list

Is anyone subscribed and still interested on this api@ list but not on
the dev@ list and would appreciate to continue API dicussions here?

WDYT?

Kind Regards,
Stefan

Re: [DISCUSSION] General API SPI Concerns

[Stefan Seelmann]

On Thu, Jan 6, 2011 at 3:43 PM, Emmanuel Lecharny elecha...@gmail.com wrote:
 On 1/6/11 2:58 PM, Alex Karasulu wrote:

 However, the schema manipulation API is in the scope of this discussion.


 This is part of the LDAP API and is as critical as Dn, or Entry since it's
 tied together.

 Damn, I overlooked this part. yes, you are totally right here, as soon as
 the LdapAPI provide Schema aware objects...

 Partition and configuration are not part of the Ldap API, thus are
 irrelevant in this discussion about shared refactoring.


 Right this has nothing to do with shared APIs but is relavent to the
 server.
 The same policies in API maintenance in shared will have to be applied to
 the server.

 yes, +1. I just want to discuss the server API in the server ML, to avoid
 confusion.

 /snip
 This is not to blame anyone. I am pointing out the problem, and pointing
 out
 a solution to it so we're not screwed by it. The web of dependencies in
 shared will f**k us down the line if we don't nix em now.

 I'm wondering what would be the best way to get rid of those coupling... May
 be creating many maven modules (one per package) then we will immediately
 see the invalid coupling ? Or is there any tool we can use to detect the bad
 coupling ?

JDepend is such a tool that helps to detect dependencies between packages

There is a maven plugin that creates a report, see [1] for an example,
especially the cycles section. But please note that this report is
from November because the site generation is broken, I have to
check...

There is also an Eclipse plugin available, just search for JDepend in
the eclipse marketplace.

Kind Regards,
Stefan


[1] 
https://hudson.apache.org/hudson/view/A-F/view/Directory/job/dir-shared-site/site/shared-ldap/jdepend-report.html

Re: [DISCUSSION] General API SPI Concerns

[Stefan Seelmann]

On Thu, Jan 6, 2011 at 2:58 PM, Alex Karasulu akaras...@apache.org wrote:
  In the end, dependency upon further transitive dependencies are making us
 expose almost all implementation classes in shared, and most can easily be
 decoupled and hidden. It's effectively making everything in shared come
 together in one big heap exposing way more than we want to.

 It's quite impossible in Java to 'hide' all the classes that a user should
 not manipulate. Unless you use package protected classes, and it quickly has
 a limit, I would rather think in term of 'exposed' (ie documented) API.


 OSGi bundles really helps in this respect. It fills in where Java left off.

 OSGi makes it so the (bundle) packaging coincides with module boundaries. In
 Java this is loose and there's leakage all over, as you say, it's very hard
 to hide all implementation classes.


 That this documented API is gathered in one separate module for convenience
 is another aspect, but the user will still have to depend on all the other
 modules.


 Certainly, you're right, dependencies will still exist. A codec will be
 depended upon for it's functionality even if we do hide the implementation
 details under the hood.

 The value add here is not from avoiding a dependency. It's from not exposing
 more than we have to and being able to hide the implementation. This way we
 can change the implementation at will across point releases without having
 to bump up to a major revision.


 So all in all, should we define a module (a maven module) containing the
 public API and the associated implementation ? Probably (But this is not an
 absolute necessity). I guess this is what you have in mind, so let's see
 what's the proposal is...


 We have multiple options for chopping this up. With bundles we have a nice
 tool to carve out physical not just logical boundaries to our API's and only
 expose those packages we need to show API users.







 LDAP Client API
 

 Everyone agrees that this API is very important to get right with a 1.0.
 Right now this API pulls in several public interfaces directly from
 shared.
 Those interfaces also pull in some implementation classes. The logical API
 extends into shared this way. Effectively the majority of shared is
 exposed
 by the client API. The client API does not end at it's jar boundary.

 All this exposure increases the chances of API change when all
 implementation details are wide open and part of the client API.  And this
 is what I'm trying to limit. There are ways we can decouple these
 dependencies very nicely with a mixed bag of refactoring techniques while
 breaking up shared-ldap into lesser more coherent modules. The idea is to
 expose the bare minimum of only what we need to expose. Yes the shared
 code
 has become very stable over time but the most stability is in the
 interfaces
 and if we only expose these instead of implementation classes then we'll
 have an awesome API that may remain 1.X for a while and not require
 deprecations as new functionality is introduced.


 How will you limit the visibility of the modules you don't want the user to
 be exposed to ?


 A combination of refactoring techniques will be used to be able to better
 use standard Java protection mechanisms to hide implementation details
 combined with using OSGi bundles instead of Jars to only export those
 packages that we do want users to see.

Alex, I agree with you that separating interfaces and implemenation
details is a good thing. Also creating OSGi bundles with a minimal set
exported packages is a good thing. But it only helps if the bundles
are used in an OSGI environment.

I think we'll continue to deploy those OSGi bundles (which are just
Jars with a good META-INF/MANIFEST.MF) to maven central. And each user
using those Jars will see and can use all classes, when not using an
OSGI environment.

So I think we need additional techniques for non-OSGi users to let
them know which packages to use, for example:
- Use a naming convention for internal packages, the name internal
is used in Eclipse and Apache Felix, not sure if is specified in OSGi.
- Create separate Jars for API and implementation (e.g. xyz-api.jar
and xyz-impl.jar)

Kind Regards,
Stefan

Re: issues in compiling latest checked out src..

[Stefan Seelmann]

For quick success you can try to run
  mvn clean install -DskipTests
That skips the test itself, but installs the required test artifacts.

I think we should create a api-with-dependencies, that includes all
required modules (shared, checkstyle, etc.)

Another must is to setup a working CI build and to deploy the
artifacts to the snapshot repository. We should also create a CI build
on a Windows machine. Alex granted me access to Hudson, I'll try if it
works and set it up tonight.

Kind Regards,
Stefan

Re: DN and valueOf( a DN ) method

[Stefan Seelmann]

 I was thinking lately about the DN class. I know that OpenDS (and probably
 UnboundId, but not sure) has a DN.valueOf( a DN ) factory that returns a
 DN potentially leveraging a cache associated to a ThreadLocal.

...

 I don't think it's such a good idea :
 - first, as it's ThreadLocal based, you will have as many cache as you have
 threads processing requests. Not sure it competes with a unique cache, not
 sure either we can't use the memory in a better way...

An advantage to use ThreadLocal is that you don't need to synchronize
access to the cache Could be worth to measure the performance
difference, I wonder if the OpenDS team did some performance analysis?

Re: Should the BIND throw an Exception ?

[Stefan Seelmann]

Emmanuel Lecharny wrote:
 Hi guys,
 
 long time, no see ... Lots of side work going on, but still progressing
 on the API.
 
 I have a question though : should the LdapConnection.bind()operation
 throw an exception, or not ?
 
 Currently we have a version that returns a BindResponse, which is
 convenient but a bit painful if you have got an error, as you have to
 check the response before using the connection.
 
 Wouldn't it be better to just throw an LdapException, containing the
 Bindresponse elements, à la JNDI ?
 
 wdyt ?

Short answer: yes, let's throw an exception.

I thought about it. There are two different paradigms:
- LDAP returns status codes. Not each status code  0 is an error.
- In Java we are used to use Exceptions

I already falled in this trap when I used the modify operation and I
expected an exception but only received the response and had to check
the response.

Maybe we should take the list of all response codes and decide in which
cases we throw an exception and in which cases we just return the
response object. Additional we could make this list configurable by the
user of the API and provide some predefined configurations (throw
always, throw never, default settings).

Here is my first try, feel free to comment:

  success  (0),
  operationsError  (1), -- Exception
  protocolError(2), -- Exception
  timeLimitExceeded(3),
  sizeLimitExceeded(4),
  compareFalse (5),
  compareTrue  (6),
  authMethodNotSupported   (7), -- Exception
  strongerAuthRequired (8), -- Exception
   -- 9 reserved --
  referral (10),
  adminLimitExceeded   (11),
  unavailableCriticalExtension (12),-- Exception
  confidentialityRequired  (13),-- Exception
  saslBindInProgress   (14),
  noSuchAttribute  (16),-- Exception
  undefinedAttributeType   (17),-- Exception
  inappropriateMatching(18),-- Exception
  constraintViolation  (19),-- Exception
  attributeOrValueExists   (20),-- Exception
  invalidAttributeSyntax   (21),-- Exception
   -- 22-31 unused --
  noSuchObject (32),-- Exception
  aliasProblem (33),-- Exception
  invalidDNSyntax  (34),-- Exception
   -- 35 reserved for undefined isLeaf --
  aliasDereferencingProblem(36),-- Exception
   -- 37-47 unused --
  inappropriateAuthentication  (48),-- Exception
  invalidCredentials   (49),-- Exception
  insufficientAccessRights (50),-- Exception
  busy (51),-- Exception
  unavailable  (52),-- Exception
  unwillingToPerform   (53),-- Exception
  loopDetect   (54),-- Exception
   -- 55-63 unused --
  namingViolation  (64),-- Exception
  objectClassViolation (65),-- Exception
  notAllowedOnNonLeaf  (66),-- Exception
  notAllowedOnRDN  (67),-- Exception
  entryAlreadyExists   (68),-- Exception
  objectClassModsProhibited(69),-- Exception
   -- 70 reserved for CLDAP --
  affectsMultipleDSAs  (71),-- Exception
   -- 72-79 unused --
  other(80),-- Exception



Kind Regards,
Stefan