My previous Maven 2 Cobertura Plugin article gives a workaround for the very buggy version 2.1 of the Cobertura Maven Plugin.
This bug is fixed on versions 2.2 or higher, and consequently, that workaround does not work anymore.
For those reading my previous article and having difficulties configuring the plugin, this is my actual configuration.
Read the rest of this entry »
Stripes Framework presentation for the Portuguese Java User Group session on the JavaPT09 event.
The used source code is also available.
The JBoss Microcontainer is a refactoring of JBoss’s JMX Microkernel to support direct POJO deployment and standalone use outside the JBoss application server.
It allows the creation of services using simple Plain Old Java Objects (POJOs) to be deployed into a standard Java SE runtime environment.
JBoss Microcontainer uses dependency injection to wire individual POJOs together to create services. Configuration is performed using either annotations or XML depending on where the information is best located.
The goal of this article is to show how easy it is to test these services using TestNG testing framework.
Read the rest of this entry »
Following the previous article Combine and minimize JavaScript and CSS files for faster loading, I implemented a similar solution as a Maven plugin.
This plugin combines and minimizes JavaScript and CSS files using YUI Compressor for faster page loading.
More details can be found on the Maven Minify Plugin page.
For those getting a SocketTimeoutException when calling an Axis 1.4 Web Service.
This may be a solution for your problem.
If your log show an error similar to this:
12:38:51,693 ERROR [TerminalSessionHelper] ; nested exception is:
java.net.SocketTimeoutException: Read timed out
AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: java.net.SocketTimeoutException: Read timed out
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:java.net.SocketTimeoutException: Read timed out
... |
And your call looks like this:
TerminalSessionService terminalSessionService = new TerminalSessionServiceLocator();
TerminalSession_PortType terminalSession_PortType = terminalSessionService.getTerminalSession();
((TerminalSessionSOAPBindingStub) terminalSession_PortType).setTimeout(15000); |
Try to use CommonsHTTPSender as the Transport Sender of the Axis client:
BasicClientConfig basicClientConfig = new BasicClientConfig();
SimpleChain simpleChain = new SimpleChain();
simpleChain.addHandler(new CommonsHTTPSender());
basicClientConfig.deployTransport("http", simpleChain);
TerminalSessionService terminalSessionService = new TerminalSessionServiceLocator(basicClientConfig);
TerminalSession_PortType terminalSession_PortType = terminalSessionService.getTerminalSession();
((TerminalSessionSOAPBindingStub) terminalSession_PortType).setTimeout(15000); |
This also has the advantage to use HTTP 1.1 instead of HTTP 1.0.
Note: You will need to add the common-httpclient.jar and common.codec.jar to the jar directory for this to work.
Still want to use HTTP 1.0? No problem, just add the following line of code:
((TerminalSessionSOAPBindingStub) terminalSession_PortType)._setProperty(
MessageContext.HTTP_TRANSPORT_VERSION, HTTPConstants.HEADER_PROTOCOL_V10); |
Hope this can save your time. Axis can be really painful…
Everyone knows that documentation is not one of JBoss strengths.
This article is meant to fill this gap. It describes and exemplifies how to configure JBoss PojoCache as a MBean service, using loadtime transformations with JBossAop framework, so you don’t need precompiled instrumentation.
Introduction
This section gives you an introduction about PojoCache and its advantages over TreeCache (a plain cache system).
PojoCache is an in-memomy, transactional, and replicated POJO (plain old Java object) cache system that allows users to operate on a POJO transparently without active user management of either replication or persistency aspects. PojoCache, a component of JBossCache (uses PojoCache class as an internal implementation, the old implementation TreeCacheAop has been deprecated.), is the first in the market to provide a POJO cache functionality. JBossCache by itself is a 100% Java based library that can be run either as a standalone program or inside an application server.
TreeCache limitations:
- Users will have to manage the cache specifically; e.g., when an object is updated, a user will need a corresponding API call to update the cache content.
- If the object size is huge, even a single field update would trigger the whole object serialization. Thus, it can be unnecessarily expensive.
- The object structure can not have a graph relationship. That is, the object can not have sub-objects that are shared (multiple referenced) or referenced to itself (cyclic). Otherwise, the relationship will be broken upon serialization.
PojoCache advantages:
- No need to implement Serializable interface for the POJOs.
- Replication (or even persistency) is done on a per-field basis (as opposed to the whole object binary level).
- The object relationship and identity are preserved automatically in a distributed, replicated environment. It enables transparent usage behavior and increases software performance.
Read the rest of this entry »
I really enjoy jQuery. But finding the right UI widget can be a daunting task.
Autocomplete is one of those widgets.
I decided to share an asynchronous example on how to use the jQuery Autocomplete plugin with Stripes.
Here’s an example output:

