Last week, we had the author of TDD for a Shopping Website LiveProject. Friday at 11am Ranch time, Steven Solomon will be hosting a live TDD session just for us. See for the agenda and registration link
Howdy Good question (and one you should know for the exam) resource-ref is for "resource manager connection factory" objects that can give you connections to a resource manager. The typical example is for javax.sql.DataSource from which you can get JDBC connections (javax.sql.Connection). The resource-ref is so that you can have a 'logical name' used in code -- that the deployer then binds to the *actual* resource factory configured into the server. So when you think of resource-ref, think of "Programmer's made-up/fake name for the datasource." Since the programmer may not know, at the time of coding, what the *real* name is going to be (and since the component model demands that the name of these things is something that can be configured at deploy-time without changing code.) So... what's the deal with resource-env-ref? 1) It is new to EJB 2.0 2) It was added because of message-driven beans/JMS 3) It has the WORST name, designed, I'm certain, just to confuse you. For example, a resource manager connection factory is certainly an entry in the bean's environment -- so it would be perfectly logical to assume that resource-env-ref is an appropriate name for what is actually resource-ref. But...you have to memorize it differently.
A resource-env-ref is for "administered objects associated with resources", and the most obvious example (and the reason it was added) was for JMS destinations. The idea is the same as resource-ref (or security-role-ref) in that it stands for "programmer's made-up/fake name", only instead of a name for a resource factory, it is a name for a 'resource'. The main difference: resource-ref: things that give you CONNECTIONS (including URL connection - JavaMail connection factory, JDBC connection -- DataSource, and -- for the really confusing one -- QueueConnectionFactory for obtaining JMS connections.) resource-env-ref: things that give you access to a resource, but which are NOT factories that give you connections. In other words, with resource-ref you are getting something that you then can use to GET to a resource, but with resource-env-ref, you get right to the resource without going through a factory. The way I think of it, for the purposes of the exam is: resource-ref: "Programmer's made-up name for the database driver" [just a way to remember, not the exact technically correct way to say it] resource-env-ref: "Programmer's made-up name for the JMS destination" From what I've heard, the resource-env-ref really should have just been called JMS-resource-ref, but that would have been more limiting. Much clearer, though. The only resource example used in the spec is for JMS destination, and although I'm sure there may be other examples, I have no idea what they might be. ======================= So, yes its confusing, but hopefully you can simply "burn-in" the differences between the two. I think the most important thing to remember is that wherever you see 'ref' you can think of "Programmer's made-up / lookup name" cheers, Kathy
Thanks for your response, Kathy. Although the purpose of each of these DD elements is different, wouldn't the code that accesses either of these look the same, since they are both obtained by similar JNDI lookups? Does that mean that these can be used intechangeably? Can I configure a data source factory in a resource-env-ref & similarly a JMS destination in a resource-ref..and still expect the code to work the same?
Hmmmm... the client *lookup* code could be the same (in the sense that the JNDI context you use does not have to follow the recommended naming conventions), but the thing the client would then cast the result to would be different, and the DD elements themselves are different, and have different requirements in the DTD. So you couldn't configure a JMS resource using a resource-ref, and you couldn't configure a connection factory with a resource-env-ref, although it's hard to say where it would blow up (it would certainly work just for making an ejb-jar, though). Most likely, the deploy tool verifications (if your server supports that, and probably does) would fail because the deployer must map between those things and *actual* resources and connection factories, so the server can tell that what you've configured into the server (for DataSource and JMS destination, for example) do not match with the DD elements you've used to declare the references. I haven't tried it, though cheers, Kathy
Originally posted by Kathy Sierra: The main difference: resource-ref: things that give you CONNECTIONS (including URL connection - JavaMail connection factory, JDBC connection -- DataSource, and -- for the really confusing one -- QueueConnectionFactory for obtaining JMS connections.) resource-env-ref: things that give you access to a resource, but which are NOT factories that give you connections. In other words, with resource-ref you are getting something that you then can use to GET to a resource, but with resource-env-ref, you get right to the resource without going through a factory.
Not trying to confuse things here - Kathy did a great job explaining the theoretical difference, but in practice (with WebLogic at least) resource-ref can be used wherever resource-env-ref is needed, i.e., I can use the former for JMS destination and Mail session. The real difference for me seems to be the lack of <res-auth> with <resource-env-ref>.
I think the way it works is that the resource-env-ref points to the resources that exist within the domain of the application server. That is, the appserver knows the details of the resource because it manages it.
But the resource-ref points to the resources that exist OUTSIDE the domain of the application server. That is, the appserver does not know how to handle that resource. It is managed by somebody else. For example, a data base. The app server can only give the bean a pointer to the guy who manages the resource, which is usually a connection factory (but it could be something else also). Since it is managed by somebody else, it is possible that that somebody else may require some authorization. Hence the res-auth tag.