HTC Incredible S Android Update - SMS/Messages Problem

This morning I got a notification on my phone to upgrade to Android Version 2.3.5 and the new version of HTC Sense (3.0). That's great - and I'm really happy with the upgrade.

However, one annoying side-effect for me is I immediately started receiving SMS notifications which were blank (or just said "SMS message") and displayed the location I was in (for example my suburb or nearby suburbs). Each message came with the option to "save" or "cancel". If I selected 'cancel' it would just go away. If I select save, it appears in my text messages coming from the sender '50'.

The annoying part is that these messages just kept coming. As I move my phone around the house it would every minute or so get messages from the sender "50" and give me an annoying notification that I had to respond to.

It turns out that these messages appear to be "Cell Broadcast" messages. The cell broadcast forum states that:

Cell Broadcast (CB) is a mobile technology that allows messages (currently of up to 15 pages of up to 93 characters) to be broadcast to all mobile handsets and similar devices within a designated geographical area. The broadcast range can be varied, from a single cell to the entire network.

There's more information about it at Wikipedia - Cell Broadcast.

In any case, it seems that the update to Android 2.3.5 and HTC Sense 3.0 on the HTC phone has caused it to start notifying me of each Cell Broadcast messages coming from channel 50. (Presuming they didn't just start broadcasting in my area this morning at the exact time I did my update, at least!)

Solution: I decided I would leave Cell Broadcasts generally enabled on the phone, but simply disable this channel.

To do this, you go to Settings on your Android phone. Then select Call. In this menu you have the option to enable or disable "Cell broadcast". I left it enabled and clicked on the "Cell broadcast settings" option, further down the list. Here I found the broadcast channel causing the problems (50) and clicked on it to select "disable".

This fixed the problem and my phone is back to its normal, quiet self! I guess I could have disabled "Cell Broadcast" entirely, but, who knows? One day there may be a flood coming to my area and I'll be glad I left it on!

I couldn't find anything about this specific issue on the internet, so thought I'd record this for others who experience the same problem. I'd be interested in comments if others know more about this and there is a better way to handle it. Was it just me, or are others are also experiencing this problem?

Problems with Unit Testing using GWTTestCase and GWT FlexTable()

I'm currently writing a web-application using Google Web Toolkit (GWT). To provide test-coverage for the app, I'm writing client-side unit tests that extend GWTTestCase.

Recently I found that some (previously passing) tests were failing. They threw a JavaScript Exception (com.google.gwt.core.client.JavaScriptException (null) null):

java.lang.RuntimeException: Remote test failed at 192.168.1.1 / Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
at com.google.gwt.junit.JUnitShell.processTestResult(JUnitShell.java:1083)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1203)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1198)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1198)
at com.google.gwt.junit.JUnitShell.runTestImpl(JUnitShell.java:1104)
at com.google.gwt.junit.JUnitShell.runTest(JUnitShell.java:523)
at com.google.gwt.junit.client.GWTTestCase.runTest(GWTTestCase.java:406)
at junit.framework.TestCase.runBare(TestCase.java:134)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at com.google.gwt.junit.client.GWTTestCase.run(GWTTestCase.java:282)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at junit.framework.TestSuite.runTest(TestSuite.java:232)
at junit.framework.TestSuite.run(TestSuite.java:227)
at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:45)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: com.google.gwt.core.client.JavaScriptException: (null): null
at
...



The tests were failing on a GWT constructor call designed to create a new FlexTable:

FlexTable flexTable = new FlexTable();

Confused about what could be going on, I created a simple test which just called this constructor and found that it failed:

package test.client;

import com.google.gwt.junit.client.GWTTestCase;

import com.google.gwt.user.client.ui.FlexTable;

public class FlexTableTest extends GWTTestCase {

public void testFlexTable() {

FlexTable flexTable = new FlexTable();

}

@Override

public String getModuleName() {

return "test.FlexTableTester";

}

}

So - I created a completely new Project package from scratch and then found it passed just fine.

So - what was going on? Well it turns it was to do with my "myProject.gwt.xml" file. It seems that when you run the GWT tests using GWTTestCase, the code is compiled and run on a virtual browser - that may be different from the actual browser you're using to run the application in for manual testing or acceptance tests. Obvious, in retrospect!

Now, in my project, I had decided that since I was only running the application (and Selenium acceptance tests) in Internet Explorer browsers, I could save GWT compile time by only compiling one permutation of the GWT options - that for Internet Explorer.

To do this, I had introduced the following line of code into my "myProject.gwt.xml" file:

<set-property name="user.agent" value="ie6"/>

This code tells GWT to only compile one permutation - for Internet Explorer. However, it seems that the "virtual browser" used by GWTTestCase is not InternetExplorer (or at least not fully compatible with ie6 mode).

Having this property set to a particular browser (IE6) led to the problems I was having with my tests.

All I had to do was remove the <set-poroperty name="user.agent" value="ie6"/> tag and the tests worked perfectly.

Selenium Testing GWT - upgrading to GWT 2.0 and Selenium 2.0a1

Recently, I'd written some acceptance tests for a Google Web Toolkit (GWT) based Web Application using SeleniumRC v1.0.1.

