On 12/17/10 4:00 PM, Pierre-Arnaud Marcelot wrote:
Hi Antoine,

I only added it for consistency with other entries in the configuration and for the 
following reason, mention by Emmanuel in the previous thread "Adding annotations to 
Configuration beans":

Begin forwarded message:
On 12/6/10 6:00 PM, Pierre-Arnaud Marcelot wrote:
On 6 déc. 2010, at 17:32, Alex Karasulu wrote:
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.
ads-compositeElement has been created at the origin as a way to tell the reader 
that the element is a composite element. The reader was supposed to be 
completely generic, ie the java Beans could have been generated automatically 
(except that because it requires the development of a maven plugin, something I 
didn't want to do).

Now that you have defined some @, sure this is redondant, but if someone decide 
to define a reader/writer in another language, then this element is probably 
necessary.

That said, I 100% agree on the fact that this attribute is redundant and 
somehow unnecessary.

I still think it should be removed for an easier (hand) writing of the 
configuration.
Also, looks like the ConfigReader does not need it in its current 
implementation, as all objects were perfectly instantiated before my fix on the 
file.

Maybe it's time to take a community-wide decision about these types of 
attributes (attributes extending 'ads-compositeElement').

Regards,
Pierre-Arnaud

On 17 déc. 2010, at 15:31, Antoine Levy-Lambert wrote:

Hello Pierre-Alain,

is this change needed ?

I would think that these attributes are only needed when you are dealing with 
for instance a multi-valued string.

But this is a list contained in a subentry ou=authenticators

So I think that this ads-authenticators attribute is not required.

So let's remove it.

No need to add stack over stack without cleaning what is obsolete. Nobody will be interested in the future to dig the code in order to ressucitate the different layers, as if ADS was the city of Troy...


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Reply via email to