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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
