deployer prototype

[bill.burke]

I recently checked in a Deployer prototype within the kernel/ module under the org.jboss.deployment package. There is also a TestCase under tests/org/jboss/test/deployment.

It is mostly bare bones with code taken from the Embeddable EJB3 deployment. THe goal of the prototype was to have a generic deployment mechanism that is usable in a Java SE environment, but with some thought put into how it can morph into a full-blown application server environment with scoped classloading.

What I got so far is a MainDeployer, Deployment, Deployer, and DeployerAspect interfaces. It has the notion of DeployerAspects at the MainDeployer configured level. There is one classloader deployer aspect, but all it does is sets the Deployment's classloader to be the TCL. Right now, if you look at the testsuite. It has one example that scans a jar and directory based classpath for MC -beans.xml files to deploy. It has one MCDeployer implemented.

Unless I get shutdown by you guys, my next steps are:

1. Get embeddable EJB3 stack running in this environment: AOP deployer and EJB3 Deployer.

2. Write an "app server" version that incorporates Scott's VFS classloader. Figure out how deployer aspects can be used for this. If the AOP/MC integration is done, I think interception should be done/configured per deployer rather than at the MainDeployer level. I'll fiddle with this to see what can be done and what works.

3. Define a usecase for the profiler (i.e. MDB configuration options). Pull in parts of the Scott's profiler service APIs and fool around with how these options could be saved/exposed/etc.. at runtime. I would play with any APIs Scott/Adrian come up with, pulling, copying, pasting, reusing profile service code. The deal would be to evolve something that already works in steps 1 and 2.

I can probably have all three done by JBoss World if you can wait that long. Would have it done sooner but, I have training and Java One coming up as well as another EJB3 release.

Bill

[adrian.brock]

See my response on the dev list.

Summary:
This should be based on the VDF (virtual deployment framework)
and be in separate project.

See other posts for VDF != VFS

[adrian.brock]

Let me take a more concrete example from your prototype.

You have a "classpath bootstrap", that decides what needs to
be deployed based on parsing the classpath.

This is the job of the profile service.
It decides what needs to be deployed whether it is
* the jars in the classpath
* a URLDeploymentScanner
* a static list
* a versioned profile in some "database"
* etc.

The deployer deploys, it does not decide what is deployed.

Another...

You have a DeployerAspect. But it does not deal with a deployment.
It deals with a virtual file.

It is the job of the VDF to decide how a "file" is decomposed
into its subdeployments and which deployment aspects should be invoked and in what order.

That is once it has been told what the top level virtual file is by
the profile service.

[bill.burke]

Let me take a more concrete example from your prototype.

You have a "classpath bootstrap", that decides what needs to
be deployed based on parsing the classpath.

Correct. It doesn't define a profile, which is what it should be doing. It should be assembly a profile based on the classpath. It should be a ProfileFactory.

This is the job of the profile service.
It decides what needs to be deployed whether it is
* the jars in the classpath
* a URLDeploymentScanner
* a static list
* a versioned profile in some "database"
* etc.

I disagree. The profile service should be a service that takes a profile and deploys it by delagting to the appropriate deployers. If you take things in terms of JBoss 4.x and the Microkernel:

Scanner -> Profile Factory
MainDeployer -> Profile service

The problem with 4.x is that the scanner creates one profile per deployment, when what we want to do in 5.x is for the Profile Factory to define a set of deployments (a profile).

In my mind there would be different Profile Factories:
* One that scans a classpath and creates an in-memory profile
* A URL Scanner
* one that loads a profile from a serialized file
* etc...

The Profile Service deploys, undeploys, and redeploys profiles.

The deployer deploys, it does not decide what is deployed.

You have a DeployerAspect. But it does not deal with a deployment.
It deals with a virtual file.

Untrue.

It is the job of the VDF to decide how a "file" is decomposed
into its subdeployments and which deployment aspects should be invoked and in what order.

