directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Becker (JIRA)" <>
Subject [jira] [Commented] (DIRAPI-206) BindRequest logs exception on valid call to setter
Date Thu, 06 Nov 2014 23:36:34 GMT


Peter Becker commented on DIRAPI-206:

I'm not a big fan of Microsoft technologies, but no matter how I want things to be different,
fact of the matter is that when connecting to AD these user names are normal. I am not going
out to tell our customers not to use AD just because I don't like that -- chances are that
would reduce the number of customers significantly.

If you feel like putting a snarky comment in, feel free to call the AD toggle something in
the spirit of POI-HSSF, I think that's quite funny. For all I care you can use a property
"usersAreOnTheDarkSide". But throwing exceptions into my logs is not nice at all, I perceive
it as a political statement that causes pain to me without much chance of making an actual
difference. That is obviously just my opinion, but I have a feeling I'm not alone.

> BindRequest logs exception on valid call to setter
> --------------------------------------------------
>                 Key: DIRAPI-206
>                 URL:
>             Project: Directory Client API
>          Issue Type: Bug
>    Affects Versions: 1.0.0-M24
>            Reporter: Peter Becker
>            Assignee: Kiran Ayyagari
>             Fix For: 1.0.0-M25
> We are using DIRAPI to connect to our corporate ActiveDirectory and it seems impossible
to do so without getting an exception logged in our application log, even on successful operations.
This is a concern since the exception creates noise potentially hiding real issues.
> The problem is described in
but the resolution is not sufficient for our purposes.
> The issue is caused by this bit of code in BindRequestImpl:
> {code}
>     public BindRequest setName( String name )
>     {
> = name;
>         try
>         {
>             this.dn = new Dn( name );
>         }
>         catch ( LdapInvalidDnException e )
>         {
>             // This might still be a valid DN (Windows AD binding for instance)
>    "Unable to convert the name to a DN.", e );
>             this.dn = null;
>         }
>         return this;
>     }
> {code}
> The comment even indicates that the call might be perfectly valid. I think it would be
much better to either drop the exception completely, or -- if it is required in other scenarios
-- to skip the attempt of creating the DN field completely if some flag is set (extra parameter
/ field / subclass). Since the name field is private it can not be done from the client side.
> This is a potential showstopper for us -- we do not like telling our support staff to
ignore exceptions in logs.

This message was sent by Atlassian JIRA

View raw message