directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Becker (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DIRAPI-206) BindRequest logs exception on valid call to setter
Date Fri, 31 Oct 2014 01:49:33 GMT
Peter Becker created DIRAPI-206:
-----------------------------------

             Summary: BindRequest logs exception on valid call to setter
                 Key: DIRAPI-206
                 URL: https://issues.apache.org/jira/browse/DIRAPI-206
             Project: Directory Client API
          Issue Type: Bug
    Affects Versions: 1.0.0-M24
            Reporter: Peter Becker


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 http://t211471.apache-directory-api.apachetalks.us/binding-and-active-directory-t211471.html
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 )
    {
        this.name = name;

        try
        {
            this.dn = new Dn( name );
        }
        catch ( LdapInvalidDnException e )
        {
            // This might still be a valid DN (Windows AD binding for instance)
            LOG.info( "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
(v6.3.4#6332)

Mime
View raw message