On Tue, Sep 14, 1999 at 01:42:26PM +0100, Rickard �berg wrote:
> Hey
>
> IMHO and FWIW :-)
>
> Malcolm Sparks wrote:
> > 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...
>
> <ejb-name> seems to be used by the deployer and bean developer roles to
> create <ejb-links>. If I were to make a tool to handle those
> relationships (uhm.. which I am..) I would simply add some code to
> update all <ejb-links> when I change a <ejb-name>.
>
> ID's, as I see it, are for vendor specific tools that need to reference
> elements in the DD. The DD itself should, as above, not use ID's as
> there are other better ways to do that.
>
> Since my tool will be specifically for Bean Developer and Assembler
> roles only, I don't see the problem you're referring to. But as a
> vendor, if you make a tool that takes care of Bean, Assembler *and*
> Deployer roles, then the confusion you mention is more apparent and
> possible.
>
Yes, you're right, it's fine for provider and assembler roles, where
you're changing just the ejb-jar.xml, but what about other
vendor-specific files? They would become stale. That's what IDs are
there to help, see spec p258:
"The ID mechanism is to allow tools that produce deployment information
(beyond the standard EJB deployment descriptor information) to
store .. in a separate file, and easily refer from these files to the
information in the standard deployment descriptor"
> IMHO the above guideline (=only use ID's for vendor specific links) is
> the Right(tm) one :-)
>
> > So perhaps us vendors should form some consensus on this issue.
>
> That would make lots of sense, yes ;-) And a heck of a lot less pain for
> developers who, for any reason :-), needs to be able to deploy an
> application in several servers from different vendors.
>
> > Will the norm be to use IDs?
>
> For vendor2DD links: I think so, yes, definitely.
>
> > If so, will vendors agree not to change
> > IDs in tags, and to only add them if they are absent?
>
> This suggestion has my vote. There's really no reason to have concensus
> on ID format or such though. Anything that is unique within the DD is
> fine IMHO (e.g. "1", "entity2", "Id3", "link15" or similar are ok.
> Whatever really, as long as uniqueness is guaranteed!).
>
> OTOH, in order to properly support evolution of the application the ID
> should perhaps be prefixed with a vendor tag (e.g. "com.iona.12").
>
> Otherwise there are some insert-link-remove-insert-link scenarios that
> will cause faulty/stale links. For example: element is inserted, then
> linked to giving it ID "12", element is removed, and then one element is
> added and linked to, which gives it the ID "12" which is free. The first
> link is now faulty. Using prefixes will make it easier, or rather will
> make it *possible*, for vendor tools to determine which ID's are free to
> use. Blah, etc, you get the picture..
>
I don't agree. The deployment descriptor is, and should stay in, a pure vendor-free
state,
ejb-jar.xml
<resource-ref id="2343">jdbc/MyDatabase</resource-ref>
iona-config.xml
<resource-link id="2343">db/TestDatabase</resource-link>
other-vendor.properties
2343=db/TestDatabase
So iona-config.xml and other-vendor.properties both
reference ejb-jar.xml in different ways.
So the original problem still remains: what if there isn't an ID in
the ejb-jar.xml to reference off? (valid because the ID bit isn't
mandatory). Should all vendors that use this ID mechanism provide a
tool to add the IDs to ejb-jar.xml files? If so, shouldn't all tools
be FORBIDDEN to change IDs already assigned, since these elements
could be referred to IN ANOTHER VENDOR'S FILE. It would be terribly
unsporting to break another vendor's file in this way.
My question is: Will vendor's stick to this "fairplay" guideline, or
should it be mentioned explicitly in the spec?
> Just my 2 cents... as Malcolm I would be very interested in hearing
> about other vendors opinions on this one!
>
> /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".