I was using GWT 1.7.1 and the tests were all working nicely. I had a Tree in the WebApp and was using GWT TreeItem elements for the nodes in this tree. I was also using GWT drag and drop (http://code.google.com/p/gwt-dnd/) to help with selecting and dragging TreeItems.

Over the last week I decided to upgrade the version of GWT from 1.7.1 to 2.0. As a result a bunch of Selenium functionality started failing. This included:

• Selenium.click() method ceased to properly select a GWT TreeItem. A manual click will make the TreeItem go blue (ie. look selected and have "gwt-TreeItem-selected" class attribute in the DOM), but the selenium test doesn't.
• Selenium.type("//*[@contentEditable='true']", newText) method ceased to properly enter text into an editable IFrame element.
• Multiple Selection (via Drag and Drop GWT) failed to show visibly what was selected.
  

After trying a bunch of things, I came to the conclusion that there is significant Selenium functionality that worked correctly when testing GWT 1.7.1 web-apps that no longer works with GWT 2.0.

A simple example was the following code (which I asked about on StackOverflow) which tests the online GWT web-page demo for TreeItems and should click() on a treeItem. However, it doesn't produce the same functionality as a manual mouse-click:

package test;

import org.junit.Before;
import org.junit.Test;

import com.thoughtworks.selenium.DefaultSelenium;
import com.thoughtworks.selenium.Selenium;

public class TestTreeClick {
    static Selenium selenium = null;

    @Before
    public void setUp() throws Exception {
        if (selenium == null) {
            selenium = new DefaultSelenium("localhost", 4444, "*iexplore",
                    "http://gwt.google.com/samples/Showcase/Showcase.html#CwTree");
            selenium.start();
        }
    }

    @Test
    public void testingClicking() {
        selenium.open("http://gwt.google.com/samples/Showcase/Showcase.html#CwTree");
        selenium.click("gwt-debug-cwTree-staticTree-root-child0-content");
    }
}

To try and alleviate this problem, I upgraded my selenium .jar file to the latest WebDriver backed Selenium (selenium-2.0a.1.jar) found at http://code.google.com/p/selenium/downloads/list. However, simply upgrading the .jar file and leaving the code the same doesn't actually use the WebDriver-backed Selenium compoments. To do this, I needed to modify the start-up code to be:

import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebDriverBackedSelenium;
import org.openqa.selenium.ie.InternetExplorerDriver;

import com.thoughtworks.selenium.Selenium;

public class TestTreeClick {

    public static void main(String[] args) {
        WebDriver driver = new InternetExplorerDriver();
        Selenium selenium = new WebDriverBackedSelenium(driver, "http://gwt.google.com/samples/Showcase/Showcase.html#CwTree");
        selenium.open("http://gwt.google.com/samples/Showcase/Showcase.html#CwTree");
        selenium.click("gwt-debug-cwTree-staticTree-root-child0-content");
    }
}

I found that the new Web-Driver backed Selenium does fix a number of the problems I'd found (or provides alternative ways to achieve functionality) - but not easily in a single step. However, it was good to find that for the click() example above, the new code works correctly with GWT 2.0, where as the old code does not.

However, at the moment (Jan 2010) this doesn't provide a really simple solution to my testing problems. Currently Web-Driver backed Selenium (Selenium 2.0a.1) does NOT provide a full set of testing functionality as found in earlier versions of standard Selenium. Some selenium methods that work in earlier versions have slightly different commands to make them work in the new version. Of the limitations/issues I've had, the key one is that Web-Driver backed Selenium does not currently provide support for right-click (context menu), and Ctrl-Click functionality.

In addition there are a number of minor changes to make things work. For instance, typing into an editable iFrame didn't seem to work using our old code:

• Selenium.type("//*[@contentEditable='true']", newText)

Instead, we now have to use:

• selenium.typeKeys(elementId, newText);

In summary, if I were to stop using the Web-Driver backed Selenium, the available test functionality is more complete, but unfortunately key bits I wish to test just don't work with GWT 2.0 code. I don't want to go back to GWT 1.7, so for the time being I'm developing my application without the ability to test Right-Clicks and having to re-write bits of the test code to work properly.

It isn't a huge deal, as I should have almost all of my right-click functionality in other menus, anyway - and hopefully the main testing comes from Unit tests and Integration tests. Nevertheless, just wanted to record these experiences here in case they help others understand what's going on when they upgrade - and what the impacts might be on Selenium tests.

Selenium Testing page with iframe/GWT RichTextArea

Recently we've been using Selenium to do integration/acceptance testing of a new web-application.

The web-application uses Google Web Toolkit (GWT) for the view layer. One of the key components is a GWT RichTextArea for user input. GWT RichTextAreas are implemented in Javascript using an iframe with designMode=On, to allow user input.

This works fine, however when we came to testing we couldn't seem to get Selenium to input text into the RichTextArea (iframe) component.

A number of websites (for example http://www.hietavirta.net/blog/item/2008/08/gwt-15-tree-and-richtextarea-testing-with-selenium) suggested something like "select the right frame with Selenium's selectFrame, type text to //html/body and finally select the top frame again."

However, this didn't work for us. We tried a combination of options for selecting the frame and then trying to select the body (or other elements) within the iframe, but all to no avail.

In the end, we didn't need to select the iframe/richtextarea separately first (and, indeed, this selecting didn't seem to work, even though the GWT "ensureDebugId" did correctly attach the id to the iframe element).

The final solution to get selenium to type into the RichTextArea was to include in our tests the code:

selenium.type("//*[@contentEditable='true'","This text is to be typed");

The first argument of the selenium.type command is a locator that finds the correct iframe (RichTextArea) element, based on the fact that GWT creates this element with a parameter indicating the content is editable. The second command is the text you want typed in your test.

Seems so simple here, but getting that to work took hours! We tried a bunch of much more "obvious" options to locate that element (including a bunch that other bloggers said worked), but in our case this was the only thing that we could find that did the job!!

So... now ya know what worked for us, too!

"java.sql.SQLException: Communication link failure" when using Hibernate, Tomcat and MySQL with Spring

I have recently obtained an error after leaving my Hibernate/Tomcat/MySQL web-application running overnight (>8 hours) with the following root-cause :

Root Cause: java.sql.SQLException: Communication link failure: java.net.SocketException, underlying cause: Software caused connection abort: recv failed

Situation: When first deployed the application works fine. However, when the application is left running for a long time (eg > 8 hours) without any interactions, the connection to the MySQL database is lost and the web-app throws an exception. The full stacktrace of that exception is below, for those interested. I am using Tomcat 6.0.18 and MySQL 5.0.27-community-nt.

Aside: It is perhaps also worth noting that another computer with the same code-base does NOT throw this error - even though the MySQL time-out settings are the same. The main difference appears to be that the other computer is running Tomcat 6.0.14 and MySQL 5.0.18-nt so it is possible that these versions don't require the fix below - but I haven't confirmed that it isn't some other minor difference.

Background:

This is a fairly common problem, but a range of solutions presented elsewhere on the internet didn't fix my problem - and they aren't documented together anywhere I could find - so I'm recording some of these here, along with the one that finally worked for me.

How to test:

The first thing to note is that this is caused by MySQL closing down connections that are idle for a period of time. One fix is to just drastically increase the "Interactive timeout" and "Wait timeout" in the my.ini file that is read on startup in MySQL. Don't forget to restart MySQL each time you change these (and to stop Tomcat before restarting MySQL). A good way to test if this timeout is really your problem is to change these to a short value (eg 40) (that is, 40 seconds) and wait to see if the error occurs in a minute or so. That way you don't have to wait overnight to test whether changes fix your problem.

Proposed Solutions:

NB: Only one of these worked (or was deemed "acceptable") for my case - and that one is the last one, but I record them all here as I couldn't find one location with all these summarized.

1. One solution is to just increase the MySQL Timeout settings as described in the "testing" section above. However, while this fixed one application I was working on, in one (different) case I found that the error was occurring overnight even if I set this to a very large value (eg 604800 sec). In any case, just increasing this value isn't a great solution as you don't want the error to occur ever - so just stalling it for a week isn't great!

2. Another solution that I didn't like, but should mention, is to put a try/catch around the Java code that accesses the database. This isn't really a hibernate solution, but I thought I'd mention it. See the suggestions at the following URL if you want to try this. It's inelegant if you're using Hibernate, but might be good if you are doing your connections manually.
http://forums.mysql.com/read.php?39,55337,139123#msg-139123

3. Another suggestion that I found on the web that didn't work - but might for similar problems - is to put the following into your hibernate config file:

<property name="connection.autoReconnect">true</property>
<property name="connection.autoReconnectForPools">true</property>
<property name="connection.is-connection-validation-required">true</property>

4. A related suggestion is to add autoReconnect=true to jdbc URL. I did try this and it didn't work for me, but it might be worth considering.

5. Another suggestion was to set the C3P0 connection-pooling properties as follows:
<session-configuration>
<property name=“hibernate.c3p0.acquire_increment">3</property>
<property name=“hibernate.c3p0.idle_test_period">14400</property>
<property name=“hibernate.c3p0.timeout">25200</property>
<property name=“hibernate.c3p0.max_size">15</property>
<property name=“hibernate.c3p0.min_size">3</property>
<property name=“hibernate.c3p0.max_statements">0</property>
<property name=“hibernate.c3p0.preferredTestQuery">select 1</property>
</session-configuration>

See https://www.hibernate.org/214.html for more details on C3PO config. This would set C3PO pooling values in the configuration - in particular setting the idle_test_period and timeout properties to be less than the values set for MySQL timeout (see 1 - I had the MySQL timeout set to 691200, so it was much longer). In fact, even before experiencing this problem I did actually already have these values set and yet the error still occurred! Still, this may be necessary /fix the problem for some people and I am still using these settings, above.

Aside: A similar set of properties for dbcp is given at https://forum.hibernate.org/viewtopic.php?f=1&t=933088&view=previous.

6. Solution (Actually worked for me): The final change that actually worked was to modify the Spring data-source to be:

<bean id="dataSource"
class="com.mchange.v2.c3p0.ComboPooledDataSource" abstract="false"
lazy-init="default" autowire="default" dependency-check="default"
destroy-method="close">
<property name="driverClass"> <value>com.mysql.jdbc.Driver</value> </property>
<property name="jdbcUrl"><value>jdbc:mysql://localhost/myApp</value></property>
<property name="user"> <value>myUser</value></property>
<property name="password"><value>myPassword</value></property>
<property name="autoCommitOnClose"> <value>true</value></property>
<property name="idleConnectionTestPeriod"><value>15</value> </property>
<property name="maxIdleTime"> <value>15</value> </property>
</bean>

The key properties here are to set the idleConnectionTestPeriod and maxIdleTime to values that are less than the mySQL timeout values mentioned in (1) above. Setting these two new properties for the datasource in applicationContext-jdbc.xml file in my Spring config settings fixed the problem.



More StackTrace Info for Error:

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.transaction.CannotCreateTransactionException: Could not open Hibernate Session for transaction; nested exception is org.hibernate.TransactionException: JDBC begin failed:
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:408)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:350)
javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:174)
org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:77)
jcifs.http.CustomNtlmFilter.doFilter(CustomNtlmFilter.java:111)

