> > Redesign deployment system to use Deployment (or DeploymentController) > > object instances to perform work for a single deployment. These objects > > are created by a factory, which lives and is configured from the client > > deployment API or DeploymentManager. A simple type -> classname map can > > be used to object creation. > > This may not be so easy. I'm partial to the current system of asking > deployers what they can do.
I don't see that it is all that complex. Rather than having singleton deployers, which contain deployment logic (and may or may not create deployment state objects), I suggest using a simple factory to create a state/controller object that handle handle all of the work itself. It does not seem like there is all that much shared state required between deployements, that which I have seen are unique number generators and the like. I was also thinking of keeping the deployer concept around and making a deployment a stateful translating proxy to the correct deployer (filling in the details that the deployer needs todo its work), but I could not see why it would make sense to complicate things in that manner. What would the deployer do, which the deployment instance could not? The only thing that I could think of was track a list of deployments, but if the deployment is bound to JMX (and named properly), then this is handled by the mbean server already. It seems like the current deployers are a bit more complex than they really need to be. By changing the way we look at them we can make things much simpler, and gaining some more administrative control. Granted, we could make DeploymentInfo, but that seems like a bloated hack. So, MD creates a DI, which holds its basics, then the real deployer possibly creates its own state object. If we want to expose different management functionality per deployment, then we have to have two objects, rather than one. If Deployement is a simple interface, then the factory would lookup and create a concrete instance of one. This object would probably be a dynamic mbean, or could be a pojo and be wrapped by a model mbean, thus allowing it to expose in the same mnmgt interface more api. > > > > Deployment objects are bound into JMX under jboss.deployments, and have > > methods to deploy, undeploy, remove. This provides a rich management > > interface to what is deployed and to easily redeploy. > > > > Retain existing DeployerMBean API and mapper for compatibility. This > > will allow clients to connect to the DeploymentManager API, use a > > deploy/undeploy method with a URL, which will then be translated and > > proxied into a call to the deployment bound in JMX. > > > > The DeploymentManager's job is to create Deployments for a given type of > > deployable content. As I mentioned before, this can be a simple JMX > > configurable map of type to deployment classname. Type will be > > initially discovered by the URL passed in, though we could eventually > > move to something more advanced using mime-types or something... eaither > > way once we have a 'type', we can get moving. > > > > The DM will also manage setting up the local file bits for now. Any > > other system level config will be passed into the Deployment during > > initialization. > > > > Once initialized and bound to JMX then it can be deployed/undeployed and > > so on. This introduces a new wrinkle in that a deployment could be > > bound, but not deployed or passive. This lets admins undeploy with out > > losing the interface to that deployment. Passive deployments can be > > removed when not needed any further. > > this happens now, you just can't see it. I am not sure what you mean here... there is a lot in the above, which most certain does not exist. Perhaps you mean that the MD, proxies requests to the real deployer? I understand that, but take a look at what it would take for an admin to look at the html adapter and see what is deployed, the undeploy or redeploy one or more apps? You can't really do it... you need the exact url, used to make the deployment in the first place. I can certainly see exposing DI to solve this, but I think that is only a bandage. If a particular deployment needs some other factory-like presence then it may choose to proxy requests over to it, but the underlying call chain would still go through the Deployment. > > To help the deployment system become more file independent, we need to > > move the 'auto deployer' functionality to an external component. Since > > deployer is overused in our environment, I suggest we rename this type > > of beast to a DeploymentScanner, since that is what is does, scans for > > deployment changes. > > > > DS is a simple interface which hooks up to the DM, via JMX. Its sole > > job is to detect new, removed, updated deployments and letting the DM > > know about them. > > Yes, I suggested this several months ago (autodeployer + universal > deployer). Marc just implemented them together. Right... well we should fix this. > > > > Initially we will provide a LocalFileDeploymentScanner, which does what > > the AutoDeployer did (and MainDeployer does). > > Current maindeployer is happy to look at http* urls also. I saw something about that in MD, but was not too sure what it was doing there. In any case, this functionality should be moved. > > > > This is pluggable, so we can have any number of these running, once we > > figure out how to get auto deployment detecttion working over different > > protocols. > > What protocols are you thinking of? ftp??? FTP would work, but I did not have a particular protocol in mind. If you take a look there is lots of "http" specific hardcoding all over the place. To remove that (or rather lessen in) we simply make it protocol unspecific, such that a user could implement it anyway they needed. https is one example of where all of this will break currently. The changes are conceptually minor, but I wanted to include it here tyo make it clear that it should be done. > > Any comments? > > > > -- definitely post 3.0 > > -- I think 95% of what you want will occould not see that there would be anything >special that deployer would need to to,ur simply by making DeploymentInfo > into a (possibly dynamic, with extensible interface) mbean. This can > perhaps be the jsr77 management bean, for ejb-jars and other j2ee modules. See my comment up further on this. Some deployments might not have a jsr77 anything (like sar, can't really imagine that being part of jsr77 at the moment). Even so, with the model I describe it would be better suited to add these types of admin apis, rather than using the current. > -- I don't see the benefit to changing the overall structure past > a. separating scanner and "deployment sorter" functionality Right, this one is a given. > b. making DeploymentInfo an mbean. Again, I thought about this... actually, I wanted to implement it like this at first, but after looking at how things work and thinking about the administration effects, I decided against it. > I'm not sure about what you're saying about string/url/file. I think I've > cleaned it up a bit today (will commit very soon) Take a look at MainDeployer.copy(), it takes URLS, but they should probably be files. There are other inconsistencies too. This is the type of stuff that I cleaned up in Main/Server when updating the booting system. I guess I also meant that we should stop providing string adapter methods. The main problem that I see here is that we don't leave those as just adapters for other JMX clients (like the html adapter), but we start using those string versions in our own code. I think we should stop this, rather fix the client in this case. > -- A while back I proposed a deployer architecture that while based on the > current separation of unpacking/classloading and deployment descriptor > processing modified the deployment descriptor step into: > a. processing using xslt all relevant dds (such as ejb-jar.xml, jboss.xml, > and jbosscmp-jdbc.xml) into a single xml file containing a > jboss-service.xml format file > b. Used the SARDeployer to construct everything specified. This will > obviously require a sophisticated xml<->object mapper as you mentioned in > another post tonight. I remember you talking about this, and think it is a good idea. I don't have the full picture of that in my head though. I don't think that such and impl would really need to follow either of the two models. Essentially, I think that we need to provide a richer admin interface to the deployment system, such that it is easy to see what is deployed and is easy to change the state of those deployments. While this can be done in any number of ways, I believe that something similar to what I have described would provide the most flexible system for providing that admin interface with out bloating the system with adapters. I actually think it may optimize it some, but allowing the deployment to put all of its state into one place, and provide admin functionality there too. Also, by redesigning it this way, we remove the possibilites that one might cause inconsistency in the DI and the deployer which manages it. --jason _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
