Relationship Between DeployableContainer and TestEnricher

[alrubinger]

Currently there's no association between DeployableContainer implementations and the TestEnricher types.  Ordinarily I think this would be fine, but each of these impls must be created with a no-argument constructor (meaning we cannot create the association on our own as needed by supplying a construction argument).

In doing the Reloaded ARQ Container we start an MCServer in the DeployableContainer.  However, it's this server which is also responsible for doing the test enrichment (ie. injection), and I imagine that could be a pretty common case.  The container has access to resources that the test may want.  In OpenEJB etc we get around this because the correct JNDI Context is obtained via system properties which fly under a real API radar.

How do we feel about bridging the gap and making "enrich(Object testCase,<? extends DeployableContainer> container)" or similar?

S,

ALR

[alrubinger]

Note that my workaround for this currently is a package-private, static ThreadLocal.  It widens the scope to an inappropriate level, but enables the TestEnricher to see stuff available to the DeployableContainer.

S,

ALR

[aslak]

Yea, I do the same in the Weld Container. Not pretty.

There is a problem with having the DeployableContainer as an argument to the Enricher tho, they're not really connected at runtime. They could even be running in two different VMs. The Enrichment is done inside the container after deployment, so you no longer control the DeployableContainer.

In a embedded/standalone container things are a bit different, since we actually have a reference to it, but the API should reflect the common ground.

I'm about to commit the new Arquillian Core which is a bit more dynamic. If we give TestEnricher and DeployableContainer access to the Context they can share state that way.

[alrubinger]

Aslak's kindly outfitted us with a Context object to pass between DeployableContainer and TestEnricher.  To take a bit of a different tack, is there anything preventing us from creating TestEnricher instances directly (no no-arg ctor required)?  Same applies for the Containers and Configuration actually; what is the driving force mandating we use the Java Service Provider facilities?

If we found another way we might be able to have some more flexibility with manually assigning state to a desired component, and we could strip some of the plumbing involved with passing contexts throughout.

S,

ALR

[aslak]

SPI was/is used for auto discovery of impls. No config.

Who will create the Container or TestEnricher instances? How would I add my own Enricher in the mix ?