You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Neale Rudd <ne...@metawerx.net> on 2012/02/27 09:38:03 UTC
Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0 plus
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
JdbcUrl jdbc:mysql://DATABASE_SERVER:PORT/USERNAME
UserName USERNAME
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
http://www.metawerx.net
Re: Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0 plus
Posted by Romain Manni-Bucau <rm...@gmail.com>.
think the jndi page only show EJBs.
it is inherited from JEE5 where jndi was contextual that's probably the
reason.
- Romain
2012/3/6 Neale Rudd <ne...@metawerx.net>
> Hi Afryer,
>
> Thanks, I tried the META-INF/resources.xml approach, but no luck there
> either. I still can't get the datasource recognised except via openejb.xml
> so far.
>
> Also when I browse JNDI with the openejb app, I can't see the JNDI
> resource defined in context.xml or resources.xml, or the one from
> openejb.xml (which is working). A bunch of beans from the app show up
> though.
>
> Why doesn't the JNDI browser show the JNDI resources from openejb.xml?
>
> I might try enumerating the JNDI space with a separate app and see what I
> can find.
>
> Best Regards,
> Neale
>
Re: Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0 plus
Posted by Neale Rudd <ne...@metawerx.net>.
Hi Afryer,
Thanks, I tried the META-INF/resources.xml approach, but no luck there
either. I still can't get the datasource recognised except via openejb.xml
so far.
Also when I browse JNDI with the openejb app, I can't see the JNDI resource
defined in context.xml or resources.xml, or the one from openejb.xml (which
is working). A bunch of beans from the app show up though.
Why doesn't the JNDI browser show the JNDI resources from openejb.xml?
I might try enumerating the JNDI space with a separate app and see what I
can find.
Best Regards,
Neale
Re: Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0
plus
Posted by afryer <ap...@hotmail.com>.
I had an issue with JSPs failing to recompile with 4.0.0-beta1 described
http://openejb.979440.n4.nabble.com/openejb-overwrites-tomcat-conf-web-xml-JspServlet-lt-development-gt-parameter-value-td4213081.html#a4216277
here . The issue was caused by openejb overwriting the web.xml file with
its own version so no matter what values you changed, they were overwritten.
This is fixed in beta2.
For the datasource, you can always deploy a META-INF/resources.xml with you
app to have openejb create Jta managed datasources that get used by
persistence units.
--
View this message in context: http://openejb.979440.n4.nabble.com/Findings-from-moving-a-Tomcat-7-0-26-app-to-TomEE-beta-1-0-0-plus-tp4423955p4426616.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0
plus
Posted by zmirc <m_...@yahoo.com>.
Thank you so much Neale Rudd.
I had the same error "user lacks privilege or object not found:" with Tomee
1.5.2.
Adding the resource in tomee.xml fixed it.
I have to mention that this app worked perfectly on Tomcat, but on Tomee I
got this error. Why is this necessary? Shouldn't moving from Tomcat to Tomee
require no modifications?
--
View this message in context: http://openejb.979440.n4.nabble.com/Findings-from-moving-a-Tomcat-7-0-26-app-to-TomEE-beta-1-0-0-plus-tp4423955p4663447.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0 plus
Posted by Neale Rudd <ne...@metawerx.net>.
Hi Romain,
> 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
> https://issues.apache.org/jira/browse/TOMEE
Figured this one out with a bit of JNDI browsing. The customer had a
resource ref in web.xml which had the same name as the resource in
context.xml.
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/JNDINAME</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
This over-rode the context.xml resource, so that now only this one existed
in java:comp/env/jdbc (it gets added to the tree after the context.xml one).
In this case, TomEE looks in openejb.xml for it and will match it if found
by name, or if not found, as you describe above, it uses the first database
found (making it the default).
One weird thing I found though was that restarting the application did not
remove the resource-ref from JNDI. It appears the JNDI directory is not
cleaned up on application destroy. This can be demonstrated by adding a
resource-ref, reloading, changing the res-ref-name, reloading, then looking
at java:comp/env/jdbc - you'll see multiple entries in there. They vanish
after the VM is restarted of course.
Best Regards,
Neale Rudd
Metawerx Pty Ltd
http://www.metawerx.net
Re: Findings from moving a Tomcat 7.0.26 app to TomEE beta 1.0.0 plus
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hu,
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
https://issues.apache.org/jira/browse/TOMEE
hope it helped
- Romain
2012/2/27 Neale Rudd <ne...@metawerx.net>
> 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
> JdbcUrl jdbc:mysql://DATABASE_SERVER:**PORT/USERNAME
> UserName USERNAME
> 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
> http://www.metawerx.net
>
>