> From: David Blevins <[email protected]> > > If you cut out JNDI and use injection instead, you can get a lot of > that complexity out of both your production code and your testcases > for your production code.
Thanks for the hints! I think I understand what you've said, but will need to think on this some. I'll get back to it next week. This is all new to me, and it's not yet clear where I am getting all the functionality. NetBeans hides much of the code-by-configuration, so when I have to get into it myself, it gets hard. I have a very risk adverse legal department that greatly restricts the use of open source directly or embedded. This is partly why I am not using JPA, and because I'm not, I do not have EclipseLink, TopLink, etc in the project. I'm not sure now, but I think when I removed those libraries, that forced me to remove the annotations such as @EJB. I don't recall having made use of @Resource. Also, I have an EAR project which contains an ejb jar and a war project. The war is making use of the EJBs out of the ejb jar. It is my understanding that the @EJB sort of injection does not work across projects that way (at least I couldn't get it to work). So, I'm using <ejb-local-ref> in my web.xml file. I haven't tried, but perhaps with my test cases still inside my ejb jar, I could make use of the @EJB annotation there. > The xml looks fine, but if you didn't use the no-arg "new > InitialContext()" in the EJB code that does the lookup than no > "java:comp/env" lookups will work. Hmm... I'm confused again. I did try to use OpenEJB context in my EJBs. The no-arg constructor does not work in JUnit (I thought and how I came to find OpenEJB) because there is no container, so I'm embedding OpenEJB to serve that purpose, but to do so I'm unable to use the no-arg constructor. I think there's some bit of information right here in front of me, but I'm not making the connection. Perhaps you are saying that by embedding OpenEJB and passing the properties object in the constructor, when it then loads it also causes the no-arg version to start working too. Will have to experiment with that. > It's also possible to set things up to use the annotation approach and > then instruct OpenEJB to spit out an equivalent xml descriptor via > setting the "openejb.descriptors.output" system property to "true". > It can also be specified in the InitialContext params. So even if > there was a strong desire to not use annotations, you could still use > them long enough to get OpenEJB to create all the xml for you. After > which point you can just keep the xml and loose the annotations. This sounds helpful. Will have to look into this for sure. I can make use of anything I need to locally (EclipseLink or whatnot) to get things configured and strip stuff back out again if necessary. Thanks again for the help. It is much appreciated. TT
