Tomcat Extended

Talking TomEE with David Blevins

Chris Mayer

From November’s JAX Magazine, we sat down with TomEE’s David Blevins to discuss the project that takes Tomcat one step further for this generation’s applications.

From November’s
JAX Magazine
, we sat down with TomEE’s David Blevins to discuss
the project that takes Tomcat one step further for this
generation’s applications.

JAX: Best place to start I guess, what
is TomEE,
what was the thinking behind starting it and what problems does it
set out to solve?

Blevins: TomEE is the Java EE version of Tomcat.
 The idea was there and many people have wanted to see Tomcat
go beyond just servlets for quite some time.  If you trace the
origins of TomEE, you can go as back as far as the early 2000s with
the OpenEJB Tomcat stack which is also where the EJBs in WARs
feature of Java EE 6 originates. The EJB 3.1 Embedded EJB Container
API comes from there as well. The thing that finally made TomEE
possible, though, was the addition of the Web Profile to Java EE

JAX: So was it feasible or way off at
that point?

Creating TomEE was incredibly difficult. Having
implemented Full Profile EE servers for over 10 years, I knew it
was going to be hard even with some of the legacy parts of Java EE
cut out and not in the Web Profile. Once we dropped the basic
parts, we were still only 40% there. It took almost a year to fill
those gaps. It doesn’t take a lot of code, but it takes the right
code. I think part of the real value of TomEE is that we have put
so much work into the completeness of the integration and have done
it in an incredibly simple and direct way.

JAX: Can you outline the main parts that
go into TomEE?

TomEE includes all of the Web Profile
technologies, all of which are very relevant. Just to list them
off, beyond Servlets and JSP we have JSF, CDI, JPA, JTA, EJB Lite
and Bean Validation. That’s the core. They’re all incredibly
important. I think actually of all the technologies, Bean
Validation tends to get the least buzz [about it], but it’s perhaps
the most relevant to every single one of those specifications. If
you’re using JPA, you need Bean Validation.

JAX: So it’s something developers might
take for granted I guess?

Yes, definitely. It’s not a large API, but it’s
definitely important. Validation is as important to data as unit
testing is to code. With all the focus there is on testing, there
really needs to be an equal focus on valid data.

JAX: Was CDI an absolute must for your
team for the main release?

We all saw it as critical. CDI is a very
compelling technology. It’s essentially the new integration layer
for Java EE and in a lot of ways it obsoletes EJB. At the Java EE
level, we’re moving more and more onto CDI.

JAX: There’s obviously a heavy reliance
on Tomcat – taking onboard its good points and moving beyond it.
How close are the ties between TomEE and other

All the projects are at Apache and the ecosystem
there is very close. We all collaborate quite a bit. When we put
out a TomEE announcement, we have people from Tomcat, MyFaces and
OpenWebBeans all chipping in and helping. It’s definitely a good
community. In technical terms, though, the way Tomcat has been
written means that we need almost nothing to be added or changed in
Tomcat itself to make TomEE possible, which is a really good
testament to that project.

JAX: So it’s refinement

I’d describe TomEE as an extension of Tomcat.
The Tomcat architecture is pretty amazing when you think how old it
is, it was really ahead of its time. It is very much an event-based
architecture and it was through that event-based architecture that
we were able to make these great extensions to how things are
deployed, started and stopped. We didn’t have to change anything
architecturally. We just followed the path that was laid out there.
Hats off to Tomcat for having that really flexible

JAX: So what does it allow you to do
that regular Tomcat doesn’t then? What scenarios does thrive

In terms of what Tomcat offers out of the box,
it’s about 2/7ths of the Web Profile. So there are a significant
number of extra technologies in TomEE. These are the typical
technologies that people usually add themselves. I think that TomEE
thrives in any scenario that involves Tomcat and the reason is
because often you start out with Tomcat installed and then the
first thing you do is you go to build it to be more than

JAX: And if the extra stuff is there,
there’s no need to go hunting?

Exactly. From day one there is a better

Adding these things as you go can cause several
problems. The first one is it can be a huge waste of time. You
start with a basic Servlet app and now you want to persist some
data to a database. So now you need to add a JPA provider. That one
is easy, but then every time you learn about a new bit of
technology, it becomes harder and harder. Say you want to add CDI,
but you don’t know much about it so you have to both learn CDI and
how to integrate CDI into Tomcat and with all your other libraries
at the same time. So you’re coupling learning about a technology
with integrating that technology. Having to integrate a technology
you know nothing about is a terrible position to be in. You might
get something working, but you don’t really know if that’s the way
it should work and every time you run into a problem you don’t know
if the problem comes from not integrating it properly or if it is
an actual bug or if you’re misunderstanding completely and
expecting the technology to do something it isn’t supposed to do.
It’s an incredibly frustrating position to be in. We then repeat
this on every new technology we want to add to our application.

We’re all mature enough to know that we don’t
“just use servlets”, as if the only useful Java APIs have already
been created and everything that came after is all stuff no one
ever uses. As if the average war file doesn’t have a ton of
additional libraries in it. These days even new war files are
packed with a ton of libraries we know we’ll need even before we’ve
written a line of real code.

