directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre-Arnaud Marcelot>
Subject Re: Adding annotations to Configuration beans
Date Mon, 06 Dec 2010 17:00:33 GMT
On 6 déc. 2010, at 17:32, Alex Karasulu wrote:

> Hi Pierre-Arnaud,
> On Mon, Dec 6, 2010 at 4:02 PM, Pierre-Arnaud Marcelot <> wrote:
> Hi Dev,
> I successfully integrated the newly introduced ApacheDS Configuration Reader (with all
configuration beans) in the ApacheDS 2.0 Configuration Editor for Apache Directory Studio.
> The UI is not completely finished yet, but I can already load a configuration from an
LDIF file and I have access to the values of each bean. It's working really great...
> Wooot !
> Now, that the configuration can be read, it also need to be written, and I started working
on a Configuration Writer.
> In order to achieve this, I'd like to propose the addition of several Annotation elements
that would be used in the Configuration Beans to help both the configuration writer and the
> Adding these Annotation elements would help maintaining the reader and writer loosely
coupled with the beans and would facilitate additions of new configuration items (like those
needed by Antoine, or others from third parties implementations).
> Good idea. However I can't help but point out that we're naturally starting to define
ldap persistence mechanisms however minimal :). Wish we had something that could do this automatically
for us by now. I guess doing the minimum just to get this configuration DIT to object containment
tree and vice a versa is enough to get us by here in this particular situation. 

Indeed, we could really leverage some LDAP Persistence Mechanisms if we had them right now.
That said, the set of features needed for this particular configuration reader/writer code
is pretty limited and can probably be implemented in a few days.

>  There 3 annotations I'd like to introduce:
> - @AttributeType( attributeTypeId )
> This annotation is intended to be used on a field of a configuration bean and indicates
which attribute type id this field is associated with.
> I think it's a great addition as we're no longer in need to infer the id of the attribute
type from the name of the field ( same thing for having to truncate the 'ads-' prefix sometimes).
> It's clear and easy.
> +1
> Furthermore, only fields with this annotation should be read and written by the configuration
reader/writer (which allows the configuration beans to have extra fields that are not necessarily
read or written).
> +1
> - @RDN
> This annotation is intended to be used on a field of a configuration bean in conjunction
with the @AttibuteType annotation and indicates that this particular field is the one (and
only for a given configuration bean) to be used in the RDN of the associated entry
> How about just adding this as an extra property to the @AttributeType annotation? You
can have a boolean flag for something like isRdnAttribute?

Héhé, see my latest mail... ;)

> Also can we all use camel humps for acronyms as well? Just looks more java'ish so if
we went ahead and did this as another annotation rather than adding this isRdnAttribute property
to @AttributeType then perhaps we can use @Rdn?

I am just following our current class naming guidelines where we now use DN, RDN since the
introduction of the new LDAP API and the discussions on the API ML.

> - @Container( containerRdn )
> This is intended to be used on a field of a configuration bean and more particularly
on a field referring to a composite (List, Set, etc.) bean value. It indicates where the adding
bean entries are to be placed (in which container entry) like the 'ou=servers' entry under
the defaultDirectoryService entry.
> Any thoughts on this?
> This @Container stuff is not so simple for me. I have no idea how we do Lists - LDAP
and List persistence is a big problem. So I guess you're talking about putting this @Container
annotation on container members like a List or Set. Specifically this will tell the writer
where in the DIT to place the elements of the container member correct?

Correct. And tell the reader where to find the elements.

> If I understood correctly then I'm thinking containerRdn really needs to be DN. I'm thinking
the parent entry containing these elements can be anywhere hence why I was thinking of a DN
verses an RDN. Now if the contained elements are always subordinate to the configuration been
then I see why it is RDN.

Yeah, they are always underneath the current bean's entry.

> Also as Kiran pointed out in his response, what if the contained elements are kept in
a single attribute like this ads-compositeElement ?

AFAIR, the 'ads-compositeElement' was introduced as kind of "quick hack" to ease the work
on the reader class. I really think we can get rid of it easily with the annotation system.

> The use of annotations sounds like the best path we can take right now without wasting
a hell of a lot of time with a generalized object ldap mapping capability. 

Yeah, it could take a large amount of time to write such a toolkit and we'd like to deliver
ApacheDS 2.0 quite soon. However, we can see this configuration annotation system as a small
prototype for a larger, more generalized LDAP Object Mapping utility.


> Thanks,
> -- 
> Alex Karasulu
> My Blog ::
> Apache Directory Server ::
> Apache MINA ::
> To set up a meeting with me:

View raw message