JSF Central - Dan Allen and Andrew Lee Rubinger on Testing with Arquillian
JSF Central

 Articles & Books 
Community Chat
Dan Allen and Andrew Lee Rubinger on Testing with Arquillian
by Kito Mann
29 Nov 2011 03:00 EDT

In this podcast, JSFCentral editor-in-chief Kito D. Mann discusses Arquillian and Seam with Dan Allen and Andrew Lee Rubinger.

Editor's note:

At the time of this posting:

  • Arquillian supports JBoss AS 7 and Glassfish 3.1.
  • The Arquillian team is about to release 1.0 Final, but the current version is 1.0CR6 (release candidate).

Podcast (MP3)
Welcome to the JSFCentral podcast #23 for the week of November 7th, 2011. This series of podcasts features interviews, news, and commentary for those working with JavaServer Faces technology. This interview was recorded in October of 2010.
Kito Hello, My name is Kito Mann and I’m not at a conference this time, but I am doing an interview here with Dan Allen and Andrew Lee Rubinger who are both at JBoss Red Hat. Dan is a principal software engineer, is that it?
Dan That’s correct.
Kito Okay, principal software engineer. And Andrew is a senior software engineer, and they both are working on a new project called Arquillian, which is all about testing in the container. And most of you probably know that Dan also has been working with Seam 3 – or Seam in general, and Seam 3 now. So I wanted to sit down and talk to these guys about what Arquillian does for JSF developers and Java EE developers in general. And actually just for those of you who are used to me being at conferences, I did talk to Dan at JavaOne this year about doing this and we had lots of phone calls back and forth and text messages. And it turned out it was better to go with Skype, so…
DanYeah kind of Fergie took the stage and – and, you know, the podcast was just rescheduled.
KitoYeah. Took a backseat for me.
DanTook a backseat, right.
KitoSo why don’t the two of you tell everyone a little bit more about yourselves. We’ll start with you, Dan.
Dan Hi everyone. I’m currently working on a whole bunch of projects at JBoss but most of them all stem from my work on Seam. I started as a Steam 2 developer and sort of shifted into…I guess you could say I got on the train with the CDI JSR-299 group and got involved in Weld and Seam 3 -- which was a natural transition from Seam 2 for me. And then also got involved with this project Arquillian and some other projects, and just testing in general. And I seem to get involved in new projects every single week, much to the dismay of my wife.

But mostly I focus on the community side of things. I like interacting with the community so you often see me doing community things, being outspoken, writing. Pretty much any time I can communicate and get involved with the great ideas that come from the community.

KitoAll right, so Andrew why don’t you tell us a little bit about yourself?
Andrew Sure, so my path to JBoss came in through the community as well. I was doing some EJB 3 development and then started contributing patches and came into the EJB 3 team. So, you know, currently I’m still there, I’m on the EJB 3 team and working on the application server, but I also started to realize that really, the missing part of being able to do some simple development was being able to boot it up quickly and test it. So I branched off a little bit, started off with the embedded sub-project of the application server, which just lets you bring up the application server using an API like an already running JVM. And from there we were able to spin off even further into using the ShrinkWrap project, which we’ll talk about today, and some of our other testing frameworks to really get you moving and have a development life cycle that’s a lot more fluid and has less stop/start.
KitoAll right, cool. So why don’t we just jump in then. First of all, the name Arquillian -- where does that come from? What does it mean?
Dan Spring Web Flow is essentially at its core it is a state machine. It allows you to maintain conversational state for web applications so you can have extendSo officially we can’t say; unofficially if you’re a fan of Will Smith movies you may have seen Men in Black. And so Arquilians are the alien species that threatens the Earth if they don’t give them the galaxy back. So, Arquillians are these little aliens and they live inside the heads of remotely controlled humans and they control everything that the human does. We got a little bit of the idea for that, in that these little aliens would sit inside of a human shell and control it.
DanAnd they were also very powerful little beings in that they worked behind the scenes to really take on this façade of a human character. So we kind of got this idea of controlling a container from that.
Kito Okay. I like that. I guess the sci-fi analogous entity would be the Goa’uld from Stargate. Could be kind of like that too, except they’re kind of evil so this is probably better…
DanWell I was kind of thinking last night too, you know, whenever we think of aliens, we think of aliens running tests on things, so it kind of fits to the whole testing.
Kito You’re right. Okay, that works out well. So that’s the name…the background for the name. So tell us more about the project.
Dan So what Arquillian is…I’ll give you sort of the short explanation first before I dive into how it got started. It’s a container-oriented integration-testing framework -- two concepts there. One: integration testing, so the idea is that it’s focusing on everything beyond unit tests. Unit tests by themselves are fairly uninteresting -- they’re intentionally simple. Integration tests can vary in complexity. And two, it’s container oriented, since most of the integration is going to be happening when your code runs inside of a container, so that’s a critical part of it. So that’s where those two terms come from.

