Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] created the discussion "AS 7 Deployment APIs" To view the discussion, visit: http://community.jboss.org/message/559597#559597 -------------------------------------------------------------- Thread to discuss the client deployment APIs for AS  7. This thread is closely related to and will probably interweave with ALR's thread at https://community.jboss.org/thread/154922?tstart=0 https://community.jboss.org/thread/154922?tstart=0 but that thread has a scope beyond AS 7, so I want a separate one for the purely AS7-focused aspects. I've posted some thoughts on deployment API in code form in a topic branch on my github repo. See http://github.com/bstansberry/jboss-as/tree/hot-deploy http://github.com/bstansberry/jboss-as/tree/hot-deploy and in particular http://github.com/bstansberry/jboss-as/tree/hot-deploy/domain/src/main/ja... http://github.com/bstansberry/jboss-as/tree/hot-deploy/domain/src/main/ja... That work is just a draft and a basis for discussion. So thoughts and comments are very much wanted. The impl subpackages there aren't critical, particularly domain/impl which is for sure wrong. I'm mostly interested in the other packages, which express the API. Note also that much if not all of this should probably move out of the domain module. There are 2 subpackages, domain and standalone. This is because the API for the full DomainController use case is significantly more complex. There is a fair bit of duplication between the two; perhaps some refactoring could be done once we decide what we want. The core of this is a client: 1) Gets a reference to DomainDeploymentManager or StandaloneDeploymentManager. How is TBD. 2) Client creates a DeploymentPlan. This describes a coherent unit of work that should be done to add deployment content, deploy content, undeploy content, remove content. Creation of the DeploymentPlan is done by getting a Builder object from the deployment manager and invoking operations on it. StandaloneDeploymentManager deploymentManager = magicallyGetDeploymentManager(); File war = getWarFileFromSomewhere(); URL ear = getEarURLFromSomewhere(); DeploymentPlan plan = deploymentManager.newDeploymentPlan()                                        .withGlobalRollback()                                        .add(war).andDeploy()                                        .add(ear).andDeploy(); The main part of the API is in the Builder interfaces that start from the return value from StandaloneDeploymentManager.newDeploymentPlan(). There are five basic operations: * add -- makes deployment content available to the standalone server or to the domain controller * deploy -- instruction that previously added content should be deployed on a standalone server or to one or more server groups * undeploy -- instruction that previously deployed content should be undeployed from a standalone server or from one or more server groups * replace -- atomic deply+undeploy. So if rollback is enabled and deploying the new content fails, the old content would be deployed * remove -- remove no longer deployed content from the repository where the standalone server or domain controller keeps content. I tried to create a fluent API so following one directive to the builder, logically coherent other directives become available, e.g. add(war).andDeploy() 3) Client asks deployment manager to execute the plan; gets back a DeploymentPlanResult which can be inspected to see what happened. The DeploymentPlanResult returns a Future for each action that went into the deployment plan, so the client can review the result asynchronously. DeploymentPlanResult result = deploymentManager.execute(plan); I'll post more later today on some of the nuances, but that's a quick intro. I did a lot of javadoc, so the best way to understand is to poke around. A few other basic points: Deployment content once added to the system has a identifying key, in this draft represented by the DeploymentUnitKey class. That's basically an encapsulation of the name of the deployment and it's SHA1 hash. Making clients use the DeploymentUnitKey class feels a bit clunky, so overloaded methods that just use a String form (e.g. "foo.war/a1b2...") are available. Perhaps we should only use the String form in the API? The API also includes a "repository" notion, e.g. add(String name, String repository, URL content). This isn't core to the API -- it's to support a notion of separate locations where a standalone server could store deployment content, one or more of which might be a hot deployment repository with an associated scanner. We need a separate discussion on whether this is the right way to do hot deployment. If not, the "repository" notion in this API could go away. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/559597#559597] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]