Archive for the ‘ J2EE ’ Category

JDBC connection pool and firewall

Connection closed

When a jdbc connection is going through a firewall you might experience connection closed issues. What happens is that the firewall detects idle TCP connections and kills them. This is good stuff, both for security reasons and to free unused resources.
But the application is not always aware of the pretty brutal TCP connection killing done by the firewall. And would end up trying to use a connection already killed by the firewall. This could give all kinds of unexpected results, but bottom line is that you don’t get through to your database.
It would be much better if the application shut down idle and unused connections before the firewall detects it and kills it. If you have written your own jdbc connection handling there are ways to set the jdbc connection timeout.
Firewalls typically has a session timeout of 30 min, before killing idle TCP connections, but it could easily be as low as 10 min. Ask you network administrator, or do a test.

Application server

Another thing is that even if the application server connection pool is configured to remove idle connections after a certain period of time which is below the firewall session timeout, we still experienced connection issues.
The reason was that the minimum size of connection pool was configured to be larger than 0, as suggested by some best practices tutorials.
Note that IDLE_TIMEOUT will not remove conn if it result in connpool smaller than minimum.
I repeat: database connection pool idle timeout value will not remove connections from pool if this result in a pool smaller than minimum.
And what do you think will happen when the application server decide to maintain a minimum size of connections in the pool? Well, the firewall comes along and kills them. The firewall will not respect your minimum number of connections configuration!


Connections should timeout if idle for a certain period of time, to reduce unnecessary overheads, and to avoid open connections left open across a firewall. The brutal killing of idle TCP connections performed by the firewall can cause all kinds of problems to the application itself.
Keeping a minimum size will again allow the firewall to detect them as idle TCP connections.
As well as timing out, make sure you allow your pool to shrink to size of 0.

Asynchronous messaging and HermesJMS

Hermes JMS console

Hermes display the activity on JMS queue or topic

Hermes display the activity on JMS queue or topic.

In a SOA solution asynchronous messaging can be used to decouple service provider from consumer, allowing service provider and consumer to process messages independently. The intermediate message buffer, typically JMS, will enable a more robust and reliable architecture.
Both during development, testing and production, it is extremely useful to be able to browse or search queues and topics, copy messages around and delete them.
This can be done by HermesJMS. Please note that the HermesJMS application is now bundled with SoapUI 3.5 and later versions. So instead of installing a standalone HermesJMS, you get it as part of SoapUI installation. Application is the same.
HermesJMS is a very useful tool supporting a wide range of JMS providers. The documentation is very good, with tutorials on how to configure this for the different providers. There is no need to give additional documentation in this blog, but just to show you how excellent this tool is, I have made some screenshots demonstrating the setup and management capabilities using Oracle Enterprise Messaging Service (OEMS) provided by OC4J in a SOA Suite installation. There are some differences from a OC4J standalone installation, as detailed here.
I repeat, the HermesJMS documentation is excellent, and there is also an older blog entry that had useful input. But some details needed to be modified so I add these screenshots to make you understand that if you are even close to JMS, you need this tool.

First it is a matter of adding the OEMS client libraries into classpath:

showing how to configure the provider classpath for OC4J Oracle Enterprise Messaging System (OEMS)

showing how to configure the provider classpath for OC4J Oracle Enterprise Messaging System (OEMS)

Adding libraries to support OC4J  JMS provider (OEMS).  Add the optic.jar library to the list of libraries so that Hermes can understand the managed OracleAS process management environment (OPMN).

Adding libraries to support OC4J JMS provider (OEMS). Add the optic.jar library to the list of libraries so that Hermes can understand the managed OracleAS process management environment (OPMN).

Now create a JNDI InitialContext:

Configure JNDI InitialContext, giving it a name.

Configure JNDI InitialContext, giving it a name.

Configuration to access Oracle SOA suite JNDI InitialContext

Configuration to access Oracle SOA suite JNDI InitialContext

Creating a session towards the recently configured provider

Creating a session towards the recently configured provider

Using session to discover destinations

Using session to discover destinations

Listing the 20 different destinations existing in this SOA suite instance

Listing the 20 different destinations existing in this SOA suite instance