And the most important part about it is that it provides declarative services for your tests. Things like injection and controlling the life cycle of the container, and stuff like that. So it’s picking up where unit tests leave off for the enterprise developer and immediately addressing the issue of: “great, how am I going to get the run times to be booted?”

So instead of having to worry about managing that environment from within your test, such as starting up a JPA or EJB in run time, and kind of getting your components to run alongside that, you instead ship the test to the run time and you really don’t have to worry about all that management of that run time. So it’s a relocation, if you will, of tests…although you could also use Arquillian to test sort of a as a client to the container. So it’s got that other mode. But what we always tend to focus on first is the idea of taking your test and running your test inside the container. And all of the sudden your test feels more like the components that you’re writing in your main application. There’s a one-to-one translation there as you move from the source main directory to the source test directory...or I should say, there is no transition. It’s just a natural progression.

KitoOkay. Sounds kind of cool. So if we were to compare this to a couple other things, like for instance if you’re using SeamTest, it runs sort of a mini container, right?
Dan Right.
KitoSo how is this different than something like that?
DanWell that’s a good question. Actually that leads nicely into kind of breaking down Arquillian. So one of the main issues with SeamTest -- first of all I’d like to say that SeamTest at the time was quite revolutionary and a useful tool because it gave you the ability to have your tests run inside of a container of sorts. The problem with it was that all of those concepts just sort of got meshed into one as this kind of big ball of wax and getting the embedded container to run correctly was quite a bit of a struggle, so people tended to focus more on how to get SeamTest to work than actually writing any tests.

So Arquillian is a new approach because it breaks everything down into its smallest components and assembles them very cleanly. So the first thing that it does is, it makes no assumption about any container that you may be using. It makes no assumption about any programming model you may be using. It simply has a core pluggable SPI and then you can introduce all of the different types of programming models and containers you want. So that’s the important thing. First, it’s not some proprietary embedded container framework, it’s a totally open stack. And it just so happens that we focused on Java EE as sort of our initial programming model, to provide as an implementation.

So the idea is that you take an existing JUnit test or a TestNG test, but kind of focus on the JUnit part. And at the top of the test you put in the annotation that says, “run with Arquillian.” And what that does is it says “okay, this is the special test that is actually going to get handled not by the regular JUnit runner, but Arquillian’s going to get a chance at this thing.” And the next step, which is the second project that I want to mention, is that you have to produce an archive. And the idea here is that if you’re going to run your test in the container, you have to give the container something that it understands how to digest.

And we know that Java EE containers understand things like web archives, enterprise archives, and EJB Java archives. So the initial cut of this, which sort of came out of the JSR-299 TCK, was: take a bunch of classes that are referred to in the annotations and just sort of stuff them into an archive and throw it over on the server. But it just so happened that about that same time, Andrew had been working on a project called ShrinkWrap which provided a Java API for doing this rather than using annotations, which is fairly limited.

So I want to let Andrew explain sort of how ShrinkWrap got started, and then he can tie it back into how it’s going to play a role in Arquillian, or how it does play a role.

