Sure. I work for Red Hat. I’ve worked for Red Hat for about 4 and a half years now. I started at Red Hat working on the Seam project. I worked there for a couple of years and then I worked on Weld which is a reference implementation of CDI which Gavin King led. I write the TCK for that as well. More recently I’ve been working on InfiniSpan which is a data grid project at JBoss. I do quite a lot with various Java EE specifications, for example, I also represent Red Hat on EJB 3.2 on the Unified EL specification, I’ve worked on JSF 2 in the past and things like that. So I’ve done quite a wide range of things at Red Hat.
2. So a little bit about CDI. Where did it come about, how did it originate?
In around 2006 Gavin King started the Seam project which really came out of some lessons learned from working on Hibernate and the way Hibernate interacted with that time Spring framework. He wanted to really investigate some ideas around holding more state in the programming model rather than trying to hold it in the database or elsewhere and I think as well from the lessons we’ve learned from the JPA from standardizing a lot of the ideas behind hibernate and JPA. It was very attractive to us to try and standardize some of the ideas we’ve seen. And, Gavin quickly got Bob Lee from Guice and I think that really influenced a huge amount the direction of CDI. I would say Guice is probably one of the major influencing facts to CDI. It really lent a lot of the ideas behind the dependency injection model. Seam provided some of the more ideas around Java EE integration and contextual information and things like that, and of course other frameworks like Spring played as well and provided inspiration for some of the ideas there.
I think there is really a number of benefits of CDI. I think the first one which other frameworks like Guice do offer is the type safety. I think type safety is really important as you get into larger teams of people, larger projects having that ability to refactor easily, use tools easily is really important for me. I think the contextual aspect as I mentioned of CDI is something that is very unique CDI, that combination of the type safety and the contextual information is very powerful. I also think using insights of Java EE is very appealing to a lot of people. You have the fully ready made stack, you don’t have to go out there and assemble all of the bits that you need.
You just take it and you know it’s going to work well together and you get the portability to other vendors if you want to. Your vendor, if you fall out with them for some reason, you don’t like them, you are concerned about their performance (you can switch). I think these are good reasons. For me there is a couple of features as well that really stand out, one of which would be the extensions. I know you’ve worked extensively with some of the extensions. I think that is something completely unique within the Java EE system. Again I don’t think this is something Spring offers in such a powerful way, the ability to really extend the framework, to really change the metadata and the way the deployment looks.
And, the event bus is actually something that’s really very simple but very powerful and I think as we move into some of these more technologies like websockets and things like that, things like events become more and more ubiquitous and more and more standardized ways of doing computing, so having a good event bus that is the core of the framework I think is very powerful.
Of course as with any DI framework it makes unit testing pretty easy. You could just inject your mock objects rather that injecting the real objects and you could easily test your POJOs which implement interfaces. And they extract out a lot of the container provider support into declarative annotations so that doesn’t affect how things run. However we at JBoss feel unit testing is very useful, but really integration testing is what’s important because that is when you really test your real application in a real scenario with all the bits working together. That for me is what testing comes into its own. And this is really hard to do in a container. Until a couple of years ago there was no good way to do this without a million and one ant build scripts that pushed up all over the place etcetera.
So we are actually coming out to the experience of writing the TCK for CDI, developed a framework called Arquillian and its aim is to make it really easy to deploy stuff into the container, run the test on the beans that are deployed to the container and get a result back to the client. It offers a lot of things as well like the ability to run the same tests in multiple containers, abstracting a way, how you should deploy to the container, abstracting a way some of the logic about how you start the test case. Now that is very useful with you writing a TCK of course, but in the real world it’s very useful because it keeps your test cases really clean. They just focus on what you are testing not on how you set up your test. Arquillian also now offers some great extensions, if you haven’t done Selenium testing, that’s been a nightmare sometimes to get Selenium integrated to the whole test environment.
Arquillian offers a really clean way to do this, you just add this Arquillian drone project and then it can just launch the Selenium test for you and pull all the results back into your standard JUnit runner so to display all of them in a standard format that something like Jenkins can easily understand. You use the same logic to decide what to deploy so no need to write and build scripts. And the final advantage of Arquillian that I forgot to mention, for me was really an absolute requirement was the fact that we had to be able to run the test from inside the IDE; being able to in Eclipse, run as JUnit test or run as TestNG test. If you can’t do that with your testing framework then there is no point in really having it because you can’t debug it as a developer.
Absolutely. It’s very much in the same game as those kinds of tools. It’s about rapid application development, it’s about being able to easily create a project. We all know that in Java unfortunately you end up with a deployment descriptors and these kind of things, lots of XML files, lots of things you need to set up and everyone I am sure has had one or more nightmares with Maven when they just can’t get the application built properly. Now you know this is a limitation of Java, it’s a limitation of software in general actually and of course with something like CDI we are really working to get rid of some of the things like deployment descriptors, but at times we are working with technology that you can’t change necessarily because of backwards compatibility requirements etc. and this is where a tool like Forge can really help you get your projects setup.
And there have been lots of tools that have done this over the years, like Archetypes you mentioned, like Seam gen this is a tool that we had for Seam 2 that would do this kind of thing. However when we sat down and we talked about what do we really think people need from this, we decided that one of the things that was absolutely critical was what we call round tripping, so the ability to not just create the project once and spit something out that has your setup project and away you got, but it’s the ability to add stuff to a project over time. So for example you say you start your project and 2 or 3 days you decide that you want to add bean validation. We don’t want people have to go back and regenerate an entire project we want them to just be able to type command, add bean validation to projects easily and move on. So this is really one of the guiding principles of forge is the idea that you had to be roundtrip suitable.
The other idea was that there are many Java frameworks out there and we wanted the ability for people to be able to choose which Java framework they use in their project. So we didn’t want to say: "Ok, Forge supports this limited set of things." We recognize that people always use different things and so Forge comes with a very powerful plug-in system where you easily write your own plug-in and that can add capabilities to the rapid application development tool. For example say you came along and you say: "I want to support something like Drools" and there is no Drools support in Forge, ok you can write your Drools plug-in and away you go. Forge is interesting, it’s completely based on CDI, so the engine that runs the container is CDI. So you write all your plug-ins using CDI sort of standard well known development metaphor when you are writing plug-ins.
It’s also backed by the MVEL scripting language which means it’s really powerful under the covers because you’ve got a really good command line, tab completion, coloring, all that kind of stuff you come to accept from bash or whatever. So you’ve got a really powerful mode there, it’s got scripting support so you can easily load scripts into it that do predefine things. We want to have the ability to be able to export scripts and things like that, so a pretty powerful tool.
6. Are there any plug-ins that are for projects outside of the JBoss ecosystem?
So far we are really getting started with Forge. We’ve been really concentrated on building up a solid core infrastructure and its plug-in infrastructure etc as I talked about. We have plug-ins now for most of the Java EE specifications, so you can generate REST end-points, you can generate JSF pages. I think so far the majority of the other plug-ins are for JBoss projects but we’re definitely looking for people to come and contribute plug-ins for their favorite project. You know something that we really learned with this kind of thing is people who could write the best plug-ins are domain experts in Wicket or in Spring or something like that. They are not the people who know Forge, they are the people who know technology they are trying to integrate in. So we are really looking for those people to come and give us a hand getting some of these plug-ins go.
So yes, we are really starting to ramp up some of the advantages and some of the information around Forge right about now right around JavaOne.
Absolutely. The JCache specification, JSR 107 is an excellent example. I think of people who have really taken CDI an annotation support right to the core. With JSR 107 they take an interesting approach which is to say that they wanted to find a set of annotations that could be implemented using CDI or using Spring, or using Guice, for example, which is really interesting and I think that’s made actually the JSR 107’s job a bit harder because they have to think about not only how does this work in one paradigm like CDI, but in a slightly different one like Spring or Guice and where there are different rules. So to go into a little bit of detail on what JSR 107 has done they define some annotations that allow you to declaratively control what goes into a cache and what goes read from the cache.
So an example we want to write JBoss example to show us how you can use this is a really typical example someone is creating a user profile, they have got a picture of a person and they want to generate various thumbnails. So the JSR 107 support is perfect for that because you could annotate the method that generates the thumbnail, a cache result annotation which says cache results into your cache, the next time the method gets caught rather than calling the method the cache will simply return, the generated thumbnail. When someone uploads a new picture we simply send an event that says: "new picture uploaded". One of the observers for this would be a metadata cache remove and that will then just remove the thumbnail from the cache and move on. So there is some really interesting use cases like that around the caching. Other specifications are also in the Java EE 7 timeframe really looking at adding a lot of CDI support. JMS is the one that springs to mind.
I’ve been spending a lot of time with JMS guys about how we can ad CDI support to JMS, what the best way to do this is. And hopefully bring back some of those lessons about the way they want to do CDI into the core specification to make it more powerful and address those use cases.
Absolutely. I think we’ve touched some of this already. I think one of the big advantages of Java EE is that it comes fully assembled stack in which you can deploy an application without having to worry about how you build things up. I think for a lot of people that is very powerful, it makes you more productive because you can just sit down and get on with things, you don’t have to worry about your packaging so much. Now a reason a lot of people have liked Spring with Tomcat in the past because they see it as lightweight, this has been a real buzzword in the last 5-10 years. But I think with something like JBoss Application Server 7 which boots in 2 and a half seconds on my machine brings up all of the services that you need, it brings up transaction services, it brings up all the CDI stuff all the EJB container, all of JPA, all of the server container, that is a container ready to run.
It’s not we’re the first deployed application and we are going to start all of this in the background but its actually ready to go. I think that kind of dispels a lot of the myths around this idea of lightweight. If you can start a container in 2 seconds then you can deploy an application in 4 or three, that is pretty damn lightweight in my opinion. So I think that dispels that myth that we need somehow move away from this heavyweight monolithic app servers towards something like Spring and Tomcat. Once you got that ability to be lightweight inside your app server remind me what is the reason for actually going out there and assembling it all yourself. I mean you might as well take this thing and the vendor has made sure it works well together and in JBoss 7 I think we run in the region of something like 60000 tests every time we release it to make sure it’s doing exactly what it should be doing and that your application will run as you expect it to run on the app server.
Frameworks like CDI bring a very powerful modern programming model to the app server as well, so again we are certainly not lagging behind there. A lot of people I speak to say that they think that the ability of CDI and Java EE has now has certainly going beyond that which Spring has. Spring at it core again is an old framework. CDI is a very modern one. If you have a specification that lays out exactly what should happen, in every situation you end up with a much cleaner implementation because it’s very well defined what happens here here and here. When you have something that is evolved perhaps it’s not so clear because it’s more just in the mind of the designer rather than written down in a formal specification, that is another advantage of that. And obviously the biggest thing that developers care about is productivity. We’ve touched some of the tools that we offer around Java EE, around CDI today like forge. Going back to the Arquillian case a Spring approach the testing has always been, ok you mock everything out and you run Spring in a stand alone environment. For me that is not good enough. That is not how the application is going to run in production, that is how the application runs in a mock environment.
I want to see how the application really runs in a production environment. We had some costumers who are using Arquillian to the extreme sense. They are actually cloning their production machines, cloning the virtual imageof the production machines to a testing machine and using Arquillian to deploy the tests up to the production machines, so really getting pretty much perfect fidelity how the application will run in real life in their data center on the VMs running with the memory that those machines have available with the CPU power those machines have available, with the quirks of the operating system and the admin who’s running the wrong command on the operating system, mistakenly deletes some Java library or something like this. We are actually testing that real environment. Those I think are just a few of the reasons I would choose CDI for the application.
One thing I would mention, is very fresh in my mind, that was an excellent talk on exactly this topic, how do I migrate an application from Spring to CDI. And he gave an excellent introduction in which he explained why you would want to do this and then he talked people through his steps for how you would do it. Very simple, he first started talking about some sort of migration bridge type framework where you can actually use your Spring beans inside a CDI container, so you could inject a Spring bean that your Apache or 3rd party framework you were talking about had defined and use that inside CDI. There is a couple of options that you can take from the Internet already that allow you to do that kind of thing.
And we are also looking at developing such a project from JBoss or contributing to the existing ones, but we definitely want to try and push that effort quite a lot further forward because we do recognize there are lots of Spring shops out there. you know. JBoss’ policy more generally around this has always been JBoss app server is a great place to run Spring apps, we are certainly not trying to get rid of those developers, but we believe that the development plan we offer is superior and therefore we want to offer people ways to use and benefit from the productivity of that platform offers. Yes of course he talked about that and then he talks about techniques ,which you can use to actually use to literally migrate your beings over where some of the incompatibilities might lie. For example you talked about JDBC template, one of the really popular features of Spring, but you are saying there is actually no dependency from JDBC template onto Spring and core itself.
So you could still use that in a CDI environment quite easily, no problem there. So I am really hopeful that we can either, I am not sure if Paul’s talk was recorded, but if not I am really hoping that we can Webinar out in which he brings out message to a wide range of people. We are certainly looking for that in the near future.