Aha!
Sweet - So the process for
engineering.example.org
that wishes to have
DN: ou=engineering, ou=example, ou=org
as the parent context for all their models persisted with the LDAP DAS
would be to first add
DN: ou=engineering, ou=example, ou=org
in the configuration file,
then use that as the root context for all the DAS operations
java.naming.provider.url=ldap://localhost:389/ ou=engineering,
ou=example, ou=org
Incidentally - Some might like it if
the DAS was able to just create this root context without using the
configuration file.
Then ADS could just add it to the configuration file.
Thoughts?
Thanks Stefan,
- Ole
P.S.
This may qualify for as a scenario (John mentioned) where configuration
data is in multiple files.
For instance right now I'm creating a model holding the configuration of
the DAS.
The model stores this type of parameter
java.naming.provider.url=ldap://localhost:389/ ou=engineering,
ou=example, ou=org
If on startup ADS could be pointed to this file, it would know that
ou=engineering, ou=example, ou=org
is a "Configured" context...
This type of thing is really easy to do with EMF.
More thoughts?
Thanks,
- Ole
Stefan Zoerner wrote:
Ole Ersoy wrote:
Ahhh - OK -Cool - So
if the DAS wants to have a model root object
stored at
DN: cn=ole
That's ok?
So to create cn=ole as my initial context I would
set the
java.naming.provider.url=ldap://localhost:389/
like that, and then create the
subcontext "cn=ole"?
No. That won't work. For a top level entry like that, you have to
create a new partition with suffix "cn=ole" within your server
configuration. Like the "dc=example,dc=com" sample partition.
Greetings,
Stefan