Andrew Sure. So if I can take one step back, I guess we hear – we get this question a lot, you know -- how Arquillian as an integration test framework compares with other previous integration test frameworks. And something I always like to point out is that it’s actually a lot more like the Java EE programming model where you have just a component model for writing tests. So as a component model for writing tests, Arquillian is going to provide services like injection, and deployment. It abstracts a lot of the test setups that you would ordinarily be doing on your own so that you’re writing less and it’s doing more for you, and you’re focusing your effort on your tests.

So it can do everything like start a container and deploy into it; the thing that you need to be able to do though is define what your deployment is. And when you think about deployments in Java EE land, they’re typically an EAR structure or JAR structure. It’s always been some sort of a file based thing. And back in the day, we had a virtual file system and Bill Burke had proto-typed this idea of a memory file where you could stuff a bunch of resources into a Java object, and the application server would somehow know, “all right, this is something we’re going to deploy.”

So what we did with ShrinkWrap was really take that idea and say, “all right let’s make a Java API for archives and instead of dealing with files or URLs or any type of file based structure, we’re going to represent our deployments as Java objects.” Because in the end, they’re all just bytes and if you could read any set of stream bytes, then that’s going to constitute your deployment. So the ShrinkWrap project was born, right? And it becomes very easy now to just say, “all right, ShrinkWrap, create me an archive and add this class, and add all the classes in this package, and also add in this EJB JAR or web.xml resource.” And from there you just have an object. And if you have a container that knows how to deploy that object, then you’re all set.

And that’s what the Arquillian adapter is doing for us, as well; it is saying, “all right, yeah, we know how to take this Java object and deploy it and we know how to port it into this container. And you don’t have to worry about any of that.” So the ShrinkWrap project is even so much smaller in scope because it just deals with Java archives. The ideas that you can add stuff into them, export it to a file system…you can even serialize it over the wire and get it on the other side.

Kito Right.
Andrew But it’s all just stuff that has to do with archives and packaging, but from an API instead of using the Java JAR tool.
DanWell it’s a small focus with a huge impact. Because one of the things that we haven’t mentioned yet is that…so typically when developers think, “How do I create an archive?” they immediately think, “Well I have to use Ant or Maven, or some build tool,” because that’s where traditionally we’ve established that archives are created. But because ShrinkWrap provides a Java API for creating an archive -- which by the way never even has to touch the file system …it may, but it doesn’t have to, especially if a container knows how to consume the memory object -- is that we totally skip this idea of a build. Builds no longer become part of testing, or a requirement in order to do testing because we don’t need that piece of functionality which we always threw to the build to do, to create an archive for us. Instead, we can do that all in Java. So if we want to add a new class or a new resource to the archive, we just type in the line in Java, press save, and the next time the test is run it’s going to include that file when it sends the archive to the server.

So we don’t have to deal with the build complexity and that gives us a lot better chance to do native tooling using your JUnit plugin or your TestNG plugin, because they’re not out of the know. They are out of the know when you go to a build tool because they have no idea what you’re doing, but here, they know about everything in the little world of the test.

Kito Well, but there’s still some builds step, right, because you haven’t turned the Java source files into class files, right?
DanRight, exactly. But the IDE is very good at that already.
Andrew This is something I had hinted at a little bit before when I was talking about the idea of making a little bit more fluid development life cycle. You know, we learned long ago that IDEs can do incremental compilation, just saving one class file at a time and putting it into a target directory. So what we’re really doing is taking advantage of what’s already being done for us. These class files are already being made as each file is saved and they’re just available in some output directory. And what you can do is, very simply write your code, run your test from the IDE, and if it fails make whatever change, hit save, and rerun the tests. You’re not rerunning the build to do any packaging or to clear everything out all over again; you’re taking advantage of the incremental compilation that’s already there.
KitoOkay, and then when we run the tests Arquillian’s going to do the magic of basically redeploying your test archive?
Andrew Yeah, I...
Dan Right, so inside of – oh, go ahead Andrew.
Andrew I was going to say…yeah, Arquillian is a beautiful piece of plumbing. What it really is going to do is adapt – it’s going to adapt the life cycle of your test framework to the life cycle of any back end container. So the life cycle of a test framework is typically something like before a suite, before a class, before a test, and then the corresponding after life cycle methods. And what we do is we map those to some operations that you might expect of a container, like start it, deploy into it, inject resources, these types of things. And once we start being able to do that, now that’s where the component model for testing comes in just like it does for anything else you expect in Java EE.
Andrew I’ll let Dan expand on some of the cool stuff it does. Because it really…you end up writing much less code. You end up pretty much writing your tests.
DanRight, so I said you would put, you know run with Arquillian in your tests, and then the second thing in your test that you have is this deployment method that’s annotated at deployment. And that’s how you define the ShrinkWrap archive. Now what’s interesting here is that you could add a single class and make that your archive, you could add a whole package, or as Andrew mentioned resources, you could also import an existing archive. How you define what you want to be part of this test is totally up to you. It can be as small or large of a scope as you want.

