David Jencks wrote: >>>>As soon as you get the first error, the deployment should stop and >>>>unroll. Correct? >>> >>> >>>I don't think so. This tends to produce behavior like stopping the >> >>server >> >>>when your ejb doesn't deploy on server startup. >> >>Yes. I don't want a half deployed application. It either works or it >>doesn't. > > > I'm not sure it's easy to tell where the boundaries of an application are. > I originally made it work this way when any deployment error while jboss > started up was shutting down the server. I found this rather hard to > straighten out, since most of the evidence disappeared before I could look > at it. > > I'll think about this some more, maybe I will be able to find a way we both > like. At one time I was confusing actual deployment exceptions with > unsatisfied dependencies, so if I think about them as the different things > they are perhaps I will come up with something.
I don't think the server should every shutdown without administrator intervention, but I do think a single file in the deployment directory is a single deployment unit. It either works as a whole or fails as a whole. If a user wants a partitioned deployment they can deploy break the application into two files. >>>I really think it is more useful to deploy everything possible and >> >>record >> >>>errors for each object. In my experience this provides much more >>>information and lets you fix several problems at once. This is the >> >>point of >> >>>the IncompleteDeploymentException, it lists everything that went wrong. >> >>>You may be able to fix stuff and start your mbeans or whatever without >>>redeploying. >> >>Complexity. This will make the code much harder to write if I can not >>assume that a DeploymentException immedately stops all deployment. It >>could do very weird things to the persistence store. > > > Obviously you know better how the persistence store works than I. However, > if you make the whole thing out of mbeans whose state is managed by > ServiceController and register the dependencies between them, you may be > able to avoid anything happening after a DeploymentException. This may happen in 4.0. > BTW did you ever figure out a solution for the problem of relationships > starting, yet not starting any ejbs before the relationship existed? I > couldn't, and was wondering if we needed a dependency "can't create mbean > until this other one is started" so you could use the datasource in the > create method. Yes it works perfectly now. I wait until all EJBs in the application are started and when the last one is done I begin the startup of the persistence manger (3 phases). >>There is no reason for this. Deployment problems should be worked out >>in development and testing, and developers and testers are used to the >>you only get the first error type of deployment. Maybe we can run the >>entire verifier and then try the real deployment, but once the real >>deployment starts the first deployment exception should stop all >>deployment of the file and rollback. > > > But what is a deployment unit? I'm not sure this is a file -- how about in > an unpacked .ear? This is easy. What does the user expect? They put a file in deployment and it works or it doesn't work. The users expect the file to be the deployment unit. If you are not sure, ask some real users. An unpacked ear (or any archive) is perceived by users as a single deployment unit. Who would only want some of the beans in a application to work? All or nothing I say. >>> The repeated exceptions here IMO are due to bad design of the xml >> >>parsing >> >>>and are not a reason to change the behavior of the deployment system. >> >>I'm not bitching about the exceptions (yet), just the weird deployment >>problems (and the confusing results). >> >> >>>So you should end up with on exception trace and an >>> >>> >>>>undeployment messages. >>> >>> >>>I find undeploying on error removes most of the information I use to >> >>find >> >>>out what is wrong. >> >>I don't think this is necessary, but if it can be done without making >>the code to complex (I know you are the king of complexity, but I can't >>handle it), then it would be nice. > > > Did you try the behaviour after the fixes I put in? It is certainly waay > better than with the bugs you found! Not yet. Taking the weekend off (except for emails). -dain ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
