simple cdi and ejb tests with deltaspike

apache deltaspike v0.6+ provides an easy to use, but quite powerful junit test-runner. it's based on the container-control api of deltaspike. deltaspike itself currently provides implementations for openwebeans, weld and openejb (tomee).

the last one is important, if you need to test a cdi+ejb based application. just by using a different container-control implementation (deltaspike-cdictrl-openejb) in your build config and adding openejb (/tomee) via org.apache.openejb:openejb-core, you can test cdi-beans as well as ejbs. just inject them as usual via @Inject (also @EJB works as expected).

an example can be found here.

[add-on] owb and actors

actor-frameworks for the jvm gain more popularity every day. even with actor-frameworks you have to be careful with shared state. however, if you have a java-ee application, you can (re-)use stateless services in your actors easily. one use-case is to resolve transactional beans (ejbs, cdi-beans which are annotated e.g. with @Transactional, ...) in an actor and invoke methods on them to access a database.

with an ee-application-server like tomee that works out-of-the-box. you just have to bootstrap an actor-framework (like akka, jetlang,...) and use the std. java-ee api to lookup the bean/s.

if you are interested in using transactional cdi beans, you can use the jpa-module provided by apache deltaspike v0.4+ (note: those transactions don't span across actors). for using @Transactional, you just have to follow the documentation and you are done. that's usually a short story. but...

if you would like to use @Singleton or @ApplicationScoped beans and you are using the openwebbeans-web module of owb v1.1.x, you need an additional plugin (due to OWB-785). in such cases just get https://github.com/os890/owb-contexts_service-addon.git, build it and add it as runtime dependency to your project.
-> you are done (there is no additional api you have to use).

additional hint:
apache deltaspike provides some nice helpers (like BeanProvider#getContextualReference to resolve cdi-beans), interceptors (like @Transactional), scopes (like @TransactionScoped) and much more...

speedup the tomee startup

apache tomee is based on apache tomcat and adds the java-ee web-profile on top of it (based on apache projects like myfaces, openwebbeans, bval,...). the runtime performance is great and also the startup time is nice. esp. during the development phase every second hurts (at least a bit). with a simple change it's easy to remove some overhead! the following part shows the difference.

tomee just adds some libs to tomcat. that means you can also use a different version of tomcat easily - so it's easy to get tweaks and bugfixes of the latest version of tomcat also for tomee and you can use the std. tomcat plugin for your ide. however, that also means you (can) get some overhead - currently the demo apps shipped with tomcat cause such an overhead during the server startup. just by removing the demo web-apps you can reduce the startup time of tomcat itself by about 50 percent (here from ~1.4 seconds to ~0.7 seconds). for tomee you can do the same, but you have to keep a webapp called "tomee" (it's needed to use remote-ejbs - so it isn't a demo). if you don't need remote-ejbs, you can remove all webapps shipped by tomee to improve the startup performance even further.

the following chart shows the differences of the mentioned constellations. the value for jboss as7 is just a reference value.

the following chart shows the overhead introduced by tomee (compared to a standalone tomcat).

please note:
1)
all those values depend on the machine, operating-system,... - in addition the values are rounded and should just give a basic impression about the differences (please don't see it e.g. as a tomee vs as7 comparison).

2)
there are 2 values printed during the tomcat/tomee startup. the first one is listed as "Initialization processed in ..." and  the second one as "Server startup in ...". the values in the charts always show the sum of both ( "Server startup in ..." sounds like the sum but it is not the sum of the full startup process).

3)
as7 is also based on tomcat but the integration is way deeper and therefore it isn't given that the startup of tomcat itself takes the same time as with tomcat standalone or tomee (that's the reason why there is no separation for as7 in the second chart).

codi meets tomee

recently the open-ejb team released beta2 of tomee v1.

tomee is already optimized a lot. today we saw an issue during the deployment of a codi demo to tomee. thx to romain manni-bucau we found the issue pretty quickly. due to an optimization tomee filters myfaces-* jar files to improve the scanning performance. so you just have to rename the jar file(s) of codi until the issue gets fixed.
(or manually patch org\apache\openejb\config\NewLoaderLogic.class in webapps\openejb\lib\openejb-core-4.0.0-beta-2.jar)

furthermore, we will add an integration test to tomee to avoid that it happens again.

so have fun with myfaces codi on tomee!