Now doubleclicking on a destination (e.g jms/demoQueue) will list the content

Now doubleclicking on a destination (e.g jms/demoQueue) will list the content

Java app, JMS send message

Here is a sample java application to send a message to a queue. Include these entries to the classpath


package no.gwr.util.jms;

import java.util.Hashtable;
import javax.jms.Message;
import javax.jms.Queue;
import javax.jms.QueueConnection;
import javax.jms.QueueConnectionFactory;
import javax.jms.QueueSender;
import javax.jms.QueueSession;
import javax.jms.Session;
import javax.naming.Context;
import javax.naming.InitialContext;

public class Send {

  public static void main(String[] args) {
    QueueConnection queueCon = null;
    try {
      Hashtable env = new Hashtable();
      env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
      env.put(Context.PROVIDER_URL, "opmn:ormi://localhost:6003:oc4j_soa/default");
      env.put(Context.SECURITY_PRINCIPAL, "oc4jadmin");
      env.put(Context.SECURITY_CREDENTIALS, "***");
      Context ctx = new InitialContext(env);
      QueueConnectionFactory qcf = (QueueConnectionFactory) ctx.lookup("jms/QueueConnectionFactory");
      queueCon = qcf.createQueueConnection();
      QueueSession queueSession = queueCon.createQueueSession(false, Session.AUTO_ACKNOWLEDGE);
      Queue queue = (Queue) ctx.lookup("jms/demoQueue");
      QueueSender sender = queueSession.createSender(queue);
      Message msg = queueSession.createTextMessage("a test message, go to");
      System.out.println("message sent");
    } catch (Exception e) {

Open Source risks – Java Enterprise rootkits

Open source is ubiquitious. There is literaly no project being run these days that is not using open source to some extent. Llibraries are downloaded and installed as needed.
If you are working on a J2EE project, what if the taglibs-library or spring-library is trojaned. Or what if a black hat developer is given commit access to one of the open source libraries in use. Remember the black hat developer is most likely an employee of Russian Business Network, or some other big business cybercrime network. They do relocate, and rebrand, but profit makers don’t disappear voluntarily.

There was an excellent presentation given by Jeff Williams on Enterprise Java Rootkits at the recent Blackhat USA conference. Should be a mandatory read for every java developer out there.

Malicious developer

The malicious inside developer is not what you should worry about. They already have access to your premises, and your network. So leaving some malicious code in there seems to be a detour for an insider. A cybercrime company would prioritize getting the code in themselves compared to paying off an untrusted inside developer. It is the risk/reward-ratio that makes cybercrime inclined to attack from anywhere, anonymously. Involving an insider would be an uneccessary risk. If the possbilities of remotely inserting malicious code are limited or removed, then getting an insider could become the only feasible option. But it is not there yet.

In a software project the developers consist of internal, outsourced, commercial and open source developers. And the amount of trust you can put on them follows same trajectory. Internals and outsourced you trust, they even have a face attached. The commercial you at least can get to some way or the other, even through court. But what about your open source developers. They do it for free, on their own spare time. How can we make sure they did not put in some moneymaking code in there.

control open source usage

So make sure you only use open source libraries that are widely used, that undergoes proper reviewing, and where upgrades and commit access is well controlled. Be conservative on updates, and the selection of open source libraries you are using. If not you are inviting every black hat developer out there to provide you some software. It is like asking the Mob to take care of your savings.

ongoing security verification

In the code process, the build process and the operational environment there are issues to consider when it comes to security.The amount of libraries and apis deployed in runtime environment is a risk. Is it all needed, and in use? Reflection, classloading, instrumentation are powerful apis that can be easily exploited by a blackhat developer.
Seal your jars, and build the open source libraries as well. And finally, what about the jdk versus jre. and the extensions folder.

Wikipedia – Russian Business Network
Enterprise Java Rootkits – Blackhat presentation

Eclipse RCP

When working on a Eclipse RCP solution Lars Vogel had a tutorial series that boosted the startup time of the project. And Eclipse RCP is in my opinion the user interface framework to stick to for rich client applications. Impressive, well-documented, and rich on functionality.

check out Lars Vogel’s site: