It all seems a bit messy. Vendors have to respect ID values that have
been included, but be able to reference tags in deployment descriptors
that have no IDs. Or, as Mark suggests, to use a tool, which should
only add IDs if they don't already exist.
If IDs were mandatory it would cause more pain for bean providers,
especially those not using tools. It's a very bad thing for anything
to cause pain for bean providers.
Neither is the current situation ideal. I can reference an EJB using
the <ejb-name> tag, but if its value changes my reference becomes
stale. So my tools should treat it with "final" status... but what if
other tools are used...
So perhaps us vendors should form some consensus on this issue.
Will the norm be to use IDs? If so, will vendors agree not to change
IDs in tags, and to only add them if they are absent?
What do other vendors have to say on this issue?
Malcolm
On Tue, Sep 14, 1999 at 09:10:27AM +0100, Rickard �berg wrote:
> Mark Hapner wrote:
> > 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.
>
> Exactly. For example, the OpenSource EJB XML editor that I'm working on
> will have to be aware of the fact that other, probably vendor specific,
> tools may update the DD with ID's that I haven't made. It's not a big
> problem, but when making these kinds of tools one have to consider it
> carefully, that's all.
>
> But it's "easier" for me: I can be *sure* that other tools exist that I
> have to work together with (there has to be in practice). But a
> vendor-specific tool might be more "blunt". So, it's even more important
> that EJB server vendors really think twice about Mark's comment, so that
> different vendor tools may work together.
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> Homepage: http://www-und.ida.liu.se/~ricob684
>
> ===========================================================================
> 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".