And then from there you can take the components that are – that get deployed, and inject them back into your test using the EJB annotation or the inject annotation,, depending on which programming model you’re using. And then you’re testing not instantiating the classes yourself, but you’re actually able to get a handle on the real proxy, so to speak, whatever the container gives you when it does an injection, and your test becomes a participant in the system just like any other component would, using the dependency injection system.

So the really neat part here is that since there’s no mention in any of this test of a container -- where or how we start, how we stop it, which container we’re choosing, are we using JBoss application server, GlassFish -- your test is totally portable to whatever container provides that programming model. So for instance if you’re developing an EJB test and you do @EJB to inject an EJB, any container that Arquillian knows how to talk to that provides EJB, you can then just take this test and run it on that container.

And this idea of having portable tests again is consistent with the Java EE methodology of having, you know, portable applications, portable systems. So you’re not just getting a component model for tests, but you’re getting a portable component model for tests.

KitoOkay. And I guess one question I had is, you know, you’re saying you can easily define the classes you want to include in your tests, right, using the ShrinkWrap API, but what about dependencies? I mean, what if your app depends on some library that has some service objects that you need to do integration tests with. How do you define that?
DanAndrew you want to mention that?
AndrewSure. I’m a little unclear on the question. Because, you know, typically you have some archive that you need to deploy in and if there are dependencies then you would add that into the archive as well, right?
Kito Right, so it’s just basically adding another file to the archive, essentially.
Andrew Right, so like if you’re building an EAR, let’s say, the deployment method would return what we call in ShrinkWrap an enterprise archive object, and contained within that would maybe be a few Java archives and web archive, maybe.
Kito Okay.
Dan Let’s say for instance you depend on Google collections, right? So you have a couple of different choices into how you put that into the archive, as Andrew mentioned. You can put it into the archive as a JAR file. So the JAR file could be coming from a local repository or within the project, or Maven repository, how you define it is really up to you. And then you deploy that. Another approach would be: I only need one class from Google collections. Well, if Google collections is already on your class path for compilation then you simply take whichever class references you want and just put them into the archive.

So you don’t have to take the whole JAR file. You could just take the pieces you want. And the benefit of doing these, what we call micro deployments is that the smaller the archive is and the less components it has within it, the faster it’s going to deploy when it goes to the server. So sure, you could include every library your application uses in every class in your whole application in all of your tests, but then it’s deploying and processing all of these components and you’re testing one.

So instead you can just put what you need into the test and it actually turns out to be pretty attractive because you all of the sudden don’t have to worry about all those other layers when you’re trying to focus your test on just one part of the application.

Kito Right, right. So I guess the obvious question, at least from my perspective here, but…I mean this sounds great, you know, you annotate your test class, you can inject the components that you need to test, but how is that different than what I could do with some of the Spring features? Like let’s say I was using a pure Spring environment, I could annotate, write a test, inject my Spring beams, and everything. So how does this compare with what you see with the Spring testing features?
Dan Well the first thing that I would mention is the Spring is just a matter of a container implementation to Arquillian. As a matter of fact, we did a Spring container, an embedded container for Spring, and a Spring integration, which is currently in HEAD of Git.
Kito Okay.
Dan So the interesting part is it takes all of what Spring did and says, “oh yeah it’s just an implementation detail. Oh and by the way, we can do OSGI too and we can do all these other programming models, sure, what do you want? We can certainly implement any of that.” So it’s putting that concept that Spring had on a larger more sophisticated backbone, a more extensible backbone, so to speak. And then we can provide exactly the same things that you had with Spring. So you wouldn’t even necessarily know that you were using Arquilian. That’s just a detail of how it’s run.

