David Montag wrote:
Hi,
Hi David,
For those of you who don't know me, my name is David Montag, and I'm a
student studying in Linköping, Sweden. I'm hoping to do a Google Summer of
Code project with Apache Directory.
Tat would be great !
So, I and Alex have been discussing a GSoC project. A brief initial
description can be found here:
http://cwiki.apache.org/confluence/display/DIRxPMGT/Google+Summer+of+Code
I will here present two use cases for the schema<->POJO/POJI mapping. The
mapping could be done using a maven plugin, for example.
You could also define a Java API. What you want is to be able to
automatically persist objects into a ladp server, as if you don't know
that is a LDAP server. As you can get the schema programatically,
nothing forbid you to generate a new Schema for your object, stores it
into the server, and then serialize the data. You don't even have to
generate a Java class for that ! The perfect O/L mapping tool :) (O/L =
Object/Ldap (tm) :)
Then you can define a Maven plugin around it.
*or* you can generate some standalone java classes too.
Many possible options !
This is how I
picture the use cases. Please correct my mistakes, and give me feedback.
1. Schema -> POJO
An LDAP server has a Foo objectClass. It may have different kinds of
attributes. The user wants to access and manipulate Foo entries natively in
Java. The plugin reads the schema from the server, and generates some files,
Foo.java being one of them. The user then codes against the Foo interface. I
don't know how the actual persisting of the objects will be done. I imagine
some kind of proxy objects for this. It can be decided later. I also don't
know how Foo objects will be created. Possibly through a factory.
You will have to consider some other cases :
- ObjectClass can inherit from other ObjectClasses. Generating some POJO
from an ObjectClass implies that you deal with these inherited OC.
- An entry can have more than one ObjectClass, and this is what we store
into the server.
- There is a special OC, extensibleObject, which allows an entry to
accept *all* the AttributeType.
FYI, we have some code which parses an OC and feed soem data structure.
You can start using it, but instead of generating some existing data
structure, generate the code :
http://svn.apache.org/repos/asf/directory/shared/trunk/ldap/src/main/antlr/schema.g
2. POJO -> Schema
A user has a Bar Java class. The user would like this class persisted using
LDAP. The user instructs the plugin to persist the class by adding
annotations to the code. The plugin then generates an LDAP schema from the
Java class. Using additional annotations, the output schema format can be
adapted. The generated schema can then be pushed to the LDAP server. The
user then possibly uses some factory to create Bar objects that are
persistent.
Interesting. Ole already worked on such a matter, I think you can
benefit from what he did :
http://svn.apache.org/repos/asf/directory/sandbox/oersoy/das.testing/
Maybe I'm considering the persistence part too much? Please give me
comments.
JNDI provide two ways to store java instances into a LDAP server :
- as a serialized java class (heavy)
- as a special serialized form, a little bit like when you write a
specific serializer instead of depending on the Object serialization.
The thing is that it's heavy in both cases, as you store the object into
one single attribute, forbidding the user to request the inner objects
fields.
A new storage (persistence) form is a major plus in this case : you save
not only the object as a whole, but each field as attributes. If you can
set the index on those attributes, you will be able to target ultimate
perfomances. So, no, I don't think you focus too much on the persistence
part. This is exactly what we need !
Hope it helps...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
