And don't forget... We should really have the "restart" semantic in the new state diagram ;)
> -----Original Message----- > From: Ivelin Ivanov [mailto:[EMAIL PROTECTED] > Sent: Sunday, March 07, 2004 10:01 PM > To: [EMAIL PROTECTED]; Scott M Stark > Cc: [EMAIL PROTECTED]; The Core > Subject: Re: [JBoss-dev] RE: Service Lifecyle confusions - > potential fix > > > I often see people puzzled by the fact that the depend tag > does not include > registration. When there are two SARs, the second of which > has MBeans that > depend on classes in the first one, the microkernel troughs > "Class Not Found" > exception if it happens to deploy the dependant SAR first. > > Also as Adrian noted, developers usually expect clicking on > Stop in the console > to also stop the dependant MBeans in the appropriate order. > > The MBean lifecycle improvements are on the roadmap and we > need to document the > detailed requirements in one place. I could do that later, > but for now I hardly > find time to collect the JMS ones. > > Ivelin > > > > --- Adrian Brock <[EMAIL PROTECTED]> wrote: > > On Sun, 2004-03-07 at 02:20, Adrian Brock wrote: > > > On Sun, 2004-03-07 at 02:08, Scott M Stark wrote: > > > > The state machine was not immeadiately for the service > layer, but > > > > will be used to enforce illegal transitions if we > decide on a state > > > > diagram. > > > > > > > > The suggested change makes sense, but the other problem > is the fact > > > > that the deployment layer is out of the loop in this. > > > > > > I wasn't considering deployment, only lifecyle. > > > > I actually feel lifecycle is unnecessary if read-ahead and > > IOC was implemented. It would be replaced by ordered configuration > > and valves. The user would have two options start/stop the valve > > or deploy/undeploy the service. > > > > > > > > > I would like > > > > to couple dependency and life cycle to delay the creation of the > > > > service as an mbean, but have not really looked at how > big a change > > > > this is. > > > > > > My preferred solution for this to read-ahead all deployments > > > to determine the full graph (including class and jndi > dependencies) > > > before any deployment starts. You can then inject > configuration IOC > > > style. It would also give enough information to allow a realistic > > > valve implementation. > > > I haven't figured out how you identify the deployers or > the scanner > > > as special - i.e. allowing their initial processing > before the full > > > graph has been read - so they can contribute to the graph. > > > > > > > One solution would be to run core services/deployers in "ring zero" > > a sort of controlling sub-machine/extensible kernel. This would make > > other services slightly second class citizens. > > This still does not solve the problem generally, > > e.g. > > 1) how to allow pluggable logging (currently implemented with > > a boot.log and server.log) > > 2) how to run the boot under a security context and still > have pluggable > > security > > 3) what if you want your mbean persistence from the db for your core > > services when the db connection isn't deployed until later > > > > It's almost like you a need a separate bootstrap "process" > > that boots enough to configure the main machine before > being discarded > > in favour of it? A bit like the bios/boot block in the pc. > > > > Regards, > > Adrian > > > > > I'd also like to introduce cleverer (more fine grained) dependency > > > information like the ejb deployer should not depend upon jms. > > > Instead it should be based on whether jms is used, either by an > > > mdb or a resource-ref. > > > This would potentially allow the jmx-console to deploy > eariler rather > > > than waiting for unnecessary dependencies specified on > the web deployer. > > > > > > Regards, > > > Adrian > > > > > > > > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > Scott Stark > > > > Chief Technology Officer > > > > JBoss Group, LLC > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > > -----Original Message----- > > > > > From: Adrian Brock > > > > > Sent: Saturday, March 06, 2004 5:24 PM > > > > > To: Scott M Stark > > > > > Cc: [EMAIL PROTECTED]; The Core > > > > > Subject: Service Lifecyle confusions - potential fix > > > > > > > > > > Hi Scott, > > > > > > > > > > Are you working on the Service lifecycle? > > > > > I saw you replaced common's state machine implementation. > > > > > > > > > > I was thinking that there should be an extra indirection to > > > > > avoid the confusion caused by people clicking stop() and > > > > > other operations in the console where dependencies are not > > > > > taken into account. > > > > > > > > > > My idea is that you implement an extra operation in > > > > > ServiceMBeanSupport > > > > > > > > > > public void jbossServiceLifecylce(String operation) throws > > > > > Exception { if (operation.equals("create")) { // the current > > > > > create() method } etc. > > > > > } > > > > > > > > > > This would be invoked from ServiceController.ServiceProxy > > > > > when it is implemented by the MBean. > > > > > > > > > > This would allow us to change the current > > > > > ServiceMBeanSupport.create() to be: > > > > > serviceController.create(serviceName); > > > > > etc. > > > > > > > > > > Now clicking stop() in the console goes via the service > > > > > controller making sure dependencies are also stopped. > > > > > > > > > > This doesn't fix the problem for MBeans that do not extend > > > > > ServiceMBeanSupport. These would still do the old behaviour. > > > > > Similar changes would be required to > > > > > ServiceDynamicMBeanSupport and the XMBean descriptor include. > > > > > > > > > > Regards, > > > > > Adrian > > > > > > > > > > -- > > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > Adrian Brock > > > > > Director of Support > > > > > Back Office > > > > > JBoss Inc. > > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > > > > > > > > > > -- > > xxxxxxxxxxxxxxxxxxxxxxxx > > Adrian Brock > > Director of Support > > Back Office > > JBoss Inc. > > xxxxxxxxxxxxxxxxxxxxxxxx > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: IBM Linux Tutorials > > Free Linux tutorial presented by Daniel Robbins, President > and CEO of > > GenToo technologies. Learn everything from fundamentals to system > > > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > > _______________________________________________ > > JBoss-Development mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/jboss-development > > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
