I don't agree that thowing an exception on a deployment failure introduces new problems that outweigh the current issues. Any exception in the context of a deployment needs to fail the entire deployment. Only unsatisifed dependencies should not constitute a failure, but even this case should thrown an exception indicating that there is no guarentee the deployment will succeed and then there needs to be a dependency manager that monitors the progress and eventually fails the deployment if the dependency is not satified by a deployment specified timeout. I need to look at the current dependency logic commenting no how to improve the current behavior.
----- Original Message ----- From: "David Jencks" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, June 02, 2002 11:55 AM Subject: Re: [JBoss-dev] [ jboss-Bugs-563448 ] deployment exceptions cause problems > I'm glad we agree there are problems here. What do you think would be the > most appropriate behavior? In both cases, the most useful behavior I can' > think of is returning lists of mbeans affected by the current deployment > ctivity in various states (successfully deployed, waiting for classes, > waiting for depend targets, failed). I think the behavior in the current > codebase is a clear indication that throwing exceptions to indicate failed > deployments causes more problems than it solves. > > david jencks > > On 2002.06.02 13:10:48 -0400 Scott M Stark wrote: > > I have a problem with the logic described in this bug. If A does not > > depend on B then its deployment should not be affected in any > > way by a failed deployment of B, the dependent object for exactly the > > reason you discuss. Why should the failure of some connection > > mgr dependent end up failing the deployment of the valid DefaultDS? > > This makes the entire system a fragile and unecessary coupled mess. > > > > I also have a problem with the behavior of deployment that does not > > have the required service class as mentioned in bug 559012. There is > > no failure and no timeout so ultimately it is the user that has to tell > > you the server is not working. > > > > > > xxxxxxxxxxxxxxxxxxxxxxxx > > Scott Stark > > Chief Technology Officer > > JBoss Group, LLC > > xxxxxxxxxxxxxxxxxxxxxxxx > > ----- Original Message ----- > > From: "David Jencks" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Sunday, June 02, 2002 5:07 AM > > Subject: Re: [JBoss-dev] [ jboss-Bugs-563448 ] deployment exceptions > > cause > > problems > > > > > > > How about deployment returning lists of successfully deployed mbeans, > > > mbeans waiting for others, and mbeans that failed deployment? > > > > > > Due to the dependency management, many of these mbeans may not be in > > the > > > package just deployed. To make the original deployer of each mbean get > > > notified we will either have to have asynchronous callbacks or > > > multithreaded deployment with blocking on missing mbeans. > > > > > > Can you write down a list of all the problems you have with the > > dependency > > > system? > > > > > > thanks > > > david jencks > > > > > > On 2002.06.02 01:38:43 -0400 Jason Dillon wrote: > > > > Yes, well... the dependency system is flawed in many ways. We should > > not > > > > have > > > > to eat exceptions to make it work. > > > > > > > > Consider command line deployments where if we eat the exception we > > have > > > > no clue > > > > if the deploy() op suceeded. Note this is not limited to command > > line > > > > deployments but really anything that needs to rely on an exception > > being > > > > throw > > > > and propagated (not eaten) to detect failure sitations. > > > > > > > > --jason > > > > > > > > > > > > > > > > Quoting [EMAIL PROTECTED]: > > > > > > > > > Bugs item #563448, was opened at 2002-06-02 02:57 > > > > > You can respond by visiting: > > > > > > > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=563448&group_id= > > > > 22866 > > > > > > > > > > Category: JBossServer > > > > > Group: v3.1 > > > > > Status: Open > > > > > Resolution: None > > > > > Priority: 5 > > > > > Submitted By: David Jencks (d_jencks) > > > > > Assigned to: Nobody/Anonymous (nobody) > > > > > Summary: deployment exceptions cause problems > > > > > > > > > > Initial Comment: > > > > > Recently 3.1 and I think 3.0 were modified so that > > > > > deployment exceptions propagated out of main deployer. > > > > > This has some questionable consequences in the > > > > > presence of mbean dependencies, which was the reason I > > > > > hid the exceptions in the first place. > > > > > > > > > > If mbean B depends on mbean A, but B does not deploy > > > > > successfully, then: > > > > > > > > > > If A is deployed first, it will deploy successfully, > > > > > then B can be deployed unsuccessfully. > > > > > > > > > > However if B is deployed first, it will wait for A. > > > > > During the deployment of A, B will be deployed, and the > > > > > resulting exception will cause the deployment of A to > > > > > fail also. > > > > > > > > > > For instance, if there is a "undeployable" depending on > > > > > the ConnectionManager mbean for DefaultDS, and the > > > > > undeployable happens to get deployed before the > > > > > ConnectionManager, it will prevent DefaultDS from > > > > > deploying, thus breaking large amounts of the system. > > > > > > > > > > I'm not sure what the best solution to this is. I > > > > > don't think the current state of affairs is desirable, > > > > > since a "rogue" mbean can break any correctly working > > > > > mbean by arranging to be deployed first. > > > > > > > > > > I lean toward having an easily accessible list of > > > > > mbeans that can't be deployed and possibly returning a > > > > > status code from deployers. > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > _______________________________________________________________ > > > > 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
