tomee-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <>
Subject Re: Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0 plus
Date Mon, 27 Feb 2012 09:04:47 GMT

1. it is to be spec compliant that dev is not the default mode
2. you can customize it, personally i like the default behavior since it
stays easy in dev mode and is often ok in prod mode
3. if your database if not correct, can't be created or is not found a
default one (the one you found in default openejb conf) will be used.
Normally we read context.xml in <your-webapp>/META-INF/context.xml. If you
manage to reproduce it in a simple test please create a jira here

hope it helped

- Romain

2012/2/27 Neale Rudd <>

> 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 again.
>   <init-param>
>           <param-name>checkInterval</**param-name>
>           <param-value>2</param-value>
>   </init-param>
> 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"?>
> <Context>
>   <Realm className="org.apache.**catalina.realm.LockOutRealm">
>       <Realm className="org.apache.**catalina.realm.MemoryRealm"
>           pathname="${catalina.base}/**conf/tomcat-users.xml" />
>   </Realm>
> </Context>
> Define container-managed security by adding the following to
> /openejb/WEB-INF/web.xml:
> <security-role>
>   <role-name>manager</role-name>
> </security-role>
> <security-constraint>
>   <display-name>Security constraint for the openejb app</display-name>
>   <web-resource-collection>
>       <web-resource-name>TomEE</web-**resource-name>
>       <url-pattern>/*</url-pattern>
>   </web-resource-collection>
>   <auth-constraint>
>       <role-name>manager</role-name>
>   </auth-constraint>
> </security-constraint>
> <login-config>
>   <auth-method>BASIC</auth-**method>
>   <realm-name>Secure Area</realm-name>
> </login-config>
> 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
> section.
> 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
> Code:
> <sql:query var="categories" dataSource="jdbc/**myJndiDatabase">
>    SELECT * FROM categories
> </sql:query>
> 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
> correctly.
> <Resource id="myJndiDatabase" type="DataSource">
> JdbcDriver com.mysql.jdbc.Driver
> Password PASSWORD
> JtaManaged false
> </Resource>
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message