A single TomEE ApplicationComposer instance for all your tests!

TomEE ApplicationComposer is a nice solution for embedded EE testing. The goal is to describe its application in Java and deploy this model. However it starts OpenEJB and deploys/undeploys the application either by class or method depending the setup.

When this feature can be insane for small deployments which would benefit of an insanely easy configuration and simple mock solution it can be an issue for application deploying again and again the same model.

To avoid that the coming TomEE 7.0.0-M2 provides a new JUnit runner but you can already benefit from it with a single class!

Advertisement

ApplicationComposer Maven Plugin

Even if it comes from test side of OpenEJB, ApplicationComposer is now a solution to develop microservices. Because of this evolution it now gets a maven plugin to be able to go further in the development pipeline.

OpenEJB ApplicationComposer and semi auto configuration

OpenEJB ApplicationComposer design is to let you build in memory JavaEE model of your application and then use it to really deploy the described application.

It is great when writing a microservice which aggregates several libraries (avoids to activate everything when you need just a subpart) but when you just write a single module it can seem a lot of work.

Since few days you can use @Default (openejb one) to ask to auto scan the module containing the main(String[]) for managed beans (CDI, EJB…) and descriptors (persistence.xml, …).

TomEE, @WebServiceRef and configuration

TomEE+ integrates JAX-WS thanks to CXF implementation. It allows you
to develop Pojo or EJB webservices but TomEE takes care to keep all CXF features.

This means you can use openejb-jar.xml to configure your webservice.

As a quick reminder the configuration (openejb-jar.xml) looks like the following one for an EJB:

<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar xmlns="http://www.openejb.org/openejb-jar/1.1">
  <ejb-deployment ejb-name="CalculatorBean"> <!-- configure the bean, values are in resources.xml -->
    <properties>
      cxf.jaxws.in-interceptors = serviceIdInResourcesXml,com.foo.FullyQualifiedInterceptor
      cxf.jaxws.out-interceptors = abc
      cxf.jaxws.in-fault-interceptors = def
      cxf.jaxws.out-fault-interceptors = hgi
      cxf.jaxws.features = jkl
      cxf.jaxws.debug = true
    </properties>
  </ejb-deployment>
</openejb-jar>

For a Pojo webservice it is the same but using pojo-deployment instead of ejb-deployment.

TomEE also has (historically) some specific integration with wss4j but with
the previous configuration it is pretty useless now. Only thing to know
about wss4j is openejb provides WSS4JInInterceptorFactory factory
to ease initialization of WSS4JInInterceptor interceptor (because it has
two constructors with a single parameter and it can be ambiguous in some cases).

Finally to configure wss4j you can do a resources.xml like:

<?xml version="1.0"?>
<resources>
  <Service id="wss4jin" class-name="org.apache.openejb.server.cxf.config.WSS4JInInterceptorFactory" factory-name="create">
    passwordType = PasswordDigest
    action = UsernameToken
    passwordCallbackClass = com.foo.MyCallbackHandler
  </Service>
</resources>

And an openejb-jar.xml like:

<?xml version="1.0" encoding="UTF-8"?>
<openejb-jar xmlns="http://www.openejb.org/openejb-jar/1.1">
  <ejb-deployment ejb-name="CalculatorBean"> <!-- configure the bean, values are in resources.xml -->
    <properties>
      cxf.jaxws.in-interceptors = org.apache.cxf.binding.soap.saaj.SAAJInInterceptor,wss4jin,org.apache.openejb.server.cxf.WSSPassThroughInterceptor
    </properties>
  </ejb-deployment>
</openejb-jar>

This is great but it has a pitfall: it is only for the server side!

This is the reason it was recently enhanced (will be available in next 1.7.2 and 2.x versions) to
support almost the same configuration for clients.

In JavaEE clients are done thanks to @WebServiceRef. TomEE already optimizes them
using local invocation when the service is deployed int the same instance and doesn’t need
remote invocation (ie it has no webservice handler) but if you needed to customize
the client for remote case (ading security, adding logging, …) you needed
to cast it thanks to CXF APIs and programmtically customize the port.

When @WebServiceRef is used to get injected a port (ie a real client) you can now simply
configure CXF client like on server side.

However client doesn’t match pojo-deployment or ejb-deployment. That is why it uses
application.properties (in WEB-INF folder). Syntax is exactly the same but in properties
format. Prefix is “cxf.jaxws.client.” or “cxf.jaxws.client.{namespace}PortName”.
Take care first one is global (ie shared for all clients) and second one is specific to a port.

Like explaining such a configuration would not be that efficient here a sample:

cxf.jaxws.client.{http://cxf.server.openejb.apache.org/}MyWebservicePort.out-interceptors = wss4jout

wss4jout = new://Service?class-name=org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor&constructor=properties
wss4jout.properties = $outProperties

# using a pass-through class to configure more easily properties
outProperties = new://Service?class-name=org.apache.openejb.config.sys.MapFactory
outProperties.action = UsernameToken
outProperties.passwordType = PasswordDigest
outProperties.passwordCallbackClass = com.foo.MyClientCallbackHandler

Bonus: a Service (or a subclass of Service) can be injected as well. Customization doesn’t go as far as for the port but you
can set WSFeatures using the key: cxf.jaxws.client.xxx.wsFeatures and the value has to be a list of id or fully qualified name
of WSFeatures.

On recent version using resources.xml for Service should be possible as well, mainly a taste
question :).

OpenEJB 5 + Groovy = service done fast!

If you read the previous post I wrote about ApplicationComposers run method you surely wonder what a service could look like using groovy and @Grab to resolve maven dependencies?

Here is a quick post showing it:

TomEE and JAXRS provider configuration depending on environment

TomEE supports “environment integration” through several solutions (altdd support, external configuration using conf/system.properties etc….). But how to configure a JAXRS provider depending the environment?

First why should I need it? Suppose you configured a JSON provider, quite common for a JAX-RS application no? You want your application to be efficient in production so you use “flat” JSON but in dev you surely prefer to get formatted (“pretty”) JSON to keep it readable.

How to do it with TomEE?

Did you ever realize OpenEJB ApplicationComposers is the EE Spring boot?

I spoke a lot of ApplicationComposers on this blog. If you don’t know it yet in two words it is originally a way to fully define its EE application programmatically and then run test against this described application.

However with a trivial main you can make it run your application!

Rule Them All meets PhantomJS to test JAX-RS javascript client generation

HTMLUnit is great to test web applications but sadly it doesn’t support recent js libraries (AngularJs/JQuery to not say their names).

PhantomJs is a great alternative but sometimes setup can be boring or too complicated for what you need.

OpenEJB ApplicationComposer and random port

ApplicationComposer is a great way to test a small JAXRS service but how to handle concurrent builds? how to avoid port conflicts since all builds will use the same (default) port?

An easy solution is to “affect” one port by build…but don’t ask me to maintain the range allocation ;).

OpenEJB now provides a nice solution.

TomEE and finer RESOURCE_LOCAL persistence unit configuration

The issue with RESOURCE_LOCAL units is that it is used a bit differently if you are in a EE container or not. Basically in a container the spec mandates the unit type to be JTA is you don’t specify any datasource (jta and non jta one)…even if you set RESOURCE_LOCAL.

Issue is: in standalone mode you never do it so if you import a standalone app then it is broken.

That’s why TomEE added two configurable properties (system properties or unit properties).