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]
