Hi Aruna, Please find my comments inline.
On 30 April 2014 11:44, Afkham Azeez <[email protected]> wrote: > > > > On Wed, Apr 30, 2014 at 11:34 AM, Manoj Kumara <[email protected]> wrote: > >> Hi Aruna/ Azeez, >> >> Please see my inline comment. >> >> >> On Tue, Apr 29, 2014 at 7:14 PM, Aruna Karunarathna <[email protected]>wrote: >> >>> Hi all, >>> >>> After having a offline discussion with Azeez and Kishanthan, Few changes >>> was suggested for the previous model. >>> >>> 1. Remove Deployer based approach for applying patches in C5 Kernel. >>> >>> In the previous model, patching solution was dependent on the >>> DeploymentEngine directly. Patch Module is going to be shipped as a >>> individual component >>> and can be invoked when the server is running or in shutdown mode. >>> Providing a tool to apply patches. >>> e.g >>> >>> ./applypatches.sh PatchZipLocation >>> >> >> +1 for using decoupling this feature from DeploymentEngine. >> >> But my concern here is Isn't it better we use a repository listener to >> patches directory and hot deploy patches instead of using a tool for this. >> I feel in this way its more user friendly. >> > > No patching is an infrequent thing. We can use the same API to call from > OC. > >> >> >>> >>> 2. Adding a patch version for a OSGI bundle. >>> >>> In the current approach we can't discretely identify a patch by it's >>> bundle name. Patch name for a particular bundle was suggested as follows >>> >>> e.g *org.wso2.carbon.clustering_5.0.0.jar* in the first patch add a new >>> patched bundle as *org.wso2.carbon.clustering_5.0.0.0001.jar* >>> >>> 3. When applying a patch >>> >>> unzip the applying zip to the * /c5-home/repository/patches* folder >>> (zip file structure would remain the same) >>> >>> >>> - for config files patch apply would remain as the way in the >>> previous mail. >>> - for OSGi bundles >>> >>> there will be an entry update in the *bundles.info >>> <http://bundles.info>* file to persist the changes in a server restart. >>> >>> for e.g >>> org.wso2.carbon.clustering,5.0.0,../../plugins/org.wso2.carbon.clustering_5.0.0.jar,4,true >>> will change to >>> >>> >>> org.wso2.carbon.clustering,5.0.0.0001,../../../patches/patch00001/org.wso2.carbon.clustering_5.0.0.0001.jar,4,true >>> >>> 4. Use the /c5-home/repository/patches/patch0000 folder for backup >>> purposes. >>> >> >From point 3 above, it seems we won't be replacing the jars in repository/components/plugins directory when applying patches and simply changing the jar to be loaded from the new patch folder. +1 for this approach since it would not need to keep multiple copies of the same jar in the server (AFAIK in the current model, we keep a copy in patch folder and replace the existing jar in the repository/components/plugins after backing up all jars to patch0000, which leads to multiple copies). If this is the case, what will be the use case for backing up jars in the patch0000 folder? Thanks, Lasantha > >>> >>> I will continue the POC for patching c5 servers with the above changes. >>> >>> >> Thanks, >> Manoj >> > > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **[email protected]* <[email protected]> > * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * > *http://blog.afkham.org* <http://blog.afkham.org> > *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> > * linked-in: **http://lk.linkedin.com/in/afkhamazeez > <http://lk.linkedin.com/in/afkhamazeez>* > > *Lean . Enterprise . Middleware* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Lasantha Fernando* Software Engineer - Data Technologies Team WSO2 Inc. http://wso2.com email: [email protected] mobile: (+94) 71 5247551
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
