[
https://issues.apache.org/jira/browse/DIRAPI-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14201210#comment-14201210
]
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: 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)