Second, just because you add a library to a webapp and can get
some use of it, doesn’t mean it is fully integrated. For example
you can’t drop CXF into Tomcat and expect Web Services security to
work with the Servlet security. You can’t drop OpenJPA into Tomcat
and expect JTA-managed EntityManagers to work. CDI, for example,
has a strong integration focus, but even if you drop OpenWebBeans
into Tomcat you’ve still only got 60% of what that spec has to
offer. CDI injection is not going to work on your Web Service,
because they’re different technologies.

So again, you’re back to Googling, writing integration code and
solving this problem as if no one’s ever solved it before. As the
number of useful Java technologies the industry has to offer grows,
it just becomes harder and harder to do it yourself and keep
everything consistent.

Then there are performance considerations to be had. APIs do a
tremendous amount of scanning do these days, which involves reading
every single class file in an application looking for annotation
declared components. Tomcat will scan your entire Web app for
servlets, listeners and filters. Then if you add MyFaces it will
scan your entire Web app for manage beans. Now it’s scanned twice.
Then you throw OpenWebBeans in there and now it’s going to get
scanned a third time. You throw OpenJPA in there and it’s going to
scan your webapp a fourth time looking for entity beans. Throw CXF
in there and now CXF is going to scan your entire Web app for Web

It’s incredibly wasteful, it’s not quick. Not only has the
number of scans gone up but the amount of jars that have to be
scanned has gone up. OpenWebBeans is going to scan MyFaces, OpenJPA
and CXF. And CXF is going to scan OpenJPA, MyFaces and OpenWebBeans

JAX: Wow. That’s a bit time

It’s not entirely efficient, no.

JAX: I think that’s fair to

These are some of the things we take care of in
TomEE. We scan once to the best of our ability, we share that
information with MyFaces, OpenWebBeans and Tomcat. We try to cut
the redundant scanning down much as possible. It’s not perfect and
we’re still going down that path, but we’re very far down it. It’s
certainly more than you’d get by just throwing those individual
specifications on Tomcat.

Another aspect is the level of testing we do as
we make improvements like these. I’m not sure how many tests other
people have for their Tomcat stacks, but I can say from a TomEE
perspective, we run hours and hours on TomEE every day because of
the very large compliance test suite that is the TCK, which all
certified implementations have to pass. If you do it in linear
time, it’s days of tests. If you break it up and parallelise it
like we do, it’s a couple of hours of tests but still a couple
hundred hours of machine time. That’s a significant level of
protection you’re getting knowing that everything you have in there
is complete and passes these set of tests. And you can get that in

JAX: Yeah, that is

It’s not a large tradeoff either. The really
critical thing we’re trying to do with TomEE is to not subtract
from the Tomcat experience, only add. It’s a difficult challenge
and we work extremely hard at it. We never claim perfection so if
you find something that ruined your Tomcat experience let us know
and we will fix it.


JAX: I remember seeing on the original
1.0 release, TomEE boasted that it was 300% faster. How was that

A lot of that was done through reduced scanning.
So, Confluence is about 200MB and 199 JARs. When we boosted the
performance, we didn’t get it tuning things using the approach
where we magically know what to skip. That would be unfair. When
someone in the wild throws a 200MB file at you, you don’t have the
luxury of knowing which parts of the Web app are important, which
ones aren’t and being able to tune accordingly. We just really
really revamped all the scanning code. We got the scan time alone
down from about 8 seconds to 2 seconds which really cuts down on
the overall deploy time. And then there was another round of
further tuning. It was just a lot of cranking on the bolts and
tightening of screws to get it into production shape for a final

JAX: You passed the Oracle TCK test,
which is quite the feat. How long did that take for a

Yeah. We started in about February 2011 with our
first full run of the TCK. We were probably about 20% compliant

JAX: Not a bad starting point there

We had a good head start with a lot of the parts
there already like EJB, JPA, JSF and obviously Servlets, JSP. But
CDI was in constant flux and in general there are a lot of things
you discover are missing features and hold you back from completing
large sections of the TCK. It’s all about filling in those gaps as
quickly as possible. From there, we were able to reach full
compliance by October. But it was close, we got our first pass at
the end of September. Maybe a week and a half before JavaOne. We
cut it so close.

JAX: Perfect timing though

We had our minds made up to make the JavaOne
date. It was an incredibly challenging goal for the community and
we really came together and made it happen.

JAX: I can imagine there were some late
nights around that period.

Many of us had really late nights and really
early mornings. I know myself, I was sleeping four hours a night
for several weeks. It didn’t stop until after JavaOne because once
you pass the test, you have file your paperwork, you’ve got to make
an announcement and get a release out the door and do it while
preparing for JavaOne. That particular year, I spoke at six
different talks, so I had a lot of material to produce. I don’t
think I really saw anybody at JavaOne (laughs). After that, I

JAX: Moving on to Java EE – what are
your thoughts about recent developments? Is it heading the right

