Hi All, On Tue, Jan 28, 2014 at 6:23 AM, Afkham Azeez <[email protected]> wrote:
> > > > On Mon, Jan 27, 2014 at 10:59 PM, Manuranga Perera <[email protected]> wrote: > >> *-1* for not being able to patch jaggery apps using stranded patch >> procedure. >> >> 1) First of all, "special" patches make lots of trouble. "Special" patch >> is a patch where user has to read the README.txt and follow any special >> instructions other than copying them to patches dir. These become >> problems during support all the time. >> >> 2) Saying we can't patch a Jaggery app via stranded procedure is like >> saying we can't patch a UI bundle jar. How is it any different ? >> > > Not it is not the same. We can't introduce an arbitrary patching mechanism > just for Jaggery. How do you patch webapps? There is no such thing called > patching a webapp! You update it or deploy a new version. Same goes for > Jaggery. > +1 And If there is a bug in my Web-App or Jaggery App, should I be Redeploy it or Patch it? What is the difference and under what circumstances should i be following those 2? Patching Web-App does not make any sense at all. Thanks and Regards, Harshana > > >> >> 3) Patching UI bundles were necessary, but in the past this has caused >> some issues where users have customized UI. That's why we need an improved >> mechanism to patch UI stuff. I think we can take this as an opportunity to >> implement that improvement. >> >> >> >> On Mon, Jan 27, 2014 at 12:27 AM, Sanjeewa Malalgoda >> <[email protected]>wrote: >> >>> >>> >>> >>> 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 thereown >>>>>> 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/confspecial >>>>>>>>> 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 jaggeryapp 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 >>> >>> >> >> >> -- >> With regards, >> *Manu*ranga Perera. >> >> phone : 071 7 70 20 50 >> mail : [email protected] >> >> _______________________________________________ >> 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 > > -- 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
