Re: [Dev] [Automation Framework]

+1 Ideally we should have a different version for connectors in integration > base. > If we modify the connector integrationBase we can optimize the integration test time. -- Thank you Best Regards *Rajjaz HM* Associate Software Engineer Platform Extension Team WSO2 Inc.

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

IMO this will create maintainability issue. We need to maintain all the separate hieradata structure for each scenarios.For the one particular alternation we need to change whole set of files. Why can't we do this by using defined types in Hiera and lookup parameters for a given instance? Based

[Dev] [APIM][BPS] Configure API-Subscription Workflow for APIM packed with IoTS

Hi All, I am trying to do $subject for the IoTServer as explained in [1] . However, since the jaggeryapp *"admin-dashboard"* is not copied from the *bin.xml* whilst the distribution is packed I have copied it manually to

Re: [Dev] [APIM][BPS] Configure API-Subscription Workflow for APIM packed with IoTS

Hi All, Found the reason for the above. IoTSever pack was missing the proxy-service *"WorkflowCallbackService.xml" *thats available in the APIM 1.10.0. It is this service that is set as the callback URL in the workflow creation request sent to BPS. Hence when the task is approved and BPS tries

Re: [Dev] [APIM][BPS] Configure API-Subscription Workflow for APIM packed with IoTS

Hi Shabir, The admin-dashboard workflow view will useful only if the workflow is a BPS based business process and if it contains human tasks.The admin dashboard workflow view will be used for approving/disproving human tasks associated in BPS side triggered process by the workflow.Once the user

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Gayan, On Sun, Apr 10, 2016 at 5:02 PM, Gayan Gunarathne wrote: > IMO this will create maintainability issue. We need to maintain all the > separate hieradata structure for each scenarios.For the one particular > alternation we need to change whole set of files. > In this

Re: [Dev] Call mediator does not return the body for 202 response

Hi Niranjan. I think this only happens when you have content aware mediators in your sequence(You can check with removing full log mediators). Inside the RelayUtils we are checking status code equal to the 202[1] and ignore build the response body. So reason could be this. You can debug the

Re: [Dev] Call mediator does not return the body for 202 response

Hi Prabath, With the backend you have provided it works. I tested it with a backend where the response header has Transfer-Encoding has chunked. I mocked the backend in another ESB instance. I have attached attached both the proxy services where proxy test4 (ESB instance with offset 0) calls

Re: [Dev] Call mediator does not return the body for 202 response

Hi Niranjan. Hope you talking about call mediator non-blocking mode. I have checked the attached configuration with the ESB 4.9.0 and got the correct response to the client side. Please check with the attached configuration. [2016-04-10 00:48:51,839] DEBUG - wire >> "POST /services/Pass202

Re: [Dev] Call mediator does not return the body for 202 response

Hi Prabath, If so, isn't this a bug? I have created a public JIRA [1] for this. [1] - https://wso2.org/jira/browse/ESBJAVA-4552 Regards, Nira On Sun, Apr 10, 2016 at 10:28 AM, Prabath Ariyarathna wrote: > Hi Niranjan. > > I think this only happens when you have content

Re: [Dev] Handling Kubernetes Specific Configurations in Puppet/Hiera

Hi Isuru, Imesh, IMO we shouldn't have any platform specific restructuring in wso2/puppet-modules. This should be done at the end user's setup. Another point is that we have now decoupled wso2/puppet-modules from wso2/dockerfiles and users are not required to incorporate puppet-modules in their

Re: [Dev] Include carbon.yml and other config files in Carbon Core feature

Hi all, i have created a JIRA [1] for this. Along with the conf folder, shall we include* bin folder* (in the distribution/carbon-home) as well into org.wso2.carbon.core.server.feature? WDYT? [1] - https://wso2.org/jira/browse/CARBON-15851 Regards, Nira On Tue, Apr 5, 2016 at 3:45 PM,

Re: [Dev] Issues with JSON Schema in representing data types and in representing an array which contains non identical elements

Hi Viraj/Nuwan, Really appreciate your input on this Thanks, Sohani Sohani Weerasinghe Software Engineer WSO2, Inc: http://wso2.com Mobile : +94 716439774 Blog :http://christinetechtips.blogspot.com/ Twitter : https://twitter.com/sohanichristine On Tue, Apr 5, 2016 at 12:06 PM, Sohani

[Dev] [DEV][IOT][CDMF] Errors when building new device type in IoTS using cdmf-devicetype-archetype-master

Hi all, I created a new device type using cdmf-devicetype-archetype-master tool, and updated the file device-deployer.xml (used IoTS-M3 SNAPSHOT, and copied file org.wso2.carbon.device.mgt.iot_2.0.4.SNAPSHOT.jar into the repository/components/plugins folder) with correct info of my device

Re: [Dev] How to set dynamic width size When adding custom buttons/functions to gadget title in toolbar Dashboard Server

Hi Dakshika,UX Team, Brief Description about the feature and current implementation === Currently I am working on the feature "*Flexibility to add/remove more functions/buttons in the gadget title bar", *that is giving more flexibility to gadget author

Re: [Dev] Issues with JSON Schema in representing data types and in representing an array which contains non identical elements

Ok. For an xml like below, let's have the value field as follows xyz 071655339 0112655333 { "$schema": "http://json-schema.org/draft-04/schema#;, "title": "person", "id": "http://wso2jsonschema.org;, "type": "object", "properties": { "firstName": { "id":

Re: [Dev] Issues with JSON Schema in representing data types and in representing an array which contains non identical elements

Hi Sohani, +1 for the above approaches. We have to decide on how to represent non identical elements with same name. Viraj is working on it. Thanks, Nuwan On Mon, Apr 11, 2016 at 10:44 AM, Sohani Weerasinghe wrote: > Hi Viraj/Nuwan, > > Really appreciate your input on this >