Inspired by a recent newsletter from Heinz Kabutz as well as Scala's Futures which I investigated in my recent book, I set about using Java 8 to write an example of how to submit work to an execution service and respond to its results asynchronously, using callbacks so that there is no need to block any threads waiting for the results from the execution service. Theory says that calling blocking methods like get on a java.util.concurrent.Future is bad, because the system will need more than the optimum number of threads if it is to continuously do work, and that results in wasting time with context switches. In the Scala world, frameworks like Akka use programming models that mean that the frameworks will never block - the only time a thread blocks is when a user programs something which blocks, and they are discouraged from doing that. By never blocking, the framework can get away with using about one thread per core which is many less than say a standard JBoss Java EE Application Server, that has as many as 400 threads just after startup. Due largely to the work of the Akka framework, Scala 2.10 added Futures and Promises, but these don't (yet?) exist in Java. The following code shows the goal I had in mind. It has three parts to it. Firstly, new tasks are added to the execution service using the static future method found in the class ch.maxant.async.Future. It returns a Future, but not one from the…
Author: Ant
Play 2.0 framework and XA transactions
XA transactions are useful and out of the box, Play 2.0 today does not have support for them. Here I show how to add that support: First off, some examples when XA is useful: - JPA uses two physical connections if you use entities from two different persistence.xml - those two connections might need to be committed in one transaction, so XA is your only option - Committing a change in a database and at the same time committing a message to JMS. E.g. you want to guarantee that an email is sent after you successfully commit an order to the database, asynchronously. There are other ways, but JMS provides a transactional way to do this with little overhead in having to think about failure. - Writing to a physically different database because of any of several political reasons (legacy system, different department responsible for different database server / different budgets). - See http://docs.codehaus.org/display/BTM/FAQ#FAQ-WhywouldIneedatransactionmanager So the way I see it, XA is something Play needs to "support". Adding support is very easy. I have created a play plugin which is based on Bitronix. Resources are configured in the Bitronix JNDI tree (why on earth does Play use a config file rather than JNDI?! anyway...) You start the transaction like this, "withXaTransaction": def someControllerMethod = Action { withXaTransaction { ctx => TicketRepository. addValidation(user.get, bookingRef, ctx) ValidationRepository.addValidation(bookingRef, user.get, ctx) } …
Hacking Maven
We don't use M2Eclipse to integrate Maven and Eclipse, partly because we had some bad experiences a couple of years ago when we were still using Eclipse 3.4 and partly because some of our developers use IBMs RAD to develop, and it doesn't (or at least wasn't) compatible. Our process is to update our local sources from SVN and then to run Maven's eclipse:eclipse locally with the relevant workspace setting so that our .project and .classpath files are generated, based on the dependencies and other information in the POMs. It works well enough, but the plan is indeed to move to M2Eclipse at some stage soon. We have parent POMs for each sub-system (each of which is made of several Eclipse projects). Some of us pull multiple sub-systems into our workspaces which is useful when you refactor interfaces between sub-systems, because Eclipse can refactor the code which calls the interfaces at the same time as you refactor the interfaces, saving lots of work. Maven generates .classpath files for Eclipse which reference everything in the workspace as a source projet rather than a JAR out of the local Maven repo. That is important because if Maven created JAR references and not project references, Eclipse's refactoring wouldn't adjust the code calling the refactored code. 10 days ago we switched from a build process based on continuum and archiva to jenkins and nexus. All of a sudden we lost some of the source references which were replaced with JAR references. If a project…
100% code coverage, Hibernate Validator and Design by Contract
Code coverage in unit testing was one of the first things I learned in my software engineering career. The company I worked at taught me that you should have 100% coverage as a goal, but achieving it does not mean there are no bugs in the system. At that time, I worked at a company whose big thing was that they delivered very reliable billing software to telecomms operators. We used to invest as much time writing unit tests as we did writing the code. If you included unit tests, integration tests, system tests and acceptance tests, more time was spent testing than designing and implementing the code which ran in production. It was impressive and I have never worked with or for a company with that kind of model since, although I am sure there are many companies which operate like that. The other day I was thinking back to those days and reading up about unit testing to refresh myself in preparation for a unit testing course I'm attending soon (don't want the instructor to know more than me!) and I started to wonder about what kind of code could be fully covered during unit testing, but which could still contain a bug. While I learned that 100% coverage should be the goal, in over 10 years I have never worked on a project which achieved that. So I have never surprised to find a bug in code which I thought was "fully" tested. It's fun write whacky…
A really simple but powerful rule engine
UPDATE: Version 2.2.0, JavaScript (Nashorn) rules in the JVM - see here. UPDATE: Version 2.1.0, Java 8, Maven, GitHub - see here. UPDATE: Version 2.0 of the library now exists which supports Scala. It is a breaking change in that "Action" instances as shown below are now "AbstractAction", and the "Action" class is only supported in Scala, where functions can be passed to the action constructor instead of having to override the AbstractAction. Scala collections are also supported in the engine. I have the requirement to use a rule engine. I want something light weight and fairly simple, yet powerful. While there are products out there which are super good, I don't want something with the big learning overhead. And, I fancied writing my own! Here are my few basic requirements: Use some kind of expression language to write the rules, It should be possible to store rules in a database, Rules need a priority, so that only the best can be fired, It should also be possible to fire all matching rules, Rules should evaluate against one input which can be an object like a tree, containing all the information which rules need to evaluate against Predefined actions which are programmed in the system should be executed when certains rules fire. So to help clarify those requirements, imagine the following examples: 1) In some forum system, the administrator needs to be able to configure when emails are sent. Here, I would write some rules like "when the config flag…
JSR-299 & @Produces
I've been reading JSR-299 and I have a few thoughts. First, a quote from chapter 1: "The use of these services significantly simplifies the task of creating Java EE applications by integrating the Java EE web tier with Java EE enterprise services. In particular, EJB components may be used as JSF managed beans, thus integrating the programming models of EJB and JSF." The second sentence made my ears prick up. Do I really want EJBs to be the backing beans of web pages? To me that sounds like one is mixing up responsibilities in MVC. Sure, there are people out there who say that an MVC Controller should be skinny and the model should be fat (youtube ad). Perhaps I'm old school, but I prefer my JSF page to have a backing bean which is my view model and deals with presentation specific logic, and when it needs transaction and security support, it can call through to an EJB which deals with more businessy things. The JSR then goes on to introduce the @Produces annotation. I don't like that annotation and the rest of this blog posting is about why. When I need an object, like a service or a resource, I can get the container to inject it for me. Typically, I use the @Inject, @EJB, @Resource or @PersistenceContext annotations. In the object which has such things injected, I can write code which uses those objects. I let the container compose my object using those pieces and other beans.…
When tool strategy gets on your nerves
In the beginning A long time ago, before the days of code prettifiers like Jalopy, we wrote code and we tested code. That code was fun to write. And because it was fun to write, we were motivated to write it well and test it well. Welcome Jalopy It was around 2008 when a powerful tool which auto-magically reformatted our code was forced on us. In the beginning we rejoiced, for this tool added "TODO: Document me!" to all methods missing Javadoc (lots). It made it very easy to see where programmers had failed to document their code. The numerous TODOs were also great, because they made it impossible to find the real meaty stuff that still needed to be done. And in classes where our constants were defined, in a specific order so that it matched our documentation, Jalopy kindly reordered the constants alphabetically, making it hard to match code to the documentation. Enter Sonar A while later, realising that programmers program bad code even though Jalopy is present to save the world, we had Sonar forced on us. It is a great tool, because it tells us how bad our code is and what we need to change in order to make it good. Ahhh, what is "good" I hear you ask? Well that is defined by a central department who knows nothing of our projects and who doesn't care about architecture (where our real problems lie). The people who work there only want drones who all program…
Eclipse e4 – from Client to Server and back again with MVC
I recently participated in a course where we learned about Eclipse e4 development. It was all very interesting, especially the reliance on declarative services from OSGi. I decided to have a think about how to build a skeletal application which makes server calls, to show how I would design the application architecture and break the application into bundles (plugins/components). I also focused on MVC. The app is a simple realtime market place for selling animals. Users can view the details of animals which are for sale and then purchase any animal they like. They can also add their own animals to the market place for others to purchase. Here's what it looks like (the red text isn't part of the app!): The first step was to think about a few requirements, use cases and design points: Refresh List - reload the list of available animals by making a server call to the central database. The user can view the list of freshly loaded animals and by clicking on an animal they can view it's details, like price, age and name. Purchase Animal - While viewing an animals details, the user may attempt to purchase the animal. It is only an attempt, because in a concurrent system, another user may have already purchased the animal. The client only shows the last loaded state - there is no push notification mechanism from server to client to inform it that there has been a change in the central model. As such, the clients…
Tomcat, WebSockets, HTML5, jWebSockets, JSR-340, JSON and more
On my recent excursion into non-blocking servers I came across Comet, server push technologies and then Web Sockets. I was late arriving at the Comet party, but I think I have arrived at the Web Sockets party just in time. The final standard is still being evovled and at the time of writing, the only browser supporting it by default is Chrome. So to get started, I had a look at what was around. Initially, I wasn't going to write a blog article about it, I just wanted to learn about this new thing. My only requirement was that the server implementation was Java based. The reason is simple - my entire technology stack is based on Java EE and I want to be able to integrate all my existing stuff into any new server, without the need for an integration bus. I like being able to drop a JAR file from one project into another one and to be up and running immediately. So I had a quick look at jWebSockets, Grizzly (Glassfish), Jetty and Caucho's Resin. All similar, yet all somewhat different. Most different, was jWebSockets, because they have gone to the extent of building their own server, instead of basing their solution on an existing server. I had a good long rant about that kind of thing when I blogged about node.js, so I won't start again. But jWebSockets has a real issue to face in the coming years. JSR-340 talks about support for web technologies based…
Non-blocking (NIO) Server Push and Servlet 3
In my previous blog posting, I wrote about what I would expect node.js to do in order to become mature. I introduced the idea of having a framework which lets you define a protocol and some handlers in order to let the developer concentrate on writing useful business software, rather than technical code, in a very similar manner to which Java EE does. And through that posting, I came to learn about a thing called Comet. I had stated that using a non-blocking server wouldn't really be any more useful than a blocking one in a typical web application (HTTP), and so I created an example based on my own protocol and a VOIP server, for streaming binary data to many concurrently connected clients. I have now read up on Comet and come to realise there is indeed a good case for having a non-blocking server in the web. That case is pushing data back to the client, like for continuously publishing latest stock prices. While this example could be solved using polling, true Comet uses long-polling or even better, full on push. A great introduction I read was here. The idea is that the client makes a call to the server and instead of the server returning data immediately, it keeps the connection open and returns data at some time in the future, potentially many times. This is not a new idea - the term Comet seems to have been invented in about 2006 and the article I refer…
