JSR-88 "permanet" deployment

[fabcipriano]

I think that the JSR88 JBoss needs a "permanet" deployment for pragmatic reasons.

Reading a suggestion from Dimitris in the http://www.jboss.org/index.html?module=bb&op=viewtopic&t=61945&postdays=0&postorder=asc&start=10 he said :
" In the DeploymentService prototype we recently added a uploadLibrary(URL src, String filename) method, it would be easy to add a similar uploadModule(url, filename). "

So instead use the MainDeployer.deploy method I´m thinking to use the DeploymentService.uploadModule to make the deployment in the JSR88 JBoss.

This form the deployment will be done by URLScanner and there is a little problem here. We dont know when URLScanner finished your job. So to resolve this problem we will need a start and stop JMX events from MainDeployer to know whwn a deployment module is finished.

I hope to implement this soon and suggestions are appreciated.

Thanks,
Fabiano.

[starksm64]

See the related posting:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3887389#3887389

There needs to be a seperate jsr88 DeploymentManager service on the server side that maps the javax.enterprise.deploy.spi.DeploymentManager methods onto the MainDeployer methods:

DeploymentManager.distribute : this needs to use the upload facility to make a deployment availble locally on the server.

DeploymentManager.start : this invokes the MainDeployer.deploy for the locally uploaded module

DeploymentManager.stop: this invokes the MainDeployer.undeploy for the locally uploaded module

DeploymentManager.undeploy : this physically removes the uploaded module from the server.

DeploymentManager.redeploy : this is simply a distribute/start combo.

[fabcipriano]

I agree with distribute, undeploy and redeploy procedure, but in my insignificant opinion I think that start and stop should use MainDeployer.

Because JBoss code map the JSR-77 status (starting, running, stopping etc) to the ServiceMBean(starting, started, stopping etc). This form the JSR-88 implementation will be like a suggestion of the j2ee deployment 1.1 specification item 4.6.2

Besides implementation of getAvailableModules and getNonRunningModules with jsr-88

implemented this way it will force us to read all modules in the local disk to find out the nonRunning modules.

In the other way the JSR-88 implementation let open this question when says in the item 4.3:
"A vendor may choose to initialize an application?s running
environment when the archive is distributed to the system or wait until the start action is called. The only requirement is that the application is not available to clients until the start action is called. Similarly a vendor may choose to shut down a running application?s environment when stop is called or wait until undeploy is called. The only requirement is that the application is made unavailable to clients when the stop action is called."

I´m using MC4J with jboss jsr-88 with the JBAS-2002 modification and I had no problem until now. I can stop, start a Module and see the state in the screen only a undeploy make my modules dissapear from the GUI.

Am I missing something ?

[starksm64]

I have no confidence that stopping/starting a deployment does the right thing in terms of restoring a completely functional deployment. Have you tested the 2002 patch with scoped deployments and actually used all deployment types after a stop/start?

The mapping to our existing deployment model from the jsr88 DeploymentManager is as I described. I don't want to mess around with the deployment semantics in 4.0.x production line.

The jsr77/jsr88 services need to be merged such that distribution of an application causes a jsr77 mbean to be created. The jsr77 layer needs to ignore the the CREATE_EVENT events for such mbeans. The MainDeployer.deploy will cause the deployments to reach their started state. The MainDeployer.deploy is invoked by the DeploymentManager.start.

The DeploymentManager.stop event needs to use the MainDeployer.undeploy to make the application unavailable. The resulting DESTROY_EVENT events also need to be ingored for mbeans being managed by the jsr88 layer.

Arguably the existing hot deployment service also needs to be merged/integrated with the jsr88 deployment service in order for there to be a consistent treatment of deployments.

[fabcipriano]

I tested a real EJB(Session, Entity, etc) application and the tests show (surprise!) that MainDeployer.stop/start do NOT work at all. The status is ok but it is impossible to access the EJB after a stop/start.

I thought that was not necessary to create another service to implement the JSR-88 deployment.

[fabcipriano]

Scott, please discard JBAS-2002/2001, for the reasons mentioned before. Thank very much.

[starksm64]

