Hi Ole,
Excuse the late response ... I've been lazy while on vacation. More inline
...
On 3/28/07, Ole Ersoy <[EMAIL PROTECTED]> wrote:
Alex Karasulu wrote:
> Ole,
>
SNIP ...
Hmmm with heirarchical services in JNDI you should not be using
> bind(). You
> should be using the createSubcontext() and modifyAttributes() methods
> instead.
Oh OK. My impression was that I would use createSubcontext() when
creating a new context for a serialized java object for example.
Oh sorry I thought you were not storing a serialized object. Then bind()
would
help you accomplish that I think. However this is not very efficient
because
of the reasons you mention: you would in essence be updating the entire
object
when just one member changes. And you're dealing with a blob of serialized
data which is bigger. Meaning the transfers are bigger for a small change
in the
overall object.
My impression was that you were converting an object into an entry with
attributes
for it's properties which is more like what you do when you persist an
object in a
record in a database. For example you have a User object and you convert
that
into a set of attributes like so:
givenName: johny
surName: walker
commonName: wiskey
age: 12
etc ...
Then this way you would call createSubcontext with the attributes and that
would
persist the entry. If you change the age to 15 then there is a single
update operation
on that attribute. Also this way indexing can be taken advantage of for
attributes for
speeding up search. I have no idea how you would search for serialized
objects in
a directory efficiently.
Let me give an exampel - I'll be starting the DAS "serious" work tomorrow,
so if I'm off on this, I'll eventually find out :-), but this may help
facilitate
the conversation with respect to updating attributes vs. the entire
object.
Suppose my initial context is:
|uid=ole,ou=users, ou=system
|
And I wanted to add a sub context for an Instance of MyClass
with reference named myClassInstance
I could do something like
ctx.createSubcontext("cn=myClassInstance");
Which would create the context:
|cn=myClassInstance, uid=ole, ou=users, ou=system|
I think you were right in using bind() where you provide the object to
serialize. This createSubcontext() operation will merely create a
javaContainer I think. There's an
RFC on this which I implemented a while back and you can find more info in
the
JNDI tutorial about this as well.
However again I don't think using this serialization mechanism is such a
good idea
because of the search implications. How would you search a blob of binary
data
effectively?
Then to store a my serialized myClassInstance under this dn in a
javaSerializedData attribute, I would do something like this:
|||String bindContext = "cn=|myClassInstance|,uid=ole,ou=users,
ou="system";|
|ctx.bind( bindContext, ||nameOfMyObject||)
I'm also guessing that the bind operation would take care
of the createSubcontext() step for me, ... but anyways...
Yes you were right. Actually you would not need to createSubcontext()
operation at all just use bind().
I recommend just going through the JNDI tutorial on this stuff and testing
these operations on the server just to see what happens.
|
> You
> might want to go through the JNDI tutorial for LDAP just to get a good
> feel for how to
> work with non-flat namespaces using JNDI. Namely with LDAP you don't
> need to
> rebind the object with a modification to an attribute. This is what
> the modify
> operations are for.
Just want to make sure we are talking about the same thing here.
We may have some attributes stored in ADS under:
|DN: uid=ole,ou=users, ou="system
This DN has the Person ObjectClass associated with it.
So I may wish to change one of the attributes (The password attribute
for instance)
that are associated with the Person ObjectClass.
Then I could see using a modify operation.
Yeah we're mixing object serialization here with converting that object to
an entry with attributes.
Is that also the case when storing entire javaObjects
in a javaSerializedData attribute?
Technically you can use modify on javaSerializedData but you're replacing
the blob of serialized bytes representing the serialized object.
|I just want to make sure we are clearly separating java object
attributes (Primitive java class members)
from LDAP attributes.
Basically my advice would be to stay clear of using java serialization in
the directory.
Let me stop here in case I'm making any sense?
If not hopefully once I'm done writing the design guide and get a
terminology and concept section going
things will be a little clearer.
>
http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes(javax.naming.Name
> <
http://bsd.cs.cofc.edu/Java/Javadocs1.5/api/javax/naming/directory/DirContext.html#modifyAttributes%28javax.naming.Name
>,
> int, javax.naming.directory.Attributes)
>
>
Cool - I'll have a looksee - I've been using the articles on the
ApacheDS website as a reference so far, but the more material the better.
>
>
> Initially I was thinking that the object's attributes (primitive
> properties - not references to other objects)
> would be serialized and made into directory attributes. But I think
a
> LDAP ObjectClass schema that corresponds to the
> object's class (The class of the object we are persisting) would
> have to
> be generated and stored along with the instance.
>
> This might lead to performance improvments, if doable...?
>
> Thoughts?
>
>
> Hmmm I think some of your premisses in this question may be due to
> considering the use
> of bind() instead of using modifyAttributes() and createSubcontext().
> If you use these methods
> I think there is no further preformance issue to consider. WDYT?
Ahh - This is the part where I need clarification.
If we serialize an entire object to ApacheDS, then we have to get it
from ApacheDS,
update it, and send it back to be stored in a javaSerializedData
attribute right?
Right exactly! This is why java LDAP serialization is not a good idea for
your DAS thingy.
For instance I may have a Class called UserClass with a String member
userName.
I create an instance of UserClass called userClass.
The I do
userClass.setUserName("ole");
Now I want to store userClass in ADS here:
|DN: cn=|userClass|,ou=users, ou="system
So I do this:
||String bindContext = "cn=|myClassInstance|,ou=users, ou="system";|
|ctx.bind( bindContext, ||userClass||);
Now userClass is in ADS stored as a javaSerializedData LDAP attribute
value,
hanging off of the bindContext I specified.
Later when I want to update
the userName member of the UserClass instance I serialized to ADS,
I need to use JNDI to load the instance again right?
Yep unless you write the code to resusitate the serialized object manually.
Then update userName. Then serialize userClass back to ADS again?
Yep.
|
WDYT?
I mentioned some stuff about generating an ObjectClass schema that is
the LDAP schema of the Java Class UserClass,
so that the primitive members (That have java primitive types) would be
stored as LDAP atttributes rather than storing the entire
object as a single javaSerializedData attribute attached to a DN.
Yes this would be best in my opinion.
Regards,
Alex