root cause:

java.sql.SQLException: Communication link failure: java.net.SocketException, underlying cause: Software caused connection abort: recv failed** BEGIN NESTED EXCEPTION ** java.net.SocketExceptionMESSAGE: Software caused connection abort: recv failedSTACKTRACE:java.net.SocketException: Software caused connection abort: recv failed at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at com.mysql.jdbc.MysqlIO.readFully(MysqlIO.java:1391) at com.mysql.jdbc.MysqlIO.reuseAndReadPacket(MysqlIO.java:1538) at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1929) at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1167) at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1278) at com.mysql.jdbc.MysqlIO.sqlQuery(MysqlIO.java:1224) at com.mysql.jdbc.Connection.execSQL(Connection.java:2248) at com.mysql.jdbc.Connection.execSQL(Connection.java:2208) at com.mysql.jdbc.Connection.execSQL(Connection.java:2189) at com.mysql.jdbc.Connection.setAutoCommit(Connection.java:546) at com.mchange.v2.c3p0.impl.NewProxyConnection.setAutoCommit(NewProxyConnection.java:756) at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:63) at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1326) at org.springframework.orm.hibernate3.HibernateTransactionManager.doBegin(HibernateTransactionManager.java:496) at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:322) at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:255) at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:102) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:176) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:210)

