Hi all,
In Andes client, I implemented a new initialContextFactory and inside that,
I made an AMQP URL.
Inside the Andes client, I called that web service to get the cluster node
IP address and Port details. When calling web service it shuffles the IP
address and gives String to the client.
On Wed, Sep 28, 2016 at 5:54 PM, Thusitha Thilina Dayaratne <
thusit...@wso2.com> wrote:
> Hi Sagara,
>
> I've added the ninja framework sample[1] to the perf test. We will use
> that too in the next msf4j release perf test.
>
Great !
Thanks !
>
> [1] - https://github.com/wso2/msf4j/pull/281
>
Hi Sagara,
I've added the ninja framework sample[1] to the perf test. We will use that
too in the next msf4j release perf test.
[1] - https://github.com/wso2/msf4j/pull/281
Thanks
Thusitha
On Fri, Jul 15, 2016 at 10:53 AM, Sagara Gunathunga wrote:
> What about ${Subject}
On Wed, Sep 28, 2016 at 3:27 PM, Chathura Ekanayake
wrote:
> If we are not storing trivial artifacts, it is very difficult to use a
> common UI for store and especially for publisher. If a store framework is
> used, we end up extending it and in many situations it can become
If we are not storing trivial artifacts, it is very difficult to use a
common UI for store and especially for publisher. If a store framework is
used, we end up extending it and in many situations it can become more
complex than developing a new UI. Therefore, I agree with Nuwan and
SajithAR that
Hi Ishara,
Thank you for the input. Having similar discussion with Darshana and Isura,
I have started extending askPassword implementation with email verification
flow in order trigger a password reset by capturing "update credential"
event. Still, we need a mechanism to distinguish admin
Hi Ayesha,
On Tue, Sep 27, 2016 at 11:00 AM, Isura Karunaratne wrote:
> Hi Ayesha,
>
> We can extend Ask Password feature we developed in IS 5.3.0 to support
> this feature. So, we can send a confirmation email rather than an OTP.
>
There can be different user cases.
If we think
>
> On Wed, Sep 28, 2016 at 10:06 AM, Chandana Napagoda
> wrote:
> I believe that we should identify commonly used components and implement
> them in a generalized manner. So relevant product team can extend those
> components based on their requirements.
Agreed, this is the