I'm glad you asked about the "embedded service container" because I've been meaning to write up a definition.

I'm introducing a new name to make a distinction between:

a server

a service

I'm defining a server as something that provides multiple integrated services, such as a Java EE application server or a servlet container, and supports deployments natively.

I'm defining a service as something that provides a single component model or programming model, such as Hibernate, JPA, CDI, EJB or Spring. These technologies don't "boot up" (the way a server does) and they don't accept deployments.

Granted, it's not totally black and white, but for the purpose of our thinking, we'll consider them as distinct.

Spring is a service. You add the service to the container in a different way (in the deployment) than with CDI (provided by the application server). Keep in mind, Weld Servlet provides CDI to a servlet container through the deployment in the same way Spring works. How the service gets into the server is not all that relevant to this terminology.

Here are examples of embedded service containers:

Weld EE Embedded and Weld SE Embedded

OpenWebBeans Embedded

OpenEJB Embedded (special case in that it provides multiple services, but still not a container)

Hibernate (planned)

Spring Embedded

Here are examples of embedded server containers:

Jetty

Tomcat

Resin

GlassFish

WebSphere Application Server

You may wonder why the distinction is important. It matters when you switch to using a server container. In those cases, services are managed using a "service deployer extension" if the service is not provided by the container. Examples are Spring (in all cases), Seam 2 (unless running on JBoss AS <= 6) and CDI (if running on a servlet container).

In other words, you mix a server with a service deployer extension. For example:

Spring + Tomcat

Weld Servlet + Tomcat

Interesting to note, you can combine a service deployer extension with an embedded server container. However, the classpath leakage can be problematic, as you've experienced.

Thus, there are two "modes" for testing Spring with Arquillian:

Embedded service container (bootstraps Spring and feeds classes and resources from the ShrinkWrap archive to Spring) <= most similar to Spring TestContext framework

arquillian-embedded-spring-3

arquillian-embedded-spring-2.5

Service deployer extension (packages the Spring libraries in the ShrinkWrap archive that is deployed to the server container)

arquillian-service-deployer-spring-3

arquillian-service-deployer-spring-2.5

Thus far, you have implemented the service deployer extension. For more rapid development, it would be good to have an embedded service container, which works almost exactly like Weld SE Embedded. The embedded service container will not be useful for Spring MVC testing because there is no web component available (though the use of mocks can be explored, like Weld EE Embedded).

Does that help clarify things. (Keep in mind, I'm still refining this myself, so I value your feedback either way).

I'm not sure "deployer" is the right word here. Another possibility is "service", because it's as though you are installing the Spring service into the container. I guess "subsystem" would work as well, or "service-extension" (though that's kind of long and redundant).

In my opinion the most accurate term would be testenricher, but the "service" works for me.

After sleeping on it, I like "service deployer", which can be written "servicedeployer" or "service-deployer". We've used "testrunner" in the past, so I'm open to using the condensed form.

I think that the next step is write up an announcement for Alpha1 (can be brief) that we'll include as part of the arquillian.org blog. It's just a matter of creating a textile file and using other blog entries as a reference and jot down some of your thoughts. I'd be happy to revise. We can shoot for Monday, the opening day of GSoC coding