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
