(tests still running) Well, it looks like with the current system this simply will not work, as there is no hook to tell the mean it has been configured... which is what I expect create is for, but this will not get invoked until all of the mbeans from the current service descriptor have been registered and configured. Why?
I am guess it is because of the desire not to parse the descriptor more than once... which I can understand, but I think we have the technology to get around this, actually I am quite sure of it ;) Anyways, I am not knocking the current system, just planning on how we can make it better. I believe we can resolve this issue, make the service controller api more straight forward and easier to interface with directly (if needed), plus some other benifits which I have not imagined just yet, but I am sure they are there. The first bit is to turn our xml descriptor into something meaningful, a object model specific to the exact configuration for the descriptor. The model should be mutable, but in this case we don't care and thus it will probably start out as imuttable... imagine something similar to the collections framework to produce immutables too, as we will probably want to hold references to this config and be sure that no-one is going to muck with it. So, now I have an object which represents the service descriptor file, which probably has an Iterator over the mbean config objects. And so I iterator over them and then pass the buck on to the ServiceController, to do its job... which is to control the lifecycle of the service. I have not thought out the full interface to the SC, but it seems like when ServiceDeployer (SARDeployer) iterates over the config objects, that it really just has to tell the SC about it and then it is done. The SC has all the info it needs to then create/start the service. All the SD needs to do is to deal with the deployment archinve/directory/whatever, find the xml dd and create an object model from it to iterator over. So, taking a look at a single mbean, the SC can check to see if it has any depends (by checking the config object), if it does it can queue the mbean for installation/config/create/start once its dependencies have been met. If there are no depends, then it can register the mbean, configure it and call create() (which should be init... but whatever I can live with create =P) The only bit which I am not sure about would be when to call start(). If the mbean does not depend on anything, then it is possible to just start it, unless we want to wait for a signal from outside to start it... though I am not sure what that signal would be. Chances are that we want to install/create then start all of the mbeans in a single deployment unit at the same time, so then we can move the burden of iterating the mbean config list to the SC, rather expose an additional method that takes a mbean config iter (list or array, whatever), and then it installs/creates each (as dependencies permit), then calls start once that has finished... queuing start calls for later execution if depends not met (perhaps with a reasonable timeout mechanism to fail the deployment if the depends are not met, or at least warn us). Following this plan, it is possible to have a deployment unit which contains some services which will install/configure and create before some others, allowing them to perform setup... and back to the classpath service, it can now setup some UCL's which the other services can now make use of. Note that the other services do not have to be dependent on the classpath service, because since it does not depend, it will have its create called before the next bean is processed. And in this case, it will only be talking to the MainDeployer, which must have been created/started before hand or we would not be here. Now we can move JARDeployer and the Classpath stuff into jboss-service.xml as regular mbeans. This make the system more configurable, thus it can do more of what people want... as they can make it do more and it isolates functionality into nice little chunks... which is what mbean really are... nice little chunks of functionality which JBoss links up to perform wonderful magic for all to see. * * * Now, is that test done yet... no... but it is close. --jason On Saturday 25 May 2002 01:20 am, Jason Dillon wrote: > From looking over ServiceController and SARDeployer, it "looks" like this > would work, but the service would have to perform its work in create()... > though I am not sure about that. > > Is there any reason why we don't start a serivce after it has been created > if it does not depend on anything? > > Could someone (probably david?) explain briefly the order of events from a > call to MainDeployer.deploy() to the service being fully started (ie > start() returned). > > --jason > > On Saturday 25 May 2002 01:08 am, Jason Dillon wrote: > > I was just thinking, waiting for tests to complete (they take hours to > > hit the error scenerio)... and while I wait I get back to the meaningful > > work. > > > > So, It occured to me that the <classpath> element really does not do too > > much except deploy urls for archives which it has found, or has an > > explicit list of. So why isn't this just another MBean? > > > > I certainly don't wan't ClassPathExtention to come back to life, but I > > think that we could add a much better service which will do the same job > > as <classpath> (perhaps more)... and as MBeans go if it doesn't do what > > you need, then you plug in a different version. > > > > Then we could move JARDeployer into jboss-service.xml, right before the > > classpath service which setups all of the UCL's to the lib/* stuff. > > > > I think I am probably missing something... like that before we start > > calling service methods we must register every MBean with the server... I > > don't know that is the case... but if it is, I suggest that is not > > optimal. > > > > Anyone know what the case is here? > > > > --jason > > > > _______________________________________________________________ > > > > Don't miss the 2002 Sprint PCS Application Developer's Conference > > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > > > _______________________________________________ > > Jboss-development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development _______________________________________________________________ Don't miss the 2002 Sprint PCS Application Developer's Conference August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