Read the rest of this entry »
JBoss announced the GA release of JBoss AS 5.0.
JBoss 5 is the next generation of the JBoss Application Server build on top of the new JBoss Microcontainer. The JBoss Microcontainer is a lightweight container for managing POJOs, their deployment, configuration and lifecycle. It is a standalone project that replaces the famous JBoss JMX Microkernel of the 3.x and 4.x JBoss series. The Microcontainer integrates nicely with the JBoss framework for Aspect Oriented Programming, JBoss AOP. Support for JMX in JBoss 5 remains strong and MBean services written against the old Microkernel are expected to work.
JBoss5 is designed around the advanced concept of a Virtual Deployment Framework (VDF), that takes the aspect oriented design of many of the earlier JBoss containers and applies it to the deployment layer. Aspectized Deployers operate in a chain over a Virtual File System (VFS), analyze deployments and produce metadata to be used by the JBoss Microcontainer, which in turn instantiates and wires together the various pieces of a deployment, controlling their lifecycle and dependencies.
See the full release notes and downloads page.
And good luck to get your J2EE applications working with this new version.
This example was greatly inspired by the Stripes and jQuery AJAX Forms article from Freddy Daoud, but with some nice improvements
Last week I was working on a new Stripes/AJAX example. It involves having a table listing entities, being the last row of the table a form for adding new ones.
The form gets submitted via AJAX, using jQuery, and the response is validated in order to check if the HTTP session is still valid.
If everything is OK, the list is refreshed and a success message appears. On the other hand, if validation errors occur, the list is refreshed and an error message appears.
Also, if the user’s session has expired on the server, an alert is shown to inform the user that his session is invalid, and the page is reloaded so the user can login once more.
Read the rest of this entry »
A long time has passed since my previous BIRT examples Deploying BIRT Report Engine API with Jakarta Struts
and Deploying BIRT Report Engine API with Stripes
.
Although they have received a lot of attention and downloads, the examples were really basic and are now outdated.
Since I had to use BIRT in my last projects I decided to update my BIRT/Stripes example.
This example doesn’t depend on the Tribix project anymore since BIRT supports HTML/Paginated HTML, PDF, Excel, Word, PowerPoint, and PostScript outputs (images/charts are not embedded in Excel output).

I’ve tried to follow some good practices
that I think are important to use in a production application:
- There is a significant cost associated with creating an engine instance, due primarily to the cost of loading extensions. Therefore, each application should create just one ReportEngine instance and use it to run multiple reports. In this example the engine is started in the context listener and the same instance is always used.
- All texts in the report should be loaded from the resources so the application can be fully localizable and fully internationalized.
- You should use a JDBC data set to preview your report with BIRT designer but you must swap the data set in runtime to use data from your business logic.
- You should use predefined styles instead of custom styles as much as you can.
- Not a good practice but often a requirement, hide the master page when generating a HTML report, and change the visibility of elements so they are visible only to specified outputs.
For this example BIRT Runtime Engine 2.2.2 2.3.1, and Stripes Framework 1.5 were used.
Read the rest of this entry »