The ID values would typically be created by a tool when it had external info
that needed to reference a DD element. A tool that added this info would
typically either use an ID value that was already in the DD or add one if it
didn't exist.
An EJB jar could include several vendor specific descriptor files that
'extended' the DD. The coordination of ID values across the extensions could be
done by a single tool or it could result from an adhoc 'sharing' of the
incrementally added IDs.
A tool designed to incrementally 'extend' a DD should be sensitive to the fact
that other extensions may exist and that they would be affected by arbitrarily
changing existing ID values.
-- Mark
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
> From: Alan Greenspan <[EMAIL PROTECTED]>
> Subject: ID attributes in the DD
> To: [EMAIL PROTECTED]
>
> This was discussed in August under Q about vendor specific info in
> Deployment Descriptor.
>
> The issue is how to use the ID attributes defined in the 1.1 DD for
> implementing container specific properties.
>
> Still not clear to me. It seems like the intent is to mark attach an ID
> attribute to each element in the DD and then use a separate container
> specific file to refer to those elements via the IDs. The idea is to keep
> the DD free of container specific information.
>
> OK good, but who assigns the ID attributes to the elements?
>
> It seems like unless it is mandatory that all elements be tagged with IDs as
> provided by the bean developer, then the container will have to add its own
> IDs to make use of this technique. If the container adds the IDs, then they
> will surely be container specific and only useful within the specific
> container. And if that's the case, why define the mechanism at all? The
> container can mutilate the DD in any way it likes, as long it's only for
> private use within a container.
>
> ????
>
> Alan
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
