On 3/15/07, Alex Karasulu <[EMAIL PROTECTED]> wrote:
On 3/12/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
> ...
> I could also move over the 3 properties that are used by the LDAP PP
> from the ServerStartupConfiguration:
>
> maxSizeLimit
> maxTimeLimit
> isAllowAnonymousAccess
There are a couple snags to watch out for. First you want to make sure
those configuration parameters are not used by the core context factory.
Secondly watch out for maven dependency issues ... these have come up on
occasion.
Right, what I'm proposing will improve dependency issues. For
starters by inverting the dependency the LDAP protocol provider has on
StartupConfiguration. Instead, ServerContextFactory depends on
LdapConfiguration.
Other than that I cannot see many issues. However what's wrong with keeping
these configuration properties together with the configuration objects?
Keeping the configuration in one place may have advantages for us later when
we clean things up and put all these parameters into the DIT under the
system partition for DIT based configuration.
Anytime you keep anything together, you are restricting modularity.
Today the assumption is that users of the
ServerContextFactory/ServerStartupConfiguration want to use both the
LDAP and Kerberos protocols. This may be correct for most people, but
it simply doesn't scale, especially when you consider the addition of
richer configuration for LDAP/SASL and the Kerberos, DNS, DHCP, and
NTP protocols.
As for helping us later, I disagree. Making configuration more
modular in fact makes a migration to anything new a bit easier. You
can move one bean at a time to what ever is new. If not we're looking
at some "big bang" migration.
Also I we need to think about what users might prefer. It might be easier
for embedders to have all the configuration options available in the startup
configurations either as part of that object or as a contained object like
the PartitionConfiguration etc. I think access should still occur from this
central location so users can drill down into contained objects etc with
ease. Or can this be done with what you're suggesting?
WDYT?
I think it is well-established that developers want modularity. As
for users, keep the configuration more modular means entire beans can
be left out of configuration if they are for a capability that is not
needed.
The central location for drilling-down into a bean will still be a
central startup class, like today's ServerContextFactory. I would
argue that having the LDAP bean separate is in fact easier to
drilldown into, since it isn't behind another class, namely the
StartupConfiguration or ServerStartupConfiguration class. These deep
drilldowns violate the law of Demeter, too.
Enrique
