On 2002.02.11 18:46:32 -0500 Jason Dillon wrote: > I was thinking this weekend, while I was having trouble sleeping > (again), about our deployers and how there isn't a very usable admin > interface to what is deployed and so on. More specifically, there is > not a domain, which lists mbeans which relate to a given deployment. I > was also thinking about some ways to reduce the dependency on files (or > rather abstract that dependency into something external from the primary > deployment components. > > I took a look at how easy it would be to add a simple facade over the > current system to add a DeploymentController which would simply live in > the MBeanServer and allow administration of that deployment. I think it > can be done, but anything would be a hack given how things work at the > moment. So I started thinking about changing the model so that we can > achive the same results with out having to muck up things, and here is > what I came up with. > > * * * > > 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. > > 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. > > * * * > > 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. > > 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. > > 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??? > > * * * > > At the same time, we should clean up the usage of URL, Strings and > Files. More specifically, use URL for everything over String (string > was only really there for JMX administration, but since a URL can be > constructed from a String I think this is a admin client coercion issue > and we should not muck up our components with this garbage; btw i have > written such a corecion system which can easily be integrated into a > http adapter once we have one of those which isn't the RI). > > Also lets not use URL when we really mean local File. There are some > places in the MainDeployer which take URLS, but those URLS must be > files... so it would be better to have them take files instead. > > We should also not hard code any http specific bits. There are if proto > is "http" or "file" all over the place, which I think we need to get rid > of. Could be running over https, or some other protocol. We should not > care. > > * * * > > All that said, I think this is a project best suited for a post 3.0 > release. Since Scott is going to branch on tuesday for 3.0, then this > should probably go into main, and be slated for a 3.1 release or > something. > > I think that it will take about a week to get all of this squared away. > > The end result will be that our deployment system will have a richer JMX > interface, which admins can use to control there system better. Plus it > will be more protocol independent and freer from the file system. > > Any comments? > -- definitely post 3.0 -- I think 95% of what you want will occur 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. -- I don't see the benefit to changing the overall structure past a. separating scanner and "deployment sorter" functionality b. making DeploymentInfo an mbean. 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) -- 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 plan to work on this last part very shortly. david jencks > --jason > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
