Hi all, IMHO, anything shipped in the binary pack that we release has a potential of eventually being patched. Some files may be more frequently patched and some might never be. But, given that each file can potentially be patched the patching model needs to take everything into consideration.
So, though we started off discussing jaggery apps, we should be looking at the broader picture (as Ruchira explained). But, it is not easy as replacing files. Let me explain why. - There are configuration files where users may introduce changes. These files should either be excluded from the patching model or we need to capture it in a way such that automatic replacements do not happen. Now, again, its not easy as giving repository/conf special treatment, because configurations for Jaggery apps reside within them. So, we need a story that works for everything. - Patching DB scripts won't help a bit, because the actual DBs should also be migrated if something is done, so they cannot be a part of the patching model. - When we patch, we also need to be looking @ maintaining backups. We have a model to backup the OSGi bundles (i.e. patch0000). For Jaggery Apps, we need something equivalent. - Also, just like jaggery apps, we also have other things like webapps (JAX-RS and JAX-WS services deployed on CXF), humantasks (ex:- WorkList in G-Reg), etc. If we are trying to find a solution for Jaggery Apps so must we find a solution for these two, or the patching model will keep changing release after release. So, IMHO, its best to start with something focusing on the complete story, find what problems that approach presents and find solutions for those rather than picking individual problems and solving them locally. Also, Kishanthan, we simply cannot categorize anything to be user-level and exclude it. As I said before, we are liable to have a strategy to patch anything that we ship. And, if each individual type of artifact is patched in its own way, the life of the server administrator becomes very complicated. So, we must try to make things work in a similar way as much as possible. Thanks, Senaka. On Sun, Jan 26, 2014 at 10:20 AM, Kishanthan Thangarajah < [email protected]> wrote: > > > > On Sat, Jan 25, 2014 at 4:53 PM, Sameera Medagammaddegedara < > [email protected]> wrote: > >> Hello Everyone, >> >> *Problem* >> >> - As it stands ,if a Jaggery application needs to be updated the user >> must manually copy the required files >> - This introduces a number of problems >> - If several files need to be changed it will become a chore >> - A user may forget to copy one or more files >> - It departs from the normal way in which patches are applied to >> other WSO2 products >> >> > IMO, these are user level issues. From a server POV, a jaggery app is > considered as a deployment artifact. So it can follow the process of normal > artifact update. > > But the main point here on why do we need to patch jaggery apps is that, > with some product releases, we are also releasing jaggery apps as part of > it. So we need a way to patch those released apps. > > >> >> - The files that could be included in a patch to a Jaggery file could >> include (but is not limited ) to the following; >> 1. JAG files >> 2. JS files >> 3. Jaggery Modules ( These will be JS files) >> 4. Images and CSS files >> 5. JSON files >> >> *Suggestion* >> >> - Package the files to be replaced in a zip format >> - All Jaggery App patches could be placed in the >> repository/components/patches/jaggeryapps similar to the way existing >> patches are applied >> - *Structure of the patch* >> - Please refer to attached image >> - The files to be updated would need to be organized according to >> structure of the app or module to be patched >> - Before the application is deployed the archive is extracted and >> the files copied over to the mirrored location in the app or module to be >> patched >> >> > The important question to ask is who will handle the patch applying > process for jaggery apps? > > *Open Questions* >> >> - How do we handle reverting a patch? >> - How can we apply the patch before Jaggery app is deployed? >> >> Thank You, >> >> Sameera >> >> >> -- >> Sameera Medagammaddegedara >> Software Engineer >> >> Contact: >> Email: [email protected] >> Mobile: + 94 077 255 3005 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