The other thing that is different is that the Spring tests always assume that they will be booting an embeddable container. And embeddable containers are actually… they have good parts, they have benefits, and they have drawbacks. The benefits you already know because if you were doing Spring tests you’ve already been taking advantage of them. The drawbacks are that really you have not exactly the same type of archive that’s going to be on the server, the class path is going to be inherited from whatever, however the unit test runs, whether it be part of Maven or Ant, it could inherit classes that aren’t necessarily going to be there when you actually deploy your application.

So we’re talking -- when you do a real deployment to a remote server -- total isolation of the class path, the way that it will be isolated when the application runs. So you don’t have to take away anything that you did in your Spring testing, but now you gain a whole bunch of stuff. And the other benefit of stepping up to Arquillian from Spring, would be something we haven’t mentioned yet, which is, you know, we’ve talked already about programming models that your application uses, but there are other types of programming models that are specific for testing. And we call them test-oriented component models.

So for instance, if you wanted to use DbUnit, or of you wanted to use JSFUnit, or let’s see, Selenium, that requires a whole other layer of setup in your testing environment. What if I told you that, “Oh by the way, that’s just another detail of Arquillian setting up the managed run time for you?” You can just inject a DbUnit operator and just say, “operate on database.” You don’t have to worry about how you get DbUnit configured, or how you get Selenium configured, because we can extend the programming model, the component model, not just from the application direction but also from a parallel direction through test frame work. So test frameworks are part of the component model too, is essentially the message.

Kito So how does that work though? Because, I guess basically what’s happening is the test is running, it has whatever is injected into it, you’ve done all the scaffolding so it doesn’t really matter where it’s running, right? So if you – I’m thinking more along the lines of JSFUnit since that’s obviously what I’m more…
Dan Sure, JSFUnit is a good example to talk about.
Kito Yeah. Because you know, what it’s doing is sort of… it’s written to run outside of the container, right? But the calls you do are examining objects from the browser perspective and from the internal perspective. But I guess, when in terms of Arquillian, it just happens – you can still have it run inside of the container, that same test?
Dan Well JSFUnit is actually designed to run inside the container, but as though it were a client to the container so that you are able to access both the client and server site objects. So this exercise…
Kito Oh yeah, you’re right...okay.
Dan So really the integration with JSFUnit is just a matter of taking JSFUnit and stuffing it into the archive that Arquillian is going to take off and send to the server. And then having Arquillian wire JSFUnit to all the strategic life cycle hooks within the runner for you so that it boots up and configs itself automatically. So when you go to use JSFUnit you’re only thinking, “which JSFUnit objects do I want to use? I don’t care how it gets set up, I’m just going to assume it’s properly set up and I can start using it.”

And that…one of the things that we kind of skipped over was that once Arquillian takes the ShrinkWrap archive, in the in container mode, that’s not actually what it sends to the server – that’s not the raw object it sends to the server. It takes that object and then combines it with all of the different auxiliary archives that plugins to Arquillian will add. And it puts that all together as a single test archive and deploys that to the server.

So Arquillian is actually taking JSFUnit or TestNG, and any of the any other integrations, and it’s moving that entire run time into the server so that it can remotely control the test.

So JSFUnit would be in the archive in this particular example…JUnit would be in the archive, any libraries that JSFUnit depended on would be in the archive. And so all that stuff goes and gets shipped to the server. We do have a client mode, which is what Selenium would use. And in that case what gets shipped to the server is the raw ShrinkWrap archive because the test model, the test component model, is actually working from the client side. So then none of that stuff has to get put into the archive. So it depends on which side of the fence you want to be on, so to speak; do you want your test to be a client, or do you want your test to be in a container? So there’s a lot of flexibility there in what Arquillian can do.