java.lang.UnsupportedClassVersionError: Bad version number in .class file

I was recently deploying a webApp in Eclipse (MyEclipse) using Tomcat when suddenly I got a UnsupportedClassVersionError:

java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1817)
at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:872)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1325)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1204)
at org.apache.catalina.startup.WebAnnotationSet.loadClassAnnotation(WebAnnotationSet.java:145)
at org.apache.catalina.startup.WebAnnotationSet.loadApplicationListenerAnnotations(WebAnnotationSet.java:73)
at org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:56)
at org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:297)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:1064)
at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:261)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4236)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:920)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:883)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at org.apache.catalina.core.StandardService.start(StandardService.java:516)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:566)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)


So my initial thought was "ok, a class is not loaded, but which one???".

Well - it turns out that this information would probably have led me down the wrong path anyway... and you don't need it (so don't get frustrated with whoever created that error message!).

The problem occurs, generally, when you compile a .java file with one version of JDK and then run the (compiled) .class with a different version of the Java Virtual Machine.

So... how was I doing this? Well - the .class file is being run within Tomcat and the .java file is being compiled by the preferred java compiler set in myEclipse. Ideally, these two versions would be the same - however they can be quite different. This won't be a problem AS LONG AS the Tomcat Java version (ie the Java running the .class files) is not an older version than the Java version used to compile the .class file from .java. It turns out that I had accidently set the Tomcat Java version to be an older one than the JAVA version being used to compile the code.

In MyEclipse:

Tomcat Java Version is set by:

• MyEclipse Tomcat[*] -> Configure -> Jdk -> Tomcat JDK Name

MyEclipse Compiler Java Version is set by:

• Project-> Properties -> Java Compiler -> Compiler Compliance Level
• Window -> Preferences -> Java -> Installed JREs -> Selected JRE

So, all I had to do to fix this was to set both the Tomcat JDK Name and Selected JRE to jre1.6.0_05 and compiler compliance to 1.6 and I'd fixed the problem.

[*] or whichever Tomcat you are using...

YouTube - JavaScript Turned off or an old version of Adobe Flash Player - Bug

Earlier today I was sent a link for a YouTube video, however when I went to the link I received the error message:

"Hello, you either have JavaScript turned off or an old version of Adobe's Flash Player. Get the latest Flash player. "

I have the latest Flash player (and, indeed, did follow the link and upgrade it just to make sure). However, this kept occurring for a number of YouTube videoes I then tried to watch as a test.

A bit of investigation indicated a huge range of suggestions for how to fix this - everything from people claiming it is a bug with YouTube and "YouTube Engineers are working on it" through to those advising turning off various bits of your Internet Explorer security settings (such as any "Add blockers" etc) and deleting temporary internet files and cookies.

Given that these fixes didn't work for me - and I don't want to leave my browser in an unsafe state with popups etc, anyway - I changed all these settings back to their usual state.

SOLUTION (Well, almost!):

I did, however, come up with a way to watch the video.

Now, to be honest, I haven't actually fixed the problem - when I go to the original URL I get the same error message still - but, on the positive side, I can watch the YouTube video (which, after all was the point). To do this, you just need to modify the URL you are using slightly.

In this particular case (as embarrassing as this may be - I didn't choose this video), my friend wanted me to view the link:

http://www.youtube.com/watch?v=AbAX9A8Cq0k

This didn't (and still doesn't at the moment of writing this) work for me. However, if you modify the link to:

• remove the words "watch?"
• replace "=" with "/"

I obtain a new URL that does work:

http://www.youtube.com/v/AbAX9A8Cq0k

So, the good news is this worked. The bad news is that had I known what the link was for I wouldn't have wasted the time :-) Ok - so maybe it isn't that bad?!?

