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.
Resource adapters are an awesome way to interact with a container to get services. (see http://blog.dblevins.com/2010/10/ejbnext-connectorbean-api-jax-rs-and.html if you doubt about it). We recently worked on TomEE to make it more powerful and usable than it was before.
Arquillian is great but some apps would prefer to use maven failsafe plugin to do their integration tests. If all your tests are client tests you can simply start the container and deploy the app before the tests are executed (pre-integration-test phase) and undeploy/stop the container after the test (post-integration-test phase). If it is not you can still write a servlet to execute the tests on the server side…wait, you are redoing Arquillian so maybe something is wrong in this case ;).
It is generally complicated/long to configure because you need to find how to start your container then to deploy an application on it etc…boring.
The solution is quite easy if you want to test against TomEE: the tomee maven plugin of course!
If you read this post you surely know ShrinkWrap and Maven. The main issue is the boilerplate code needed to create a WebArchive in a Maven project. This is really easier since ShrinkWrap resolver has a correct implementation of the Maven resolver but it still looks useless. All projects end with a ShrinkWrapUtil utility class to do it.
On another side TomEE provides an utility module to ease ShrinkWrap usage called ziplock. It allows you, for instance, to find a File from a class (see JarLocation) or provides you some shortcuts to create Archives (see WebModule). These utilities were created because of TomEE tests need.
However since few days it includes something more general and interesting for any maven user: the Mvn class.
New ShrinkWrap Maven resolver is awesome to avoid to handle all dependencies manually but it can be a bit long to resolve dependencies. We just introduced a hack in TomEE and OpenEJB adapters to make it less painful. The idea is quite simple: do the resolution while the container is starting up.
Writing a GUI for a library/tool is quite common and each time the question how do I do or package it leads to a headache.
You can use any existing web framework but you risk a conflict with the application. So basically the solution is to use client side technology or a jsp/servlet.
When starting an application with an existing database we often look for a reverse tool to generate JPA entities from the database. OpenJPA provides this kind of tool and it is easily integrable with maven.
Here is the way to do so.
A common need when writing batches is to interact with a database. The two main ways to do it is to either use JDBC or JPA.
In this post we’ll see how to use JDBC to get items from a database.
Arquillian has a lot of extensions which can dramtically cut needed code. An interesting one is the persistence one which simplifies a lot the DBUnit usage.
The sad part is this extension is designed for not embedded containers….but with this tip you’ll be able to use it (so with OpenEJB, OpenWebBeans, Weld…).
Chunking is the minimum you can expect from a batch framework. The idea is simply to do the work for a list of items and commit it for this list then continue on next list etc…You can see it as something more general than the commit interval (the interval can be a number of items, a timeout, etc…).
New posts here >>> rmannibucau.metawerx.net 