Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 98689 invoked from network); 6 Dec 2010 16:33:14 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Dec 2010 16:33:14 -0000 Received: (qmail 7390 invoked by uid 500); 6 Dec 2010 16:33:14 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 7222 invoked by uid 500); 6 Dec 2010 16:33:12 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 7214 invoked by uid 99); 6 Dec 2010 16:33:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Dec 2010 16:33:11 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.212.50 as permitted sender) Received: from [209.85.212.50] (HELO mail-vw0-f50.google.com) (209.85.212.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Dec 2010 16:33:06 +0000 Received: by vws14 with SMTP id 14so4929419vws.37 for ; Mon, 06 Dec 2010 08:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=xYCLyJ0PTkPRppH+N0Ww4/5M5CQDXlhTxP69+F/8LEQ=; b=vXCzJK6DRaxW+5PCviRpzojL78i65LXSNE0YrU9BHtv86PdWOY9CSULrBzU7N22cXd Dl+J7WtlYw8vIeBNEIvWtBVg0pWxmlu9l1pzTPpYI5/7DzIYa2UK6SQFuivHW6+c2a9p I7Z703CSCfDc8MMqTUBABbkgqfkqW3mFb0yfM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=ZuD9/M3mDAilIdtt4QrHcHl96ETyAR7e1KcW2h84VU57D1bfVEUlxwG2rtqndb6qeO pxMJdKUz8lA7SOeM0s1jJ2SvZ5OmWB0hrbpqHY6uI7isNJFq2T8lUVH3ez/DXmsPF1/3 4nj5Asxw0vsWV8sk6cyqzoSpEoIphe++LxrCs= MIME-Version: 1.0 Received: by 10.229.242.66 with SMTP id lh2mr4391517qcb.118.1291653165003; Mon, 06 Dec 2010 08:32:45 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.229.192.196 with HTTP; Mon, 6 Dec 2010 08:32:44 -0800 (PST) In-Reply-To: References: Date: Mon, 6 Dec 2010 18:32:44 +0200 X-Google-Sender-Auth: tfgmDkMhE8YUStJwBSPc_hcEsDw Message-ID: Subject: Re: Adding annotations to Configuration beans From: Alex Karasulu To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=0016362843d612b3ed0496c07092 --0016362843d612b3ed0496c07092 Content-Type: text/plain; charset=ISO-8859-1 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 reader. > 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. > 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? 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? > - @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? 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. Also as Kiran pointed out in his response, what if the contained elements are kept in a single attribute like this ads-compositeElement ? 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. Thanks, -- Alex Karasulu My Blog :: http://www.jroller.com/akarasulu/ Apache Directory Server :: http://directory.apache.org Apache MINA :: http://mina.apache.org To set up a meeting with me: http://tungle.me/AlexKarasulu --0016362843d612b3ed0496c07092 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi=A0Pierre-Arnaud,

On Mon, Dec 6, 2010 at 4:02 PM, Pierre-Arnaud Marcelot <pa@marcelot.net> wrot= e:
Hi Dev,

I successfully integrated the newly introduced ApacheDS Configuration Reade= r (with all configuration beans) in the ApacheDS 2.0 Configuration Editor f= or Apache Directory Studio.
The UI is not completely finished yet, but I can already load a configurati= on 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 A= nnotation elements that would be used in the Configuration Beans to help bo= th the configuration writer and the reader.
Adding these Annotation elements would help maintaining the reader and writ= er loosely coupled with the beans and would facilitate additions of new con= figuration items (like those needed by Antoine, or others from third partie= s implementations).


Good idea. However I can't help bu= t point out that we're naturally starting to define ldap persistence me= chanisms however minimal :). Wish we had something that could do this autom= atically for us by now. I guess doing the minimum just to get this configur= ation DIT to object containment tree and vice a versa is enough to get us b= y here in this particular situation.=A0
=A0
There 3 annotations I'd like to introduce:

- @AttributeType( attributeTypeId )
This annotation is intended to be used on a field of a configuration bean a= nd 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 t= he id of the attribute type from the name of the field ( same thing for hav= ing to truncate the 'ads-' prefix sometimes).
It's clear and easy.

+1
= =A0
Furthermore, only fields with this annotation should be read and written by= the configuration reader/writer (which allows the configuration beans to h= ave extra fields that are not necessarily read or written).


+1
=A0
- @RDN
This annotation is intended to be used on a field of a configuration bean i= n conjunction with the @AttibuteType annotation and indicates that this par= ticular field is the one (and only for a given configuration bean) to be us= ed 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?

Also can we all us= e camel humps for acronyms as well? Just looks more java'ish so if we w= ent ahead and did this as another annotation rather than adding this isRdnA= ttribute property to @AttributeType then perhaps we can use @Rdn?
=A0
- @Container( containerRdn )
This is intended to be used on a field of a configuration bean and more par= ticularly 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 cont= ainer entry) like the 'ou=3Dservers' entry under the defaultDirecto= ryService entry.

Any thoughts on this?

This @Container = stuff is not so simple for me. I have no idea how we do Lists - LDAP and Li= st persistence is a big problem. So I guess you're talking about puttin= g this @Container annotation on container members like a List or Set. Speci= fically this will tell the writer where in the DIT to place the elements of= the container member correct?

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. No= w if the contained elements are always subordinate to the configuration bee= n then I see why it is RDN.

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

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

--0016362843d612b3ed0496c07092--