Re: Comments on draft-ryan-java-schema-02

[Vincent Ryan <Vincent.Ryan@ireland.Sun.COM>]

Thanks for your feedback Jeff.

The general model for a directory is to store (reference)
information about entities rather than storing the entities
themselves. Jarfiles are typically stored in a filesystem.
I'm not convinced that it'd be useful to store them in the
directory. However, there may be merit to storing a jarfile
manifest (and a reference to the jarfile) in the directory
- how would you see it being used in practice?

Regarding point 2 below, the existing javaClassName and
javaClassNames attributes are already searchable. They
describe an object in a well-defined manner. Introducing
a new attribute with type/value pairs would also require
the definition of its contents in order to be generally
useful. It'd be more in keeping with LDAP to define a
specific EJB schema rather than defining a general-purpose
object that describes itself by means of its type/value pairs.



Jeffrey Spirn wrote:
> 
> I have two suggestions:
> 
> 1) It would be a good idea to define a way to store Jar files, as a
> representation of Java classes (and EJB's, etc.).  Perhaps this is
> viewed as out of the scope of this proposal, since the draft discusses
> only individual objects.  But it will be very useful if class files
> (along with manifests and deployment descriptors in the case of EJB's)
> can also be stored in the directory.  It should even be possible for a
> serialized object to specify a value for its "javaCodebase" attribute
> which is an ldap URL of a Jar file in the same or another directory.
> 
> 2) LDAP searches cannot be expected to be performed against the interior
> of serialized Java objects (or the contents of Jar files!), and yet the
> ability to search is one of the advantages of a directory.  It would be
> useful to add an optional, multi-valued attribute to Java objects and
> jar files in the directory which is a set of strings to search against.
> Each value in this attribute could be a string of the form
> <name>=<value>, where "name" and "value" are specific to the type of
> object of Jar file.  (For example, it might include portions of the
> manifest file in the case of an EJB jar file.)
> 
> Regards,
> Jeff Spirn
> Oracle