Since Tomcat now packages JSR 356 (little name of websocket 1.0 specification) TomEE inherited of it in its last release.
DeltaSpike is now providing a Data module allowing to use interface or abstract classes as repositories for JPA (a bit like spring-data). It got recently a new feature aiming to support DTOs pattern.
I’ll just show how to use it on a simple “User” entity in this post.
Working on cassandra store for Apache Sirona (I’ll speak surely of it in another post) I used cassandra-cli to check my persisted data and browse my Cassandra keyspace easily.
However doing a simple ‘list’ (select *) the result looked like the expected one but was not that readable. Even if test data values were not that important the row keys were something crucial in my modelling and tests so I needed to read it (even if my unit tests were green it is always better to validate it twice ;).
Few days ago a user went on #deltaspike IRC channel (on freenode) and asked if there was a replacement for seam rest. There is no one ATM (a bit too early) but this post will show you how simple it is to build a MVC framework based on any template engine you want (velocity for me) and JAXRS.
Resources are something basic in JavaEE but in TomEE and OpenEJB it is quite more powerful than it looks like.
Apache Sirona is a brand new project in Apache Software foundation world. It targets Java applications monitoring. One awesome feature of this library is the fact the reporting GUI is easily extensible and you don’t need to write tons of code/pages to add your info in this GUI.
Here is a sample simply reporting the JVM system properties.
TomEE and OpenEJB add by default an interceptor on each EJB to report basic metrics through JMX.
If you don’t want it you can disable it easily.
You basically just need to add the system property (in conf/system.properties to keep it persistent):
openejb.stats.interceptor.disable = true
One of important updates for TomEE done recently (last releases) was to allow the user to configure CXF endpoints (ang get access to advanced configuration/features of CXF). One of them is the schema (xsd) validation of INPUT/OUTPUT messages.
This post will only deal with it but the way to activate it is the same for all properties of the JAXWS CXF endpoint.
JBatch (aka JSR 352) is the new standard to write Java and JavaEE batches. It is mainly based on reader/processor/writer and batchlet (task) concepts. This is not that far from camel which is based on consumers and processors.
So how can both work together?
JAXRS 2 provides a simple way to unmarshal using JAXRS providers a Response entity (got from response#getEntity() method): readEntity(…).
However if you still have to stick to JAXRS 1 you’ll often get an InputStream as entity…not that fun.
The worse is when you use an interface with the JAXRS metadatas to generate a client. To avoid to need to play with stream there is a simple solution.