Kito Okay, cool. So let’s take a step back just so it’s clear to everyone what sort of containers you currently work with. Because you mentioned a while ago…we talked about EJB, etc. So can you just clarify exactly what sort of containers Arquillian currently supports?
Dan Yeah, I’ll let Andrew answer that, to start kind of with the JBoss containers.
Andrew Sure, all right, so we have support for a series of JBoss containers: the application server version 5, 5.1…excuse me, Lucy is growling a little bit.
Kito Is that a cat?
Andrew That – so as ambulances drive by, she will…
Kito It’s very cute.
Andrew Just let her finish that real quick. You can ask again if you want Kito, I’m sorry.
Kito Sure.
Andrew I’ll just jump in. For the JBoss container adapters for Arquillian, we have support for JBoss version 5, 5.1, 6, and those will come in a remote mode, meaning connect to an AS instance running in another JVM. For AS 6 we also have an embedded mode, too, so it’ll bring everything right up in process.

As Dan mentioned there are some drawbacks to it. Some of the things that I love about that though, are that you can actually test a synchronous component with some reliability in that you can rely upon the JDK’s, like, shared memory references in the Java util concurrent libraries to properly set up blocking and make sure that…you know, if you’re testing a message driven bean or sort of an asynchronous thing, you can set barriers and latches at the appropriate places, really get on in there.

But you know, from first grab we also made a bunch of other containers outside in the community. One of the first ones we had done was with OpenEJB, which is an Apache project run by David Blevins. And also GlassFish version 3 embeddable, Jetty as a Web Server, you know, and it’s just been growing and growing.

Kito Okay.
Dan So one of the interesting things about Arquillian is that we’re actually starting to see people come to us, within JBoss, and they say to us, “you know, we spent a couple of months writing an integration testing framework for our programming model, or project, because we had no way to test it. And we did a lot of work on it, but we realize that now we have to maintain it and we hate that. And we realized that we can off load all of that back to Arquillian and then we can just focus back on our tests again.”

So I imagine that we’re going to start to see this as people get introduced to Arquillian, they’re going to bring us stories, like, “Oh my goodness, we have this huge integration testing framework that we developed in our company, and if we could just dump all of that and just switch it over to Arquillian, we’ll save ourselves so much time and maintenance effort.” So the stories that we see internally are just the beginning of the stories I think that we’ll see coming from the community and companies that can get rid of these proprietary testing frameworks, and switch to something that is a de facto standard, at least today. Who knows if it becomes a standard in the future -- for Java EE that would be nice -- but certainly they can give up a lot of code that they would otherwise have to maintain and just put it on the Arquillian backbone.

So Thomas Deisler introduced the JBoss OSGI container. Jean Deruelle came to us at one conference and said, “I looked at what you guys did, I can’t believe the parallels between it and my project.” So he’s re-written his testing framework on an Arquillian adapter for SIP Servlet.

Kito Cool.
Dan Yeah, so we’re starting to see individuals come to us that can contribute and support other environments that we may not even really know how to get to work. And they become kind of the leads for those. So it’s branching out in all different sorts of directions. So the containers you see today are really just a small subset. And then recently we’ve been communicating with the jclouds guys, Adrian Cole specifically, and he realized, “wait a minute, this is the perfect solution for cloud testing because you’ve abstracted away all of the container life cycle management, why does the container have to be on the same computer or in the same network?” Or why does the container have to exist on a computer that is already running? Why not boot the entire computer, you know run the virtual machine somewhere on a cloud, start up all the servers that you need to send the test to the cloud, let it run inside of there, and then pull it back down and tear down the whole thing.

So we’re starting to see Arquillian branch out in different programming models, but also in different infrastructures. And it’s really fascinating what types of testing we never really thought was possible before, or we thought was way too much effort to get set up, is now just child’s play with Arquillian.

