+1. Thanks and Regards, Harshana
On Mon, Jan 27, 2014 at 6:27 AM, Afkham Azeez <az...@wso2.com> wrote: > We should strictly stick to supporting patching the middleware only. If > you start supporting patching deployed artifacts, it becomes a > slipery slope. > > > On Sun, Jan 26, 2014 at 7:29 PM, Kishanthan Thangarajah < > kishant...@wso2.com> wrote: > >> If I think along this view point, a clean way to handle this is to >> register a carbon server extension, which gets executed during the server >> start-up. And this extension should handle the patch applying strategy for >> apps (or anything we need do before the server starts). This is how we >> handle the normal patch applying process also. A carbon server extension is >> a launch extension, which gets executed before the OSGi run-time is started >> (eg: dropins bundle installer, patch installer, etc). >> >> But currently, without requiring code changes, it is not possible to >> register a new server extension. There should be a way (may be via >> configuration file) to register new server extensions with server. But this >> feature is lacking at kernel level now. May be we can consider this >> requirement for next kernel release (4.3.x). >> >> This also leads to some other questions as-well. i.e we have to a >> patching process which is common and consistence for all kind of artifacts >> we plan to support. >> >> >> >> On Sun, Jan 26, 2014 at 2:22 PM, Senaka Fernando <sen...@wso2.com> wrote: >> >>> 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 < >>> kishant...@wso2.com> wrote: >>> >>>> >>>> >>>> >>>> On Sat, Jan 25, 2014 at 4:53 PM, Sameera Medagammaddegedara < >>>> samee...@wso2.com> 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: samee...@wso2.com >>>>> Mobile: + 94 077 255 3005 >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> Architecture@wso2.org >>>>> 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 >>>> Architecture@wso2.org >>>> 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 <%2B1%20408%20754%207388>; ext: 51736*; >>> >>> >>> *M: +94 77 322 1818 <%2B94%2077%20322%201818> Linked-In: >>> http://linkedin.com/in/senakafernando >>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>> >> >> >> >> -- >> *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 >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Afkham Azeez* > Director of Architecture; WSO2, Inc.; http://wso2.com > Member; Apache Software Foundation; http://www.apache.org/ > * <http://www.apache.org/>* > *email: **az...@wso2.com* <az...@wso2.com> > * 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 > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Harshana Martin Associate Technical Lead WSO2 Inc. : http://wso2.com Mobile: +94 775 998 115 Profile: https://www.google.com/profiles/harshana05 Blog: http://harshana05.blogspot.com Twitter: http://twitter.com/harshana05
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
