We can always make it required, and make it optional later, but
making it optional then required is harder since it might require
code changes to those using it.
It's true that conflicts have to be handled, but my suspicion is that
forcing someone to choose a name might help reduce the number of such
conflicts, and tie into a "best practice" which we javadoc as part of
the annotation.
Lloyd
On Jan 18, 2008, at 1:28 PM, Bill Shannon wrote:
> Jerome Dochez wrote:
>> ok I think it would be ok yes, we then make name() a mandatory
>> attribute of the @Extract annotation. anyone else want to comment
>> before we commit ?
>
> Even with explicit names you have to handle conflicts so the behavior
> there needs to be well defined.
>
> Whether you should always require a name to be specified or whether
> defaulting the name to (e.g.) the class name is acceptable seems to
> depend on how often you expect there to be conflicts. If it's very
> common that a given type is extracted from multiple services, then
> you probably want to require a name. If < 20% of the services will
> extract conflicting objects, then a default name is probably
> worthwhile.
>
> And if we don't know which is best right now, just pick one approach
> and we'll change it later when we know more.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>
---
Lloyd L Chambers
lloyd.chambers_at_sun.com
Sun Microsystems, Inc