1

It could be a stupid question since almost everyone is preffering embedded container technique to test EJBs, but I have to clarify this because of my lack of experience. Also, some my argue that embedded containers my not reproduce the real life situation of deploying in a real app server. So, when testing ejb3, why is indicated to use embedded containers instead of standalone container ? Thanks in advance.

mariu
  • 151
  • 2
  • 3
  • 10

3 Answers3

2

Time.

Testing EJBs in full blown application servers usually takes up a lot of time because of app. server has to "spin up" whenever changes are made, so a lot of time is wasted. Because of that, embedded containers such as OpenEJB can save you a lot of time. Embedded Glassfish is also an options these days, although I haven't personally tried it.

Zero turnaround is a kind of holy grail in Java EE.

darioo
  • 46,442
  • 10
  • 75
  • 103
  • thanks for the quick reply. yes, this is the obvious answer, but I would like just to skip this for a moment. don't know if someone could afford that because time is always an issue, but let's suppose I have a small-medium project. are there any other programatically reasons like: direct access to seassion beans or the stateless nature of beans... – mariu Nov 01 '10 at 18:46
  • what about flexibility ? is it required to use an embedded container like openEJB to be able to provide the testing project on different app servers ? – mariu Nov 02 '10 at 13:12
  • @mariu: you can use annotations (@Stateless, @Stateful) just like in an app server to get a hold of your beans. Since openEJB is self contained, it doesn't rely on other app servers. Of course, you don't have to use openEJB if you want to, but in my experience testing EJBs is a lot faster in it than in full blown servers. – darioo Nov 02 '10 at 13:25
  • i understand that openEJB seems to be the best solution for the moment as an embedded container. the thing is that i cannot argue enough for using an embedded container instead of a real app server one... – mariu Nov 02 '10 at 13:54
  • You don't have to use openEJB if you don't want to for testing. You're not going to be using it when your application is finished and ready to be deployed on a real app server, since openEJB is not a substitution for a real one and can't be used as such. It is simply a tool that can help you test parts of your application which are usually slow to test on a real server. – darioo Nov 02 '10 at 13:57
  • @darioo There are people using the OpenEJB/Tomcat stack in production. We are in the process of Java EE 6 Web Profile certifying that stack. Many more who use it in Geronimo which has included and certified with OpenEJB for years. – David Blevins Nov 10 '10 at 16:46
  • Certainly those platforms also contain more code, but all use the same openejb-core libraries. OpenEJB was originally designed to be embedded into app servers and the embedded testing concept was sort of a "happy accident" that derived from the flexibility we had built into the codebase. – David Blevins Nov 10 '10 at 16:57
1

Here are the most relevant arguments that I've found. Please comment beside this, or add your own reasons about testing with embeddable containers vs. a real application server container. Thank you.

  1. using an embedded container testing technique ensures flexibility(you just need to add the new libs to the classpath). as far as I understand if we want to be able to deliver the testing project for several application servers we have to not be bound to the application server container in tests implementation. some app server could use some specific annotations or deployment descriptors, if they are used then you are bound to app server
  2. embedded containers are lighter - this means reduced time for running the tests. real appserver have difficulties in starting and stopping automatically or could hang up. so to build fully automated testing process using real app server could be too difficult...
  3. another problem is the stateless nature of most Java EE applications. after a method invocation of a transaction boundary (for example, a stateless session bean), all JPA-entities become detached. the client loses its state. this forces you to transport the entire context back and forth between the client and the server - heavy load,Every change of the client’s state has to be merged with the server
  4. with embedded container you have one process that runs all (tests and ejbs), with real app server you should coordinate 2 processes(AppServer and Tests)
  5. for full testing, of course, you need also tests on real appserver. different server could have some particularities, for example class loading etc.. embedded containers, however, help testing the logic (unit and integration of units testing) so for daily automated testing this could be enough and more easy.
mariu
  • 151
  • 2
  • 3
  • 10
0

An embedded container is much faster to execute (start/stop) than a full container -> this affects the developer for sure. Setup/configuration is easier to automate, specially with continuous integration. On the other hand, as some core features are disabled on an embedded container, you can't test everything.

You may want to investigate http://www.jboss.org/arquillian to have both options. From the site:

Arquillian enables you to test your business logic in a remote or embedded container. Alternatively, it can deploy an archive to the container so the test can interact as a remote client.

In the end, it depends on the kind of EJBs you want to test. Certain complex scenarios will not work on an embedded container without mocks to some external services. In my projects we test EJBS with a custom mock container we created (ultra fast and easy to use) and, if all proceeds well, we test in the real thing, a full JBoss, using a remote control API pretty much like Arquillian.

Hope it helps.

Antonio
  • 2,406
  • 1
  • 16
  • 8