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