Kito Cool. I just wanted to go back to the testing integration, testing framework integration part, when you were talking about DbUnit or JSFUnit or whatever. How much of that is currently available? Like if I want to use JSFUnit with Arquillian, you know, can I do that today?
Dan JSFUnit has great support. And the reason for that is twofold: One, because it is a JBoss community project, but also because Stan has now really picked up on this idea that Arquillian is his path to really reaching out to a larger subset of users. So he’s been supporting and getting that integration working nicer.
Kito Cool.
Dan That’s probably the best integration that we have so far -- the jclouds stuff is going to be coming quickly behind that. But so far the framework integrations that we have are still in the early stages.
Kito Okay, cool. One thing that seems…kind of jumps out at me when listening to you guys is that if you take away the testing aspect, basically you have sort of a general purpose deployment framework, right?
Andrew Yeah this is something we’ve talked…well, we keep on talking about as it seems that we’re getting a lot of requests in to have a really good deployment abstraction. And a way of, across different containers, saying how you’re going to deploy something through some sort of a simple unified API. It’s something that I think could be maybe ripped out of Arquillian so that Arquillian really becomes the plumbing that calls some centralized deployment mechanism.

I think it’d be awesome to work with some of the other vendors on that too. I know that I just heard back from Carlo, our team lead, who was just over at OpenBlend conference in Slovenia, and he had spoken to some GlassFish guys about doing just exactly that kind of thing: talking about, you know, a deployment abstraction.

Kito Yeah, I think that could be really helpful.
Dan It’s a sort of a revival…kind of a revival of JSR-88, at least a revival of the goals, and Cargo is interesting. People often ask us about Cargo and…
Kito Yeah, that’s a good thing to bring up.
Dan If you look at the source code of Cargo, you realize that all Cargo really did in the end was take JSR-88 and all of its inconsistent implementations and put a layer of abstraction over it so that you could use JSR-88 really the way that the original goals were. So all it was doing was really…I’m not saying that it wasn’t a lot of effort, it was a lot of effort and that was part of the point is the JSR-88 was so fundamentally broken in its specification that you required a whole other framework to put an abstraction layer over top of it so that you could just use that spec.

So what we’re saying is forget the scope of JSR-88 because that scope is way too narrow. It really only has a couple functions. What we want to be able to do is make it a deployment abstraction which itself is a new standard. And base it not on file based operations, but base it on ShrinkWrap based operations. Or you could even say just memory objects.

Andrew Right, I mean my whole goal is for ShrinkWrap to become so ubiquitous that it becomes central to the Java platform and also becomes recognized by container vendors such as they want to support direct deployment of it. And from there, I mean now you’re essentially just…you’re able to deploy streams, you’re able to deploy Java objects, and come into some agreement about deployment, abstraction, API…above that should be pretty simplistic.
Kito Just to take a step back, Dan, JSR-88, for those who don’t know, is the Java EE application deployment JSR, right?
Dan That’s correct, which by the way, was pruned from Java EE 6. So it’s no longer even in the standard.
Kito Okay, okay, all right.
Dan So it’s dead.
Kito Yeah looks pretty dead to me. All right, yeah, I just wanted to clarify that. Go ahead.
Dan Well I was going to say, it’s narrow too in that it only focused on deploying. But there’s other issues at hand, like how do you tell the container to start? And how do you tell the container to restart, or to deploy into a cluster, or things like that? So there are other API… parts of the API that weren’t addressed. So we want to make sure we address all of those. Because by the way, starting containers is Wild West. I mean even if you look inside of the code that we have already, and this is just life, every container has its own crazy way of starting and we have to hide all of that from you so that’s it’s simpler.
Andrew What’s interesting about the EJB 3.1 spec is they introduced an embeddable EJB container SPI. So that’s actually part of the platform, where the logic to start up the embeddable EJB container is part of the platform, it’s an SPI and then it uses manifests to figure out what the implementation class is going to be, and that will be specific to vendor, to bring up the whole implementation. But the start API is actually there and I think it’s the first time that I’ve seen it for Java EE and starting a container.
Dan Well you could call the JPA persistence class also to some degree an embedded container, although it was fairly narrowly scoped and it’s not providing really a programming model.
Andrew Right, I mean it’s a framework but the idea is you’re right.
Dan And JSR-299 tried to put in a bootstrap API just like the EJB container, but that didn’t make it. It’s proposed for CDI 1.1.
Kito Okay. Yeah and I think that’s kind of the problem, is that every piece needs to have some sort of bootstrap, right?
Dan Yep.
Kito So, all right. Well, I think that gives us a pretty good idea about what Arquillian does. Right now as of this recording in October, it’s 1.0 Alpha, is that correct?
Dan Yes, we’re currently at Alpha 4 and Alpha 5 is in the works. And a beta is just around the corner. Alpha 5 may just become Beta 1. The things that we’re still trying to work out…Andrew’s been stabilizing the ShrinkWrap API, so there’s been discussions about that. By the way, the lead of Arquillian is Aslak Knudsen, he’s a new member of RedHat. He joined to work on the Arquillian project, he immediately became the Arquilian lead, and he’s Norwegian, which is kind of neat. So we’re spread out a bit around the globe.

