I am +1000 on calling create, and then start immediately. I implemented something like this at least once (I think there was only one step, start. I have since been convinced that the init/create step is a good idea as well. I don't think it should wait for dependencies, however). It does require that you abide by what I consider the contracts for create and start:
create has to set up some externally accessible representation of everything exposed by the mbean, but cannot try to access any services of other mbeans start can assume any other mbean it knows about through a depends element has been started, so everything is available and working. If your mbean depends on another one, you have to explicitly state it. You cannot rely on the order of mbeans in a *service.xml file to hide dependencies. ------------ After prolonged howls of protest from Bill and Marc, Marc (as I recall) put back the current magic ordering dependencies. At one time the clustering code had some complex dependencies between mbeans that required multiple calls to get everything set up properly. The last time I looked this code appeared to use a combination of the mbean ordering in the file and calling methods on the other mbeans from the create method. david jencks On 2002.05.25 05:21:35 -0400 Jason Dillon wrote: > (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 > > _______________________________________________________________ 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