Anyway, music taste aside, the good news is that this works on all the YouTube files I've tried so far. They're all giving me this same error message but, if I really wanted to, I could watch them by changing the URL manually...

So... it isn't a long term fix - but maybe this is a good start for others if the problem is with something at YouTube's end, or if you're just in a real hurry to watch that link you've been sent and don't wanna spend days re-installing Adobe products and Virus scanners!!!

Booleans in Hibernate

As the following helpful article (http://www.databasesandlife.com/hibernate-boolean-fields-mysql-50/) points out:

"There's a problem persisting boolean fields using Hibernate 3.2.2 to MySQL 5.0, if you allow Hibernate to generate your schema and you leave Hibernate to generate the schema in the default way". The problem is, by default, it generates a MqSQL field of type "bit(1)" - which causes Hibernate to throw:

could not insert: [com.company.MyObject] org.hibernate.exception.DataException: could not insert: [com.company.MyObject] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:77) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) .... Caused by: java.sql.SQLException: Data too long for column 'my_field' at row 1 at ....

When I try to save.

That's causing my tests to fail… so what to do?

Well the article I mention above suggests mapping the field using

<column sql-type="BOOLEAN" />,

which does work.

However, I'm using annotations, so my preferred mapping for booleans is:

@Column(columnDefinition = "tinyint", nullable = false)
private boolean exampleBooleanValue;

An alternative is to use:

@Column
private Boolean exampleBooleanValue;

But I prefer to work with primitives rather than boxed primitives wherever possible.
Anyway, the first solution above works wonderfully.

Log4J Warnings

Annoyingly, when I run a junit test that is testing my Hibernate DAO objects, I get the following warnings:

log4j:WARN No appenders could be found for logger (jpt.dao.impl.test.GenericDaoImplTest). log4j:WARN Please initialize the log4j system properly.

This shouldn't be surprising, it's saying that Log4j hasn't been initialized properly. Why not? Well, It can't find my log4j.properties file. That's because hibernate needs it to be in the class path. So, I need to put log4j.properties into the classpath.

Well that's fine, and doing so does fix the problem - I just put log4j.properties into my src folder (or, in this case, specifically my test-src folder).

However, the problem is that I already have log4j.properties in the WebRoot/WEB-INF folder. When running my web-app (not the tests, but the web app itself), hibernate knows to look for it there because web.xml has:


<context-param>
<param-name>log4jConfigLocation</PARAM-NAME>
<param-value>/WEB-INF/log4j.properties</PARAM-VALUE>
</CONTEXT-PARAM>


What's more, that's exactly where I want my log4j.properties to be. Sure, I could change this to point somewhere else, but I don't want to do that. I want log4j.properties to be located in this directory for my web-app and configured just so.

So… the question is, how do I get Junit to initialize using this log4j.properties, rather than looking into src (on the classpath) and finding it missing. Well, I haven't been able to do it yet. I can manually configure log4j in my test class - but that's after the warnings are already shown. The only way I've been able to avoid those warnings is by placing log4j.properties into the classpath.
So, in the end, I've now got two versions of log4j.properties. One is in test-src and defines the logging levels etc for the debug running. One is in WebRoot/WEB-INF and defines logging levels for the webapp.

This is fine - and some might even say the best of both worlds - because I can have different default logging for my tests and my web-app. However, I still don't really like it. It could be confusing having two files named log4j.properites in the one project. What if I want to have only one!

Surely it shouldn't be THAT hard to configure my Junit test runs (that extend AbstractTransactionalDataSourceSprignContextTests) so that they search for the log4j.properties in the web-inf directory rather than on the classpath?!?!?!? Any ideas? (By the way, trying to add web-inf to the classpath doesn't work, as I'm using MyEclipse and it doesn't allow this!)

Hibernate "PreInsertEvent.getSource()" NoSuchMethodError.

I recently obtained the following error:

java.lang.NoSuchMethodError: org.hibernate.event.PreInsertEvent.getSource()Lorg/hibernate/engine/SessionImplementor;

This occurred when attempting to run a test on one of my Hibernate DAO entities.

The problem started when I updated some (but not all) of my hibernate .jar libraries, to enable the use of spring-test.jar to provide access to the helper org.springframework.test.AbstractTransactionalDataSourceSpringContextTests methods.

