(moving this here, the quoted stuff is from Sacha) anonymous wrote : | but do we agree that for all services that is deployable through | your system, you have a corresponding MBean that can be used to | perform such action? Is this MBean JSR-77 related (it should IMHO). | There is no "proxy/management mbean" for each deployment now, all operations (upload, create, deploy, undeploy, remove) go through the deployment service.
This is probably a good idea, i.e. keep DeploymentService as a factory and create wrapping proxies for all top-level deployments. Or infact, integrate somehow with the existing management mbeans and enhance their API to add methods like undeploy or remove. I'll need to think about it... anonymous wrote : | Furthermore, can the deployment process be synchronous (not | Asynchronous like the default deployment mode) and report any issue? | That is something that is currently missing: you cannot report an | error to a client that has launched a deployment operation. This will | be increasingly difficult in the future as we moving towards | clustering deployment and maybe should we directly move to some kind | of "transactional" or "two-steps" deployment where you can first ask | the deployer to "prepare" a deployment (check as much as it can that | the deployment should be ok i.e. that required dependencies, | resources, etc. are available) and then "commit" (i.e. effectively | deploy the service/app). Hence, in a clustered environment, we could | first ask all nodes if a "prepare" is fine and then issue a commit. We | might not want to go to full TX semantic but even a weak clustered | semantic would be better than a simply asynchronous try-and-forget | semantic ;) | The implemented API was the simplest possible to do at this stage, in the sense that we re-use the DeploymentScanner. We can emualate short of synchronous behaviour by waiting on the main deployer. If we want to be really synchronous we'll have to re-implement the Scanner functionality and somehow isolate the DeploymentService deployments from the ./deploy dir... So the question really is, given a new deployment in directory ./undeploy, how we deploy this? Either we give it to the scanner by moving this to ./deploy, (or ./farm, or ./hasingleton...), or we give it directly to the MainDeployer, but then we have to solve the problem how we treat a server start-up. (essentially we'll have to duplicate what the scanner does...) In any case, my initial intention was to solve the problem of having a deployment "factory", since a deployment in jboss is basically any type of package (.sar, .rar, .xml, .war, .etc). rather than just MBeans. If you have any ideas let me know! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3865733#3865733 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3865733 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
