[
https://issues.apache.org/jira/browse/DIRAPI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201573#comment-14201573
]
Peter Becker commented on DIRAPI-206:
-------------------------------------
Emmanuel: that seems sensible assuming the exception itself is not important in
any scenario. Otherwise you would potentially lose information in those cases
where you did not expect the conversion to fail. I can't judge that.
Having it at info still means every log in attempt could log a line in
production, which could raise concerns with support staff. After all it is
still a failure message they will see. I'd prefer debug level. Or at least to
re-phrase that it is normal, e.g. "Unable to convert the user name to a DN, we
assume the server allows non-DN user names." (or something like that).
For me the {{activeDirectoryMode}} still seems the best option, or something
more specific like {{convertUsernameToDn}}. If on -> don't even try to convert
to DN; if off -> conversion failure is a real problem and needs to be reported.
But my main goal is to get rid of the stack traces, they make people nervous.
> 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)
