Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 7813 invoked from network); 6 Dec 2010 17:01:04 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Dec 2010 17:01:04 -0000 Received: (qmail 63086 invoked by uid 500); 6 Dec 2010 17:01:04 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 62963 invoked by uid 500); 6 Dec 2010 17:01:03 -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 62956 invoked by uid 99); 6 Dec 2010 17:01:03 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Dec 2010 17:01:03 +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 (nike.apache.org: domain of pajbam@gmail.com designates 209.85.215.53 as permitted sender) Received: from [209.85.215.53] (HELO mail-ew0-f53.google.com) (209.85.215.53) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Dec 2010 17:00:56 +0000 Received: by ewy6 with SMTP id 6so21154317ewy.40 for ; Mon, 06 Dec 2010 09:00:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:mime-version :content-type:subject:date:in-reply-to:to:references:message-id :x-mailer; bh=V0zQiT2gTb6KBF6sx1tfTbAChv6hyfdK0E87rR0GLEY=; b=u+CYQsiYFpVPcWwCUfQ+sXqLuZCJqE+xgh0tl8wvPOy+0jZnrHPHy3OAOM5ETb95Mb m68d3FfTlX0VlfK3S7cwLW3oIEkpQV7OnZhZyb223R6905As0WhRSyCg20PgrSjYBLCa PHdsFiFSdqqNkz9CgLyG/4FlYLLxK/wQSeTYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:mime-version:content-type:subject:date:in-reply-to:to :references:message-id:x-mailer; b=Ha5H06We2d4tbnR/6jfq1KNFtT9BwMtLjNfmnD+i9h8ehOFBJSP6nFOvbZYWwe7C2W BjWL+Rzy0/8p01UxNKppUox/xqZBOaEjY5G+NhXhCCozlWJ3Az1X0VyyWzF1lxW3Nub4 N19e/bwboJ9rctTAXFtQaqRbuISF1Rf5A+1cY= Received: by 10.216.150.166 with SMTP id z38mr161290wej.6.1291654836383; Mon, 06 Dec 2010 09:00:36 -0800 (PST) Received: from [192.168.0.52] (lon92-10-78-226-4-211.fbx.proxad.net [78.226.4.211]) by mx.google.com with ESMTPS id p4sm2455889wej.4.2010.12.06.09.00.34 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 09:00:35 -0800 (PST) Sender: Pierre-Arnaud Marcelot From: Pierre-Arnaud Marcelot Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-11--184978954 Subject: Re: Adding annotations to Configuration beans Date: Mon, 6 Dec 2010 18:00:33 +0100 In-Reply-To: To: "Apache Directory Developers List" References: Message-Id: X-Mailer: Apple Mail (2.1082) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail-11--184978954 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 6 d=E9c. 2010, at 17:32, Alex Karasulu wrote: > Hi Pierre-Arnaud, >=20 > On Mon, Dec 6, 2010 at 4:02 PM, Pierre-Arnaud Marcelot = wrote: > Hi Dev, >=20 > 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... >=20 >=20 > Wooot ! >=20 > Now, that the configuration can be read, it also need to be written, = and I started working on a Configuration Writer. >=20 > 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). >=20 >=20 > 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.=20 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: >=20 > - @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. >=20 > +1 > =20 > 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). >=20 >=20 > +1 > =20 > - @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 >=20 >=20 > How about just adding this as an extra property to the @AttributeType = annotation? You can have a boolean flag for something like = isRdnAttribute? H=E9h=E9, 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=3Dservers' entry under the = defaultDirectoryService entry. >=20 > Any thoughts on this? >=20 > 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.=20 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, Pierre-Arnaud > Thanks, > --=20 > 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 --Apple-Mail-11--184978954 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi Pierre-Arnaud,

On Mon, Dec 6, 2010 at 4:02 PM, Pierre-Arnaud = Marcelot <pa@marcelot.net> = 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. 

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=E9h=E9, = 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=3Dservers' 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,
Pierre-Arnaud
Thanks,
--
Alex Karasulu
My = Blog :: http://www.jroller.com/akarasul= u/
Apache Directory Server :: http://directory.apache.org
Apache MINA :: http://mina.apache.org
To set up = a meeting with me: http://tungle.me/AlexKarasulu

= --Apple-Mail-11--184978954--