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