Hi , Totally agree with Azeez, better way to patch( I think update is the correct word here) app is redeploy it. If there is such requirement, then shouldn't it handle by corresponding runtime instead of framework.
Thanks, Shameera. On Mon, Jan 27, 2014 at 7:17 AM, Joseph Fonseka <[email protected]> wrote: > Hi > > Another difficulty when patching jaggary apps is that there can be > customizations made by users. Ex most of the APIM users has there own > themes for the store and publisher. These customizations can be only at the > CSS level but possibly they might change the template files as well. > > But +1 if we could provide a patching or updating mechanism because there > can be important security fixes that we need to push out to clients. > > Thanks > Jo > > > On Mon, Jan 27, 2014 at 6:27 AM, Afkham Azeez <[email protected]> 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 < >> [email protected]> 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 <[email protected]>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 < >>>> [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 <%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 >>> [email protected] >>> 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: **[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 >> >> > > > -- > > -- > *Joseph Fonseka* > WSO2 Inc.; http://wso2.com > lean.enterprise.middleware > > mobile: +94 772 512 430 > skype: jpfonseka > > * <http://lk.linkedin.com/in/rumeshbandara>* > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Software Engineer - WSO2 Inc.* *email: shameera AT wso2.com <[email protected]> , shameera AT apache.org <[email protected]>* *phone: +9471 922 1454* *Linked in : *http://lk.linkedin.com/pub/shameera-rathnayaka/1a/661/561 *Twitter : *https://twitter.com/Shameera_R
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
