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
Hi Srinath,
Yes. We are in the process of developing an ESB connector for the github.
Basically there are 254 operations listed under the API document[ 1]. We
have selected 123 out of 254 to go ahead based on the usability of each
operation.
Here with I have attached the orginal analysis
This may be different from the current context but may be important if we
are thinking back to re-implement the data-bridge in a better way.
In the current data publishing, the publisher side should be authenticated
with the BAM/CEP side username and password. This is asking for username
and
*Introduction*
IBM® CICS® Transaction Server is a family of scalable general-purpose
transaction processing solutions for z/OS®, VSE/ESA, and distributed
platforms. These servers support large transaction volumes with fast,
consistent response times and provide high availability and scalability at
Hi All,
We are pleased to inform you that the second milestone release for Carbon
Kernel 5.0.0 is now available for download [1].
This milestone includes the first development release of carbon based
deployment framework [2].
*Fixed Issues*
https://wso2.org/jira/browse/CARBON-14605?filter=11710
*-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
Thought of some improvements.
- We shall have an AbstractThrottleDecisionEngine so that we can extend the
core to support various decision engines later on (to accommodate
suggestions from Suho and Senaka).
- Make CallerContext abstract so extend into ClusterAwareCallerContext and
I don't think we need a single node caller context. This is a feature that
will always get used in production in a cluster.
On Jan 28, 2014 7:40 AM, Manoj Fernando man...@wso2.com wrote:
Thought of some improvements.
- We shall have an AbstractThrottleDecisionEngine so that we can extend
the
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.
Hi All,
The summary of the meeting is as follows.
- The repository implementation should be very minimal.
- Social aspects like Comments and Tags need not be in the Repository.
- UserRegistry and RemoteRegistry need not be in the repository and have
to be moved to platform
- Axis2
The idea was to have separate implementations for stand-alone and clustered
scenarios of which in the stand-alone, we will not have to deal with global
counters at all. In this way, we don't have to do multiple checks for
cluster availability on the code.
- Manoj
On Tue, Jan 28, 2014 at 8:46
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
Hi Sameera,
I doubt whether we will need a different client side framework for this?
AFAIK, improving t helper in caramel to load the proper translation from
the server would be enough?
i.e. In your handlebar templates, you have h2t('app.title')/h2 and in
your translation file you will have,
{
On Tue, Jan 28, 2014 at 7:31 AM, Manoj Fernando man...@wso2.com wrote:
Thought of some improvements.
- We shall have an AbstractThrottleDecisionEngine so that we can extend
the core to support various decision engines later on (to accommodate
suggestions from Suho and Senaka).
+1 for doing
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
17 matches
Mail list logo
