IDs (names) should be used only for items that a non-singletons within
their scope.
If you want to have an identifier that's OK, but do not mark it as
@Attribute(key=true), since that effectively states that there can be
more than one in its scope.
Lloyd
On Jul 6, 2009, at 8:35 AM, Justin Lee wrote:
> June has requested that IDs be added to the <http> and <file-cache>
> elements so that the create/delete commands can be implemented/
> documented as usual. There are arguments for and against doing this
> so I'm going to try to enumerate them all so that we can come to a
> consensus about this.
>
> As I understand things, IDs are usually only given to elements that
> are cross referenced from others. In the cases of <http> and <file-
> cache> they are embedded in parents and never referred to
> externally. The awkwardness with having no IDs present (at least on
> file-cache) is that a glassfish admin would need to know the ID of
> the grandparent (<protocol> in this case) because <http> itself
> doesn't have an ID either. One solution, of course, is to add IDs
> all the way down. Another possibility would be to take either the
> protocol ID or the network-listener ID. That would look like:
> asadmin create-file-cache --networklistener=http-listener-1
> or
> asadmin create-file-catch --protocol=protocol-1
> This would frame the create/delete in the context of the logical
> constructs that would use that file-cache which actually might lower
> some of the mental hurdles in configuring the system. Not having
> IDs on the elements might make the list commands awkward, but I'm
> not entirely sure those commands make much sense for these elements
> anyway.
>
> One disadvantage of adding IDs to these elements now (and i'm
> including <ssl>, <http>, and <file-cache> in this for consistency)
> is that it would break existing domain.xml files found in every
> installation of v3 preview onward. This may or may not matter as I
> don't think there's any official requirement to support v3 upgrades,
> but thought I'd mention it. The fix for this is as simple as
> copying over the generated domain.xml from distributions/glassfish
> in to the config dir for a glassfish instance. Of course, if you've
> customized your domain.xml, you'd need to manually add IDs to these
> elements. I'm not sure we really have any automated upgrade
> facilities that deal with breaking schema changes like this one
> would be.
>
> I could go with either decision but I'd like to go with one that's
> the correct approach. Does anyone have a strong feeling either way?
Lloyd Chambers
lloyd.chambers_at_sun.com
GlassFish Team