Hey Jim, I'm still a bit unclear on your response to my post. I agree with the idea of not allowing Atomic Components to be unregistered from a Composite. But I'm looking at completely undeploying the top-level composite from the Tuscany runtime, not just redeploying. The composite is ultimately registered with the RuntimeComponent's root component.
If we are looking at simply undeploying an application altogether from the runtime, should we not have a corresponding unregister function to remove the composite from the RuntimeComponent's root component (which is defined as a CompositeComponent)? Maybe the idea should be to declare an unregister function, but restrict what it is capable of unregistering. Kapish On 8/22/06, Jim Marino <[EMAIL PROTECTED]> wrote:
Hi Kappish, Comments inline On Aug 22, 2006, at 11:56 AM, Kapish Aggarwal wrote: > Refering back to a previous posting about the removing an existing SCA > composite from the Tuscany runtime, I was try to determine what is > required > in the process of removing a composite from the runtime. Looking > through the > code, it seems that a couple things need to be done: > > 1) Add a method that can stop the CompositeComponent object > representing the > composite There already is one on Lifecycle which all SCAObject descendants inherit > > 2) Add an unregister method to the CompositeComponent interface and > have it > remove the objects that are added by the corresponding register > methods. > These would the register methods found in > CompositeComponentExtension and > AbstractCompositeComponent. Maybe but my inclination is to only allow redeployment of entire composites which are deployment units. For example, it should not be possible to unregister an Atomic composite from composite that is a deployable unit as children are considered tightly coupled. Rather, the composite should be redeployed to the parent. This will I think make things a lot easier as well since it will allow us to support side-by-side deployment and versioning where a previous composite version can be quiesced as all invocations finish and have a new composite version receive new incoming requests. > > These were the main aspects I discovered as I traced through the > code. Is > there any other interaction with the Tuscany Runtime instance and that > application that needs to be dealt with? Yes I think there are a number of aspects we need to sort out such as implications for wiring. For example, if I unregister a target, what happens to the wire? Jim > Or are there more register > implementations that need to have corresponding unregister methods? > Any > feedback would be appreciated. Thanks. > > Kapish Aggarwal --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