It turns out (http://opensource.atlassian.com/projects/hibernate/browse/HV-67) that the problem was:

Method getSource from an older version of the Hibernate Core is referenced.

It is stated within the compatibility matrix that Hibernate Validator 3.1.0.CR1 is compatible only with Hibernate Core 3.3.x version(s).Exception in thread "main" java.lang.NoSuchMethodError: org.hibernate.event.PreInsertEvent.getSource()Lorg/hibernate/engine/SessionImplementor;

That is, I was using the latest Hibernate Core (3.3.x), but didn't have the most up to date Hibernate Validator. I downloaded a new hibernate-validator.jar and everything worked again.

Problems with @Test annotations with AbstractTransactionalDataSourceSpringContextTests.

I've recently been writing tests, most of which use the Junit @Test (http://junit.org/apidocs/org/junit/Test.html) annotations to identify the methods for testing as junit tests. This works really well, and also allows me to use other great annotations like @Before.

However I decided I needed to do some integration testing of my DAOs with the database. So, to do this, I took advantage of Spring's AbstractTransactionalDataSourceSpringContextTests class (http://static.springframework.org/spring/docs/2.0.x/api/index.html?org/springframework/test/AbstractTransactionalDataSourceSpringContextTests.html).

This is great, however, I noticed that all of my test annotations for classes extended AbstractTransactionalDataSourceSpringContextTests were being ignored. This means that tests that were named "testExample" would run, but those named "doTestExample" would not - even if annotated. More to the point, something called "testExample" would run as a test even if not annotated.

The reason soon became clear. AbstractTransactionalDataSourceSpringContextTests extends the Junit.Framework.TestCase class. Now JUnit4 and JUnit3 tests really should not be mixed and they don't go together. So, because I'm extending TestCase (although I don't really want to), I need to go back to old fashioned Junit Tests, without test annotations. This is commented, briefly in:
http://www.jetbrains.net/jira/browse/IDEA-16466

MySQL Database Recovery

I recently had a key application server die (hardware). One of the key applications running on this machine was a web-application that used a MySql database. We did have some specific MySql backup files, but the most recent backup of the data was a complete server backup of all files.

This meant that I had to work out how to restore a MySql database from the files stored in the data folder (under MySQL Server5.0/data/)

The files I had were:

ib_logfile0
ib_logfile1
ibdata1
and a folder, my_application, which contained a whole bunch of .frm files describing the table structures.

To restore MySql I started by copying these three files and one folder into a newly installed MySql folder on a replacement server. However, on starting mySql as a service, I got:

Could not start the MySQL service on Local Computer.
Error 1067: The process terminated unexpectedly.

I then checked out more information about this error in the file named machineName.err in the MySql/data folder.

This showed that:

InnoDB: Error: log file .\ib_logfile0 is of different size 0 25165824 bytes
InnoDB: than specified in the .cnf file 0 1782 57920 bytes.
080917 12:30:17 [ERROR] Default storage engine (InnoDB) is not available
080917 12:30:17 [ERROR] Aborting.

In this case, I went to my.ini file and changed:

innodb_log_file_size=170M

to

innodb_log_file_size=25165824

I was then able to start the MySql Server and create a normal backup for later retrieval on other servers.

Tomcat - Error starting.

I recently have been installing Tomcat 6 on a new server.

After installing a fresh JRE and then apache-tomcat-6.0.18.exe I got the error:

Windows could not start the Apache Tomcat on Local Computer. For more information, review the System Event Log. If this is a non-Microsoft service, contact the service vendor, and refer to service-specific error code 0.

To fix this I copied the file msvcr71.dll from my Java/bin directory into the Apache-Tomcat/bin directory.

It worked... though why it didn't work "out of the box" without such "black magic" I really don't know!!!!. I spent ages trying a range of different Tomcat installations, JAVA versions and classpath settings.

Aaaargh! Those were precious hours of my life I'm never going to get back...

Upgrading Hibernate Annotations from V3.2 to V3.4.0

I recently blooged about a Hibernate Annotations bug that had been fixed in Hibernate Annotations 3.4.0, but not in 3.2.

While upgrading fixed this problem, I did have some problems with changing to Hibernate Annotations 3.4.

I tried downloading hibernate-annotations-3.4.0.GA.tar.gz and just swapping over the hibernate-annotations.jar file in my project. Seemed like a simple thing to do, however, using the new hibernate-annotations.jar file caused a new error:

Caused by: java.lang.NoClassDefFoundError: org/hibernate/annotations/common/reflection/ReflectionManager

This problem is discussed at this post. It turns out that, in upgrading, I need also to include hibernate-commons-annotations.jar.

Then I got another problem that is due to the lack of the slf4j-api.jar:

Caused by: java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory

After that, I decided I'd better trust the README.txt file that comes with hibernate-annotations-3.4.0 and pulled across a bunch of (I think) required libraries:

dom4j.jar
ejb3-persistence.jar
hibernate-core.jar
slf4j-api.jar
slf4j-log4j12.jar

which fixed one problem... but led to another new error:

Caused by: java.lang.NoSuchFieldError: TRACE

The problem here seems to be that I need log4j.jar to be of version 1.2.12 or higher. (I've got 1.2.11 - missed it by that much!)

Having upgraded to log4j-1.2.15 that fixed that problem - but, a new one was waiting for me:

Caused by: java.lang.NoClassDefFoundError: org/apache/commons/collections/map/LRUMapat org.hibernate.util.SimpleMRUCache.init(SimpleMRUCache.java:71)

I realized (following a bit of reading I probably should have done right at the start!) that I needed to upgrade not just the hibernate-annotations, but also the hibernate core packages themselves to be compatible with the new annotations.

I downloaded the hibernate-distribution-3.3.0.SP1-dist.tar.gz file (something I probably should have done right from the start).

With Hibernate and Hibernate Annotations both updated, everything worked just fine.

The Moral of the Story: Check the dependencies when you upgrade one part of a system and make sure you read the documentation!

Now... I won't make that mistake again (not a guarantee!)

@Transient Annotation and Generics in Hibernate Superclasses

I'm working with Hibernate Annotations, and have a transient field in one of my entity superclasses that is mapped as @MappedSuperclass. That is:

@MappedSuperclass
public abstract class MyEntity<T extends MyEntity<T>> implements Serializable {
@Transient
protected Class<T> domainClass = getDomainClass();

This is throwing the following error:

org.hibernate.AnnotationException: Property my.entity.MyClass.domainClass has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type

I found the following Hibernate bug report that seems to refer to the same problem, and indicated it is a bug in Hibernate:

http://opensource.atlassian.com/projects/hibernate/browse/ANN-698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

This bug was recently fixed. Seeing as I've been using Hibernate 3.3, I decided to upgrade to Hibernate Annotations 3.4 to fix this.

It worked! Just thought I'd mention this as a fix to that problem, in case others have it.

PS: Sounds easy, huh ?- but I did have some issues with changing to Hibernate Annotations 3.4 which you can read about here.

@Entity annotations

I've just been scratching my head, attempting to figure out why some of my Java classes, marked with the @Entity annotation, weren't being generated (by Hibernate) as tables in my database.

They were correctly included in my hibernate.cfg.xml file with mappings:

<mapping class="mypackage.entity.myclass" />

However, while most of my classes were being correctly generated, some were not.

It turns out that in the classes which were failing, I'd accidently imported org.hibernate.annotations.Entity rather than the correct class (javax.persistence.Entity)

I guess this is a pretty easy trap to fall into - especially if you're using nice editor features (like the myEclipse "organize imports" plugin) and not paying sufficient attention (I did it once in a template and then copied this to a bunch of other locations!). Once done it can be kinda hard to see what isn't right .. Of course, the documentation is clear when it states:

"Note: @javax.persistence.Entity is still mandatory, @org.hibernate.annotations.Entity is not a replacement. "

Oooops...

Hibernate and SQL keyword Column Names

I have recently experienced some problems with Hibernate and the generation of SQL Tables. I am using Hibernate Annotations, and some of my entities have annotations that look something like:

@Column(nullable = false)
String myProperty;

@Column
@Temporal(TemporalType.TIMESTAMP)
@GeneratedValue(strategy = GenerationType.AUTO)
Date timestamp;

@Column
boolean insert;

@Column
boolean update;

@Column
boolean delete;

The problem is that Hibernate is throwing the following errors:

DEBUG [org.hibernate.tool.hbm2ddl.SchemaUpdate] - <create table MyTable (id bigint not null auto_increment, modifyingUsername varchar(255) not null, timestamp datetime, insert bit, update bit, delete bit, primary key (id))>

ERROR [org.hibernate.tool.hbm2ddl.SchemaUpdate] - <Unsuccessful: create table TextMetaDataHistory (id bigint not null auto_increment, modifyingUsername varchar(255) not null, timestamp datetime, insert bit, update bit, delete bit,primary key (id))>

ERROR [org.hibernate.tool.hbm2ddl.SchemaUpdate] - <Syntax error or access violation message from server: "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'insert bit, update bit, delete bit' at line 1">

Upon further investigation, it seems the problem is with the SQL that Hibernate is generating. Unfortunately some of my Java variable names (such as "timestamp", "insert", "update" and "delete") are themselves SQL keywords.

The Debug information above shows that the SQL being generated is not correct SQL syntax. In particular, if you type in MySQL:

create table MyTable (id bigint not null auto_increment, modifyingUsername varchar(255) not null, timestamp datetime, insert bit, update bit, delete bit, primary key (id))

you'll get an error.

If you manually edit this so it, instead, reads:

create table MyTable (id bigint not null auto_increment, modifyingUsername varchar(255) not null, `timestamp` datetime, `insert` bit, `update` bit, `delete` bit, primary key (id))

the SQL will run beautifully. All I've done here is insert quotes (the "`" quote, which is found on a standard keyboard above Tab, and using Shift on this key produces "~").

All I need to do now is work out how to get Hibernate to generate SQL with this included!!!
More news soon... (I hope!)

Update: Ok, so I decided, in the end, to fix this just by manually changing my Hibernate annotations to give an explicit name for each "questionable" column that includes the quotes. Thus the modified annotations are now:

@Column(name="`timestamp`")
@Temporal(TemporalType.TIMESTAMP)
@GeneratedValue(strategy = GenerationType.AUTO)
Date timestamp;

@Column(name="`insert`")
boolean insert;

@Column(name="`update`")
boolean update;

@Column(name="`delete`")
boolean delete;

NB: The "`" quote I'm using is the one above on a US keyboard, sharing the key with "~". Other quotation marks didn't work for me.

This now works - but it does seem unusual that I have to do this. I'm surprised Hibernate doesn't do this automatically for all Column names to avoid such "keyword" problems. Having said that, some "newbie" Hibernate users who have experienced similar problems, have suggested modifying Hibernate to do this, and the response from more experienced Hibernate programmers in at least one case was "Read the manual - stop wasting time" or something to that effect. Makes me wonder if I'm missing something in proposing this solution?

If you know of a better way to fix this problem, please post a comment on this blog! In the meantime, using the @Column(name="`whatever`") annotation is fixing my immediate problem, and doesn't seem to have any bad side effects, so I'll just stick with it!



PS: By the way, to get Hibernate to log the SQL it was using, I set:

log4j.logger.org.hibernate=debug

in the log4j.properties file I'm using..

Incorrect Version of ehcache

Within a web application I'm currently working on, I've just added the Hibernate entity mappings into the hibernate.cfg.xml file. These look something like:

<mapping class="project.entity.MyClass" />

and follow a cache configuration line that says:

<property name="cache.use_second_level_cache">true</property>
<property name="hibernate.cache.provider_class">
net.sf.ehcache.hibernate.SingletonEhCacheProvider
</property>

However, when I launch Tomcat, I get the following errors:


org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'sessionFactory' defined in ServletContext resource [/WEB-INF/bean-defs-6-session.xml]: Invocation of init method failed; nested exception is java.lang.NoSuchMethodError: net.sf.ehcache.CacheManager.getEhcache(Ljava/lang/String;)Lnet/sf/ehcache/Ehcache;
Caused by:
java.lang.NoSuchMethodError: net.sf.ehcache.CacheManager.getEhcache(Ljava/lang/String;)Lnet/sf/ehcache/Ehcache;
at net.sf.ehcache.hibernate.SingletonEhCacheProvider.buildCache(SingletonEhCacheProvider.java:89)
at ...

It turns out that the application is using an old version of ehcache.jar. Further investigation revealed that the reason for this is that the MyEclipse "Hibernate 3.1 Core Libraries" includes a copy of "ehcache-1.1.jar". Even though I had "ehcache-1.3.0.jar" included as a project library (and even changed its order above the Hibernate Core Libraries in the "Order and Export" tab), the application was still defaulting to the ehcache-1.1.jar version.

To fix this, I removed the Hibernate 3.1 Core Libraries from the project libraries. (Subsequently you can add it back in, if you want, as it will now be below the ehcache-1.3.0.jar so the correct version of ehcache will now be used, if you need other bits from the Hibernate 3.1 Core libraries).

Defining DAO Objects

A little while back in an earlier blog post I mentioned a web application I've been developing which uses Hibernate Annotations and Spring MVC.

As mentioned then, the framework I'm using is based on one described in this tutorial.

In the section of this tutorial that discusses defining the DAOs (Database Access Objects) it suggests creating your DAOs using code that looks like:

<bean id="daoTmpl">
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>

<bean id="myObjectDao" class="org.annotationmvc.dao.MyObjectDaoTmpl" parent="daoTmpl" />

A similar pattern is repeated in a number of other locations on the internet, suggesting using a daoTmpl bean so you don't have to include the sessionFactory object individually in each one of your DAOs.

This is great advice, but in every case you get an error something like:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'daoTmpl' defined in ServletContext resource [/WEB-INF/bean-defs-5-dao.xml]: Instantiation of bean failed; nested exception is java.lang.IllegalStateException: No bean class specified on bean definition
Caused by:
java.lang.IllegalStateException: No bean class specified on bean definition

The problem is that you can only define a bean without a class if you declare it as abstract. To do this, change the bean definition to:

<bean id="daoTmpl" abstract="true" >
<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>

and it will work as expected.

Hibernate Inheritance Mapping Strategies

If you've played with Hibernate for a while, one thing you'll really appreciate is how it helps you avoid the "object/relational mapping" paradigm mismatch.

Now, this is great, because it frees you up to focus on getting your object hierarchy / object models right, without (too much) focus on the underlying persistence layer. However, this doesn't come completely for free.

Inheritence is one area where the mistmatch between object-oriented and relational world becomes particularly visible. What this means is that you have to undertake some thought when it comes to mapping classes to tables, in the case where the classes exhibit inheritence.

A number of references (for instances, I read about this in Chapter 3 of the excellent book "Hibernate In Action") talk about the "three different approaches to representing an inheritance hierarchy", as classified in a paper "Mapping Ojects to Relational Databases" by Scott Ambler in 2002. These are:

• Table per concrete Class ("Table per class") - One table is used for each (non-abstract) class.
• Table per class hierarchy ("Single table per class hierarchy") - One table is used to map an entire class hierarchy.
• Table per subclass ("Joined subclasses")- One table is used for every subclass (including abstract classes and interfaces). These only contain columns for the non-inherited properties.

Each of these is mapped (using Hibernate annotations) using the @Inheritance annotations. That is, @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS), @Inheritance(strategy=InheritanceType.SINGLE_TABLE) and @Inheritance(strategy=InheritanceType.JOINED) respectively.

However, recently I found about another way of handling inheritance in my object model being mapped to the persistence layer. It is useful for the case where you have a superclass that does not need to have any corresponding tables in the underlying database, and does not need to be queryable. In this case, a superclass can be annotated with the @MappedSuperclass annotation.

I thought I should mention this, as most of the information about the three strategies for inheritance doesn't seem to mention this as a "fourth" option - probably because in this case the superclass is not actually an entity.

In fact, I had a bit of difficulty understanding the difference between @MappedSuperclass and the @Inheritance(strategy=InheritanceType.TABLE_PER_CLASS) strategy. They are, in fact, very similar.

@MappedSuperclass reference states:

"A mapped superclass designates a class whose mapping information is applied to the entities that inherit from it. A mapped superclass has no separate table defined for it."

So, the MappedSuperclass annotation is similar to "table per class" inheritance, but (the difference is) it does not allow querying, persisting or relationships to the superclass. Table per class does allow these (but, if I understand correctly, is fairly inefficient at these compared to the other two inheritance strategies.)

Thus:

• Mapped superclasses can't be targets of entity relationships
• They can be either abstract or concrete. (Some references suggest that a mapped superclass normally should be an abstract class).
• A mapped superclass is not an Entity

More information on these can be found at http://en.wikibooks.org/wiki/Java_Persistence/Inheritance#Mapped_Superclasses

The advantage of using MappedSperclass annotation for me, at this time, is that it seems the simplest approach if I don't want the superclass to be queried or relationships going directly to it. For the top level of my hierarchy this seems to be a good way to go.