EJB 3 Support
Brought to you by:
aibba
Menu
▾
▴
I don't think it makes sense. There are frameworks like ejb3unit and many "lightweight" EJB3-containers.
Alwin, maybe similar to how http://www.mockejb.org/ was included in mockrunner? I think might be able to offer a unified approach (not requiring the user the learn another mock tooling). Thanks
To be honest, I'm no longer convinced of the tightly integrated approach of Mockrunner. Furthermore I don't have the time to actively develop Mockrunner. But I want to keep the code as it is (maybe keeping it compatible with Java 7 and new Servlet API) because some projects are using it. Parts of Mockrunner are outdated (Struts, EJB 2). I think some parts are still useful. So I'm thinking about keeping Mockrunner as it is and starting a new project based on one or two Mockrunner modules (probably on another platform than Sourceforge) but only a small one which I can actively develop and maintain in my spare time (maybe the JDBC part). The code is free and open source, so everyone can do this with other valuable parts of Mockrunner (JMS, JCA). So Mockrunner will be stable, at least for a while, we don't have the tightly integrated "one stop shop" framework and the useful parts will be actively developed. But I'm still thinking about this and I'm not sure. Comments are welcome.
I understand.
I studied the approach taken by ej3unit, and I'm not fully sold. I think I better liked the mock approach taken by mockrunner, with specific binds being in code (instead in config files), and also better liked how the container and JDBC layer, etc. are geared towards unit testing with "assert" capabilities (not just a reuse of an embeddable container or database).
It does not seem that many of existing unit testing projects are really modular (they address multiple facets of the JEE stack, and usually in a monolithic fashion ...). I'm also not clear on how multiple tools can connect to a single mock JNDI tree, and the JUnit setup (with subclassing in many cases) also does not seem ideal (as multiple frameworks might need to cooperate to test a single class).
I'm looking forward to hear your thoughts on modularizing and your new project(s) showing up.
Thanks
I agree with you on EJB3Unit.
There's a mock EJB3 container in the CVS. It only supports session beans and has some issues in this area as well. Without entity and message driven bean support and without a build script and examples it's not very useful anyway. There's also the completely outdated mockjdo project, which supports unit testing of Hibernate 2 applications in "Mockrunner JDBC style" (which is also not complete). I won't have the time to have a closer look at the existing code at the moment, at least until christmas. But I think it would be a lot of work to consolidate this and to come out with a (nearly) working and complete EJB3 test framework. I don't know if it's worth to take the effort because there are existing solutions (EJB3Unit) even if they do not fit perfectly into Mockrunner. I also do not know if it's such a big advantage to integrate EJB3Unit into Mockrunner. And (as mentioned) I'm not sure about the future of Mockrunner.
I agree with your remarks on multiple tools. But it's also a matter of spare time and effort. One huge "all-in-one" project is a lot of work. If it's really actively developed by more than one person, even the supervising work (collect and discuss ideas, keep sure that everything stays "in-line" and compatible etc) would exceed my spare time by far. At the moment it's not actively developed at all. Let me think about it. Comments are welcome.
Alwin, I sent you an email with some code for your review/thoughts. Did you have a chance to look at it yet? Thanks