Deployers in AS

[alrubinger]

We've previously talked about the deployers being an integration point with AS, and therefore should be placed within the AS source tree.

Why is this the case? I thought the deployers only depended on (sometimes each other and) MC. If they were to be removed, we wouldn't have to mock up/recreate their functionality when Unit Testing other areas that depend on Deployers' output.

As a concrete example, the EJB3 Proxy Component makes use of output from the MergedJBossMetaDataDeployer and Ejb3Deployer. Am I mocking up this data when I could be setting up an MC Deployer Chain from the real thing?

S,
ALR

[starksm64]

That is probably true for the newer more aspectized deployers, but 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.

[alrubinger]

I'll put it on my "for another day" wishlist. :)

Thanks for clearing this up.

S,
ALR

[adrian.brock]

"ALRubinger" wrote:
We've previously talked about the deployers being an integration point with AS, and therefore should be placed within the AS source tree.

That is correct. Here's a repeat of the reasons I've stated before in both the aop,
tomcat and webservices forums.

NOTE: This is an idealisation of where we want to get to, rather how it has
actually being done now.

1) DO IT

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.

The deployers are just a mechanism to construct metadata and then
create the MC ControllerContext(s) that will actually instantiate the real objects.

The parsing available in the metadata project (from ejb-jar.xml and jboss.xml)
should be enough to write your tests (using the same hooks that the deployers
use to create the real objects).
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.

i.e. Appserver/deployers is:
Some artifacts -> metadata
ejb3 is:
ejbmetadata -> ejb3 container

The examples I give are the MC and new classloader. Neither of these projects
depend upon the deployers. Instead there are deployers that integrate this code.
e.g. when I test unit test the classloaders, I just parse the
jboss-classloading.xml (or create it programmatically) and then use the
same ClassLoading api that is used by the classloader deployers.

2) Standalone usage

The individual projects should not depend upon the appserver's deployers
or even the deployment api.
Use case: If I want to re-use ejb3 programmatically I should just be
able to instantiate the ejb3 metadata and make some call to a factory in the ejb3
project.

If I have to mock out deployment api (which I have to do with the current ejb3 api
because it wronglg depends upon the deployers api)
or otherwise make use of appserver specific stuff there is something wrong.

This also reflects the idea that the deployer and runtime are different ideas/artifacts.
i.e. the ejb3 deployer(s) are just responsible for creating and manipulating metadata
then using the MC to activate it via the runtime component. (See for example
the split we did of the Tomcat service).

There should be no runtime parameters/service injection etc. onto the deployers
that should be injected onto the runtime service.

NOTE: There's another reason for this seperation which is we
want to be able "bootstrap" an appserver configuration "offline" in
a management client to verify it works without actually starting it.
i.e. it just goes through the deployers and dependency validation without
actually constructing the real services.
This is impossible without a proper seperation.

3) Configuration

Deployer and runtime configuration is a policy decision of the appserver.
If I want to swap out, augment or otherwise change how EJBMetaData gets
constructed that is something that is done in the integration project i.e. the AS.

The configuration files should therefore live there where they can be easily changed.

To make version control easy/managable, it also makes sense for the deployer to live
in the same codebase (although obviously not a requirement).

But more importantly, there will be many different configurations/implementations.
e.g. JBoss Embedded has a totally different mechansim (search the externally
constructed "classpath") on how to find ejb deployments to
what the appserver does.


SUMMARY

EJB3's job should be to provide a Runtime service that can be used to
construct EJB3 container(s) from EJBMetaData (and others)
with other service injections onto that service.

The Appserver's job (or any other project) is to create that metadata
(currently done using the aspectized deployers) and use that Runtime service
(currently done via the MC).

[alrubinger]

The parsing available in the metadata project (from ejb-jar.xml and jboss.xml)
should be enough to write your tests (using the same hooks that the deployers
use to create the real objects).
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.

This assumes that EJB3 is intended for use only within the AS Environment. The Deployers in question need be an integration point only between jboss-metadata/MC and ejb3/MC, not AS. If I want to start up an Embedded or Standalone EJB3 Environment, I should be able to use the same Deployers, as they depend only on the MC Deployment API and other dependencies of EJB3.

The individual projects should not depend upon the appserver's deployers
or even the deployment api.
Use case: If I want to re-use ejb3 programmatically I should just be
able to instantiate the ejb3 metadata and make some call to a factory in the ejb3
project.

The EJB3 Components should not depend on the Deployers, true. Only metadata, and I'm doing a refactoring effort now to create Containers from only the metadata objects. The end result will eventually make programmatic creation of an EJB possible.

However, an Assembly of EJB3 Standalone/Embedded should be able to re-use the same Deployers used in AS. That way, we don't have to create the metadata on our own by duplicating the logic already written.

Deployer and runtime configuration is a policy decision of the appserver.
If I want to swap out, augment or otherwise change how EJBMetaData gets
constructed that is something that is done in the integration project i.e. the AS.

AS is not the only target integration project. So configuration is a policy decision of whatever is providing the runtime, and this is achieved by editing the ejb3-deployers-beans.xml file accordingly.

S,
ALR

[adrian.brock]

"ALRubinger" wrote:

This assumes that EJB3 is intended for use only within the AS Environment. The Deployers in question need be an integration point only between jboss-metadata/MC and ejb3/MC, not AS. If I want to start up an Embedded or Standalone EJB3 Environment, I should be able to use the same Deployers, as they depend only on the MC Deployment API and other dependencies of EJB3.

JBoss Embeded and JBoss AS sharing the same metadata processing features
(or not) is a different issue to what EJB3 should do with the metadata they supply

[alrubinger]

JBoss Embeded and JBoss AS sharing the same metadata processing features
(or not) is a different issue to what EJB3 should do with the metadata they supply

In this case, I'm talking strictly EJB3 Embedded, not JBossAS Embedded.

We've established and agreed upon the responsibility of EJB3 to produce EJBs from metadata, no matter how it's supplied.

Back to the main question of the Thread: What is preventing us from moving the EJB / Metadata Deployers out of the AS Source tree such that another Assembly may consume them without depending upon AS? In turn, AS would consume the same deployers and use them just as they are now, only on the CP as JARs.

S,
ALR

[alrubinger]

"ALRubinger" wrote:
Back to the main question of the Thread: What is preventing us from moving the EJB / Metadata Deployers out of the AS Source tree...

Aside from the pieces Scott has identified as needing abstraction and extraction. I just want to hear "Yes, this is possible with some work, and wouldn't violate a central tenant of the AS Structuring Rules."

S,
ALR

[adrian.brock]

"ALRubinger" wrote:

"ALRubinger" wrote:
Back to the main question of the Thread: What is preventing us from moving the EJB / Metadata Deployers out of the AS Source tree...

Aside from the pieces Scott has identified as needing abstraction and extraction. I just want to hear "Yes, this is possible with some work, and wouldn't violate a central tenant of the AS Structuring Rules."

Yes, that's possible. But that's a minor task compared with making sure the
cart doesn't lead the horse, i.e. the EJB3 runtime doesn't depend upon the deployers.