Thanks for the info, makes sense. Will simply make undeployment an option before redploying. - Rich
On 8/21/07, Alex Boisvert <[EMAIL PROTECTED]> wrote: > > On 8/21/07, Rich Taylor <[EMAIL PROTECTED]> wrote: > > > > 1. After restarting the Ode server, I see that foo-1(bar-1) is again > > started > > up. I understand this is for any long running instances of this > process. > > But I was thinking that the old versions of the process would not live > > through server restarts and apparently live forever, even with no > > instances > > are alive/created. > > > Correct. We currenlty don't throw away retired process definitions if > there > are no instances. > > 2. That said, for undeployment, do you explicitly need to undeploy each > > version of a process if it was deployed multiple times? > > > At the moment, yes. > > > > 3. Going further on the same subject, would there be some way to > configure > > Ode to delete previous versions upon redployment if there were no long > > running instances being run? Or is there a better way to manage > previous > > versions of a bundle/process? > > > Yes, we could set it up to undeploy previous versions automatically (and > optionally destroy previous instances as well) for development/testing > scenarios. I would see this as configuration options. (See below for an > alternative) > > We're looking at a scenario where someone is working in the Eclipse BPEL > > designer for example, and deploying every 2 minutes when they make > tweaks > > to > > their bpel process (during development). After a while, there are > > _numerous_ versions of the same process deployed that will be around > > forever > > if I understand correctly. I'm looking at how best to manage that. > > > Another option is to teach the Eclipse BPEL Designer how to undeploy > processes ;) I personally I think that it makes more sense to do it in > the > IDE because an Ode server might be shared between different people who > desire different behavior. So I see it more of a personal preference. > > alex >
