We may need this for our internal integration. Recently decided this is
going to be upgraded to *5.8.17* from *5.3.4.*
Can we do a connector for rest api instead please?
[1] https://developer.atlassian.com/confdev/confluence-rest-api
On Mon, Nov 30, 2015 at 3:37 PM, Sajitha wrote:
> *Introduct
Hi Srinath,
Thanks for initiating this.
On Tue, Dec 1, 2015 at 1:28 PM, Srinath Perera wrote:
> Hi Nirmal,
>
> I tried to think about what are gaps in ML algorithms. Basically, there
> are three main things we want to do with ML ( ignoring unsupervised and
> semi-supervised method for understan
Hi Nuwan, Sanjeewa and Joe,
Thanks a lot for all the suggestions.
I have a small doubt for using the group as part of the path.
Lets say we use GET /tiers/api/{tier-id} to get a single API tier by its id
(actually Name). Then, are we exposing the resource /tiers alone too? If
we do, are we retu
Hi,
Another option is using a combined id. Ex: /tiers/{group}-{tiername}. That
is similar for the {provider}-{api}-{version} parameter we used for
identifying an API.
Thanks.
On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe
wrote:
> Hi Nuwan, Sanjeewa and Joe,
>
> Thanks a lot for all the
I think the group param should be mandatory. Therefore there will not be a
GET /tiers, but instead a GET /tiers/{level} only.
Thanks,
NuwanD.
On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe
wrote:
> Hi Nuwan, Sanjeewa and Joe,
>
> Thanks a lot for all the suggestions.
>
> I have a small do
Hi all,
After testing this we could observe that the individual jar sized were
almost halved.
The final P2 contains both the packed jars and unpacked jars and on
downloading it downloads the packed jars, hence the download time was also
reduced to a reasonable extent.
Yet, one concern we have is
Just to double-check: but we still have a POST /tiers to add a new tier to
the collection, right?
Best regards,
Frank
2015-12-01 11:50 GMT+01:00 Nuwan Dias :
> I think the group param should be mandatory. Therefore there will not be a
> GET /tiers, but instead a GET /tiers/{level} only.
>
> Th
Hi Nuwan,
Thanks for the clarification.
Hi Frank,
Yes, would that need to be changed for POST /tiers/{tier-level}? Or shall
we keep the previous one (/tiers ) only for POST and identify the tier
level from the request body?
Thanks.
On Tue, Dec 1, 2015 at 5:32 PM, Frank Leymann wrote:
> Just
Hi all,
It has become a vital requirement to avoid access tokens being expired
which are used in the connectors. This issue can be avoided at the
connector level, using the refresh tokens provided by the corresponding
api. In order to have this requirement fulfilled we wanted to use the
persistent
Hi Malintha
The POST should go to /tiers/{tier-level} since if you are posting /tiers
you need to add an additional parameter. BTW is the tier model same for all
the levels ?
Thanks
Jo
On Tue, Dec 1, 2015 at 5:40 PM, Malintha Amarasinghe
wrote:
> Hi Nuwan,
>
> Thanks for the clarification.
>
>
Hi Sajitha,
Consider following for the v1
*Selected Methods:*
*Webservices*
geoNameSearch:Returns the names found for the searchterm.
postalCodeSearch: Returns a list of postal codes and places for the
placename/postalcode query.
listPlacesForPostalcode: Returns a list of places for the given po
Yes this is a required feature for many use cases. I guess we have missed
it from esb 490 release.
Added jira[1] to track this for esb 4.10 release.
[1] https://wso2.org/jira/browse/ESBJAVA-4346
On Tue, Dec 1, 2015 at 10:12 PM, Nadeeshaan Gunasinghe
wrote:
> Hi all,
> It has become a vital req
Hi Nadeeshan,
avoiding the access token expiration is really important feature for
connector's stability. i hope it will work with all kind of connectors
which are need access tokens not only with Google connectors.
On Wed, Dec 2, 2015 at 9:23 AM, Malaka Silva wrote:
> Yes this is a required fea
I think all the required changes are already merged into ESB 4.10. If so
can we resolve the jira?
On Wed, Dec 2, 2015 at 9:45 AM, Rajjaz Mohammed wrote:
> Hi Nadeeshan,
> avoiding the access token expiration is really important feature for
> connector's stability. i hope it will work with all ki
Resolved the jira. Check the functionality on pre release pack and seems to
be working.
On Wed, Dec 2, 2015 at 10:14 AM, Kasun Indrasiri wrote:
> I think all the required changes are already merged into ESB 4.10. If so
> can we resolve the jira?
>
> On Wed, Dec 2, 2015 at 9:45 AM, Rajjaz Mohamme
Hi Joe, Hi Nuwan,
Yes as of now we are using the same model for all levels. Bdw we have
following two attributes in the model which is specific to API tiers.
"stopOnQuotaReach": true,
"tierPlan": "FREE"
Would that be OK for having it for all levels? As we might be implementing
this in the future
Hi,
WSO2 BPS already contains a RESTInvokerTask to send a message from a BPMN
process instance to a REST service. Similarly, we can provide a JMS
transport support for BPMN. This includes the following tasks:
* - JMSStartEvent*
This activity consists of a reference to an external JMS
Hi Dilini,
What is the Acknowledgement Type you are hoping to use here?
Or is it configurable?
Acknowledgment type changes the way JMS messages are acked. Once acked,
message is getting removed from the queue. i.e if you use AUTO_ACK message
will be acked no matter processing failed or not. If yo
Hi Hasitha,
Currently we are using AUTO_ACK as the acknowledgement type. This is
because there are limitations in using client acknowledgements in BPMN.
Thanks for the suggestions.
On Wed, Dec 2, 2015 at 11:48 AM, Hasitha Hiranya wrote:
> Hi Dilini,
>
> What is the Acknowledgement Type you ar
19 matches
Mail list logo
