Re: [Dev] Impact of C-App deployer changes on ESB artifacts
Can someone from the ESB team put some input here please? Thanks, ~Isuru On Mon, May 21, 2012 at 4:26 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: One more thing we discussed was, ESB checks the dependency at the deployment time. For example, if a proxy service depends on a sequence, it validates whether the sequence exist when trying to deploy proxy service. (e.g proxy service in one car file and sequence in another car file.. now we have to order the car file deployment). We discussed this with Paul and the decision is, we should change this behavior so that the validation happens with first message arrived, not at the time of deployment. Hiranya, how hard is it to do that? Regards, Shankar On Mon, May 21, 2012 at 4:10 PM, Isuru Suriarachchi is...@wso2.comwrote: Hi all, As per few discussions we did on C-App deployment, we identified that the current C-App deployment process causes problems in cluster with deployment synchronizer. Currently the C-App deployer reads different artifacts and copy those into relevant hot directories in the Axis2 repository (repository/deployment/server/xxx). When these artifacts and the original C-App are synchronized to a different node, there are conflicts. So as a solution, I've already implemented a way in which the C-App extracts the individual artifacts into a temp directory and directly call the relevant deployer for the artifact. This works well for aar services etc. which won't get changed after first deployment. However, I wonder ESB artifacts will have a different impact on this because the user can edit the ESB configuration through the UI and then it internally get serialized to the original xml file in the repository. But in this new approach, original artifact will be in the temp directory. So will that be a problem from the ESB side? And also please let me know if there are any other possible downsides of this approach which you can think of. Thanks, ~Isuru -- Isuru Suriarachchi Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware -- S.Uthaiyashankar Senior Software Architect Chair, Management Committee – Cloud Technologies WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 -- Isuru Suriarachchi Senior Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Impact of C-App deployer changes on ESB artifacts
After building the latest ESB trunk and testing a C-App which contains all sorts of ESB artifacts, I found out the following behavior. * C-App get extracted into tmp/xxxCapp directory * C-App deployer calls individual ESB deployers and deploys all artifacts. This works fine. But still the original artifacts are in tmp and not in repository/deployement/server/synapse-configs. * Now if the C-App is deleted, all artifacts get deleted as well. * But if I go the source view and edit the configuration, all artifacts are written to repository/deployement/server/synapse-configs directory * Now if I try to delete the C-App there are all sorts of errors. So it looks like, according to how ESB artifact deployment is handled, it's hard to deploy a C-App without following the already existing approach (copying individual artifacts into relevant hot directories). Thanks, ~Isuru On Mon, May 21, 2012 at 4:10 PM, Isuru Suriarachchi is...@wso2.com wrote: Hi all, As per few discussions we did on C-App deployment, we identified that the current C-App deployment process causes problems in cluster with deployment synchronizer. Currently the C-App deployer reads different artifacts and copy those into relevant hot directories in the Axis2 repository (repository/deployment/server/xxx). When these artifacts and the original C-App are synchronized to a different node, there are conflicts. So as a solution, I've already implemented a way in which the C-App extracts the individual artifacts into a temp directory and directly call the relevant deployer for the artifact. This works well for aar services etc. which won't get changed after first deployment. However, I wonder ESB artifacts will have a different impact on this because the user can edit the ESB configuration through the UI and then it internally get serialized to the original xml file in the repository. But in this new approach, original artifact will be in the temp directory. So will that be a problem from the ESB side? And also please let me know if there are any other possible downsides of this approach which you can think of. Thanks, ~Isuru -- Isuru Suriarachchi Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware -- Isuru Suriarachchi Senior Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Impact of C-App deployer changes on ESB artifacts
On Mon, May 21, 2012 at 4:26 PM, Selvaratnam Uthaiyashankar shan...@wso2.com wrote: One more thing we discussed was, ESB checks the dependency at the deployment time. For example, if a proxy service depends on a sequence, it validates whether the sequence exist when trying to deploy proxy service. (e.g proxy service in one car file and sequence in another car file.. now we have to order the car file deployment). There is no such validation mechanism in ESB. A proxy service deployment will fail only if the publish WSDL (or the WSDL referenced by a WSDL endpoint) cannot be loaded at deployment time. Thanks, Hiranya We discussed this with Paul and the decision is, we should change this behavior so that the validation happens with first message arrived, not at the time of deployment. Hiranya, how hard is it to do that? Regards, Shankar On Mon, May 21, 2012 at 4:10 PM, Isuru Suriarachchi is...@wso2.comwrote: Hi all, As per few discussions we did on C-App deployment, we identified that the current C-App deployment process causes problems in cluster with deployment synchronizer. Currently the C-App deployer reads different artifacts and copy those into relevant hot directories in the Axis2 repository (repository/deployment/server/xxx). When these artifacts and the original C-App are synchronized to a different node, there are conflicts. So as a solution, I've already implemented a way in which the C-App extracts the individual artifacts into a temp directory and directly call the relevant deployer for the artifact. This works well for aar services etc. which won't get changed after first deployment. However, I wonder ESB artifacts will have a different impact on this because the user can edit the ESB configuration through the UI and then it internally get serialized to the original xml file in the repository. But in this new approach, original artifact will be in the temp directory. So will that be a problem from the ESB side? And also please let me know if there are any other possible downsides of this approach which you can think of. Thanks, ~Isuru -- Isuru Suriarachchi Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware -- S.Uthaiyashankar Senior Software Architect Chair, Management Committee – Cloud Technologies WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 -- Hiranya Jayathilaka Senior Technical Lead; WSO2 Inc.; http://wso2.org E-mail: hira...@wso2.com; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
[Dev] Impact of C-App deployer changes on ESB artifacts
Hi all, As per few discussions we did on C-App deployment, we identified that the current C-App deployment process causes problems in cluster with deployment synchronizer. Currently the C-App deployer reads different artifacts and copy those into relevant hot directories in the Axis2 repository (repository/deployment/server/xxx). When these artifacts and the original C-App are synchronized to a different node, there are conflicts. So as a solution, I've already implemented a way in which the C-App extracts the individual artifacts into a temp directory and directly call the relevant deployer for the artifact. This works well for aar services etc. which won't get changed after first deployment. However, I wonder ESB artifacts will have a different impact on this because the user can edit the ESB configuration through the UI and then it internally get serialized to the original xml file in the repository. But in this new approach, original artifact will be in the temp directory. So will that be a problem from the ESB side? And also please let me know if there are any other possible downsides of this approach which you can think of. Thanks, ~Isuru -- Isuru Suriarachchi Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
Re: [Dev] Impact of C-App deployer changes on ESB artifacts
One more thing we discussed was, ESB checks the dependency at the deployment time. For example, if a proxy service depends on a sequence, it validates whether the sequence exist when trying to deploy proxy service. (e.g proxy service in one car file and sequence in another car file.. now we have to order the car file deployment). We discussed this with Paul and the decision is, we should change this behavior so that the validation happens with first message arrived, not at the time of deployment. Hiranya, how hard is it to do that? Regards, Shankar On Mon, May 21, 2012 at 4:10 PM, Isuru Suriarachchi is...@wso2.com wrote: Hi all, As per few discussions we did on C-App deployment, we identified that the current C-App deployment process causes problems in cluster with deployment synchronizer. Currently the C-App deployer reads different artifacts and copy those into relevant hot directories in the Axis2 repository (repository/deployment/server/xxx). When these artifacts and the original C-App are synchronized to a different node, there are conflicts. So as a solution, I've already implemented a way in which the C-App extracts the individual artifacts into a temp directory and directly call the relevant deployer for the artifact. This works well for aar services etc. which won't get changed after first deployment. However, I wonder ESB artifacts will have a different impact on this because the user can edit the ESB configuration through the UI and then it internally get serialized to the original xml file in the repository. But in this new approach, original artifact will be in the temp directory. So will that be a problem from the ESB side? And also please let me know if there are any other possible downsides of this approach which you can think of. Thanks, ~Isuru -- Isuru Suriarachchi Technical Lead WSO2 Inc. http://wso2.com email : is...@wso2.com blog : http://isurues.wordpress.com/ lean . enterprise . middleware -- S.Uthaiyashankar Senior Software Architect Chair, Management Committee – Cloud Technologies WSO2 Inc. http://wso2.com/ - lean . enterprise . middleware Phone: +94 714897591 ___ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