See the org.jboss.deployment.services.DeploymentManagerService I just committed. With this, the org.jboss.test.deployment.test.DeploymentTestCase is passing all tests. The MainDeployer is no longer used at all on the client side.

The only deployments that are managable through the jsr88 layer are those that have been distributed through its DeploymentManager. The distribute op copies the deployment to the DeploymentManagerService.UploadDir, the start op deploys the distributed copy, the stop op undeploys the distributed copy, and the undeploy op removes the distributed copy.

To make all deployments managable through the DeploymentManager, the hot deployment service needs to be integrated. This is not something that needs to be done for 4.0.3.

[dimitris]

Leaving aside the jsr-88 specifics, this has a lot of similarities with the other deployment service prototype. The main issues were how to serve non-local URLs from the client to the server for uploading modules, and whether or not to deploy synchronously from the upload directory or let the scanners asynchronously do their job.

I tried the second option, mostly because I was thinking a little ahead how to deal with ./farm. Without an API I'd have to replicate a lot of farm deployer's code.

In any case, after 4.0.3 we should see if we can unify some of this stuff.

[starksm64]

I think one unification should be to use the deployment scanner for deployment, with the addition of a deployment state to control whether or not a given item actually is deployable. The jsr88 directory could be just another element of the deployment scanner URLs list, but distribution marks the deployment as unavailble to the scanner. Only when the deployment is started is its state updated to allow for deployment. If the deployment state was just a file, this could also address another long standing issue of not being able to copy large content over slow links to the deploy directory.

[dimitris]

Scott, any particular reason for loading org.jboss.deployment.services.DeploymentManagerService under:
jboss.management.local:j2eeType=J2EEDomain,name=DeploymentManager?

I just noticed the web-console breaks because it uses the query:
JMX_JSR77_DOMAIN + ":j2eeType=J2EEDomain,*"
to get to j2eeType=J2EEDomain,name=Manager, 'servers' attribute

We are running out of names :)

[starksm64]

Ah, I fixed a similar problem in the JSR77SpecUnitTestCase. I'll just remove the j2eeType=J2EEDomain attribute from the jsr88 service. I don't see any other problem with having this service in the JMX_JSR77_DOMAIN, at least the web-console is working.

Of course the deployment tests are broke until you update to the new default jsr88 name.

[dimitris]

Sure, I'll make the console a little more resilient too, thanks.

[fabcipriano]

This is a try to unify hot deployment and jsr88. Getting ideas from this forum. This implemetation(http://jira.jboss.com/jira/browse/JBAS-2114) passed in all deployment tests:

URLDeploymentScanner now launch 3 events: URL_DEPLOYMENT_FAILED, URL_DEPLOYMENT_DEPLOYED and URL_DEPLOYMENT_UNDEPLOYED

DeploymentManagerService.startService(): listen for URLDeploymentScanner evants and config scanner to scan uploadDir

distribute() -> DeploymentManagerService --> upload file and rename it to "file".tmp to be ignored by URLScanner
start() -> DeploymentManagerService --> rename file upload to original name to be deployed by scanner
stop() -> DeploymentManagerService --> rename file to "file".tmp to be undeployed by scanner
undeploy() -> DeploymentManagerService --> delete "file".tmp
getAvailableModules() -> DeploymentManagerService --> union of modules deplyed by this service and the MainDeployer list

except modules deployed by jsr88

Restritions and TODOs:
- make mores tests to validate list union
- make tests to validate deployments that failed
- make sanner return ignored files case of JBoss server shutdown this form stopped modules can be recovered
- config scanner in DeploymentManagerService.startService() to ignore a jsr88 extention file ex. ".jsr88stopped"
- make tests about start/stop modules that was deployed using MainDeployer

[starksm64]

This http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3901705 post is a jboss5 work that ultimately affects the jsr88 deployer and needs to be considered for any updates to the 4.0.x codebase.

[fabcipriano]

ok, I'm a little busy these days and I still dont know about VFS or VDF , I'm reading about it in http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3860842#3860842
Is there other place to undertand this ?
This will be in the JBoss 4.0.4 too ?

Thanks.