Quest for improvement - java-programming

asynchrmi 1.2 released

quest — Thu, 02 Jul 2015 13:33:43 +0000

asynchrmi goes to version 1.2. This is the first production-ready release. Its core features seems to serve us well.

For those who used earlier snapshots, note that there is an interface change in the ChainBuilder. It now uses a common object called a ChainResult. In traditional Promise programming, each group of tasks typically feed the next step. When using asynchrmi we foung that we needed to gradually build up a data by successive layers of relation lookups. Only at the end do we have enough data to produce the actual result (i.e. a web page).

Maven dependency looks thus:

   <dependency>
     <groupId>net.windwards</groupId>
     <artifactId>asynchrmi</artifactId>
     <version>1.3-SNAPSHOT</version>
   </dependency>

Tags:

quest-blog

java-programming

jboss

asynchrmi

asynchrmi helps writing JBoss RMI clients

quest — Fri, 15 Aug 2014 09:33:01 +0000

I have started a new project called asynchrmi. The purpose of this lib is to make it simpler to write serious applications that calls a JBoss application server.

We were in the process of writing a modern web frontend to our car-sharing system when we concluded that: 1) making many parallel calls to JBoss as different users didn't work, and 2) that because of the heavily relational datamodel (a typical Hibernate model) you needed to make several calls to get all the data you wanted - calls that could be parallelized.

In order to encourage the building of a vocabulary, I wrote a simple library called asynchrmi that enables threadpool-mediated, Future- and/or callback-driven client JNP operations that will be safely threaded.

The project is still in early stages, but has proved useful and robust.

The big missing piece is the ability to inject RMI endpoints on RMITask objects so that all the tedious lookups can be compressed (and ideally performed in parallel).

Please note that this is a large hammer. You can easily sink your application server, either via lock-death or through load-death. Proceed with caution.

Tags:

The case against dependency injection (in its common form)

quest — Tue, 11 Jun 2013 21:51:27 +0000

Dependency injection as it seems to be commonly used in Javaverse, is at the center of what I consider problematic (read sucks) with the philosophy behind JEE.

To be clear: annotation-driven dependency injection is a reasonable software pattern. For example, it allows defining partial standards such as JAX-RS. However, dependency injection as the default mechanism (i.e. with one global namespace) for interconnecting beans makes sense only for small projects.

Dependency injection is often sold with the argument that it solves the problem of constructors with long argument lists. The problem with this sales pitch is that having ten arguments to your constructor or having ten injections on your class both amount to an unsurveillable mess. Put differently, ten constructor arguments or ten injections make no difference to a unit test.

Both JAX-RS and stateless beans are (more or less) instantiated per request. Given the low cost of instantiation this makes sense as an isolation mechanism, but since classes are just used to group responders that are related (operate on similar data, use shared helpers, et cetera) each responder method is likely to require a slightly different set of injections. The grouping class ends up with the union of all injections. The result is a chaotic network that is hard to create a mental map of. Where dependency injection has created such networks, isolating functional units for testing becomes much harder. Massive mocking ensues.My position is that in order to be comprehensible and unit testable, any large software project needs to be divided into subsystems. Each subsystem should be a namespace unto itself. Its interaction should be isolated properly, e.g. using a message passing pattern (a message queue in JMS terminology). A system thus subdivided will not suffer from unwieldy constructors. It could still use dependency injection internally for e.g. plugins.

Expressed differently, dependency injection should be a tool in the hands of a systems architect to apply where relevant, rather than the default mechanism of a framework for interconnecting individual classes. Square Dagger is designed for this purpose and allows creating mini-frameworks focused on sensible injection.

Tags:

quest-blog

java-programming

How to get a servlet to answer

quest — Thu, 27 Dec 2012 11:06:05 +0000

The basic problem, as illustrated by this somewhat aged Jetty pathSpec documentation, is that "/" is treated as "/*" when giving a servlet path spec. Thus, if you want to have a servlet as "front page" in an embedded scenario:

ServletContextHandler servlets = 
    new ServletContextHandler(ServletContextHandler.SESSIONS);
servlets.addServlet(MyServlet.class, "/");

... that servlet will get requests for the entire URL space and no other servlet in the context will get any requests. In particular, if you want to add a DefaultServlet to serve static web pages, images and CSS, that will be tricky.

The solution is to stick each servlet in its own context handler. If you do this, you can control in what order they are asked to handle the HTTP request. Thus, you can make sure it asks all other servlets before asking the greedy "/" servlet. Something like this:

ServletContextHandler html, servlets;
servlets = new ServletContextHandler(ServletContextHandler.SESSIONS);
servlets.addServlet(MyServlet.class, "/");

html = new ServletContextHandler(ServletContextHandler.SESSIONS);
ServletHolder holder = html.addServlet(DefaultServlet.class, "/html/*");
holder.setInitParameter("resourceBase", "./");

ContextHandlerCollection collection = new ContextHandlerCollection();
// First, try the static stuff
collection.addHandler(html);
// Then ask the greedy servlet
collection.addHandler(servlets);

Server server = new Server(8080);
server.setHandler(collection);
server.start();
server.join();

The reason this works is that a context will simply "pass" if it does not match a certain URL.

While on the subject, it is fairly annoying when developing that the context won't print tracebacks. When developing, we would prefer the error web page to contain the stack trace. This can be achieved fairly easily:

ErrorHandler errorHandler = new ErrorHandler();
errorHandler.setShowStacks(true);
server.addBean(errorHandler);

Tags:

quest-blog

java-programming

teaching