[
https://issues.apache.org/jira/browse/DIRAPI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201894#comment-14201894
]
Emmanuel Lecharny commented on DIRAPI-206:
------------------------------------------
I forgot to mention that using a flag that would be disabled or enabled through
an AP configuration is not going to happen : that would require to expose some
dedicated configuration, something we want to avoid at all cost.
I have removed the stacktrace, and the log is only produce when DEBUG is one
for this class (org.apache.directory.api.ldap.model.message.BindRequestImpl).
It's enough to set this logger to something different to DEBUg to not have it
in the logs.
> 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
> 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
> 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)
