I don't know about complaining to Borland. However, the ejb-link is in spec and is meant to provide support if I remember correctly, for vendor specific information in a vendor deployment file. It is provided as a reference so the vendor's container specific deployment information is tied back to the ejb-jar.xml definitions. You can think of these as helper files for the container to connect up the bean/webapp to the container infrastructure - as the J2EE/EJB specs are vague about some aspects of container implementation.
Most vendors do have an additional container specific definition file and have deployment management tools to ease this. WebSphere has this as of course does JBoss - but the files and definitions/templates are vendor specific. Hence the growing popularity of XDoclet. And, feel for Borland as every container vendor is going to do things a little differently - otherwise there would be no product differentiation.
I hope I've got the gist of it right. Feel free to correct me.
Well, perhaps "complain" was too strong a word. Especially seeing as how the Borland "support" for JBoss comes in the form of a third-party OpenTool. However, it is the JBuilder interface that refuses to accept that a bean in a different module can be used via a <ejb-link>.
And then, what to make of Weblogic having no apparent difficulties without the <ejb-link> in the DD? Does that mean they are not in-spec, or just that they are not strict about it (as you say, product differentiation)?
Aside from all that, I am a bit confused about your reply. If I understand you, you are suggesting that the <ejb-link> element is a bridge between vendor-specific info (for instance, stuff in the jboss.xml file) and vendor-independent info (ejb-jar.xml), yes? Then why is the <ejb-link> element in the ejb-jar.xml fileand not the vendor file? Wouldn't it make more sense to have that bridge where the vendor will look for its specific needs? Clearly, I don't really understand how the AppServers use these files, so please try to go easy on me.
OK. Let's try again as I may have incorrectly conveyed it. The ejb-link is meant to define whether the reference is in the same archive or not. If it is, there may be some additional hookup information the container needs - maybe WebLogic has a location schema that doesn't need supplemental information or they have a flat global naming space that ensures no naming clashes. In any case, the helper deployment file will probably use the ejb-link as the reference point.
"The ejb-link entry defines if the ejb-local-ref refers to an EJB in the same archive (either the same JAR/EAR). If you partition your EJBs to reside within the same
physical process, but in different modules (JARs or EARs), you'd need to provide additional information."
The short and cryptic definition from BEA was:
"Used in the ejb-ref element to specify that an EJB reference is linked to another EJB in the EJB JAR file."
Java Guru has this to say:
"No - you don't have to use ejb-link every time you reference an enterprise bean component. It allows an Application Assembler to reference an EJB by name without the need to have unique names for all beans by constantly renaming them for the J2EE application. And, of course, such cannot be guaranteed if one buys third-party bean components.
The Deployer is then responsible for binding the ejb-link references to the home of the target bean."
I've got to say that it all seems confusing by these definitions. Suffice it to say, ejb-link is a signpost for the various containers when they deploy your bean. When they encounter it (in the standard ejb-jar.xml), they have the option of reading their vendor specific deployment file to determine additional container specific configuration required to support locating this local reference. A standard to support non-standard (vendor-specific) details?
To answer your second question on why not have it in the vendor specific file :-
The issue is probably about being able to manufacture vendor specific hooks. If you take a bean and want to deploy it in another container (the whole point of the J2EE spec is that components are transportable between containers without changes to the coding - only changes to the deployment descriptors), as the vendor wanting to perform the deployment migration painlessly, you don't want to read or even understand the other vendor's deployment supplement. It's just too much work. So if the artefact signalling that you might need to do something to get the plumbing right is in the standard ejb-jar.xml, then your job is much easier. It saves on the amount of stuff you need to know.
I think that would be the rationale.