tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neale Rudd" <>
Subject Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0 plus
Date Mon, 27 Feb 2012 08:38:03 GMT
Hi Guys,

Just joined the list, nice to meet you all.

We host a series of Tomcat and JBoss VMs and that's our key business area. 
We're planning on starting hosting for TomEE within the next week, and have 
had a couple of minor issues getting started so I thought I'd mention them.

As our first TomEE instance, we used a Tomcat 7.0.26 customer who has 
started using EJB's and enquired if we supported TomEE or Glassfish.  It's a 
simple application, with a JNDI datasource lookup from META-INF/context.xml

Here's a list of the issues and patches we had to provide to get the TomEE 
(beta2-1.0.0-plus) instance working nicely.  Please bear in mind this is our 
first TomEE instance, so if some of the below are caused by the EE spec, 
please let us know and ignore them.

The changes were quite minor, so great work!

1. JSPs were not being automatically recompiled, this is different behaviour 
to our standard Tomcat 7 installation.

/conf/web.xml declares the JSP servlet which handles jsps. 
development=true, modificationTestInterval=4 are supposed to be the 
defaults, but for some reason JSPs were not recompiling dynamically.  We set 
checkInterval in the JSP servlet declaration and they started recompiling 


Would TomEE be interfering with the JSP servlet somewhere?  Perhaps it's a 
problem with Tomcat 7.0.21 used by TomEE beta 1.0.0?

2. The openejb application is not locked down to public access.  For the 
openejb.war download, this is documented as being locked down by a valve, 
but in the TomEE download, the valve is commented out in 
META-INF/context.xml.  For a hosted environment, locking down to a 
username/password is more useful than to a local IP address, so I'd like to 
suggest the following patch which makes the /openejb use roughly the same 
security as the /manager app:

Replace /openejb/META-INF/context.xml with the following (or add the realm):

<?xml version="1.0" encoding="UTF-8"?>
    <Realm className="org.apache.catalina.realm.LockOutRealm">
        <Realm className="org.apache.catalina.realm.MemoryRealm"
            pathname="${catalina.base}/conf/tomcat-users.xml" />

Define container-managed security by adding the following to 


    <display-name>Security constraint for the openejb app</display-name>

    <realm-name>Secure Area</realm-name>

This gives the same HTTP Auth protection as the standard /manager servlet, 
and uses the same tomcat-users.xml file from the conf folder.

3. For the customer's application, the MySQL JNDI datasource from the 
META-INF/context.xml was ignored, and for some reason the application tried 
to access an HSQLDB datasource which we didn't define anywhere.  We tracked 
down that it seemed to be trying to use the one defined in openejb.xml, even 
though the JNDI name was different.

It seems to be accessing a "default JDBC datasource" when the JNDI-name is 
undefined.  If this is standard EE behaviour, then please ignore this 

Instead of a missing JNDI reference error, we got a database error from this 
default database:
javax.servlet.ServletException: javax.servlet.jsp.JspException:
    SELECT * FROM some_table
: user lacks privilege or object not found: PRODUCT_CATEGORIES

 <sql:query var="categories" dataSource="jdbc/myJndiDatabase">
     SELECT * FROM categories

The JNDI name (jdbc/myJndiDatabase) for this resource is not a standard name 
so I can't see where it's deciding to use a default datasource instead of 
throwing an error.  The datasource from META-INF/context.xml seems to be 
ignored in TomEE where it works fine in Tomcat.  This seems to be insecure 
behaviour as accessing a "default" database, could potentially insert 
confidential information into that database by mistake.

We added the resource in openejb.xml and it now accesses that database 

<Resource id="myJndiDatabase" type="DataSource">
 JdbcDriver com.mysql.jdbc.Driver
 Password PASSWORD
 JtaManaged false

Other than that, everything is running fine!  It took about 30 minutes to 
convert the application from a standard Tomcat 7 app to run on TomEE with 
the above changes.

So great work guys, and keep it up!

Best Regards,
Neale Rudd
Metawerx Pty Ltd

View raw message