Re: what are the limitations of the JNDIAdapter?
Re: what are the limitations of the JNDIAdapter?
- Subject: Re: what are the limitations of the JNDIAdapter?
- From: Benjamin J Doherty <email@hidden>
- Date: Wed, 30 Nov 2005 08:04:19 -0600
Friends,
I've pushed ahead with the JNDIAdapter and settled on a paradigm of
mapping LDAP-style objects to Java-style objects. Some problems and
questions still remain, especially with respect to relationships
between JNDI objects and anything that involves reading or writing
the relativeDistinguishedName attribute.
However, I believe I'm closer to my goal of being able to use
auxiliary classes. Here's my method:
I created a set of base classes for every objectClass in the schemas
on my LDAP server all in a single EOModel. The base of my searches is
just the nameless root (""), so I also have needed to create
additional EOModels for any functional instance of my EOF classes.
All the base classes are functionally abstract in that they're never
instantiated in my application, but I'm not declaring them abstract.
What's important here is that I've implemented inheritance from Top
down for each class. So almost every class has a parent. (A few
auxiliary classes don't even inherit from Top.) I also start creating
custom business logic for these classes, so for example inetOrgPerson
has some special methods that automatically generate a cn attribute
to be used in the relativeDistinguishedName, etc. Here's the
description of my generic inetOrgPerson class:
className = "org.mygroup.directory.InetOrgPerson";
name = inetOrgPerson;
parent = OrganizationalPerson;
Then I create another EOModel for parts of the LDAP tree where I'm
going to actually be creating entries. I named them after their RDN,
but that's not important. Here my concrete instances of classes are
just copied and pasted from the base model:
className = "org.mygroup.directory.Staff"; name = Staff;
It's important to know that org.mygroup.directory.Staff inherits from
org.mygroup.directory.InetOrgPerson. I copied the inetOrgPerson
entity from my base classes and pasted that into the new EOModel with
a new name. You can't give the new class a parent, because EOF
considers the two classes to be in separate "databases," so it can't
do a deep fetch, so it complains and dies.
For me, all my Staff are inetOrgPerson-classed and posixAccount-
classed. Because posixAccount is auxiliary, I've interpreted that as
an interface. I got EOGenerator to give me a _posixAccount class
which I modified into an interface named posixAccount. Now I can
paste the grubby details from the _posixAccount class into my classes
which implement the posixAccount interface. There's really nothing
magical going on here. It's just a cheap and easy way to always get
good methods for my interface by pasting the generated ones into my
superclass.
This allows me to edit existing entries in the LDAP database. I can
edit all the attributes for my Staff records, not just those from
either inetOrgPerson or posixAccount classes.
How do I create records with both objectClasses inetOrgPerson and
posixAccount? This is speculative now, and I will report more later.
If you've got cautionary tales, please tell me so I don't repeat your
mistakes. I've discovered that I can make the objectClass property in
EOF visible to the server side. It's type also needs to be NSArray
instead of String. What I can say is that THIS DOES NOT CAUSE MY APP
TO CRASH. Yay! But now EOF won't generate the objectClass
automatically, so I need to create it myself in the business logic.
What have I learned so far?
1. When confronted with multiple inheritance, choose the parent
class that will bring in the most custom logic.
2. Just like in LDAP, you should build around structural classes.
Map auxiliary LDAP classes onto java interfaces.
3. It's not harmful to cast multi-valued LDAP attributes as NSArray,
but then you need to deal with some special situations. I believe
Chuck Hill posted some code about dealing with multi-valued
attributes on the list a few years ago, and that's useful. Basically
you need classes to handle actual multi-valued attributes and those
multi-valued attributes that may only hold a single value in a
particular instance and so EOF hands off a String instead of a NSArray.
What am I gonna do now? I must write a method which checks for the
existence of the appropriate object classes (somewhere around
awakeFromInsert probably) and sets them if necessary. If that works,
I'll use inheritance to my advantage and make all superclasses
provide their type.
If that doesn't work, I'm going to have to create some structural
subclasses that inherit from multiple places. So MyorgStaff would
inherit from inetOrgPerson and posixAccount. Not elegant but it will
work.
Cheers,
Benjamin in Chicago
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden