You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Graham Leggett <mi...@sharp.fm> on 2007/12/17 17:17:07 UTC
Object LDAP mapping
Hi all,
Although not directly related to the directory server itself, I thought I
would ask here as the concentration of LDAP experts is high :)
Has anybody heard of a Java package that does object to LDAP mapping,
along the lines of Hibernate or Torque in the land of SQL?
In other words, I would like a Java class hierarchy of objects
representing LDAP objectlasses and LDAP objects.
If such a thing doesn't exist, would the directory project be keen to
adopt such a new piece of code as its home, if it were to be written?
Regards,
Graham
--
Re: Object LDAP mapping
Posted by Ole Ersoy <ol...@gmail.com>.
Hi Graham,
The LDAP DAS is sitting in Tuscany. It would need an EMF based model though, as it is designed to work with the EMF API / EMF SDO API. The longer term plan is to have it work with the Tuscany SDO API as well + support Transactions, etc. Also note that the persistance to ADS is done by convention and the model's XML Schema Namespace is used to create the root DN within ADS.
In general the way it works is you would generate an EMF model (Basically model Pojo's ehanced by the EMF API, similar to what modello does for maven) from an source such as XML Schema, Annotated Java Interfaces, or XMI and then use the DAS to store the model instance in ADS. When doing CRUD stuff, the DAS loads a model from ADS and then uses SDO's change summary capability to handle updates.
I still need to do the Developer Use Case documentation (Or the How To), but the tests are pretty thorough so giving it a go should be easy. If you need Object to DN mapping though that's not by convention (XML Namespace) I think some of the other tools mentioned would suit you better. It's pretty easy to implement mapping with the SDO / EMF API using annotations, but I need more days :-).
Cheers,
- Ole
Emmanuel Lecharny wrote:
> Hi Graham,
>
> Ole Ersoy has worked on such a piece of code a while back. I think it
> has matured in the Tuscany project.
>
> Otherwise, you have to know that there is a Java schema containing all
> the Objectclasses you need to describe a Java class, and to store a
> serialized object. Not sure that it will fit your need.
>
> In any case, as we are redesigning the JNDI API to be closer to what we
> need, it will be a pleasure to include a Java<->Ldap OL-Mapping tool in
> ADS project (OL = ObjectLdap, with Object-Relational-mapping in mind :)
>
> Graham Leggett wrote:
>> Hi all,
>>
>> Although not directly related to the directory server itself, I thought I
>> would ask here as the concentration of LDAP experts is high :)
>>
>> Has anybody heard of a Java package that does object to LDAP mapping,
>> along the lines of Hibernate or Torque in the land of SQL?
>>
>> In other words, I would like a Java class hierarchy of objects
>> representing LDAP objectlasses and LDAP objects.
>>
>> If such a thing doesn't exist, would the directory project be keen to
>> adopt such a new piece of code as its home, if it were to be written?
>>
>> Regards,
>> Graham
>> --
>>
>>
>>
>>
>
>
Re: Object LDAP mapping
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Graham,
Ole Ersoy has worked on such a piece of code a while back. I think it
has matured in the Tuscany project.
Otherwise, you have to know that there is a Java schema containing all
the Objectclasses you need to describe a Java class, and to store a
serialized object. Not sure that it will fit your need.
In any case, as we are redesigning the JNDI API to be closer to what we
need, it will be a pleasure to include a Java<->Ldap OL-Mapping tool in
ADS project (OL = ObjectLdap, with Object-Relational-mapping in mind :)
Graham Leggett wrote:
> Hi all,
>
> Although not directly related to the directory server itself, I thought I
> would ask here as the concentration of LDAP experts is high :)
>
> Has anybody heard of a Java package that does object to LDAP mapping,
> along the lines of Hibernate or Torque in the land of SQL?
>
> In other words, I would like a Java class hierarchy of objects
> representing LDAP objectlasses and LDAP objects.
>
> If such a thing doesn't exist, would the directory project be keen to
> adopt such a new piece of code as its home, if it were to be written?
>
> Regards,
> Graham
> --
>
>
>
>
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Object LDAP mapping
Posted by Alex Karasulu <ak...@apache.org>.
On Dec 17, 2007 2:12 PM, Alex Karasulu <ak...@apache.org> wrote:
> Hi Graham,
>
> It's a please to hear from you again.
s/please/pleasure/
Doh?
On Dec 17, 2007 11:17 AM, Graham Leggett <mi...@sharp.fm> wrote:
>
> > Has anybody heard of a Java package that does object to LDAP mapping,
> > along the lines of Hibernate or Torque in the land of SQL?
> >
>
> I think Castor had something out there and even Hibernate tried. There's
> also this Spring LDAP stuff but that's not really an object mapping
> framework but rather more of a utility library that removes most of the
> redundant scaffolding used with JNDI code specifically.
>
> There is a big void in this space and I have some ideas where we can fill
> that gap. I started experimenting with a few things in the sandbox here:
>
> http://svn.apache.org/viewvc/directory/sandbox/akarasulu/j2l/trunk/
>
> The code experiments with a handful of simple ideas:
>
> A default mapping scheme is used to map Classes to STRUCTURAL
> objectClasses and Interfaces to AUXILIARY objectClasses. You probably can
> immediately infer on your own what abstract Java classes map to. Java
> interface and class properties map to ldap attributes. There is some level
> of smart inference we can make for most general cases to make sure the right
> things happen with regard to may and must lists. Hence there is a default
> mapping scheme with some smart logic designed to handle most common cases in
> terms mentioned above and on how to handle syntaxes etc. Also I think we
> can do some superb stuff with other concepts in both LDAP and Java like
> ditStructureRules, nameForms etc, and with things like Java aspects.
> However we can talk about this later. This should cover about 60-80% of the
> mapping needs.
>
> The rest of the user's needs can be accomodated with hints to the mapping
> engine using Java 5 Annotations.
>
> So this little experiment played with these concepts to see just how
> feasible this is and the amount of wattage we'd need to apply to get this
> done in a reasonable amount of time. I am by no means attached to the code
> there. I just tinkered so we can discard this and start fresh if you like.
>
Sorry I should have gone further but I was rushing. This code is intended
to generate a schema if one does not already exist based on mapping rules or
directives in the form of annotations. It will also generate code for a
Java POJO or POJI to do the basic CRUD and search operations needed. I had
some internal discussions with my split personalities on different flavors
of API's to generate based on what was needed or what interested the user
most like ones that leverage DAO based patterns or to leverage other
patterns that are more conducive to the LDAP access model. DAO's are very
RDBMS oriented but can still be applicable to a degree although I see some
problems in certain areas.
Theres lots to discuss. I'm sure there will be some debates on how to
proceed. I had several with myself. However if we could suspend being
extremely critical and just get something out we could do this rapidly and
adapt our approach after getting more user feedback. This is not going to
be perfect the first time it's implemented.
Alex
Re: Object LDAP mapping
Posted by Jörg Henne <j....@levigo.de>.
Alex,
Alex Karasulu schrieb:
> A default mapping scheme is used to map Classes to STRUCTURAL
> objectClasses and Interfaces to AUXILIARY objectClasses. You probably
> can immediately infer on your own what abstract Java classes map to.
> Java interface and class properties map to ldap attributes. There is
> some level of smart inference we can make for most general cases to
> make sure the right things happen with regard to may and must lists.
> Hence there is a default mapping scheme with some smart logic designed
> to handle most common cases in terms mentioned above and on how to
> handle syntaxes etc. Also I think we can do some superb stuff with
> other concepts in both LDAP and Java like ditStructureRules, nameForms
> etc, and with things like Java aspects. However we can talk about
> this later. This should cover about 60-80% of the mapping needs.
Just a few quick notes on the rationale behind our approach. We started
out from a few basic premises:
1. We want to be able to support multiple different LDAP schemas (or
rather schema dialects) from the same domain model.
2. Differences between the dialects can not easily be factored out in a
generic fashion, like a HibernateDialect, since they are not language
dialects but structure dialects
3. We want to be able to map our domain model onto existing directories,
without forcing them to install custom schemas or schema extensions.
This premise is pain-inducing and, in retrospect, debatable. We talked
to administrators of large MS-ADS installations any they were generally
very reluctant or hostile towards schema extensions. So, in order to not
artificially limit us by requiring one, we tried to do without - but
failed: the schema for the RFC classes present in ActiveDirectory looks
good upon cursory inspection, but is actually horribly broken. The
nesting rules imposed by the schema makes it impossible to use quite a
few classes in the way they were meant to be used. Therefore we require
a minimal schema extension which relaxes those restrictions.
Premises #1 and #2 rule out Java 5 annotations, therefore we are using
separate XML to describe the mapping. Mapping creation from annotations
could be added though.
That being said, I must confess that compared to a solution where the
inheritance hierarchies of the LDAP schema and the domain model are
"synchronized" our approach lacks a lot of elegance.
Joerg Henne
Re: Object LDAP mapping
Posted by Alex Karasulu <ak...@apache.org>.
Hi Graham,
It's a please to hear from you again.
On Dec 17, 2007 11:17 AM, Graham Leggett <mi...@sharp.fm> wrote:
> Has anybody heard of a Java package that does object to LDAP mapping,
> along the lines of Hibernate or Torque in the land of SQL?
>
I think Castor had something out there and even Hibernate tried. There's
also this Spring LDAP stuff but that's not really an object mapping
framework but rather more of a utility library that removes most of the
redundant scaffolding used with JNDI code specifically.
There is a big void in this space and I have some ideas where we can fill
that gap. I started experimenting with a few things in the sandbox here:
http://svn.apache.org/viewvc/directory/sandbox/akarasulu/j2l/trunk/
The code experiments with a handful of simple ideas:
A default mapping scheme is used to map Classes to STRUCTURAL objectClasses
and Interfaces to AUXILIARY objectClasses. You probably can immediately
infer on your own what abstract Java classes map to. Java interface and
class properties map to ldap attributes. There is some level of smart
inference we can make for most general cases to make sure the right things
happen with regard to may and must lists. Hence there is a default mapping
scheme with some smart logic designed to handle most common cases in terms
mentioned above and on how to handle syntaxes etc. Also I think we can do
some superb stuff with other concepts in both LDAP and Java like
ditStructureRules, nameForms etc, and with things like Java aspects.
However we can talk about this later. This should cover about 60-80% of the
mapping needs.
The rest of the user's needs can be accomodated with hints to the mapping
engine using Java 5 Annotations.
So this little experiment played with these concepts to see just how
feasible this is and the amount of wattage we'd need to apply to get this
done in a reasonable amount of time. I am by no means attached to the code
there. I just tinkered so we can discard this and start fresh if you like.
Regards,
Alex
You annotate a your classes, and interfaces their members or methods with
tags
> In other words, I would like a Java class hierarchy of objects
> representing LDAP objectlasses and LDAP objects.
>
> If such a thing doesn't exist, would the directory project be keen to
> adopt such a new piece of code as its home, if it were to be written?
>
> Regards,
> Graham
> --
>
>
>
Re: Object LDAP mapping
Posted by Jörg Henne <j....@levigo.de>.
Emmanuel,
Emmanuel Lecharny schrieb:
>
> long time, no see :)
yes, I am painfully aware of that. My involvement with our thin client
activities is a on-again off-again affair. Currently it is more
on-again, allowing me to re-visit lots of things which have been left in
a less-than-satisfying state since. :-/
> That would be great. There is only one little problem I can oversee :
> the actual project is released under GPL V2 license, which is not
> compatible with ASL 2.0. But I'm sure we can work this around.
>
The GPL choice is mainly influenced by the fact that a large part of
openthinclient.org depends on the Linux-based thin client OS.
Re-licensing any original openthinclient.org component (i.e. one for
which we actually own the copyright) that is useful outside
openthinclient.org is no problem at all.
> It would be a pleasure to discuss more in detail about such a
> contribution. I suggest we can start a new thread about it.
Ok, so be it. I've procrastinated for too long with giving the Apache DS
community an update, so I better use this kick to get me going :-)
Joerg Henne
Re: Object LDAP mapping
Posted by Emmanuel Lecharny <el...@gmail.com>.
Hi Jörg !
long time, no see :) At least, you are still prresent on the Directory
page : http://directory.apache.org/community%26resources/the-team.html
<snip/>
>
> I have toyed with the idea of donating this component to the Apache
> Directory Project, but have so far kept quiet, since the level of
> maturity wasn't where I would have deemed it fit for general
> consumption. This however, has changed in the last few weeks. So, if
> you consider rolling your own mapping solution, I think you would be a
> lot better off with the openthinclient.org component. The component
> currently lives at
> https://openthinclient.svn.sourceforge.net/svnroot/openthinclient/suite/trunk/common
> in the org.openthinclient.ldap package. Also contained are some
> test-cases illustrating basic usage. The GENERIC_RFC.xml mapping file
> could serve you as a rough guide to mapping your own objects.
>
> Just as a quick note to the broader Apache DS community:
> For the lack of a proper writeup of what I/we've been up to I'll give
> you a quick update. A few years ago, levigo developed a Linux based
> thin client management solution which has been deployed at quite a few
> customers, driving some thousands of thin client systems. Through the
> years it has always been a solution catering more to specialized
> cases, than to a real mass-market.
> About two years ago we started to replace the existing solution with a
> complete overhaul. This new solution was based on the idea of serving
> everything thin clients need from a single server with a simple
> deployment, to replace the old one requiring separate native TFTP,
> NFS, and DHCP servers. Second system syndrome along with limited
> resources has dragged out development of this system much longer than
> we anticipated, but in the past months the system reached a state
> where we can successfully pilot it in various settings.
> Since levigo's business model with respect to thin clients does not
> hinge on the sale of licenses, we open-sourced this solution in
> September. The project pulls together several technologies in order to
> achieve the goal of a single-server thin client solution: Java-based
> servers for NFS, TFTP, and PXE (a DHCP derivate for network boot
> applications) as well as Apache DS for the storage of all
> configuration information. At least two components of the system might
> be of interest for integration into Apache DS:
> - the PXE proxy has a lot of code which could be forged into a full
> DHCP server - I've always wanted to do this, but haven't found enough
> time yet.
> - the LDAP mapping mentioned above.
That would be great. There is only one little problem I can oversee :
the actual project is released under GPL V2 license, which is not
compatible with ASL 2.0. But I'm sure we can work this around.
It would be a pleasure to discuss more in detail about such a
contribution. I suggest we can start a new thread about it.
Thanks a lot !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: Object LDAP mapping
Posted by Alex Karasulu <ak...@apache.org>.
On Dec 17, 2007 12:13 PM, Jörg Henne <j....@levigo.de> wrote:
> Graham,
>
> Graham Leggett schrieb:
> > Hi all,
> >
> > Although not directly related to the directory server itself, I thought
> I
> > would ask here as the concentration of LDAP experts is high :)
> >
> > Has anybody heard of a Java package that does object to LDAP mapping,
> > along the lines of Hibernate or Torque in the land of SQL?
> >
> > In other words, I would like a Java class hierarchy of objects
> > representing LDAP objectlasses and LDAP objects.
> >
> > If such a thing doesn't exist, would the directory project be keen to
> > adopt such a new piece of code as its home, if it were to be written?
> >
> the openthinclient.org project contains an LDAP mapping component which
> uses a persistence model similar to Hibernate with an XML based mapping
> specification similar to Castor's. Although it is currently part of the
> aforementioned project, if has always been designed with a stand-alone
> operation in mind.
>
> What the LDAP mapper currently can do:
> - map "entities" (essentialy POJOs) to LDAP objects
> - handle CRUD operations
> - handle one-to-many (multi-valued attributes referencing objects as in
> groupOfNames) relationships
> - handle many-to-one relationships (single-valued attributes referencing
> objects)
> - handle bi-directional associations (currently with two active
> association ends leading to somewhat brittle behaviour - to be replaced
> with JPA/Hibernate style association management where only one end with
> be "responsible")
> - handle parent-child relationships (nesting of objects within the tree)
> - handle some degree of transitive persistence (save/update a graph of
> objects in one go)
> - offer reasonable performance through lazy-loading and caching
> - support different mappings for one Java-class allowing one domain
> model to be used on different DIT "dialects", e.g. RFC-based directories
> and MS-ADS-based directories.
>
I could have used that several times in the past 3 years. Let's talk about
it more and glad to hear below with your responses to Emmanuel that the
license issue can be rectified.
Now that we have some attention on this topic let's crank something out that
people can use. Whether you guys have something already working or you want
to start fresh no matter to me. The sooner we can avoid writing needless
handwoven code for LDAP persistence the better.
> What it currently can't do:
> - support for transactions though compensating actions has been designed
> into the system, but hasn't been properly implemented. Implementing it,
> would be rather simple, though.
> - the mapping model works for us, but might be too limited in some cases.
> - handle attribute types beyond simple strings
> - be properly documented :-)
>
> There is one other product in this area I am aware of: spring LDAP. I
> had a quick look at spring LDAP, and it appeared to me to have a rather
> limited scope of merely eliminating LDAP chores more along the lines of
> a templating rather than a mapping. However, it supports transactions.
>
> I have toyed with the idea of donating this component to the Apache
> Directory Project, but have so far kept quiet, since the level of
> maturity wasn't where I would have deemed it fit for general
> consumption. This however, has changed in the last few weeks. So, if you
> consider rolling your own mapping solution, I think you would be a lot
> better off with the openthinclient.org component. The component
> currently lives at
>
> https://openthinclient.svn.sourceforge.net/svnroot/openthinclient/suite/trunk/common
> in the org.openthinclient.ldap package. Also contained are some
> test-cases illustrating basic usage. The GENERIC_RFC.xml mapping file
> could serve you as a rough guide to mapping your own objects.
>
> Just as a quick note to the broader Apache DS community:
> For the lack of a proper writeup of what I/we've been up to I'll give
> you a quick update. A few years ago, levigo developed a Linux based thin
> client management solution which has been deployed at quite a few
> customers, driving some thousands of thin client systems. Through the
> years it has always been a solution catering more to specialized cases,
> than to a real mass-market.
> About two years ago we started to replace the existing solution with a
> complete overhaul. This new solution was based on the idea of serving
> everything thin clients need from a single server with a simple
> deployment, to replace the old one requiring separate native TFTP, NFS,
> and DHCP servers. Second system syndrome along with limited resources
> has dragged out development of this system much longer than we
> anticipated, but in the past months the system reached a state where we
> can successfully pilot it in various settings.
> Since levigo's business model with respect to thin clients does not
> hinge on the sale of licenses, we open-sourced this solution in
> September. The project pulls together several technologies in order to
> achieve the goal of a single-server thin client solution: Java-based
> servers for NFS, TFTP, and PXE (a DHCP derivate for network boot
> applications) as well as Apache DS for the storage of all configuration
> information. At least two components of the system might be of interest
> for integration into Apache DS:
> - the PXE proxy has a lot of code which could be forged into a full DHCP
> server - I've always wanted to do this, but haven't found enough time yet.
> - the LDAP mapping mentioned above.
>
That's pretty cool. I'll take a closer look at it. It would be cool if we
can get our DHCP module up to speed too. Also I talked to an acquaintance
who would has already implemented SLP and would like to do it here as a
module in ApacheDS in MINA. Don't know for sure but this might add some
value. Regardless it's good to hear from you again.
Regards,
Alex
Re: Object LDAP mapping
Posted by Jörg Henne <j....@levigo.de>.
Graham,
Graham Leggett schrieb:
> Hi all,
>
> Although not directly related to the directory server itself, I thought I
> would ask here as the concentration of LDAP experts is high :)
>
> Has anybody heard of a Java package that does object to LDAP mapping,
> along the lines of Hibernate or Torque in the land of SQL?
>
> In other words, I would like a Java class hierarchy of objects
> representing LDAP objectlasses and LDAP objects.
>
> If such a thing doesn't exist, would the directory project be keen to
> adopt such a new piece of code as its home, if it were to be written?
>
the openthinclient.org project contains an LDAP mapping component which
uses a persistence model similar to Hibernate with an XML based mapping
specification similar to Castor's. Although it is currently part of the
aforementioned project, if has always been designed with a stand-alone
operation in mind.
What the LDAP mapper currently can do:
- map "entities" (essentialy POJOs) to LDAP objects
- handle CRUD operations
- handle one-to-many (multi-valued attributes referencing objects as in
groupOfNames) relationships
- handle many-to-one relationships (single-valued attributes referencing
objects)
- handle bi-directional associations (currently with two active
association ends leading to somewhat brittle behaviour - to be replaced
with JPA/Hibernate style association management where only one end with
be "responsible")
- handle parent-child relationships (nesting of objects within the tree)
- handle some degree of transitive persistence (save/update a graph of
objects in one go)
- offer reasonable performance through lazy-loading and caching
- support different mappings for one Java-class allowing one domain
model to be used on different DIT "dialects", e.g. RFC-based directories
and MS-ADS-based directories.
What it currently can't do:
- support for transactions though compensating actions has been designed
into the system, but hasn't been properly implemented. Implementing it,
would be rather simple, though.
- the mapping model works for us, but might be too limited in some cases.
- handle attribute types beyond simple strings
- be properly documented :-)
There is one other product in this area I am aware of: spring LDAP. I
had a quick look at spring LDAP, and it appeared to me to have a rather
limited scope of merely eliminating LDAP chores more along the lines of
a templating rather than a mapping. However, it supports transactions.
I have toyed with the idea of donating this component to the Apache
Directory Project, but have so far kept quiet, since the level of
maturity wasn't where I would have deemed it fit for general
consumption. This however, has changed in the last few weeks. So, if you
consider rolling your own mapping solution, I think you would be a lot
better off with the openthinclient.org component. The component
currently lives at
https://openthinclient.svn.sourceforge.net/svnroot/openthinclient/suite/trunk/common
in the org.openthinclient.ldap package. Also contained are some
test-cases illustrating basic usage. The GENERIC_RFC.xml mapping file
could serve you as a rough guide to mapping your own objects.
Just as a quick note to the broader Apache DS community:
For the lack of a proper writeup of what I/we've been up to I'll give
you a quick update. A few years ago, levigo developed a Linux based thin
client management solution which has been deployed at quite a few
customers, driving some thousands of thin client systems. Through the
years it has always been a solution catering more to specialized cases,
than to a real mass-market.
About two years ago we started to replace the existing solution with a
complete overhaul. This new solution was based on the idea of serving
everything thin clients need from a single server with a simple
deployment, to replace the old one requiring separate native TFTP, NFS,
and DHCP servers. Second system syndrome along with limited resources
has dragged out development of this system much longer than we
anticipated, but in the past months the system reached a state where we
can successfully pilot it in various settings.
Since levigo's business model with respect to thin clients does not
hinge on the sale of licenses, we open-sourced this solution in
September. The project pulls together several technologies in order to
achieve the goal of a single-server thin client solution: Java-based
servers for NFS, TFTP, and PXE (a DHCP derivate for network boot
applications) as well as Apache DS for the storage of all configuration
information. At least two components of the system might be of interest
for integration into Apache DS:
- the PXE proxy has a lot of code which could be forged into a full DHCP
server - I've always wanted to do this, but haven't found enough time yet.
- the LDAP mapping mentioned above.
Joerg Henne
Re: Object LDAP mapping
Posted by Alex Karasulu <ak...@apache.org>.
The RDBMS access model is completely different from the LDAP access model.
Trying to map JDBC to LDAP and vice versa may work superficially but should
only be used by those who need training wheels on LDAP.
Alex
On Dec 17, 2007 11:42 AM, Marc Boorshtein <mb...@gmail.com> wrote:
> You may want to try using jdbc-ldap with your favorite orm.
>
> Marc
>
>
> On 12/17/07, Graham Leggett <mi...@sharp.fm> wrote:
> > Hi all,
> >
> > Although not directly related to the directory server itself, I thought
> I
> > would ask here as the concentration of LDAP experts is high :)
> >
> > Has anybody heard of a Java package that does object to LDAP mapping,
> > along the lines of Hibernate or Torque in the land of SQL?
> >
> > In other words, I would like a Java class hierarchy of objects
> > representing LDAP objectlasses and LDAP objects.
> >
> > If such a thing doesn't exist, would the directory project be keen to
> > adopt such a new piece of code as its home, if it were to be written?
> >
> > Regards,
> > Graham
> > --
> >
> >
> >
>
Re: Object LDAP mapping
Posted by Marc Boorshtein <mb...@gmail.com>.
You may want to try using jdbc-ldap with your favorite orm.
Marc
On 12/17/07, Graham Leggett <mi...@sharp.fm> wrote:
> Hi all,
>
> Although not directly related to the directory server itself, I thought I
> would ask here as the concentration of LDAP experts is high :)
>
> Has anybody heard of a Java package that does object to LDAP mapping,
> along the lines of Hibernate or Torque in the land of SQL?
>
> In other words, I would like a Java class hierarchy of objects
> representing LDAP objectlasses and LDAP objects.
>
> If such a thing doesn't exist, would the directory project be keen to
> adopt such a new piece of code as its home, if it were to be written?
>
> Regards,
> Graham
> --
>
>
>
Re: Object LDAP mapping
Posted by Stefan Zoerner <st...@labeo.de>.
Hi Graham!
Graham Leggett wrote:
> Although not directly related to the directory server itself, I thought I
> would ask here as the concentration of LDAP experts is high :)
>
> Has anybody heard of a Java package that does object to LDAP mapping,
> along the lines of Hibernate or Torque in the land of SQL?
>
> In other words, I would like a Java class hierarchy of objects
> representing LDAP objectlasses and LDAP objects.
JNDI itself offers a simple mapping from LDAP entries to Java objects
and vice versa with the help of so called state factories (Java -> LDAP)
and object factories (LDAP -> Java).
http://java.sun.com/products/jndi/tutorial/objects/state/index.html
http://java.sun.com/products/jndi/tutorial/objects/factory/index.html
At least it helps you to abstract from the LDAP schema.
Spring LDAP is another option. It has comparable functionality, but you
get another dependency (JNDI is always present).
http://www.springframework.org/ldap
Both options do not provide transparent mapping like Hibernate does.
Greetings,
Stefan