On Mon, Jan 27, 2014 at 11:54 AM, Harshana Martin <[email protected]> wrote:
> HI All, > > I think what Kishanthan has mentioned in his first reply is the correct > way. > > Jaggery Apps are (whether they come as a part of the server or not) are > deployable artifacts and the correct approach is to redeploy the newer > version of that artifact in the server because it is the easiest and > cleanest. There is no need to make the life complicate by introducing patch > folders because like in OSGi bundles we do not have other complications > tied in to these Jaggery Applications. We cannot follow the simply replace > task for Jar files/bundles because it needs to have the revert capability > as well which I do not see for the Jaggery app. But with OSGi bundles also > we effectively do the same during the patch application process. > +1. In future we might need to patch jaggery apps as most of our UIs based on jaggery. So i think this is something we should support. Thanks, sanjeewa. > > Thanks and Regards, > Harshana > > > On Mon, Jan 27, 2014 at 11:38 AM, Shameera Rathnayaka > <[email protected]>wrote: > >> 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 <%2B9471%20922%201454>* >> >> *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 >> >> > > > -- > > 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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* Senior Software Engineer WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/<http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