Absolutely. I think that when Java EE 7 started
out, it was assumed we would want to do some cloud-based

JAX: Because of the move toward

Initially it was an obvious goal. But as we
developed and went further down that path, it became clear that we
weren’t ready to do that yet. The fact that there was enough
self-awareness shows it’s an astonishing victory for standards
because we all know what happens when things are standardised too
prematurely with a non-proven API.

We end up having an API that is a false start
and we have to figure how to bury it and supersede it with
something. It’s not a good position to be in and it’s not what’s
standards are supposed to do. The fact that we could perceive that
this was something that wasn’t ready to be standardised, I think is
exactly the kind of things that standard bodies should be doing. I
really compliment the group for doing that.

That said, there are a number of really cool
things being done in the various Expert Groups and being talked
about in Java EE 7. JMS 2.0 is going to be a really great part of
Java EE 7 as is JAX-RS 2.0. Then there are things coming from the
TomEE side as well. I had hoped that TomEE would be an important
contributor to the specifications in the same way OpenEJB was to
the EJB specifications. It’s looking like we’re going to be able to
add some neat things, or at least inspire some changes.

We have a proposal for revamping the Connector
Architecture and MDB relationship to handle modern APIs. Something
like JAX-RS could have been done via the Connector Architecture
with the right tweaks to that model. It sounds a little bit boring
on the surface, but imagine being able to create an expressive API
modelled like JAX-RS but for consuming email or exposing an SSH
interface or accepting Thrift requests and dropping that into any
certified Java EE server and having the components that accept
those requests just as integrated into the platform as Servlets,
EJBs or CDI beans are.

Another one of them is this concept of ‘meta-annotations’ we
introduced it at JAX London 2011. It’s a concept of broadening
annotation reuse consistently to the entire Java EE platform. These
concepts started popping up in various Java EE 6 specifications.
Bean Validation which allows for reuse of validation annotations on
other validation annotations. So say you add @NotNull on a bean
validation annotation, the new annotation implies @NotNull plus the
additional constraints it adds.

With CDI, there’s a similar concept called Stereotypes. If say
@Red is an annotation annotated with @Stereotype, @Named and
@RequestScoped or any other CDI aspect. Anywhere you use @Red it
implies that component is @RequestScoped and @Named. Now instead of
using all those annotations, you just use @Red.

This concept exists, but someone inconsistently
in various specifications and there is currently no ability to
reuse annotations that are standard annotations such as any of the
annotations from the Servlet, JPA, EJB, JSF, JAX-WS or any similar
APIs. The value of such reuse is only as powerful as the number of
annotations that allow reuse. Currently, that’s almost none.

JAX: Is that more a matter of time
before we see annotation reuse concepts occurring throughout Java
EE or does it need a push?

No, I think the push has been made now. Aside
from JAX London, I’ve presented afterwards at JavaOne 2011 and
2012. I’ll be presenting it again along with the Connector revamp
at W-JAX and Devoxx. I’ve also been working with various people
from other app servers on what would be the performance impact of
having this annotation reuse enabled all the time. We’ve already
had this implemented in TomEE back in 2011 and we found it to not
have a significant performance impact. As we’ve been working with
more people, they’ve found the same thing. So now it’s a question
of how we want to do this.

The current proposals on the table is that
@Stereotype would be what we proposed as @Metatype and would be the
annotation that would drive this annotation reuse. Then we would go
through and we would change all these Java EE annotations so they
could be applied to @Steretype and other annotations.

JAX: Good to hear. There was a TomEE 1.5
release recently – was that a case of listening to the community
and fixing a few things?

We received a flood of feedback from 1.0. So
much feedback it was difficult to close the lid and say no more
fixes. By the time we did close the lid, we had major new features
such as the JAX-RS certification, several of the new tools. The
textual description of the 1.5 release notes appears to be very
short but if you look at the actual change list, it’s difficult to
summarise it all. I would say usability, migration issues and
rounding off of sharp corners are all very strong aspects of the

JAX: What are the plans for TomEE moving
forward then, if you’re allowed to divulge in them?

I can speculate of course, but the community
sets the direction.

JAX: As any good project

Exactly. I’d personally like to see more of the
same things we’ve been doing. We need to continue to address
migration issues. We need to do more along the lines of helping
people find the right information to the problems they might
encounter. Very basic things like that. There is already a lot of
functionality within TomEE which we need to make more accessible
and known.

Continuing to do that is great. In terms of next
major things, obviously Java EE 7 is right around the corner.
That’s going to be Tomcat 8, Java 7 and will contain a lot of new
technologies. That will be an all consuming focus of the project a
year from now. Between now and then it’s about focusing on basics.
I know from experience that you only have very short windows
between major spec revisions to really focus on the fundamentals
before you have to go back into a very major
implementation/integration phase. We need to keep driving down the
path we’re on, filling out TomEE in terms of monitoring and other
types of production concepts and focusing on the fundamentals of
the server.

This interview first appeared in JAX
Magazine: JavaFX Revisited. Download that and other issues here.

comments powered by Disqus