what will happen if broken-page.js was edited by the user? then patching
will override everything right?
On Wed, Feb 19, 2014 at 10:49 AM, Madhuka Udantha madh...@wso2.com wrote:
Hi,
*Deploying patches *
If we have meta file(/json file) in patch directory can be used as patch
meta
Before replacing the files, we will have to validate the checksum with the
latest copies provided, back it up and replace, or just notify the
user(either a log entry or as the diff) without replacing.
/Ruchira
On Wed, Feb 19, 2014 at 2:42 PM, Madhuka Udantha madh...@wso2.com wrote:
On Wed,
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
On Tue, Feb 18, 2014 at 3:42 PM, Ruchira Wageesha ruch...@wso2.com wrote:
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
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. Shall we come to a conclusion and
implement this. IMO this is vital to all the products that has jaggery
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 madh...@wso2.com wrote:
On Mon, Feb 17, 2014 at 8:56 PM, Nuwan Bandara nu...@wso2.com
Hi Nuwan and all,
If there is a patch which has a dependency to jar file(say a hostobject or
any other carbon bundle changed) which will be used in jaggery application,
In that case, we have a dependency between jaggery patch and usual
patch(patch). How does the dependency resolution works if
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
- We can either ask them to
On Thursday, January 30, 2014, Tanya Madurapperuma ta...@wso2.com wrote:
On Wed, Jan 29, 2014 at 10:49 AM, Chan duli...@wso2.com wrote:
On Wed, Jan 29, 2014 at 10:43 AM, Chan duli...@wso2.com wrote:
On Wed, Jan 29, 2014 at 10:25 AM, Madhuka Udantha madh...@wso2.comwrote:
On Wed,
On Sat, Jan 25, 2014 at 4:53 PM, Sameera Medagammaddegedara
samee...@wso2.com 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
Cluster-wide patch distribution will be handle by the Operations Center.
Azeez
On Tue, Jan 28, 2014 at 12:40 PM, Ruchira Wageesha ruch...@wso2.com wrote:
If we patch a webapp, then we will do it only on master node and the
patching process is for that. Synchronizing workers with master is
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
What should we do?
On Tue, Jan 28, 2014 at 4:51 AM, Chan duli...@wso2.com wrote:
Hi All
On Tue, Jan 28, 2014 at 11:33 AM, Manuranga Perera m...@wso2.com 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
The solution is to update the app through patch file if the app is uses a
textual scripting language
this is a nice solution, but we need support form carbon kernel to do this,
so we don' have to ask users to go and do it manually.
--
With regards,
*Manu*ranga Perera.
phone : 071 7 70 20 50
How do you patch PHP apps? You provide a patch file apply that which
changes the relevant PHP pages. How do you patch a .war file? You change
it redeploy it, or deploy a different version. These are the standard
ways of patching webapps. Don't expect a solution such as having a
On Wed, Jan 29, 2014 at 12:18 AM, Manuranga Perera m...@wso2.com wrote:
The solution is to update the app through patch file if the app is uses a
textual scripting language
this is a nice solution, but we need support form carbon kernel to do
this, so we don' have to ask users to go and do
On Mon, Jan 27, 2014 at 11:54 AM, Harshana Martin harsh...@wso2.com 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
*-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
Hi All,
On Tue, Jan 28, 2014 at 6:23 AM, Afkham Azeez az...@wso2.com wrote:
On Mon, Jan 27, 2014 at 10:59 PM, Manuranga Perera m...@wso2.com wrote:
*-1* for not being able to patch jaggery apps using stranded patch
procedure.
1) First of all, special patches make lots of trouble.
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.
Why do we release patches for carbon products? Instead we could
On Tue, Jan 28, 2014 at 11:55 AM, Sanjeewa Malalgoda sanje...@wso2.comwrote:
On Tue, Jan 28, 2014 at 11:37 AM, Ramith Jayasinghe ram...@wso2.comwrote:
Hi Kishanthan,
if we version the webapp(s) will that change the endpoint? if so the
reality of that is users has to keep changing
The bottom line is, there are tried tested solutions for these problems
that have worked over the past many years. We don't have to reinvent
solutions only to figure out a few years later that the tried tested
solution is in fact the best one. The branching strategy is a good example
where we
If we patch a webapp, then we will do it only on master node and the
patching process is for that. Synchronizing workers with master is a
different task which belongs to depsync. Why do we need to mix up the
things? May be I am missing something?
No, you can't have patching only at
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.
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
I don't think that we should support patching jaggery apps, webapps, or any
other app for that matter. As a matter of fact, there is no such thing as
patching a .war file or a PHP app. If there is some problem in an app, the
solution is to either overwrite it, or introduce a new version.
Azeez
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 kishant...@wso2.com
wrote:
If I think along this view point, a clean way to handle this
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
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
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
+1.
Thanks and Regards,
Harshana
On Mon, Jan 27, 2014 at 6:27 AM, Afkham Azeez az...@wso2.com 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,
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
32 matches
Mail list logo
