I agree with jason that we should always continue deployment as far as possible and undo as little as possible. We also need to make all problems extremely visible through jmx and possibly logging. With proper dependency specifications nothing that depends on a unsuccessfully deployed mbean will start anyway, including your application, so I don't see the problem in leaving the state as is, and letting the administrator fiddle with it to try to fix things through jmx.
david jencks On 2002.06.15 20:25:55 -0400 Dave Neuer wrote: > Perhaps it makes sense to have a way to mark an MBean > as "essential" or "optional", and treat failures of > the latter as loggable, non-fatal errors. > > Dave Neuer > > --- Scott M Stark <[EMAIL PROTECTED]> wrote: > > This is a good feature for exactly the case you > > mention, jboss-service.xml > > being screwed up. Why put the mbeans together if you > > don't want this > > behavior? > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > > From: Jason Dillon > > To: [EMAIL PROTECTED] > > Sent: Friday, June 14, 2002 12:05 PM > > Subject: [JBoss-dev] Why does one MBean failure > > cause the entire deployment unit to fail? > > > > > > Just what the subject says: Why does one MBean > > failure cause the entire deployment unit to fail? > > > > > > > > If I have put several MBeans into user-service.xml > > (or whatever) of which the last one fails to start, > > why do we stop/destroy all of the others? This also > > happens from time to time with jboss-service.xml, > > say of Naming can't start because of a port conflict > > (perhaps because the jvm did not die when it was > > asked to). When this does happen the server will > > shutdown and exit. > > > > > > > > I can see how this might be useful to force users > > to deal with problems with the deployment unit, but > > I think that logging an ERROR is a better option, > > only failing the deployment unit if none of the > > MBeans have deployed, or rather throw the exception > > but don't stop/destroy/unregistered beans which have > > been started. > > > > > > > > This behavior is more desirable in my opinion, as > > it allows for easier debugging by allowing the user > > to inspect the logs, and the state of the other > > MBeans to possibly resolve the issue, possibly by > > changing config and starting by hand. With the > > system as is, the only options are to comment the > > config, or configure/create each MBean by hand. both > > kinda suck, the latter much more. > > > > > > > > Is there a reason to fail all MBeans when one > > MBean fails? > > > > > > > > --jason > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! - Official partner of 2002 FIFA World Cup > http://fifaworldcup.yahoo.com > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas - >http://devcon.sprintpcs.com/adp/index.cfm?source=osdntextlink > > _______________________________________________ > 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?source=osdntextlink _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
