Hi, +1 for using an API in patching.
As per the discussions we are having on the OC architecture, OC will not directly upload the patch to a particular server, instead OC will sends the details about the repository location to the patching engine and patching engine should be able to download patch and apply the patch. *Jayanga Dissanayake* Senior Software Engineer WSO2 Inc. - http://wso2.com/ lean . enterprise . middleware email: [email protected] mobile: +94772207259 On Wed, Apr 30, 2014 at 11:44 AM, 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. >>> >>> >>> 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
