Apache JCS: LorraineJUG slides

On friday I did with Jean-Louis Monteiro the Lorraine JUG. I presented Apache JCS which is a nice Java Caching solution implementing now JCache specification.

Slides are available here: http://rmannibucau.github.io/2015/LorraineJUG/#/.

And few code samples/examples can be found here (this is a maven project you can open in your IDE): https://github.com/rmannibucau/rmannibucau.github.com/tree/master/2015/LorraineJUG/demo.

Don’t hesitate to get in touch the Apache JCS community if you want more information (use Apache Commons mailing list – user@commons.apache.org – and just specify [JCS] in the subject), we’ll be very happy to help you!

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 :).