SQL Server 2000

May be it is the third day.... I haven't found any jdbc driver that nicely handles distributed transactions on SQL Server 2000. One says JSQLConnect is nice and expensive.

In any events, one point on jTDS: they say the XA data source is not production quality so a good driver is out of question. Another point, data direct's driver does not work with hibernate and SQL Server 2000 unless you disable hibernate's fetch identity values. On top of that our application goes crazy when I use data direct jdbc driver.  The first call to create first jms table fail because it is there and the subsequent queries fail with XAER_NOTA. jTDS does not exhibit this problem. Life sucks...

JBossWeb, Tomcat and Apache...

JBossWeb is said to be faster when it comes to secure connections. However, my two-days-testing didn't show any significant difference on how it handles regular http connections.

The first day was spend on testing Tomcat against 1500 http connections, and Tomcat reasonably handled the connections. JBossWeb did the same job with quite less CPU usage, which was not really impressive (around 2 percent CPU usage difference, and no significant performance gain). Both Tomcat and JBossWeb crapped out when bombarded with too many connections on the same hardware. In this test JBoss crashed with a running out of native threads errors message, and Tomcat did not throw any exception but it did not respond to any other request.

The second day was spend on configuring Apache to accept http requests, parse them into AJP1.3, and redirecting parsed requests to Tomcat. This test showed a better performance improvement, but still it was not impressive enough (around 3 percent performance gain) for us.

These tests had been run with a test client we have for our online game engine, and the results do not generally stand for a reasonable comparision of these technologies. I still need to see if I can tweak them so that I can get a better performance, in terms of CPU usage or speed, in our game engine.

Java 7

I am nervous to see where this is going...

JBoss JMX and remote monitoring

Java 5 comes with a nice monitoring console, JConsole, which is able to connect localy/remotely to a Java program and tell you basic stuffs about the program. This will require an application to start with a -Dcom.sun.management.jmxremote parameter. How easy! However, this parameter forces the JVM to start an MBeanServer. Well, so far so good, but I tried to use this with JBoss and boom! The JBoss didn't start up successfully. Actually, It was our application that fell apart. Why?

Our application uses Spring to manage its in-container beans. We also use MBeanProxyFactory to get a reference to the MBeans defined within JBoss deployment descriptors. The problem here is that MBeanProxyFactory looks up in the first MBeanServer it finds and ignores the others. It's more likely that this MBeanServer is not the JBoss MBeanServer one when JBoss is started with the monitoring paramter. 

Today I dug up the whole internet for a solution, and it seriously took me a long time to find a solution. First, I started to define a server connection factory but I couldn't find the right service url for the JBoss JMX. The more I tried the less I found :( However, I happened to see a post in spring forums on a similar problem, and it turned out that JBoss has a utility class that gives you access to its MBeanServer. So, the solution for now is to use a base bean for all other proxied mbeans, and set the server:

 

<bean id="baseMBeanProxyFactory" class="org.springframework.jmx.access.MBeanProxyFactoryBean" abstract="true">
    <property name="server">
        <bean class="org.jboss.mx.util.MBeanServerLocator" factory-method="locateJBoss"/>
    </property>
</bean>  

 

This works fine, but it would be easier to specify which MBeanServer should be queried for an MBean lookup. I have requested Spring people to add a new property to the MBeanProxyFactory.

 

ps. For the ones who are still wondering what the JBoss MBeanServer is called, it is 'jboss'.

Java 7, a new Java?

Apparently serious discussions are taken on the new Java language syntaxes. To me, most changes and enhancements help with the repeating code one developes in a daily Java coding. For example, we are all used to code single-method-anonymous-classes, which in a way resemble what C method pointers do. However, it doesn't look great to have all that class code while you only need a method. FCM addresses this in its entirety.

 

More on this is happening at www.javac.info. The latest Closures for the Java Programing Language explains how new literals and syntaxes can be put together to eliminate huge piles of repeated Java codes.

 

One good side of this is that all these new literals and syntaxes are translated to the existing ones, which means they will be translated into the same binary code. Nonetheless, I am not sure how this will effect code maintainability. At the same time, one could expect all sort of magical refactoring tools with Extract to Code Template bla bla to come out.

 

My take, we will be soon experiencing a new Java.

private members, are they private?

Today I was to this Seam presentation by David Geary, and it was the first time I was actually seeing an EJB 3 code in which I pointed out Seam is magically (k, I mean using reflection) setting private members of a bean class. This was the first time I had to think if that is actually possible. Guess what? Yes it is possible.

Consider this example:

package test; public class TestClass {       private int a = 2;       public void printA()       {             System.out.println(">> a =" + a);       } }

TestClass has a private in member and a method to print the private data out. My goal is to access this private memeber's value through reflection. A quick and dirty try to do so would be a code like this:

import java.lang.reflect.Field; public class TestReflection {       public static void main(String[] args) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException {             TestClass t = new TestClass();             t.printA();             Field a = t.getClass().getDeclaredField("a");             a.setInt(t, 14);             t.printA();       } }

Running this will run into a java.lang.IllegalAccessException exception, which is what you would expect. However, the trick to access a private member's value is to set its accessibility. The Field class has a setAccessible method by which you can tell the VM I want to set this field's value. So, adding a single line to the same code will do the job:

import java.lang.reflect.Field; public class TestReflection {       public static void main(String[] args) throws SecurityException, NoSuchFieldException, IllegalArgumentException, IllegalAccessException {             TestClass t = new TestClass();             t.printA();             Field a = t.getClass().getDeclaredField("a");             a.setAccessible(true);             a.setInt(t, 14);             t.printA();       } }

Installing a security manager will prevent setting a field's accessiblity. However, you still have the option to let a specific code base do it. Yes, I am talking about security policy files. In other words, there is ways to get around this anyways.

In any events, I am not sure if this is only my illusion that private fields are not really private or there is a way to secure private values.