TomEE is of course able to reuse Tomcat realms but one limitation of Tomcat is the need to provide it in the container (understand it is not designed to be provided in the webapp).
TomEE proposes a small tip regarding this topic.
TomEE is of course able to reuse Tomcat realms but one limitation of Tomcat is the need to provide it in the container (understand it is not designed to be provided in the webapp).
TomEE proposes a small tip regarding this topic.
TomEE is using quartz to implement @Schedule
methods. At the beginning quartz was hidden and its configuration was not exposed.
Since some days it is no more the case!
Getting SQL queries is particularly important to identify potential bottlenecks and understand what is doing an application.
We often use external tools like jamon, slf4j-jdbc and so on to get this information.
There are two main drawbacks:
That’s why in OpenEJB and TomEE we added a property LogSql which simply logs all queries, no need of hard configuration, that’s just a boolean.
JPA is great but it doesn’t manage a standard way to add a prefix to database tables out of the box.
All (known) vendors have some hooks to do so but that’s not obvious or specified. For hibernate you have to play with NamingStrategy, with OpenJPA you either define a custom DBDictionary or a NamingDefaults and with EclipseLink you have to implement a SessionCustomizer and play with eclipselink model.
That’s why in OpenEJB and TomEE we started to work on it.
Pooling its datasource connection in a real application is very important to respect its SLA.
OpenEJB (and by the way TomEE) uses commons-dbcp since many years. It works well if well configured, but suffers from an old design. What’s more, some other libraries are today interesting and are good alternatives.
Two famous of them are tomcat-jdbc (a fork from commons-dbcp) and BoneCP. Both promises great performances (particulary in high load).
Many refactoring has been done in OpenEJB to allow switching pool library keeping the JTA management (supported by commons-dbcp but no others). The result is mainly a “magic” abstract class called org.apache.openejb.resource.jdbc.pool.PoolDataSourceCreator. Its API obliges you to implement a way to pool a provided datasource, to create a pooled datasource and to destroy what you created.
But in a user life, you don’t need it, and you can simply use what is already done through configuration :).