directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "lucas theisen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DIRAPI-170) Allow StandaloneLdapApiServices to be configured without system properties
Date Thu, 26 Dec 2013 16:15:50 GMT

     [ https://issues.apache.org/jira/browse/DIRAPI-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

lucas theisen updated DIRAPI-170:
---------------------------------

    Attachment: DIRAPI-170.patch

I attached a patch for this issue.  It was a little more difficult than expected as there
are many classes that just assume the singleton factory is the place to get the service from
so even if I construct an LdapNetworkConnection with a hand configured service api, its parent
class was using the singleton factory to look it up again (which is odd, why would LdapNetworkConnection
have its own instance var instead of using its parents).  And other places did the same thing.
 So I went through and added an overloaded constructor in all the places that mattered so
that if you supply an LdapApiService to the LdapNetworkConnection constructor, all things
created by that connection will also use that service (I trusted the unit tests rather than
checking every line of code).

> Allow StandaloneLdapApiServices to be configured without system properties
> --------------------------------------------------------------------------
>
>                 Key: DIRAPI-170
>                 URL: https://issues.apache.org/jira/browse/DIRAPI-170
>             Project: Directory Client API
>          Issue Type: Improvement
>    Affects Versions: 1.0.0-M20
>            Reporter: lucas theisen
>            Priority: Critical
>         Attachments: DIRAPI-170.patch
>
>
> Requiring configuration via system properties makes the client api near unusable in situations
where you do not control startup of the application (like in a web container).  
> Also, DI containers don't work well with the Singleton factory approach as you don't
control the order in which your beans are constructed so you would have to be careful to initialize
the factory with your hand constructed service in every place that it might be used or the
default service may be initialized first forcing your custom initialization to fail.
> Finally, it just make sense to allow an LdapNetworkConnection to be configured independent
of any other LdapNetworkConnection.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Mime
View raw message