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
