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 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
