The use case requiring ejb-refs is a module of resuable components that are deployment more than once with different security, transaction, envrionment, resource-refs, etc. based on the utilization of the component in the application workflow. You cannot have such a component's access to its dependent ejbs, resources, etc. be a hard-coded source level property of the reusable component.
This is the same reason why I don't really believe in xdoclet as a production mechanism. Its fine to get a template of the metadata files bootstrapped, but having to modify the source to update the metadata becomes impossible when I am using the component with completely different settings based on its different deployment contexts. xxxxxxxxxxxxxxxxxxxxxxxx Scott Stark Chief Technology Officer JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ----- Original Message ----- From: "Rod Macpherson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 18, 2003 11:58 AM Subject: RE: [JBoss-user] Error: my patience Not Bound David, We lookup EJBs using the local or global JNDI name specified in the DD and consequently bypass the need for ejb-ref elements. What is the downside of this strategy? We use the fully qualified class name on our stateless session beans and entity beans so we have a self-documenting naming convention. Is this simple and effective strategy masking some underlying evil? I have been warned about doing this but nobody has come up with a valid argument except to regurgitate a paragraph from here or there saying that a given component should declare the other components it uses using an ejb-ref. Perhaps in a distributed enterprise where the same class gets used is deployed with various permissions and such. I would appreciate some clarification on this. Thanks! ------------------------------------------------------- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
