directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [GSoC] Project use cases
Date Sat, 15 Mar 2008 15:19:32 GMT
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:
> 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,
> 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 :
> 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 :

> 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 

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

View raw message