You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ersin ER <er...@gmail.com> on 2009/03/18 18:41:41 UTC
ApacheDS ConfigNG - Was: Toward 2.0...
Let's continue discussion on next generation configuration mechanism for
ApacheDS in this thread.
BTW, we already have some notes on CiDIT:
http://cwiki.apache.org/DIRxSRVx11/configuration-in-dit-cidit.html
On Wed, Mar 18, 2009 at 18:37, Alex Karasulu <ak...@gmail.com> wrote:
> I'm down with CiDIT over xbean. I'd do this for 2.0. I hate this XML
> crap. Maybe this is something I can dedicate myself to as others work on
> replication.
>
> I think this XBean stuff is way to mysterious without any documentation.
>
> Alex
>
>
> On Tue, Mar 17, 2009 at 7:07 PM, Emmanuel Lecharny <el...@apache.org>wrote:
>
>>
>> - Documentation : This is also an something we must deliver.
>>>> Documentation is not only good for our users, it's also good for us, as
>>>> developpers, because writtng documentation helps to see where the API is not
>>>> consistent.
>>>>
>>>
>>> Main problem is the configuration, which has changed with each minor
>>> version. In order to make any progress here, we need to finalize the
>>> configuration for the 2.0 first. There must be a decision at some point
>>> about the technologies used etc. (XML, xbeans, stored in DIT, ...). We had
>>> discussions about this topic every month.
>>>
>>
>> Ok. Today, I spent something like 5 hours trying to get some new classes
>> injected into LdapService, and make them work nicely with xbeans. So far,
>> it's a plain failure.
>>
>> I will be very clear : if we are to continue with xbeans+spring, I will -1
>> the release. This is absolutely not mature, cryptic, unusable, undocumented.
>> In other words, it recalls me Maven 1.
>>
>> Unless xbeans reach another level of stability, I want it out of the
>> configuration. I'm fed of this piece of garbage.
>>
>> I think this is something we have to discuss at ApacheCon, but the
>> decision should be done on the ML.
>>
>>
>> --
>> --
>> cordialement, regards,
>> Emmanuel Lécharny
>> www.iktek.com
>> directory.apache.org
>>
>>
>>
>
--
Ersin ER
http://www.ersiner.net
Re: ApacheDS ConfigNG
Posted by Alex Karasulu <ak...@gmail.com>.
On Wed, Mar 18, 2009 at 4:51 PM, Stefan Zoerner <st...@labeo.de> wrote:
> Hi all!
>
> David Jencks wrote:
>
>> 1. in your list below there are at least 2 kinds of "type" info for the
>> parameters: known types (int) and objects where the main choice is which
>> class you use to implement an interface (Interceptor). I think these are
>> sort of qualitatively different but that is not clear from your notation.
>> As a sub-comment I don't know how you'd specify the implementation class
>> for a component in DIT but this is probably my own ignorance.
>>
>
> Perhaps a comparable point: Spring offers us extensibility (custom
> partitions, custom interceptors etc) ans these extension may have an
> arbitrary configuration.
>
> We must not loose that from my point of view.
>
Yes I agree. With that said we must and can make sure this capability is
preserved with a switch to CiDIT.
Alex
Re: ApacheDS ConfigNG
Posted by Stefan Zoerner <st...@labeo.de>.
Hi all!
David Jencks wrote:
> 1. in your list below there are at least 2 kinds of "type" info for the
> parameters: known types (int) and objects where the main choice is which
> class you use to implement an interface (Interceptor). I think these are
> sort of qualitatively different but that is not clear from your
> notation. As a sub-comment I don't know how you'd specify the
> implementation class for a component in DIT but this is probably my own
> ignorance.
Perhaps a comparable point: Spring offers us extensibility (custom
partitions, custom interceptors etc) ans these extension may have an
arbitrary configuration.
We must not loose that from my point of view.
Greetings from Ingolstadt,
Stefan
Re: ApacheDS ConfigNG
Posted by Emmanuel Lecharny <el...@apache.org>.
Ersin ER wrote:
> One of the things we should consider for a configuration mechanism is that
> whether this configuration format is for humans or is for tools. If it's for
> humans neither XML nor LDIF are good candidates. If it's for tools, both are
> fine and then there can be other criteria to select one or also both can be
> supported. I don't think one if superior to other in terms of
> expressiveness.
>
I think that it does not matter too much. Or, more generally, a
configuration mechanism should be versatile. From a human being, a GUI
is obviously the best. But that mean we need a tool to read the
configuration and to present it. Some prefer a text file (either because
it's lightweight, or because you don't have a graphic terminal available
), and then it should be straightforward. Of course, comments must be
present.
So what we need is a Configuration bean, loaded from a configuration
file, whatever the format of this file is.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ApacheDS ConfigNG
Posted by Ersin ER <er...@gmail.com>.
One of the things we should consider for a configuration mechanism is that
whether this configuration format is for humans or is for tools. If it's for
humans neither XML nor LDIF are good candidates. If it's for tools, both are
fine and then there can be other criteria to select one or also both can be
supported. I don't think one if superior to other in terms of
expressiveness.
On Wed, Mar 18, 2009 at 21:22, Emmanuel Lecharny <el...@apache.org>wrote:
> David Jencks wrote:
>
>> A couple comments...
>>
>> 1. in your list below there are at least 2 kinds of "type" info for the
>> parameters: known types (int) and objects where the main choice is which
>> class you use to implement an interface (Interceptor). I think these are
>> sort of qualitatively different but that is not clear from your notation.
>> As a sub-comment I don't know how you'd specify the implementation class
>> for a component in DIT but this is probably my own ignorance.
>>
> You're right : I forgot to give some clues to understand the list... So
> here they are :
>
> - Standard values (ie, Java types) don't have any + or * in front of them
> - Complex objects (ie objects which are defined somewhere else in the
> project have a '+'
> - Collections of Objects have a '*'. If it's a collection of complex
> object, then the class is given
>
>>
>> 2. Despite the unpleasantness of getting poked by all the pointy brackets
>> in xml it does make it pretty easy to express the tree structure of wired
>> together components in an easy to understand way. It's much less good at
>> showing non-tree graphs (you have to use some kind of reference). I think
>> this is pretty useful information that AFAIK would be completely obscured in
>> a DIT configuration model. On the other hand this wiring info is mostly
>> useful for advanced users that need to assemble a custom server; people
>> using a more or less plain server probably only need to change a few
>> "primitive" parameters.
>>
> IMO, the ConfigurationNG should be agnostic. Ie, I don't really mind if
> someone want to define a configuration using Spring, as soon as it has no
> impact on the code. For instance, OpenLDAP stilll have to ways to see the
> configuration : as a big slapd.conf property file, and as a config in the
> DiT (LDIF with sub-directories where you can find the children).
>
> Regarding the config in the DiT, the biggest advantage is that you keep the
> hierarchical vision, as LDAP is hierarchical. So you get the Tree structure
> for free. What is a bit more problematic is the attributeType you may have
> to define. OpenLDAP have created one AttributeType per object. here is an
> example :
>
> dn: cn=config
> objectClass: olcGlobal
> cn: config
> olcArgsFile: /var/run/slapd/slapd.args
> olcLogLevel: sync
> olcPidFile: /var/run/slapd/slapd.pid
> olcToolThreads: 1
> structuralObjectClass: olcGlobal
> olcServerID: 1
>
> (this is for the root configuration)
>
> We can also define one single AttributeType, and use options. Something
> like :
>
> dn: cn=replicationPerrConfig,cn=ldapService,cn=config
> objectClass: adsConfig
> cn: replicationPeerConfig
> adsConfig;interval: 30000
> adsConfig;password: secret
> adsConfig;principalDN: uid=admin,ou=system
> adsConfig;producer: ldap://localHost:10489/dc=example,dc=com
> adsConfig;refreshOnly: true
>
> This is just an option. It might be better to define attributeTypes for
> each parameter (I see two advantages to do so : (1) you can define the AT
> syntax and (2) you won't have a confusion between two AT with the same name)
>
> For composite Objects (for instance, in a Server, we define a Transport, it
> can be done using a DN pointing to the associated transport.
>
> In any case, there is no real problem to express the full server
> configuration using this notation.
>
> But we will have to define something we had in ancient age, a
> ServerConfiguration bean which will be in charge of loading the
> configuration. The fact is that we decided (O tempora, O mores ...) to
> replace it by Springshlplut... We were lazzy and in a hurry, and didn't
> resisted enough. That's our mistake. Anyway.
>
> If we have this configuration bean back, then it should be easy to
> implement a configuration reader based on the DIT, a propertyFile, JSon, XML
> or even Spring with xbeans !
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Ersin ER
http://www.ersiner.net
Re: ApacheDS ConfigNG
Posted by Emmanuel Lecharny <el...@apache.org>.
David Jencks wrote:
> A couple comments...
>
> 1. in your list below there are at least 2 kinds of "type" info for
> the parameters: known types (int) and objects where the main choice is
> which class you use to implement an interface (Interceptor). I think
> these are sort of qualitatively different but that is not clear from
> your notation. As a sub-comment I don't know how you'd specify the
> implementation class for a component in DIT but this is probably my
> own ignorance.
You're right : I forgot to give some clues to understand the list... So
here they are :
- Standard values (ie, Java types) don't have any + or * in front of them
- Complex objects (ie objects which are defined somewhere else in the
project have a '+'
- Collections of Objects have a '*'. If it's a collection of complex
object, then the class is given
>
> 2. Despite the unpleasantness of getting poked by all the pointy
> brackets in xml it does make it pretty easy to express the tree
> structure of wired together components in an easy to understand way.
> It's much less good at showing non-tree graphs (you have to use some
> kind of reference). I think this is pretty useful information that
> AFAIK would be completely obscured in a DIT configuration model. On
> the other hand this wiring info is mostly useful for advanced users
> that need to assemble a custom server; people using a more or less
> plain server probably only need to change a few "primitive" parameters.
IMO, the ConfigurationNG should be agnostic. Ie, I don't really mind if
someone want to define a configuration using Spring, as soon as it has
no impact on the code. For instance, OpenLDAP stilll have to ways to see
the configuration : as a big slapd.conf property file, and as a config
in the DiT (LDIF with sub-directories where you can find the children).
Regarding the config in the DiT, the biggest advantage is that you keep
the hierarchical vision, as LDAP is hierarchical. So you get the Tree
structure for free. What is a bit more problematic is the attributeType
you may have to define. OpenLDAP have created one AttributeType per
object. here is an example :
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: sync
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1
structuralObjectClass: olcGlobal
olcServerID: 1
(this is for the root configuration)
We can also define one single AttributeType, and use options. Something
like :
dn: cn=replicationPerrConfig,cn=ldapService,cn=config
objectClass: adsConfig
cn: replicationPeerConfig
adsConfig;interval: 30000
adsConfig;password: secret
adsConfig;principalDN: uid=admin,ou=system
adsConfig;producer: ldap://localHost:10489/dc=example,dc=com
adsConfig;refreshOnly: true
This is just an option. It might be better to define attributeTypes for
each parameter (I see two advantages to do so : (1) you can define the
AT syntax and (2) you won't have a confusion between two AT with the
same name)
For composite Objects (for instance, in a Server, we define a Transport,
it can be done using a DN pointing to the associated transport.
In any case, there is no real problem to express the full server
configuration using this notation.
But we will have to define something we had in ancient age, a
ServerConfiguration bean which will be in charge of loading the
configuration. The fact is that we decided (O tempora, O mores ...) to
replace it by Springshlplut... We were lazzy and in a hurry, and didn't
resisted enough. That's our mistake. Anyway.
If we have this configuration bean back, then it should be easy to
implement a configuration reader based on the DIT, a propertyFile, JSon,
XML or even Spring with xbeans !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ApacheDS ConfigNG
Posted by David Jencks <da...@yahoo.com>.
A couple comments...
1. in your list below there are at least 2 kinds of "type" info for
the parameters: known types (int) and objects where the main choice is
which class you use to implement an interface (Interceptor). I think
these are sort of qualitatively different but that is not clear from
your notation. As a sub-comment I don't know how you'd specify the
implementation class for a component in DIT but this is probably my
own ignorance.
2. Despite the unpleasantness of getting poked by all the pointy
brackets in xml it does make it pretty easy to express the tree
structure of wired together components in an easy to understand way.
It's much less good at showing non-tree graphs (you have to use some
kind of reference). I think this is pretty useful information that
AFAIK would be completely obscured in a DIT configuration model. On
the other hand this wiring info is mostly useful for advanced users
that need to assemble a custom server; people using a more or less
plain server probably only need to change a few "primitive" parameters.
thanks
david jencks
On Mar 18, 2009, at 11:03 AM, Emmanuel Lecharny wrote:
> Ersin ER wrote:
>> Let's continue discussion on next generation configuration
>> mechanism for
>> ApacheDS in this thread.
>>
>
> I have listed _all_ the parameters we currently want to manage, in
> all classes :
>
> DirectoryService
> ----------------
> accessControlEnabled : boolean;
> allowAnonymousAccess : boolean
> +changeLog : ChangeLog
> denormalizeOpAttrsEnabled : boolean
> exitVmOnShutdown : boolean
> id : String
> +journal : Journal
> maxPDUSize : int
> passordHidden : boolean
> replicaId : int
> +systemPartition : Partition
> workingDirectory : File
> *interceptors List<Interceptor> :
> org.apache.directory.server.core.interceptor.Interceptor
> *partitions Set<? extends Partition> :
> org.apache.directory.server.core.partition.Partition
> *testEntries List<? extends LdifEntry> :
> org.apache.directory.shared.ldap.ldif.Entry
>
>
> ChangeLog
> ---------
> enabled : boolean
> exposeChangeLog : boolean
> partitionSuffix : String
> revisionsContainerName : String
> tagsContainerName : String
> +changeLogStore : ChangeLogStore
>
>
> ChangeLogStore
> --------------
> No setters...
>
>
> Journal
> -------
> enabled : boolean
> +journalStore : JournalStore
>
>
> JournalStore
> ------------
> fileName : String
> workingDirectory : String
>
>
> Partition : JdbmPartition
> -------------------------
> cacheSize : int
> id : String
> optimizerEnabled : boolean
> suffix : String
> syncOnWrite : boolean
> *indexedAttributes Set<Index<?,ServerEntry>> indexedAttributes ) ???
> property( String propertyName, String propertyValue ???
>
>
> Index : JdbmIndex
> -----------------
> attributeId : String
> cacheSize : int
> numDupLimit : int
> wkDirPath : File
>
>
> Interceptor : AuthenticationInterceptor
> ---------------------------------------
> *authenticators Set<Authenticator> :
> org.apache.directory.server.core.authn.Authenticator
>
>
> Authenticator
> -------------
> No setters...
>
>
> Interceptor:JournalInterceptor
> ------------------------------
> rotation : int
>
>
> LdifEntry
> ---------
> No setters...
>
>
> LdapService
> -----------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
> allowAnonymousAccess : boolean
> certificatePassword : String
> confidentialityRequired : boolean
> enableLdaps : boolean
> keystoreFile : String
> maxSizeLimit : int
> maxTimeLimit : int
> +replicationSystem : ReplicationSystem
> saslHost : String
> saslPrincipal : String
> serviceId : String
> serviceName : String
> *extendedOperationHandlers Collection<ExtendedOperationHandler> :
> org.apache.directory.server.ldap.ExtendedOperationHandler
> *saslQop Set<String> : java.lang.String
> *saslRealms( List<String> : java.lang.String
> *saslMechanismHandlers( Map<String, MechanismHandler> :
> MechanismHandler + mech-name
> *transportProtocols Set<TransportProtocol> :
> org.apache.directory.server.protocol.shared.TransportProtocol
>
>
> ReplicationSystem
> -----------------
> *replicaPeers Set<ReplicaPeerConfiguration> :
> org.apache.directory.server.ldap.replication.ReplicaPeerConfiguration
>
>
> ReplicaPeerConfiguration
> ------------------------
> setInterval : long
> setPassword : String
> setPrincipalDN : String
> setProducer : String
> setRefreshOnly : boolean
>
>
> ExtendedOperationHandler
> ------------------------
> No setters...
>
>
> MechanismHandler : NtlmMechanismHandler
> ---------------------------------------
> +ntlmProvider : NtlmProvider
> ntlmProviderFqcn : String
>
>
> NtlmProvider
> ------------
> No setters...
>
>
> ChangePasswordServer
> --------------------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
> allowableClockSkew : long
> emptyAddressesAllowed : boolean
> policyCategoryCount : int
> policyPasswordLength : int
> policyTokenSize : int
> primaryRealm : String
> servicePrincipal : String
> *encryptionTypes EncryptionType[] : EncryptionType
>
>
> DnsServer
> ---------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
>
>
> KdcServer
> ---------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
> allowableClockSkew : long
> bodyChecksumVerified : boolean
> emptyAddressesAllowed : boolean
> forwardableAllowed : boolean
> kdcPrincipal : String
> maximumRenewableLifetime : long
> maximumTicketLifetime : long
> paEncTimestampRequired : boolean
> postdatedAllowed : boolean
> primaryRealm : String
> proxiableAllowed : boolean
> renewableAllowed : boolean
> *encryptionTypes( EncryptionType[] : EncryptionType
>
>
> NtpServer
> ---------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
>
>
> TcpTransport
> ------------
> setAddress : String (AbstractTransport)
> setBackLog : int (AbstractTransport)
> setNbThreads : int (AbstractTransport)
> setPort : int (AbstractTransport)
>
>
> UdpTransport
> ------------
> setAddress : String (AbstractTransport)
> setBackLog : int (AbstractTransport)
> setNbThreads : int (AbstractTransport)
> setPort : int (AbstractTransport)
>
>
> ApacheDS
> --------
> allowAnonymousAccess : boolean
> ldifDirectory : File
> synchPeriodMillis : long
>
>> BTW, we already have some notes on CiDIT:
>>
>> http://cwiki.apache.org/DIRxSRVx11/configuration-in-dit-cidit.html
>>
> This is a good starting point.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
Re: ApacheDS ConfigNG
Posted by Ersin ER <er...@gmail.com>.
ASL.
http://www.datanucleus.org/project/license.html
On Thu, Mar 19, 2009 at 17:59, Emmanuel Lecharny <el...@apache.org>wrote:
> Stefan Seelmann wrote:
>
>> Hi,
>>
>> if we go the CiDIT way and we need some mapping between LDAP entries and
>> Java beans we should consider to use DataNucleus.
>>
>> DataNucleus is an implementation of JDO and JPA standards, Andy
>> Jefferson already announced it on this list last year. Beside RDBMS it
>> also supports other data stores like LDAP and XML. I worked on the LDAP
>> persistence part recently.
>>
>> A list of mappings that are currently supported for LDAP:
>> - An object is obviously mapped to an entry
>> - Primitives, wrappers of primitives, String, Date, Calendar could be
>> mapped to single-valued attributes
>> - Arrays and Sets of the above types could be mapped to multi-valued
>> attributes (no order and no duplicate values are supported atm)
>> - Relationships between Java objects could be mapped hierarchical, by
>> using DN references or by using attribute references
>>
>> Please see [1] for more information.
>>
>> To go a step further, the same Java beans, mapping configuration and
>> data access layer could be used to access the configuration over the
>> wire. For example it could be used for the configuration UI within Studio.
>>
>> Maybe another advantage - however I'm not sure if possible - could be to
>> use the DataNucleus XML store to map the current configuration file.
>>
>> Kind Regards,
>> Stefan
>>
>>
> Sounds interesting. What is the license ?
>
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
--
Ersin ER
http://www.ersiner.net
Re: ApacheDS ConfigNG
Posted by Emmanuel Lecharny <el...@apache.org>.
Stefan Seelmann wrote:
> Hi,
>
> if we go the CiDIT way and we need some mapping between LDAP entries and
> Java beans we should consider to use DataNucleus.
>
> DataNucleus is an implementation of JDO and JPA standards, Andy
> Jefferson already announced it on this list last year. Beside RDBMS it
> also supports other data stores like LDAP and XML. I worked on the LDAP
> persistence part recently.
>
> A list of mappings that are currently supported for LDAP:
> - An object is obviously mapped to an entry
> - Primitives, wrappers of primitives, String, Date, Calendar could be
> mapped to single-valued attributes
> - Arrays and Sets of the above types could be mapped to multi-valued
> attributes (no order and no duplicate values are supported atm)
> - Relationships between Java objects could be mapped hierarchical, by
> using DN references or by using attribute references
>
> Please see [1] for more information.
>
> To go a step further, the same Java beans, mapping configuration and
> data access layer could be used to access the configuration over the
> wire. For example it could be used for the configuration UI within Studio.
>
> Maybe another advantage - however I'm not sure if possible - could be to
> use the DataNucleus XML store to map the current configuration file.
>
> Kind Regards,
> Stefan
>
Sounds interesting. What is the license ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: ApacheDS ConfigNG
Posted by Stefan Seelmann <se...@apache.org>.
Hi,
if we go the CiDIT way and we need some mapping between LDAP entries and
Java beans we should consider to use DataNucleus.
DataNucleus is an implementation of JDO and JPA standards, Andy
Jefferson already announced it on this list last year. Beside RDBMS it
also supports other data stores like LDAP and XML. I worked on the LDAP
persistence part recently.
A list of mappings that are currently supported for LDAP:
- An object is obviously mapped to an entry
- Primitives, wrappers of primitives, String, Date, Calendar could be
mapped to single-valued attributes
- Arrays and Sets of the above types could be mapped to multi-valued
attributes (no order and no duplicate values are supported atm)
- Relationships between Java objects could be mapped hierarchical, by
using DN references or by using attribute references
Please see [1] for more information.
To go a step further, the same Java beans, mapping configuration and
data access layer could be used to access the configuration over the
wire. For example it could be used for the configuration UI within Studio.
Maybe another advantage - however I'm not sure if possible - could be to
use the DataNucleus XML store to map the current configuration file.
Kind Regards,
Stefan
[1] http://www.datanucleus.org/products/accessplatform_1_1/ldap/mapping.html
Emmanuel Lecharny wrote:
> Ersin ER wrote:
>> Let's continue discussion on next generation configuration mechanism for
>> ApacheDS in this thread.
>>
>
> I have listed _all_ the parameters we currently want to manage, in all
> classes :
>
> DirectoryService
> ----------------
> accessControlEnabled : boolean;
> allowAnonymousAccess : boolean
> +changeLog : ChangeLog
> denormalizeOpAttrsEnabled : boolean
> exitVmOnShutdown : boolean
> id : String
> +journal : Journal
> maxPDUSize : int
> passordHidden : boolean
> replicaId : int
> +systemPartition : Partition
> workingDirectory : File
> *interceptors List<Interceptor> :
> org.apache.directory.server.core.interceptor.Interceptor
> *partitions Set<? extends Partition> :
> org.apache.directory.server.core.partition.Partition
> *testEntries List<? extends LdifEntry> :
> org.apache.directory.shared.ldap.ldif.Entry
>
>
> ChangeLog
> ---------
> enabled : boolean
> exposeChangeLog : boolean
> partitionSuffix : String
> revisionsContainerName : String
> tagsContainerName : String
> +changeLogStore : ChangeLogStore
>
>
> ChangeLogStore
> --------------
> No setters...
>
>
> Journal
> -------
> enabled : boolean
> +journalStore : JournalStore
>
>
> JournalStore
> ------------
> fileName : String
> workingDirectory : String
>
>
> Partition : JdbmPartition
> -------------------------
> cacheSize : int
> id : String
> optimizerEnabled : boolean
> suffix : String
> syncOnWrite : boolean
> *indexedAttributes Set<Index<?,ServerEntry>> indexedAttributes ) ???
> property( String propertyName, String propertyValue ???
>
>
> Index : JdbmIndex
> -----------------
> attributeId : String
> cacheSize : int
> numDupLimit : int
> wkDirPath : File
>
>
> Interceptor : AuthenticationInterceptor
> ---------------------------------------
> *authenticators Set<Authenticator> :
> org.apache.directory.server.core.authn.Authenticator
>
>
> Authenticator
> -------------
> No setters...
>
>
> Interceptor:JournalInterceptor
> ------------------------------
> rotation : int
>
>
> LdifEntry
> ---------
> No setters...
>
>
> LdapService
> -----------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
> allowAnonymousAccess : boolean
> certificatePassword : String
> confidentialityRequired : boolean
> enableLdaps : boolean
> keystoreFile : String
> maxSizeLimit : int
> maxTimeLimit : int
> +replicationSystem : ReplicationSystem
> saslHost : String
> saslPrincipal : String
> serviceId : String
> serviceName : String
> *extendedOperationHandlers Collection<ExtendedOperationHandler> :
> org.apache.directory.server.ldap.ExtendedOperationHandler
> *saslQop Set<String> : java.lang.String
> *saslRealms( List<String> : java.lang.String
> *saslMechanismHandlers( Map<String, MechanismHandler> :
> MechanismHandler + mech-name
> *transportProtocols Set<TransportProtocol> :
> org.apache.directory.server.protocol.shared.TransportProtocol
>
>
> ReplicationSystem
> -----------------
> *replicaPeers Set<ReplicaPeerConfiguration> :
> org.apache.directory.server.ldap.replication.ReplicaPeerConfiguration
>
>
> ReplicaPeerConfiguration
> ------------------------
> setInterval : long
> setPassword : String
> setPrincipalDN : String
> setProducer : String
> setRefreshOnly : boolean
>
>
> ExtendedOperationHandler
> ------------------------
> No setters...
>
>
> MechanismHandler : NtlmMechanismHandler
> ---------------------------------------
> +ntlmProvider : NtlmProvider
> ntlmProviderFqcn : String
>
>
> NtlmProvider
> ------------
> No setters...
>
>
> ChangePasswordServer
> --------------------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
> allowableClockSkew : long
> emptyAddressesAllowed : boolean
> policyCategoryCount : int
> policyPasswordLength : int
> policyTokenSize : int
> primaryRealm : String
> servicePrincipal : String
> *encryptionTypes EncryptionType[] : EncryptionType
>
>
> DnsServer
> ---------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
>
>
> KdcServer
> ---------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
> catelogBased : boolean (DirectoryBackedService)
> searchBaseDn : String (DirectoryBackedService)
> allowableClockSkew : long
> bodyChecksumVerified : boolean
> emptyAddressesAllowed : boolean
> forwardableAllowed : boolean
> kdcPrincipal : String
> maximumRenewableLifetime : long
> maximumTicketLifetime : long
> paEncTimestampRequired : boolean
> postdatedAllowed : boolean
> primaryRealm : String
> proxiableAllowed : boolean
> renewableAllowed : boolean
> *encryptionTypes( EncryptionType[] : EncryptionType
>
>
> NtpServer
> ---------
> +directoryService : DirectoryService (AbstractProtocolServer)
> enabled : boolean (AbstractProtocolServer)
> +tcpTransport : TcpTransport (AbstractProtocolServer)
> +udpTransport : UdpTransport (AbstractProtocolServer)
>
>
> TcpTransport
> ------------
> setAddress : String (AbstractTransport)
> setBackLog : int (AbstractTransport)
> setNbThreads : int (AbstractTransport)
> setPort : int (AbstractTransport)
>
>
> UdpTransport
> ------------
> setAddress : String (AbstractTransport)
> setBackLog : int (AbstractTransport)
> setNbThreads : int (AbstractTransport)
> setPort : int (AbstractTransport)
>
>
> ApacheDS
> --------
> allowAnonymousAccess : boolean
> ldifDirectory : File
> synchPeriodMillis : long
>
>> BTW, we already have some notes on CiDIT:
>>
>> http://cwiki.apache.org/DIRxSRVx11/configuration-in-dit-cidit.html
>>
> This is a good starting point.
>
Re: ApacheDS ConfigNG
Posted by Emmanuel Lecharny <el...@apache.org>.
Ersin ER wrote:
> Let's continue discussion on next generation configuration mechanism for
> ApacheDS in this thread.
>
I have listed _all_ the parameters we currently want to manage, in all
classes :
DirectoryService
----------------
accessControlEnabled : boolean;
allowAnonymousAccess : boolean
+changeLog : ChangeLog
denormalizeOpAttrsEnabled : boolean
exitVmOnShutdown : boolean
id : String
+journal : Journal
maxPDUSize : int
passordHidden : boolean
replicaId : int
+systemPartition : Partition
workingDirectory : File
*interceptors List<Interceptor> :
org.apache.directory.server.core.interceptor.Interceptor
*partitions Set<? extends Partition> :
org.apache.directory.server.core.partition.Partition
*testEntries List<? extends LdifEntry> :
org.apache.directory.shared.ldap.ldif.Entry
ChangeLog
---------
enabled : boolean
exposeChangeLog : boolean
partitionSuffix : String
revisionsContainerName : String
tagsContainerName : String
+changeLogStore : ChangeLogStore
ChangeLogStore
--------------
No setters...
Journal
-------
enabled : boolean
+journalStore : JournalStore
JournalStore
------------
fileName : String
workingDirectory : String
Partition : JdbmPartition
-------------------------
cacheSize : int
id : String
optimizerEnabled : boolean
suffix : String
syncOnWrite : boolean
*indexedAttributes Set<Index<?,ServerEntry>> indexedAttributes ) ???
property( String propertyName, String propertyValue ???
Index : JdbmIndex
-----------------
attributeId : String
cacheSize : int
numDupLimit : int
wkDirPath : File
Interceptor : AuthenticationInterceptor
---------------------------------------
*authenticators Set<Authenticator> :
org.apache.directory.server.core.authn.Authenticator
Authenticator
-------------
No setters...
Interceptor:JournalInterceptor
------------------------------
rotation : int
LdifEntry
---------
No setters...
LdapService
-----------
+directoryService : DirectoryService (AbstractProtocolServer)
enabled : boolean (AbstractProtocolServer)
+tcpTransport : TcpTransport (AbstractProtocolServer)
+udpTransport : UdpTransport (AbstractProtocolServer)
catelogBased : boolean (DirectoryBackedService)
searchBaseDn : String (DirectoryBackedService)
allowAnonymousAccess : boolean
certificatePassword : String
confidentialityRequired : boolean
enableLdaps : boolean
keystoreFile : String
maxSizeLimit : int
maxTimeLimit : int
+replicationSystem : ReplicationSystem
saslHost : String
saslPrincipal : String
serviceId : String
serviceName : String
*extendedOperationHandlers Collection<ExtendedOperationHandler> :
org.apache.directory.server.ldap.ExtendedOperationHandler
*saslQop Set<String> : java.lang.String
*saslRealms( List<String> : java.lang.String
*saslMechanismHandlers( Map<String, MechanismHandler> :
MechanismHandler + mech-name
*transportProtocols Set<TransportProtocol> :
org.apache.directory.server.protocol.shared.TransportProtocol
ReplicationSystem
-----------------
*replicaPeers Set<ReplicaPeerConfiguration> :
org.apache.directory.server.ldap.replication.ReplicaPeerConfiguration
ReplicaPeerConfiguration
------------------------
setInterval : long
setPassword : String
setPrincipalDN : String
setProducer : String
setRefreshOnly : boolean
ExtendedOperationHandler
------------------------
No setters...
MechanismHandler : NtlmMechanismHandler
---------------------------------------
+ntlmProvider : NtlmProvider
ntlmProviderFqcn : String
NtlmProvider
------------
No setters...
ChangePasswordServer
--------------------
+directoryService : DirectoryService (AbstractProtocolServer)
enabled : boolean (AbstractProtocolServer)
+tcpTransport : TcpTransport (AbstractProtocolServer)
+udpTransport : UdpTransport (AbstractProtocolServer)
catelogBased : boolean (DirectoryBackedService)
searchBaseDn : String (DirectoryBackedService)
allowableClockSkew : long
emptyAddressesAllowed : boolean
policyCategoryCount : int
policyPasswordLength : int
policyTokenSize : int
primaryRealm : String
servicePrincipal : String
*encryptionTypes EncryptionType[] : EncryptionType
DnsServer
---------
+directoryService : DirectoryService (AbstractProtocolServer)
enabled : boolean (AbstractProtocolServer)
+tcpTransport : TcpTransport (AbstractProtocolServer)
+udpTransport : UdpTransport (AbstractProtocolServer)
catelogBased : boolean (DirectoryBackedService)
searchBaseDn : String (DirectoryBackedService)
KdcServer
---------
+directoryService : DirectoryService (AbstractProtocolServer)
enabled : boolean (AbstractProtocolServer)
+tcpTransport : TcpTransport (AbstractProtocolServer)
+udpTransport : UdpTransport (AbstractProtocolServer)
catelogBased : boolean (DirectoryBackedService)
searchBaseDn : String (DirectoryBackedService)
allowableClockSkew : long
bodyChecksumVerified : boolean
emptyAddressesAllowed : boolean
forwardableAllowed : boolean
kdcPrincipal : String
maximumRenewableLifetime : long
maximumTicketLifetime : long
paEncTimestampRequired : boolean
postdatedAllowed : boolean
primaryRealm : String
proxiableAllowed : boolean
renewableAllowed : boolean
*encryptionTypes( EncryptionType[] : EncryptionType
NtpServer
---------
+directoryService : DirectoryService (AbstractProtocolServer)
enabled : boolean (AbstractProtocolServer)
+tcpTransport : TcpTransport (AbstractProtocolServer)
+udpTransport : UdpTransport (AbstractProtocolServer)
TcpTransport
------------
setAddress : String (AbstractTransport)
setBackLog : int (AbstractTransport)
setNbThreads : int (AbstractTransport)
setPort : int (AbstractTransport)
UdpTransport
------------
setAddress : String (AbstractTransport)
setBackLog : int (AbstractTransport)
setNbThreads : int (AbstractTransport)
setPort : int (AbstractTransport)
ApacheDS
--------
allowAnonymousAccess : boolean
ldifDirectory : File
synchPeriodMillis : long
> BTW, we already have some notes on CiDIT:
>
> http://cwiki.apache.org/DIRxSRVx11/configuration-in-dit-cidit.html
>
This is a good starting point.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org