administerd objects: reference or copy ?
Hi,
Question for understanding purposes.
When I store an administered object in an LDAP server, say, does it just store the name of the class I configure or does it also store a copy of the class ?
The fact that it's called an Object Store and the fact that some of the documentation refers to 'storing objects' at first gives the impression that the classes themselves are stored in the object store.
However, when I look in the LDAP server, although I can see this type of attribute:
javaClassName: com.sun.messaging.QueueConnectionFactory
I cannot see any attribute that corresponds to a 'blob' of code.
Also, if I remove imq.jar from a client's classpath, even one written for portability and just using the javax.jms.* classes/interfaces then it fails with a class/cast exception.
So, what it looks like is happening is that the so called object store stores parameters and names of classes but the actual classes themselves must be on the classpath of the client, and copied out to all the client systems.
Am I on the right track or have I strayed hopelessly from the path ?
thanks,
Rob.
# 1
My understanding is that what's stored in LDAP is the serialized copy of the object...or information/data that is sufficient to deserialize the object. Not sure how LDAP/JNDI handles this (in terms of how serialized data is stored in LDAP) - all JMS providers need to do is make sure that the objects implement javax.jndi.Referenceable and java.io.Serializable.
I just fired up Directory Server 5.2 to see what LDAP attrs are there (been a while since I did this) and I do see the javaclassname attr set to com.sun.messaging.QueueConnectionFactory. I also see the LDAP attribute javareferenceaddress which contains a whole list of values - this appears to be the values that need to be set on the connection factory class. This to me is the 'blob' of code.
With regards to imq.jar being on the classpath - if/when you deserialize an object, the class for that object needs to be on the CLASSPATH. Similarly, when a lookup of a connection factory is done, that factory class needs to be instantiated. Regardless of the fact that you are casting it to a javax.jms.* type, it needs to be instantiated - and what's stored in object stores are not interface objects, but real concrete provider specific classes, and for MQ, these classes live in imq.jar.
hope this helps,
-i
