Hi Senaka,

> Alright. If so, we need to fix the interface of the OSGi Service
> registered by the Runtime, to have getDeployer() which (with return type
> Deployer) instead of deployArtifacts() and undeployArtifacts() instead of
> what you explained in the example.
>
>
Yes it can have getDeployer() and many more methods needed by runtime to
provide the intended functionalists. By deployArtifact() what I meant was
usage of runtime specific methods relevant to artifact deployment [ ex: for
Tomcat addWebapp() ]. These methods will be used by the custom deployer to
create the artifact deployer.



> Each runtime(Axis2/Tomcat etc.) will be registering an OSGI service
> corresponding to its functionalists,
>
> Ex : deployArtifacts(), undeployArtifacts(), startRuntime() etc.
>
> The Runtime Manager can call the deploy and undeploy methods of the
> Deployer if that is available. If a deployer is not returned by the Runtime
> the Runtime Manager can simply not include it in its deployer list, and
> only invoke the start() and stop() methods.
>
>
The runtime will not be handling artifact the deployment and un-deployment
methods. These methods will be handled by the Deployment Engine. If certain
runtime need a deployer then it can register its deployer on the Deployment
Engine and it keep the control of the deployment. Runtime is only
interested on initializing and starting its runtime. Registering the
deployer is not coupled with the runtime.

Thanks,
Manoj
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to