[
https://issues.apache.org/jira/browse/DIRAPI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14200968#comment-14200968
]
Peter Becker commented on DIRAPI-206:
-------------------------------------
The solution still breaks the rule of using exceptions only for exceptional
cases. The performance overhead doesn't matter much here since the LDAP part
will be much more expensive, but I still don't think it's a good idea. And
having a stack trace in any log for me is a massive warning sign, it should
happen only if something went wrong.
As a developer I constantly run code with debug logging on across the board,
the new solution will still force me to tweak my logging configuration. Worse:
every new person to this will first have to do research as to why they see the
exception, to then realize it's not their fault.
Also: if I would be in a mixed scenario where I would talk to Active Directory
and other LDAPs (which I might be in the future), then there is no logging
configuration that is correct: either I get stack traces that shouldn't be
there, or I might miss a problem.
Switching to debug reduces the pain, but it doesn't really solve the real
problem.
> 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)
