From dev-return-35991-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Mon Dec 06 16:37:04 2010 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 99797 invoked from network); 6 Dec 2010 16:37:03 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 6 Dec 2010 16:37:03 -0000 Received: (qmail 14679 invoked by uid 500); 6 Dec 2010 16:37:03 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 14631 invoked by uid 500); 6 Dec 2010 16:37: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 14624 invoked by uid 99); 6 Dec 2010 16:37:03 -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:37: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 (athena.apache.org: domain of pajbam@gmail.com designates 209.85.214.50 as permitted sender) Received: from [209.85.214.50] (HELO mail-bw0-f50.google.com) (209.85.214.50) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 06 Dec 2010 16:36:57 +0000 Received: by bwz17 with SMTP id 17so14100166bwz.37 for ; Mon, 06 Dec 2010 08:36:35 -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=z1MsYkTUklNzyC1p+OuAVjZdceU4fCONk9xJ2gmrAAM=; b=Shq6YM+Y8O2prbyAxuyki54kbzYK4WzjogL1z/oWSkxhq9K5nPopaLdZWH/JX9yaAS QZQAHopLhWCjTO2kubezXB60SdZv4TueWpXhCAVovHqC/qviLNNGEiaSng8uBvQF5vqB dkeauCnxTBieCUgsYjmoinx2u9JXFQSvN9C+o= 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=hySYPLbZdyGnWOzvONwLiEPuwa1uZsiHDW7QcULsAyPKkLeZhZ5HbHRCDYBqE5eAqJ K6mjFyD/oppdSMfP1CWBQ1/Iog+V7JCw0iGCu6odNsPnSevrJbY2hdyOqzPbmo7ub44I RQo/JQEESi7n5ioGVhzPF5vFN0mkABVXxqHog= Received: by 10.216.22.79 with SMTP id s57mr169809wes.94.1291653394494; Mon, 06 Dec 2010 08:36:34 -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 p4sm2442428wer.29.2010.12.06.08.36.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Dec 2010 08:36:32 -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-10--186421423 Subject: Re: Adding annotations to Configuration beans Date: Mon, 6 Dec 2010 17:36:31 +0100 In-Reply-To: To: "Apache Directory Developers List" References: Message-Id: <81A931E6-6D27-4481-BF22-E33FC9D2E94D@marcelot.net> X-Mailer: Apple Mail (2.1082) --Apple-Mail-10--186421423 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 6 d=E9c. 2010, at 15:16, Kiran Ayyagari wrote: > 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 > cool >> 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 >> 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. >> 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 >> - @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 > sounds good >> - @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 > hmm, not sure how it will distinguishes a collection of other > container from a collection of plain attribute values, will wait till > some code gets committed to comment on this, but all in all it sounds > good to me Indeed, although I could get it to work in the writer's code (where I = could test the type of the field), it will probably be a problem on the = other side, in the reader's code. After, playing a bit with the implementation of this annotations idea, = I'm wondering if it would not be better to combine all annotations into = a single one. We could have something like this one: > /** > * An annotation used to specify that the qualified field is = configuration element. > * > * @author Apache = Directory Project > */ > @Documented > @Inherited > @Retention(RetentionPolicy.RUNTIME) > @Target(ElementType.FIELD) > public @interface ConfigurationElement > { > /** > * Returns the attribute type. > * > * @return > * the attribute type > */ > String attributeType() default ""; >=20 >=20 > /** > * Returns the object class. > * > * @return > * the object class > */ > String objectClass() default ""; >=20 >=20 > /** > * Returns true if of the qualified field (attribute type and = value)=20 > * is the RDN of the entry. > * > * @return > * true if of the qualified field (attribute = type and value)=20 > * is the RDN of the entry, > * false if not. > */ > boolean isRDN() default false; >=20 >=20 > /** > * Returns true if the qualified field contains multiple values. > * > * @return > * true if the qualified field contains multiple = values, > * false if not. > */ > boolean isMultiple() default false; >=20 >=20 > /** > * Returns the string value of the DN of the container. > * > * @return > * the string value of the DN of the container. > */ > String container() default ""; > } This should be easier to write in the configuration beans and should = also solve the problems with the collections. Note the addition of the 'isMultiple' flag and the 'objectClass' string = value for the name of the object class in case a field is linked to = another Bean or collection of Beans. Thoughts? At some point, I think it's better that I start a new branch for = experimenting this. I'll do this in a few minutes. Thanks, Pierre-Arnaud >=20 > thanks for the heads up Pierre-Arnaud >=20 > --=20 > Kiran Ayyagari --Apple-Mail-10--186421423 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
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...

cool
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).

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.
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).

- = @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

sounds good
- = @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.

hmm, not sure how it will distinguishes a = collection of other
container from a collection of plain attribute = values, will wait till
some code gets committed to comment on this, = but all in all it sounds
good to = me

Indeed, although I could = get it to work in the writer's code (where I could test the type of the = field), it will probably be a problem on the other side, in the reader's = code.

After, playing a bit with the = implementation of this annotations idea, I'm wondering if it would not = be better to combine all annotations into a single one.
We = could have something like this one:
 * An annotation = used to specify that the qualified field is configuration = element.
 *
 * @author <a href=3D"mailto:dev@directory.apache.org">Apache Directory = Project</a>
 */
@Inherited
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.FIELD)
public @interface ConfigurationElement
{
/**
     * Returns the attribute = type.
     = *
     * @return
     */
    String = attributeType() default "";


    /**
     * = Returns the object class.
@return
     */
    String = objectClass() default "";


    /**
     * = Returns true if of the qualified field (attribute type and = value) 
     * is = the RDN of the entry.
     = *
     * @return
<code>true</code> if of the qualified field (attribute type = and value) 
     * is = the RDN of the entry,
     = *      <code>false</code> if not.
    boolean isRDN() default = false;


/**
     * Returns true if the qualified = field contains multiple values.
@return
<code>true</code> if the qualified field contains multiple = values,
     = *      <code>false</code> if not.
    boolean isMultiple() default false;


    /**
     * = Returns the string value of the DN of the container.
     *
@return
     = */
default "";
}

This = should be easier to write in the configuration beans and should also = solve the problems with the collections.

Note = the addition of the 'isMultiple' flag and the 'objectClass' string value = for the name of the object class in case a field is linked to another = Bean or collection of = Beans.

Thoughts?

At = some point, I think it's better that I start a new branch for = experimenting this. I'll do this in a few = minutes.

Thanks,
Pierre-Arnaud


thanks for the heads up = Pierre-Arnaud

--
Kiran = Ayyagari

= --Apple-Mail-10--186421423--