JVMXM008 workaround

Brian D. Carlstrom wrote:

At Stanford I have my own automated regression infrastructure that runs processor simulations remotely via ssh. One problem that has existed for months is this error from jbuild.linkImage:

JVMXM008: Error occured while initialising System ClassException in thread “main” Could not create the Java virtual machine.

I noticed that Sergiy Kyrylkov had posted in his blog about a similar issue when running JikesRVM regressions from cron:


I found that if I forced the ssh remote bash to be a login shell, I did not get the error. Eventually I narrowed it down to the fact that /etc/profile was sourcing /etc/profile.d/lang.sh which was setting the LANG environment variable. I found that if I my remote command set LANG explicitly, I can build jikesrvm over ssh without the JVMXM008 error.

I just wanted to post the workaround to the list in case it helps someone else. I don’t know if it is needed for later SDKs, but my version of JikesRVM seems to only work with 1.4.1, nothing earlier, nothing later.

For the record, this is on Fedora Core 4 on G5 machines running IBM’s SDK 1.4.1-SR2 with a jikesrvm source tree from last updated at “2005-12-09 03:00:00”. We are frozen until after some paper deadlines this month…
I hope I’ll have time soon to try this workaround on UNM machines.

org.hibernate.HibernateException: Wrong column type

If you are getting the following exception:

org.hibernate.HibernateException: Wrong column type...

when Hibernate 3.1 validates your MySQL 4.1 database schema using

<property name="hbm2ddl.auto">validate</property>

in your hibernate.cfg.xml check whether you have custom sql-type in your Hibernate mappings and whether it is written in lower case as in example below (sql-type="mediumblob"):

<component name="photo" class="com.example.sample.model.user.BinaryData">
<property name="data" type="binary">
<column name="PHOTO_DATA" sql-type="mediumblob"/>
<property name="name" column="PHOTO_NAME" type="string" />
<property name="contentType" column="PHOTO_CONTENT_TYPE" type="string" />

The exception

org.hibernate.HibernateException: Wrong column type: PHOTO_DATA, expected: MEDIUMBLOB
at org.hibernate.mapping.Table.validateColumns(Table.java:219)
at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:964)
at org.hibernate.tool.hbm2ddl.SchemaValidator.validate(SchemaValidator.java:116)
at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:296)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1154)
at com.sac.ta.util.HibernateUtil.(HibernateUtil.java:91)
at com.sac.ta.util.HibernateListener.contextInitialized(HibernateListener.java:32)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3692)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4127)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:910)
at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:873)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
at org.apache.catalina.core.StandardService.start(StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
at org.apache.catalina.startup.Catalina.start(Catalina.java:536)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

happens if you use upper case instead of (sql-type="MEDIUMBLOB"):

<component name="photo" class="com.mpxsys.sample.model.user.BinaryData">
<property name="data" type="binary">
<column name="PHOTO_DATA" sql-type="MEDIUMBLOB"/>
<property name="name" column="PHOTO_NAME" type="string" />
<property name="contentType" column="PHOTO_CONTENT_TYPE" type="string" />

java.lang.NoSuchMethodError getHibernateLazyInitializer()

We seem to be affected by java.lang.NoSuchMethodError problem described more in Hibernate forum and Hibernate Jira.

The solution that works for us is switching to the server VM using -server switch while starting Tomcat. It works for our production VM, which is:
java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Server VM (build 1.5.0_06-b05, mixed mode)

Hibernate lazy fetching with Tapestry 3.x

The best references for Hibernate lazy fetching with Tapestry are Open Session in View pattern and, if you use Hibernate 3.1, generic DAO pattern with the latest Caveat Emptor constantly updated for Hibernate in Action 2nd edition, covering Hibernate 3.0 and 3.1

It is up to you to choose between session-per-request and session-per-conversation approach, but with a single servlet filter and generic DAO pattern you’ll have Hibernate transparently working with as few lines of code as possible, as far as I know.

For example, the only thing you’ll have to handle manually in case of session-per-request(which you want to do anyway to minimize the possibility of stale data) is (re)loading objects by IDs on every request, which can be achieved with pageBeginRender listener:

public abstract class PublicationViewPage extends BasePage implements
  PageRenderListener {
    public abstract void setPublicationID(long publicationID);
    public abstract void setPublication(Publication publication);
    public void pageBeginRender(PageEvent event) {
      if (!event.getRequestCycle().isRewinding()) {
        PublicationDAO publicationDAO = DAOFactory.DEFAULT.getPublicationDAO();
        Publication publication = publicationDAO.findById(getPublicationID(), false);

assuming the ID of the data item to be displayed (Publication in my example) was set in the previous page:

public abstract class PublicationListPage extends BasePage implements
  PageRenderListener {
    public void selectPublication(IRequestCycle requestCycle) {
      Object[] parameters = requestCycle.getServiceParameters();
      Long publicationID = (Long)parameters[0];
      PublicationViewPage publicationViewPage = (PublicationViewPage)requestCycle.getPage("PublicationView");

Blojsom short URL's with Apache httpd and Tomcat

Probably there are not many people who like the way default Blojsom URLs look:


The easiest way to remedy this situation is to use standard Apache HTTP proxy by adding the following lines into your Apache conf file (be it httpd.conf or
something else):

ProxyPass /blog http://localhost:8082/blojsom/blog/default/
ProxyPassReverse /blog http://localhost:8082/blojsom/blog/default/<

ProxyPass /blojsom http://localhost:8082/blojsom
ProxyPassReverse /blojsom http://localhost:8082/blojsom

The only thing that needs to be adjusted in Blojsom itself in order for this to work is Blog URL in Weblog Setttings->Properties

Blog URL: http://localhost/blog/

Also be sure that your Proxied HTTP/1.1 Connector on port 8082 is enabled in your Tomcat in server.xml (Tomcat 5.5.x in the excerpt below):

<Connector port="8082"
  maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
  enableLookups="false" acceptCount="100" connectionTimeout="20000"
  proxyPort="80" disableUploadTimeout="true"
  proxyName="localhost" />

After these changes you can use:


as the address of your blog.

Can't write to a readonly object with Hibernate read-only second-level cache

If you enabled read-only second-level cache in Hibernate and have the following error:

Stack Trace:
* org.hibernate.cache.ReadOnlyCache.lock(ReadOnlyCache.java:43)
* org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:69)
* org.hibernate.engine.ActionQueue.execute(ActionQueue.java:239)
* org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:223)
* org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:137)
* org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:274)
* org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
* org.hibernate.impl.SessionImpl.flush(SessionImpl.java:730)
* org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:324)
* org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:86)

which also shows up in Eclipse like this:

ERROR org.hibernate.cache.ReadOnlyCache : Application attempted to edit read only item

Check that your Hibernate class mapping has mutable="false", which prevents Hibernate from issuing updates for already existing instances. Here is a link to my Hibernate Forums thread about this problem.