He has been working on getting the life cycle and abstracting out some of the ways in which we communicate with the containers -- a little bit more clean and overall just improving the documentation and all that…kind of getting ready to be in a beta status. Because right now we’ve been flying alpha and it’s amazing how many people have been able to have success on the alpha, and we’re thrilled about that, but we do want to get some of this stuff rounded out so that it’s at least in beta software mode and people can feel a little bit better about that.

Kito Okay, so most likely by the time people hear this podcast you will have – my guess is there will be some Beta version out.
Dan We were hoping to announce it by Devox at the latest. That’s in November.
Kito Okay, yeah, so I would say look for Beta something when this is out.
Andrew It should be noted too that when we say alpha and beta level software - Dan’s right, we’ve had a lot of success in people using this stuff. ShrinkWrap now is in Alpha 11. There’s a reason that we’ve done all these Alpha releases and it’s not because it’s unstable or not well tested, I think I’ve gotten maybe one true bug in the entire course of it’s development. Because it’s been such a stable development cycle, the idea is to keep the APIs locked. And once we lose that Alpha status there’s really got to be a very compelling reason to break an API or, you know, if it’s even possible.

We want to make sure that for our users everything is assured. So that when the GlassFish team brings it in and they say, “Yeah, all right we’re going to support this natively,” the rug isn’t swept out from under them when some API changes.

Kito Right, right. So for you guys it’s more about API stability and probably some extra documentation.
Dan Yup.
Kito Okay, cool. Anything else you guys want to add about Arquillian?
Dan Yeah, so just come check us out, it’s http://www.jboss.org/arquililan and if you search for JBoss testing, or ShrinkWrap, those words will likely lead you down the same path. So definitely come by, we’ve got forums, IRC, and we’ve got tons and tons of examples and showcases and presentations and stuff. So there’s lots of information there and you’ll pretty much be able to find everything that you need starting there.
Kito And also if you go to a conference, Dan and Andrew have been on the Arquillian world tour lately so you might see them. Keep an eye out for the Arquillian session.
Andrew There you go – also I should take advantage of the marketing. I wrote an EJB book, EJB 3.1, it’s the next edition of Bill Burke’s last edition.
Kito Oh okay.
Andrew And all of the examples are based on Arquillan, too. So it ends up being kind of a nice way to learn EJB and then also see a bunch of different containers. What was cool about the book is that, you know, a book should be kind of vendor agnostic. And by doing this I was able to write the tests in such a fashion that there’s like three different containers that you can use, and they are used in the examples. And they’re all available online on GitHub as well as on the JBoss community site.
Kito Okay.
Dan Yeah, so I get super excited that you can walk into Barnes and Noble or Borders pretty much anywhere in the United States, and Arquillian is in a book. So go find the O’Reilly Enterprise Java Bean 3.1 book and check it out.
KitoThat is kind of cool. All right, thanks. Bye.
AnnouncerThat’s it for this edition of the JSFCentral podcast. The music for this podcast was composed and performed by Kito Mann. Thank you for listening…

RSS feed(all feeds)

The Editor's Desk
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2015 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.