You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Kapish Aggarwal <sc...@gmail.com> on 2006/08/22 20:56:55 UTC
Unregister Method Design
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
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.
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? Or are there more register
implementations that need to have corresponding unregister methods? Any
feedback would be appreciated. Thanks.
Kapish Aggarwal
Re: Unregister Method Design
Posted by Kapish Aggarwal <sc...@gmail.com>.
Following the exchange of messages with Jim Marino, I made an initial
attempt to add limited undeployment capability to Tuscany. I took the
simple approach and literally performed the opposite of the net
results of the bootApplication() method call in
org.apache.tuscany.core.launcher.LauncherImpl. I also attempted to
follow the structure as close as possible. I wanted to know what
additions still need to be made since I'm sure this initial design is
incomplete.
Note that the stopping of application and unregistering of the
application have been coupled together because the starting of the
application has been coupled with the registering of the application.
Specifically, the LifeCycle.stop() call for an application is made in
the unregister function. I am positive this is not the corrext place
to perform it, but I did not know the if the application must be
stopped before removing it from the Runtime instance. I have detailed
the steps I took with the significant snippets of code added below:
---org.apache.tuscany.host.Launcher
---Added header:
void stopApplication(String appName);
---This is the point of declaration for the bootApplication()
methods so I defined the header here also.
---I was't certain how different systems would deal with
application identifiers, so I stuck with the use of the name the
application was registered with
---org.apache.tuscany.core.launcher.LauncherImpl
---Defined method:
public void stopApplication(String appName)
-Call undeploy() with the runtime's root component as the
parent and the name as the idenfitier for the application.
---bootApplication gathers the information together into a
single object and then calls a deploy method. Since we do not need to
"build" the composite, I resorted straight to a call to undeploy.
---org.apache.tuscany.spi.Deployer
---Added header:
void undeploy(CompositeComponent<?> parent, String compositeName);
---This is the point of declaration for the deploy() method
---org.apache.tuscany.core.deployer.DeployerImpl
---Defined method:
public void undeploy(CompositeComponent<?> parent, String compositeName)
-Call the unregister() method from the provided parent
---deploy() performs the task of building and defining all the
internal components, which does not need to be done for removing the
application
---org.apache.tuscany.spi.component.CompositeComponent
---Added header:
void unregister(String name) throws ComponentNotFoundException;
---This is the point of declaration for register()
---org.apache.tuscany.spi.extension.CompositeComponentExtension
---Defined empty function:
public void unregister(String name)
---register() has an implementation here, but we are only
interested in removing applications, which take the type of
CompositeComponent. Since register() does not handle that type, I left
the method empty to prevent accidental unregistering of internal
components.
---org.apache.tuscany.core.implementation.composite.AbstractCompositeComponent
---Defined three functions:
public void unregister(String name)
-Retrieve the object that corresponds to the provided name
-If the object is a CompositeComponent, call the inherited stop() from
LifeCycle, unregisterAutowire(), removeListener(), and
remove the object
from the children list
protected void unregisterAutowire(CompositeComponent<?> component)
-Cycle through each service defined in the provided component
-unregisterAutowireInteral() on the interface for each service
protected void unregisterAutowireInternal(Class<?> interfaze)
-Check if the provided class is the list autowireInternal
and remove if it is.
---The unregister() methods perform the exact opposite of their
counterparts. Again, since application removal is the main point of
interest, I ignored the removal of other parts.
---The component.stop() call is the LifeCycle stop call. In the
assumption that the only the name is necessary as an identifier, this
is the first point where we have the actual component object. Again,
the stop() method is called here to make sure it happens *before*
removal from the runtime. If this is not necessary, it seems that that
call should be placed after removal in which unregister() should
return the component. Can anyone answer whether or not it is
necessary?
I would appreciate any and all comments on the design. Thanks.
Kapish
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Unregister Method Design
Posted by Jim Marino <jm...@myromatours.com>.
On Aug 22, 2006, at 3:14 PM, Kapish Aggarwal wrote:
> 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.
>
It may be something like "undeploy" which could call an "unregister"
I think we just need to be careful about the level of granularity and
what happens to wires during this.
> Kapish
>
> On 8/22/06, Jim Marino <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Unregister Method Design
Posted by Kapish Aggarwal <sc...@gmail.com>.
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 <jm...@myromatours.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Unregister Method Design
Posted by Jim Marino <jm...@myromatours.com>.
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org