I've been trying the JBoss Embedded AS container with Arquillian for a few days now. After a lot of wasted time (I learned a lot though), I realize that It works without any change on the code (I had to uncomment the module in the parent POM but that was it! ).

One man's wasted time is another man's treasure. We appreciate your dedication. Unfortunately, we have to do some head banging until we get this right

Yes, this is too much work. We need to break down the requirements for this in our design kickoff meeting so that we start with the end goal in mind. They way I see it, when the test suite is started, that's when the server needs to come up. The server stays up while individual test artifacts are run. Then the server comes down. The server going up and down needs to be distinct phases.

As I see it, the user shouldn't have to configure the plugins directly. He should do this using the container configuration (which we don't have yet). So, there still a lot of work in order to make it really work.

+1. We absolutely want to get out of the business of mucking around with Maven plugins. We need to tie into the regular test setup transparently. We need the Jetty run experience (okay, that's a Maven plugin, but our plugin is Surefire).

Out of curiosity, what are the benefits of using the Embedded API instead of calling the org.jboss.Main directly (with the run.jar in the classpath)? It could be then easily adapted for each AS version.

ALR does a great job of explaining the need in his blog entry No Pain, No Pain | Embedded APIs for JBoss AS. As I understand it, starting and stopping the server is just one small aspect of what an embedded API needs to be able to do. Other tasks are configuration, startup callbacks, deployment, and so on.

I can't believe I missed this post initially.

Agree with all useability points.  We should require the user to do as little as possible.  That said, some explanation about the current setup:

Application Server was not built to be an Embeddable runtime.  It's a standalone piece of software to be installed in the filesystem, so the whole hack of the Maven dependency plugin is just to go online, fetch it from a repo, and install it (so the user isn't doing this manually).  Until AS 6.0.0.M1, the AS distribution wasn't even a Maven artifact; it had to be fetched from SourceForge.  Even now the two distributions aren't identical (we'll fix that).

Configuration is another issue.  The EmbeddedAS APIs now allow for configuration similar to that which might be specified when starting at the command-line (ie. launch parameters).  But most AS configuration is done by its files internally, hence beyond the scope of the Embedded APIs.

My feeling is that we can only go so far with things like ShrinkWrap and Arquillian.  They define APIs and tie into existing test frameworks' lifecycles.  At the end of the line we need a truly Embeddable container, and JBossAS does not fit that criteria.  JBoss Embedded EJB3 will, for instance.

S,

ALR

My feeling is that we can only go so far with things like ShrinkWrap and Arquillian.  They define APIs and tie into existing test frameworks' lifecycles.  At the end of the line we need a truly Embeddable container, and JBossAS does not fit that criteria.  JBoss Embedded EJB3 will, for instance.

We are at an interesting junction point (the industry in general). People want to embed and we are shoehorning a long history of standalone installations into this new need. So I 100% agree that the long term goal (hopefully not too long term) is to have an embedded container (I won't even say EJB 3 since it is really more general than that).

There is a lot we can do in the short run though. If you look at Embedded GlassFish, what they are doing isn't too far off from Embedded AS. They have the same problem that some of the configuration is specified in the domain instance. So what they do is create an instance on the fly and stick it in a temporary directory (for some reason they thought a good choice for a temporary directory is the current directory, but I digress).

So, we could have the Embedded APIs create a JBoss AS domain on the fly in a temporary directory to take care of the "configured only by file" settings. I think as long as we give the impression that the server is embedded (no work for the developer to "install"), then we will satisfy people a great deal in the short run.

This ties into discussions we have in AS about package managers and the ProfileService.

For instance, a package manager takes a very slim boot JAR (and slim classpath dependency) and knows how to install components from some repository (Maven2, or locally, for example) and make it available to ClassLoading.

The ProfileService is a component capable of handling course-grained requests (ie. "give me EJB3 and JBossWeb") and in turn knowing the dependencies this must pull in first.  It's a central authoritative view, which can then trigger the deployments necessary to bring up requisite subsystems.