Originally posted by Jim Petersson:
"Look up the JNDI name for the bean and inject it yourself"
- This is pretty much the EJB2 style right? Since it's pretty "verbose" I would like to stay away from it.
Yes, this is EJB style. It is verbose, but you can write a factory and deal with it in one place. Note that a lot of EJB 3 code is still going to have callers using the "old style." For example, a
Struts action cannot inject the EJB reference since it is not a servlet. (Even though it is called from a servlet.) I guess I'm saying the "old style" isn't bad.
"Call the EJB as a regular Java class"
- I'm not sure I get exactly what you mean? Are you suggesting that I just create the EJB-object with new? Seems like cheating
Yes, I meant call with "new." It's not cheating - it's a different use. Say you want to test a method in the EJB that doesn't access the database. It makes sense to just create the bean as a class to test that method. This approach doesn't help with your problem of testing the real EJB. I was mentioning it more to be thorough.
"Write a test servlet which can automatically inject resources."
- This is what I hoped not having to do, since my knowledge in servlets are rather limited.
I would lean towards the JNDI call or app client rather than the servlet as it is clearer why the class exists.
In Ejb3 in action it says someting (page 55), that you should be able to use dep.inj. from a standalone client as long as it's running in the "Application Client Container". Question is then, how do I get it to run in the ACC?
That is correct. An application client is a type of JEE component. (just like an ejb-jar or war is.) This
Sun page has some details on it.
Btw, nice quote on the back of the book
Thanks!