That's exactly what my MainDeployer is currently doing. But, I think you're gonna want to have aspects tied to each Deployer rather than defined at the "top-level". Consider classloading. For each deployment type the ClassloaderAspect defaults are gonna be configured differently. What I think you'll have is a default AOP domain for deployment aspects, then each deployer may override the default AOP domain and configure their aspects differently.

That is once it has been told what the top level virtual file is by
the profile service.

I think you've got it backwards. I think it should be:

1. A scanner obtains list of top level VirtualFiles
2. Scanner hands off top level VirtualFiles to a MainDeployer, VDF, or whatever you want to call it. VDF matches VirtualFiles to deployers and creates Deployments aggregated in a Profile.
3. Scanner then hands off created Profile to ProfileService.
4. ProfileService deploys Profile into runtime.

Step 1-2 could be skipped if there is already a pre-existing profile (on disk, db, on network).

Bill

[starksm64]

I think you've got it backwards. I think it should be:

1. A scanner obtains list of top level VirtualFiles
2. Scanner hands off top level VirtualFiles to a MainDeployer, VDF, or whatever you want to call it. VDF matches VirtualFiles to deployers and creates Deployments aggregated in a Profile.
3. Scanner then hands off created Profile to ProfileService.
4. ProfileService deploys Profile into runtime.

Step 1-2 could be skipped if there is already a pre-existing profile (on disk, db, on network).

Bill

I don't think a scanner like a hot deployment scanner has any interaction with the profile service now. The scanner is simply another service that was activated as part of the static profile. The profile service needs the VDF to deploy content in general.

Redeployments are also independent of the profile service. It could be that an update to a running profile triggers a redeployment but this is the result of a lifecycle dependency wiring.

[starksm64]

Another task associated with all of this VDF, ProfileService, etc work is a need to refactor the aspects and annotations sitting in the embedded ejb3 project into pojo server projects that own the aspects. @SecurityDomain, @Management are the two most obvious examples of aspects that have to be reused. org.jboss.annotation.ejb.Management is a pure mc/pojo server notion that should have aspects configured in the VDF layer to deal with this behavior.

In the ProfileService the most recent change is a related @Management annotation to identify those attribute which are candidates for the deployment management view. This is really a general notion that can be reused across all mc configurations that include a management aspect. jmx, jsr77 and jsr88 are also all related. A management project that pulls together these annotations, aspects and services seems needed.

A j2se style common annotations project seeded with the jsr250 annotations as a common base metadata library would also seem to be needed.

[adrian.brock]

I disagree. The profile service should be a service that takes a profile and deploys it by delagting to the appropriate deployers. If you take things in terms of JBoss 4.x and the Microkernel:

Scanner -> Profile Factory
MainDeployer -> Profile service

No the profile service is a client side api. It can/should be
capable of being run offline.
Running it inside the address space is just a choice.

It is the job of the VDF to decide how a "file" is decomposed
into its subdeployments and which deployment aspects should be invoked and in what order.

That's exactly what my MainDeployer is currently doing. But, I think you're gonna want to have aspects tied to each Deployer rather than defined at the "top-level". Consider classloading. For each deployment type the ClassloaderAspect defaults are gonna be configured differently. What I think you'll have is a default AOP domain for deployment aspects, then each deployer may override the default AOP domain and configure their aspects differently.

That is once it has been told what the top level virtual file is by
the profile service.

I think you've got it backwards. I think it should be:

1. A scanner obtains list of top level VirtualFiles
2. Scanner hands off top level VirtualFiles to a MainDeployer, VDF, or whatever you want to call it. VDF matches VirtualFiles to deployers and creates Deployments aggregated in a Profile.
3. Scanner then hands off created Profile to ProfileService.
4. ProfileService deploys Profile into runtime.

Step 1-2 could be skipped if there is already a pre-existing profile (on disk, db, on network).

Bill

[starksm64]

I'm not seeing this in the current kernel module. Was this checked in?

[adrian.brock]

I removed it from CVS.
It was in the wrong place.
The tests were broken anyway.