Currently, we always ship the clients and Admin services in one pack, so if
we change one we automatically get the other.
Do we have a usecase where we need clients and admin services are separate?
I think this make sense for those cases only. For example, BAM should be
able to receive events from
We had several discussion on doing Throttling with Siddhi or CEP, shall we
do that?
On Tue, Apr 7, 2015 at 9:53 AM, Kasun Indrasiri wrote:
> This will be used by several products. Hence I think we need to have it in
> a common repo such as carbon-commons or something.
> Sameera any thoughts on t
I think we have already done one with APIM we can refine that and make that
as a generic implementation
WDYT?
Suho
On Wed, Apr 8, 2015 at 4:01 PM, Srinath Perera wrote:
> We had several discussion on doing Throttling with Siddhi or CEP, shall we
> do that?
>
> On Tue, Apr 7, 2015 at 9:53 AM, K
Hi,
We[BPS team] have plans to develop workflow Integration components that
will tally with this implementation. Hence different products will not
require to build workflow extensions to obtain human intervention for
approval processes for certain activities performed within these products.
Idea
hi Rajeenthini,
the proposed jquery-validation would a realy helpful feature.
But even more helpful would it be to validate on client-side in sync with
server-side-validation. The data would be secure and consistent through
server-side-validation. And at the same time the user experience would be
Hi Sachini,
#3, do we make any DEBS related assumptions? I think no.
Please also add it to docs and wrap it up completely.
--Srinath
On Tue, Apr 7, 2015 at 2:28 PM, Sachini Jayasekara
wrote:
> Hi Srinath,
>
> 1) It's already been done
> 3) Yes, FrequentK, MaxK, and Median functions can be pu
Hi Isuru,
As per our chat yesterday, please look at the $subject. Idea is not to
intergate those tools, but document and know them so we can use them
internally for debugging etc.
Lets start with Flame Graphs
http://www.brendangregg.com/blog/2014-06-12/java-flame-graphs.html
Others could be
htt
On Thu, Apr 9, 2015 at 11:23 AM, Srinath Perera wrote:
> Can Miyuru update the Doc? Miyuru can u update doc while you are at it.
>
Documented some steps on the setup[1] hope it helps.
[1]
https://docs.google.com/a/wso2.com/document/d/1l_qewhLiY2cPLoBcz9TXr2i-m583A2qkZwYcGj_lDfc/edit#
>
> --Sri
Hi Srinath,
>
>
> #3, do we make any DEBS related assumptions? I think no.
>
No DEBS related assumptions. But have to do some
small alterations to FrequentK and MaxK before putting to siddhi.
>
>
> Please also add it to docs and wrap it up completely.
>
@Manu, first up, thanks for implementing this with such a short notice. Now
that we've got this fully implemented, would you be able to drop a note to
the thread explaining the config bits associated with enabling the required
authorization levels for UI blocks?
Cheers,
Prabath
On Wed, Mar 25, 20
Can Miyuru update the Doc? Miyuru can u update doc while you are at it.
--Srinath
On Thu, Apr 9, 2015 at 10:46 AM, Miyuru Dayarathna wrote:
> Hi Tishan,
>
> Thank you for providing me the information. I will work on setting up the
> environment based on these guidelines and will get in touch wi
Hi Miyuru,
For starters try out this[1] sample. But please note
that storm-deployment-config.xml is now part of event-processing.xml which
is at /repository/conf. So steps may vary slightly. AFAIK
separate effort is there to enrich storm documentation. You can contribute
to that as well with your
12 matches
Mail list logo
