On Tue, Feb 18, 2014 at 12:15 PM, Ruchira Wageesha <[email protected]> wrote:
> Hi, > > If we are going with patching directory model, then following are my > initial thoughts. > > - We will have a directory named .patches(or a better name) in the app > root > - Patches will have to be copied into that with directories named 0, > 1, 2 ... n > > Better we have some name rather 'patches' such 'jaggery-patch' or any name. Since carbon platform also have 'patch0001', this name could confuse customers and need to think how we will manage it in support as well. > > - We can either ask them to restart the server or we can simply hot > deploy/undeploy the patches by listening to the .patch directory of the app > > Another doubt that I have is, whether we need to offer it as a part of > Jaggery core itself or to offer it as a Jaggery module. If it is included > in the core, then Jaggery server itself will be looking at the directories > and deploy the patches. > +1, > But, if we go with a Jaggery module, then they will have to explicitly > engage/initialize the apps for patching via an init script. > If we follow jaggery module for patching then to apply patch, user have to update/add jaggery config file and init script. It is not much good in IMO If this feature come from jaggery core user only need to add the patch folder. It is bit easy and nice for jaggery app user/Dev. > WDYT? > > /Ruchira > > > > On Tue, Feb 18, 2014 at 11:17 AM, Chan <[email protected]> wrote: > >> Guys it would be awesome if you can describe how the patch directory in >> the app works (I mean in detail). Then everyone will be clear about it. >> >> Cheers~ >> >> >> On Tue, Feb 18, 2014 at 10:12 AM, Madhuka Udantha <[email protected]>wrote: >> >>> >>> >>> >>> On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara <[email protected]> wrote: >>> >>>> Guys whats the verdict on this discussion ? Having a patch directory >>>> within the app seems to be a fine idea, which does not effect the platform >>>> patching or raise depsyc complications. >>>> >>> "patch directory" was most fine solution that we came across on this >>> thread and also same discussion had in few email threads[1] did not have >>> any conclusion for $subject. I too think $subject is essential for all >>> products that depend on jaggery apps >>> I am +1 for "patch directory" >>> >>> Shall we come to a conclusion and implement this. IMO this is vital to >>>> all the products that has jaggery applications. >>>> >>>> >>> [1] Webapp Patching Strategy @ [email protected] on 4/5/13 >>> >>>> Regards, >>>> /Nuwan >>>> >>>> >>>> On Thu, Jan 30, 2014 at 12:19 AM, Chan <[email protected]> wrote: >>>> >>>>> >>>>> >>>>> On Thursday, January 30, 2014, Tanya Madurapperuma <[email protected]> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 29, 2014 at 10:49 AM, Chan <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 29, 2014 at 10:43 AM, Chan <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha >>>>>> <[email protected]>wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Jan 29, 2014 at 3:27 AM, Nuwan Bandara <[email protected]>wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 1:19 PM, Afkham Azeez <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 11:06 PM, Nuwan Bandara <[email protected]>wrote: >>>>>> >>>>>> Hi All >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera <[email protected]>wrote: >>>>>> >>>>>> The problem ultimately boils down to this common scenario: >>>>>> >>>>>> a) A customer has a Jaggery app in their environment. >>>>>> b) Some UI (images, css, headers, ect.) is customized >>>>>> c) Now they find a bug and ask for a patch >>>>>> >>>>>> >>>>>> +1, the issue here is all others replied here against patching a >>>>>> jaggery app is because you think of a jaggery app as a "hello world" web >>>>>> app. But you should look at the jaggery code in products like APIM / >>>>>> AppFac >>>>>> / UES / ES / MDM. In all these products Jaggery app is the place that has >>>>>> the major business logic. In these products Carbon is just the hosting >>>>>> environment. These are full fledge applications that does all kinds of >>>>>> things, generate meta data, has its own configurations etc, and when we >>>>>> find a minor issue we cannot ask people to replace the entire app and >>>>>> reconfigure every thing from the beginning. >>>>>> >>>>>> Just try the application developers shoes for a moment here and get >>>>>> out of the midleware developer mindset; Imagine we have developed an >>>>>> application and thats our main product. Now how do you fix problems in >>>>>> this >>>>>> product ? will you be shipping new versions of the product always when >>>>>> you >>>>>> find an issue ? If that is the case we will be shipping new versions of >>>>>> AS >>>>>> every day ;) >>>>>> >>>>>> Also when there is a requirement we should not think about how it can >>>>>> be squeezed into the existing model with minimum headache. We should >>>>>> find a >>>>>> comfortable solution for the users not something comfortable to >>>>>> implement. >>>>>> >>>>>> >>>>>> The requirement is to fix bugs in apps. The requirement is not, >>>>>> support patching of webapps. The solution is to update the app >>>>>> through patch file if the app is uses a textual scripting language, >>>>>> or redeploy changed or a new version, if the app is in a compiled/binary/ >>>>>> bytecode form. >>>>>> >>>>>> >>>>>> +1, that should work, but we nee >>>>>> >>>>>> AFAIU this solution is not feasible as we have to maintain a separate >>>>>> git repo for each customer. >>>>>> >>>>> As far as I know - we do maintain code bases for customers. Plus >>>>> maintaining git repos for customers is realistically not a hard thing to >>>>> do >>>>> cause everything is scriptable in git. >>>>> >>>>>> It will become an issue when the number of customers grow. And also >>>>>> customers with lesser developer knowledge will face issues in resolving >>>>>> conflicts in merging etc. >>>>>> >>>>> If customers customize our jaggery apps which they will definitely do >>>>> - they will version control it anyway and most probably they will use git. >>>>> >>>>> >>>>>> >>>>>> Patches approach is nice but thinking from an Application Developer >>>>>> stand point version controlling is the best way to handle this type of >>>>>> patches. Food for thought I guess. >>>>>> >>>>>> [1] - https://devcenter.heroku.com/articles/git >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 1:37 PM, Afkham Azeez <[email protected]> wrote: >>>>>> >>>>>> Cluster-wide patch distribution will be handle by the Operations >>>>>> Center. >>>>>> >>>>>> Azeez >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha >>>>>> <[email protected]>wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Tanya Madurapperuma >>>>>> >>>>> >>>>> >>>>> -- >>>>> Chan (Dulitha Wijewantha) >>>>> Software Engineer - Mobile Development >>>>> WSO2Mobile >>>>> Lean.Enterprise.Mobileware >>>>> * ~Email [email protected] <[email protected]>* >>>>> * ~Mobile +94712112165 <%2B94712112165>* >>>>> >>>>> * ~Website dulithawijewantha.com <http://dulithawijewantha.com/> * >>>>> >>>>> * ~Blog blog.dulithawijewantha.com >>>>> <http://dulichan.github.io/chan/>* >>>>> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >>>>> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> *Thanks & Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. * >>>> *lean . enterprise . middleware | http://wso2.com <http://wso2.com> * >>>> >>>> *blog : http://nuwanbando.com <http://nuwanbando.com>; email: >>>> [email protected] <[email protected]>; phone: +1 812 606 7390 >>>> <%2B1%20812%20606%207390> * >>>> <http://www.nuwanbando.com/> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> *Madhuka* Udantha >>> Senior Software Engineer >>> Development Technologies >>> WSO2 Inc. : http://wso2.com >>> >>> *Mobile*: +94774066336 >>> *Blog*: http://madhukaudantha.blogspot.com/ >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Chan (Dulitha Wijewantha) >> Software Engineer - Mobile Development >> WSO2Mobile >> Lean.Enterprise.Mobileware >> * ~Email [email protected] <[email protected]>* >> * ~Mobile +94712112165 <%2B94712112165>* >> >> * ~Website dulithawijewantha.com <http://dulithawijewantha.com/> * >> >> * ~Blog blog.dulithawijewantha.com >> <http://dulichan.github.io/chan/>* >> * ~Twitter @dulitharw <https://twitter.com/dulitharw>* >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > *Ruchira Wageesha**Associate Technical Lead* > *WSO2 Inc. - lean . enterprise . middleware | wso2.com <http://wso2.com>* > > *email: [email protected] <[email protected]>, blog: > ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, > mobile: +94 77 5493444 <%2B94%2077%205493444>* > -- *Madhuka* Udantha Senior Software Engineer Development Technologies WSO2 Inc. : http://wso2.com *Mobile*: +94774066336 *Blog*: http://madhukaudantha.blogspot.com/
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
