I have looked into replacing the metadata xml parsing with Castor XML in my spare time (ha, spare time... I made a joke). From a few emails with the Castor folks I belive that the XML snippet is possible with Castor because it is based on XML Schema's and not DTD... but I have not tested anything yet.
Once I have verified that this will work, I will setup a prototype for the service configuration. This should allow us to easily modify the ServiceController and friends to allow better register/create/start control. --jason On Thursday 30 May 2002 06:55 am, David Jencks wrote: > 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 _______________________________________________________________ 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
