Stefan Seelmann wrote:
Ole Ersoy schrieb:
OH - OK - I think the lights are turning on.
Suppose I have a
DN: cn=user1 ou=users, ou=system
I can hang any attribute I want on this DN right?
Yes, assumed that the attribute type is defined in the LDAP schema and
the DN/entry has the object classes that allow that attribute.
Ah Right - I was hoping maybe there was a way to turn that off, so that
I can just
have any attribute I want without any Schema checking.
So that's why I need to generate the ObjectClass for the Java Class on
the fly / before
I write the object.
So if I want to store an instance of Java Class User (That has members
[userName:String, userPassword:string]
I could simply add the member values of a User instance as attributes to
the DN, and my object is effectively stored.
If I want to get an instance of that object later,
the DAS just creates a user instance, and fetches the attributes using the
DN: cn=user1 ou=users, ou=system
context.
In other words I get the attributes assigned to this context and
the ones that have the same name as the User Class members, would be
be assigned used to initialize the state of a User instance?
Hm, JNDI defines a framework for doing such mappings between Java
objects and LDAP entries: State Factories and Object Factories. Please
see http://java.sun.com/products/jndi/tutorial/TOC.html, especially
chapter 'Java Objects and the Directory'.
So even thought userName has java type String,
I don't have to create a corresponding
LDAP ObjectClass named User that says that
userName is of LDAP attribute type String....., and then map the java
members
to the members of the User ObjectClass?
For such a simple case you could just reuse the standard object class
'person' with its attributes 'cn' and 'userPassword'. But note that the
userPassword attribute is defined as binary (Octet String) in RFC 4519.
If your User Java class additionally has an attribute (e.g. 'shoeSize')
that is not specified in an standard schema you could define an
additional (AUXILIARY) object class in LDAP, e.g. 'customPerson' and an
attribute type 'shoeSize' as may attribute. Then you could add this
object class to the entry and then you could store the attribute
'shoeSize' to the entry.
Yes! Precisely. It could be that the Class I want to store is a
ShoeSizeGuesser class.
I want to store the following members of that class
weight: int
height: int
hairColor: String
But I don't have an ObjectClass for this in ADS, so first I need to
create one programmatically.
So the DAS first creates it, stores it in ADS, then
creates a context to store the attributes of ShoeSizeGuesser under
So the ShoeSizeGuesser would have these LDAP attributes:
ObjectClass: ShoeSizeGuesser
weight: int
height: int
hairColor: String
So my question is, how do I create the
ShoeSizeGuesser ObjectClass programmatically
at the client end, and then "bind" / "load" it into
ApacheDS?
I looked at the New Schema Subsystem material, but did not see a section
on how to do this...
Any ideas?
Thanks,
- Ole
Thanks,
- Ole
Stefan
