Porting Deployers to EJB3 Source Tree

[alrubinger]

Time to address this again, after some more thought. Previous discussion is:

http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4151711

The Problem:

Timeboxed EJB3 Releases assume that no changes will be required of AS Deployers, regardless of whether an SPI has been altered. Because Deployers are orthogonal (in most cases), their role is decoupled from compile constraints, but we still rely heavily on their output. Most relevant here is the preparation of the metadata from which we create EJB Containers.

Can't Have it Both Ways:

...legacy deployers like ejb2 and the war deployer still have way too many dependencies on other jbossas pieces to pull out.

The Ejb3Deployer does have other integration pieces like JBossASDepdencyPolicy, JBossASKernel, Ejb3JBoss5Deployment, so those would have to be separated out into another layer and injected when configured for jbossas.

In other words, in the present setup we cannot simply move the deployers out of AS as they're needed by other AS components. We also cannot update them from the EJB3 Plugin in subsequent EJB3 releases. So we're stuck in an undesirable situation.

For this reason, we must provide an EJB3 component to define deployers (I use this term generically, this is not necessarily MC Deployers SPI) without AS dependencies. AS may then bring these in.

A Disagreement over EJB3 Project Scope:

Individual projects should not be making policy decisions. They're job is to "do one thing well". In ejb3's case, its task is to create an EJB container from an EJBMetaData object.
...
You don't care how the EJBMetaData gets constructed, that is a policy decision of the appserver. e.g. parsing annotations, programmatically or something else.

EJB3 should be able to take in artifacts, create the appropriate metadata, and deploy; this is what will enable us to run outside of the AS. In our Unit Tests we're currently hacking up metadata in an inconsistent fashion to mock the deployers' actions.

It is the responsibility of *EJB3 Core* to create Containers from Metadata. However, there's nothing preventing an "EJB3 Deployers" Component from providing metadata creation out of JARs, EARs, or even .class files.

Proposal:

Stemming from some thoughts and discussions with Carlo and Ales -

* Create "org.jboss.ejb3:jboss-ejb3-deployers" in repos/jbossas/projects/ejb3
* Deployers to be created must rely on a new vendor-agnostic SPI
* The Deployers themselves become an MC-specific plugin to the SPI abstraction. This decouples the EJB3 deployment mechanism from MC, and further paves the way for EJB3 to run atop other IoC providers.

The Take Home:

* We provide a mechanism for deploying EJBs outside of AS (rapid-development, user-friendliness)
* We further decouple from MC's Deployer SPI, in direction to support arbitrary IoC Containers (user choice)
* We may then continue with EJB3 Releases without worry of what's changed within the AS deployers upon which we currently rely (timeboxing, a stated EJB3 Project Goal)

I haven't been Brocked in awhile, so let's hear it.

S,
ALR

[starksm64]

"ALRubinger" wrote:

Can't Have it Both Ways:

...legacy deployers like ejb2 and the war deployer still have way too many dependencies on other jbossas pieces to pull out.

The Ejb3Deployer does have other integration pieces like JBossASDepdencyPolicy, JBossASKernel, Ejb3JBoss5Deployment, so those would have to be separated out into another layer and injected when configured for jbossas.

In other words, in the present setup we cannot simply move the deployers out of AS as they're needed by other AS components. We also cannot update them from the EJB3 Plugin in subsequent EJB3 releases. So we're stuck in an undesirable situation.

There is no reason to move all deployers out. Move the ejb3 deployers out into a separate project and ensure that the policy elements that need to be overridden like the dependency, kernel and deployment view have a proper spi that can be implemented by the runtime environment. That is all I and Adrian are saying as far as I can see.