Tomcat Extended

Talking TomEE with David Blevins

Chris Mayer
TomEE.1

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 6.

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 projects?

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 then?

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 architecture.

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

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 Tomcat…

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

Exactly. From day one there is a better alternative.

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 Services.

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 (laughs)

JAX: Wow. That’s a bit time consuming.

It’s not entirely efficient, no.

JAX: I think that’s fair to say.

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 27mb.

JAX: Yeah, that is impressive.

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 achieved?

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 release.

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

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

JAX: Not a bad starting point there then?

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 right?

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 collapsed.

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

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

JAX: Because of the move toward standardisation…

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 1.5.

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 should.

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.

Author
Comments
comments powered by Disqus