Re: [Dev] MTOM Attachment to secured Proxy

[Roberto Sanz Perez]

Hi Himasha,
i invoke this endpoint
https://xxx:8243/services/Alfresco_ObjectService_SSL_Proxy.Alfresco_ObjectService_SSL_ProxyHttpSoap12Endpoint
and this one
https://xxx:8243/services/Alfresco_ObjectService_SSL_Proxy.Alfresco_ObjectService_SSL_ProxyHttpSoap11Endpoint
and the error it´s the same :(

   http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
">
  
 soapenv:Server
 unknown
 
  
Thanks
R.

El lun., 29 ene. 2018 a las 16:01, Himasha Guruge ()
escribió:

> Hi Roberto,
>
> Are you trying to invoke HTTPS endpoint in SOAPUI? Are you using the
> correct port?
>
> Thanks,
> Himasha
>
> On Thu, Jan 25, 2018 at 4:34 PM, Roberto Sanz <
> roberto.sanz.pe...@gmail.com> wrote:
>
>> Hi,
>> I´m using SOAPUI to test a secured proxy published on WSO2-EI-6.1.1. and
>> i´m
>> facing the following error:
>>
>> Error processing POST reguest for :
>>
>> /services/Alfresco_ObjectService_SSL_Proxy.Alfresco_ObjectService_SSL_ProxyHttpSoap11Endpoint.
>> Error detail: null.
>>
>> it works if i dont apply security to the proxy.
>>
>> This is my proxy:
>>
>> 
>> http://ws.apache.org/ns/synapse;
>>name="Alfresco_ObjectService_SSL_Proxy"
>>startOnLoad="true"
>>statistics="disable"
>>trace="disable"
>>transports="http,https">
>>
>>   
>>  
>> 
>>  
>>  > xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "
>>  action="remove"
>>  name="wsse:Security"
>>  scope="default"/>
>>  > value="true"/>
>>  >scope="axis2"
>>type="STRING"
>>value="multipart/related"/>
>>  http://org.apache.synapse/xsd;
>>expression="fn:concat('Basic ',
>> base64Encode('test_fwk:test..246'))"
>>name="Authorization"
>>scope="transport"/>
>>  
>> > value="CreateWSSecurityAndForward"/>
>>  
>>  
>> >
>> key="conf:/RegistryResources/Endpoints/Alfresco/Alfresco_ObjectServiceAddressEndpoint.xml"/>
>>  
>>   
>>   
>>  > xmlns:wsse="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
>> "
>>  action="remove"
>>  name="wsse:Security"
>>  scope="default"/>
>>  
>>   
>>
>>> key="conf:/RegistryResources/Endpoints/Alfresco/wsdl/ObjectService.wsdl">
>>   > key="conf:/RegistryResources/Endpoints/Alfresco/schemas/cmis_msg"
>>
>> location="https://alf2.dev.sgai.csic.es/alfresco/cmisws/cmis?msg"/>
>>   > key="conf:/RegistryResources/Endpoints/Alfresco/schemas/cmis_core"
>>
>> location="https://alf2.dev.sgai.csic.es/alfresco/cmisws/cmis?core"/>
>>
>>scenario2
>>
>>
>>
>> 
>>
>> This is my sec policy: (notice thats it´s SigOnly policy)
>>
>> > xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy;
>> xmlns:wsu="
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
>> ">
>> > xmlns:wsoma="
>> http://schemas.xmlsoap.org/ws/2004/09/policy/optimizedmimeserialization
>> ">
>> 
>> 
>> > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
>> 
>> 
>> 
>> > sp:IncludeToken="
>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
>> ">
>> 
>> 
>> 
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> > sp:IncludeToken="
>> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never;>
>> 
>> 
>> 
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
>> 
>> 
>> 
>> 
>> 
>> > xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
>> 
>> 
>> 
>> 
>> > 

[Dev] [VOTE] Release WSO2 IoT Server 3.2.0 RC1

[Rasika Perera]

Hi Devs,

We are pleased to announce the release candidate of WSO2 IoT Server 3.2.0.

This is the first release candidate (RC) of the WSO2 IoT Server 3.2.0
release.

This release carries 275 issue fixes [1-12] over the last GA (3.1.0)
release.

Reported Issues:

   - https://github.com/wso2/product-iots/issues

Source and distribution packages:

   - https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC1

Tag to be voted upon:

   - https://github.com/wso2/product-iots/releases/tag/v3.2.0-RC1

Please download, test, and vote. The README file under the distribution
contains guide and instructions on how to try it out locally.

[+] Stable - Go ahead and release
[-] Broken - Do not release (explain why)

This vote will be open for 72 hours or as needed.

[1] https://github.com/wso2/product-iots/milestone/3?closed=1
[2] https://github.com/wso2/product-iots/milestone/4?closed=1
[3] https://github.com/wso2/product-iots/milestone/5?closed=1
[4] https://github.com/wso2/product-iots/milestone/6?closed=1
[5] https://github.com/wso2/product-iots/milestone/7?closed=1
[6] https://github.com/wso2/product-iots/milestone/11?closed=1
[7] https://github.com/wso2/product-iots/milestone/12?closed=1
[8] https://github.com/wso2/product-iots/milestone/13?closed=1
[9] https://github.com/wso2/product-iots/milestone/14?closed=1
[10] https://github.com/wso2/product-iots/milestone/18?closed=1
[11] https://github.com/wso2/product-iots/milestone/19?closed=1
[12] https://github.com/wso2/product-iots/milestone/20?closed=1

Regards,
The WSO2 IoT Team.

-- 
With Regards,

*Rasika Perera*
Senior Software Engineer
LinkedIn: http://lk.linkedin.com/in/rasika90



WSO2 Inc. www.wso2.com
lean.enterprise.middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] How to recover from a java.net exception in a template?

[Vinod Kavinda]

Hi Thomas,
I believe this error is happening on the backend server. Then you can use
the fire and forget pattern. Try adding following property, before making
the service invocation.


Thanks,
Vinod

On Mon, Jan 29, 2018 at 8:30 PM, Thomas LEGRAND <
thomas.legr...@versusmind.eu> wrote:

> Hello,
>
> I have a template where I *Call* a *Address* mediator. However, during the
> runtime, I have a network problem which causes it to explode with a
> graceful java.net.NoRouteToHostException. Of course, I will have to fix
> the network part but, in the same time, I would like to be able to continue
> my process.
>
> My template is something like:
>
> http://ws.apache.org/ns/synapse;>
>> 
>> 
>> 
>> > expression="fn:concat($ctx:commonConfigurationUrl, '/parameters/name/',
>> $ctx:targetParamName)" name="uri.var.parameterRetrievalEndpoint"
>> scope="default" type="STRING"/>
>> > name="REST_URL_POSTFIX" scope="axis2"/>
>> > name="Accept" scope="transport"/>
>> > value="GET"/>
>> 
>> 
>> 
>> 
>> 2
>> fault
>> 
>> 
>> 
>> 
>>
> 
>>
>
> And my "recovery" sequence, named commonServiceFaultSequence , is like
> that:
>
> 
>> http://ws.apache.org/ns/synapse;>
>> 
>> 
>> 
>> 
>>
>
> Have you got any idea?
>
> Regards,
>
> Thomas
>
>
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Vinod Kavinda
Senior Software Engineer
*WSO2 Inc. - lean . enterprise . middleware .*
Mobile : +94 (0) 712 415544
Blog : http://soatechflicks.blogspot.com/
[image: http://wso2.com/signature]

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM2xx] how to add an api level throttling policy for "Apply to API" using updateAPI from publisher rest api?

[Anuruddha Liyanarachchi]

[+ Irham]

On Tue, Jan 16, 2018 at 2:41 PM, Sanjeewa Malalgoda 
wrote:

> Can we address this and fix it for 2.2.0?
>
> Thanks,
> sanjeewa.
>
> On Fri, Jan 12, 2018 at 4:23 PM, Kavitha Subramaniyam 
> wrote:
>
>> Thanks Rajith to pointing out!
>>
>> @Harsha, please find the github issue created on [1]
>> [1] https://github.com/wso2/product-apim/issues/2388
>>
>> Thanks,
>>
>> On Fri, Jan 12, 2018 at 3:59 PM, Harsha Kumara  wrote:
>>
>>> Yes, it seems like we have missed it. Please create a github issue.
>>>
>>> On Fri, Jan 12, 2018 at 3:44 PM, Rajith Roshan  wrote:
>>>
 Hi,

 It seems like API level policy is not included in the APIDTO object[1].
 Hence this is not supported with rest api

 [1] - https://github.com/wso2/carbon-apimgt/blob/6.x/components/
 apimgt/org.wso2.carbon.apimgt.rest.api.store/src/gen/java/or
 g/wso2/carbon/apimgt/rest/api/store/dto/APIDTO.java

 Thanks!
 Rajith

 On Fri, Jan 12, 2018 at 12:13 PM, Kavitha Subramaniyam <
 kavi...@wso2.com> wrote:

> Hi all,
>
> While am trying to update API for my scenario using publisher rest
> api, I need to add a throttling policy (advance policy created from admin
> dashboard) specifically for API (Apply to API). By following this doc[1], 
> I
> couldn't find a specific parameter to do this.
>
> Observation:
> I have modified API from UI and added api level throttling policy
> (change2.jpeg) and retrieved api details, but the response doesn't return 
> a
> value for relevant field in api object[2]. Same way when I change API to
> add resource level policy (change1.jpeg) response values are returned in
> API definition.
>
> Appreciate your insight on this please.
>
> [1] https://docs.wso2.com/display/AM210/apidocs/publisher/#!
> /operations#APIIndividual#apisApiIdPut
> [2]
> {
> "id": "47027dad-12ff-4e31-84ce-4d574a8caa1b",
> "name": "Mobile_stock_API",
> "description": "This is the api description",
> "context": "/stocks",
> "version": "1.0.0",
> "provider": "admin",
> "apiDefinition": "{\"swagger\":\"2.0\",\"paths\
> ":{\"/stock/{id}\":{\"get\":{\"responses\":{\"200\":{\"descr
> iption\":\"\"}},\"parameters\":[{\"name\":\"id\",\"in\":\"pa
> th\",\"allowMultiple\":false,\"required\":true,\"type\":\"st
> ring\"}],\"x-auth-type\":\"Application & Application
> User\",\"x-throttling-tier\":\"headerPolicy\"}},\"/stocks\":
> {\"get\":{\"responses\":{\"200\":{\"description\":\"\"}},\"x-auth-type\":\"Application
> & Application User\",\"x-throttling-tier\":\
> "ipPolicy\"}}},\"info\":{\"title\":\"Mobile_stock_API\",\"ve
> rsion\":\"1.0.0\"}}",
> "wsdlUri": null,
> "status": "PUBLISHED",
> "responseCaching": "Disabled",
> "cacheTimeout": 300,
> "destinationStatsEnabled": null,
> "isDefaultVersion": false,
> "type": "HTTP",
> "transport": [
> "https"
> ],
> "tags": [],
> "tiers": [
> "Gold",
> "Unlimited"
> ],
> "maxTps": {
> "production": 500,
> "sandbox": null
> },
> "thumbnailUri": null,
> "visibility": "PUBLIC",
> "visibleRoles": [],
> "accessControl": "NONE",
> "accessControlRoles": [],
> "visibleTenants": [],
> "endpointConfig": "{\n  \"production_endpoints\": {\n\"url\": \"
> http://localhost:9763/sample-data-backend/rservice/stockservice/\",\n
>\"config\": null,\n\"template_not_supported\": false\n  },\n
>  \"endpoint_type\": \"http\"\n}",
> "endpointSecurity": null,
> "gatewayEnvironments": "Production and Sandbox",
> "sequences": [],
> "subscriptionAvailability": "current_tenant",
> "subscriptionAvailableTenants": [],
> "businessInformation": {
> "technicalOwnerEmail": null,
> "businessOwnerEmail": null,
> "businessOwner": null,
> "technicalOwner": null
> },
> "corsConfiguration": {
> "accessControlAllowOrigins": [],
> "accessControlAllowCredentials": false,
> "corsConfigurationEnabled": false,
> "accessControlAllowHeaders": [],
> "accessControlAllowMethods": []
> },
> "additionalProperties": {}
> }
>
>
> Thanks,
> Kavitha
>
> --
> Kavitha.S
> *Software Engineer -QA*
> email : kavi...@wso2.com
> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194>
>
>


 --
 Rajith Roshan
 Senior Software Engineer, WSO2 Inc.
 Mobile: +94-7 <%2B94-71-554-8430>17-064-214

>>>
>>>
>>>
>>> --
>>> Harsha Kumara
>>> Software Engineer, WSO2 Inc.
>>> Mobile: +94775505618 <+94%2077%20550%205618>
>>> Blog:harshcreationz.blogspot.com
>>>
>>
>>
>>
>> --
>> Kavitha.S
>> *Software Engineer -QA*
>> email : kavi...@wso2.com
>> Mobile : +94 (0) 771538811 <%2B94%20%280%29%20773%20451194>
>>
>>
>
>
> --
>
> *Sanjeewa 

[Dev] "Payload could not be written as JSON" error when using call mediator in blocking mode

[Riyafa Abdul Hameed]

Hi,

This is regarding the issue[1]. This occurs because the json stream is not
set in the MessageContext before the call mediator in blocking mode tries
to call the JsonFormatter.
We are setting the json stream only when building the message. Is there a
specific reason for setting it only when building the message? Can't we set
it before building the message? If this is set as soon as the message comes
in the issue could be resolved.

Or other option would be to set the json stream in the call mediator for
blocking mode which is not the best option.

For call mediator in non-blocking mode the message goes through the pass
through transport and hence has no issues, but when in blocking mode the
message formatter is called. Can someone explain why this difference in
behavior for the two modes of the same mediator?

[1]https://github.com/wso2/product-ei/issues/1805

Thanks,
Riyafa

-- 
Riyafa Abdul Hameed
Software Engineer, WSO2 Lanka (Pvt) Ltd 

Email: riy...@wso2.com 
Website: https://riyafa.wordpress.com/ 
  

___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [DEV] Please review and merge PR

[김대경]

Can you please review and merge PR.

[1] https://github.com/wso2/wso2-axis2/pull/132

Best Regards.
Daekyung Kim.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM-ANALYTICS-2.1.0] Error ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUES does not exist

[Chaminda Jayawardena]

On Mon, Jan 29, 2018 at 10:46 PM, Sajith Perera  wrote:

> Hi Chaminda
>
> Is this single node analytics setup? could you attach the full server log
> files?
>
Hi Sajith,
I have attached the full error logs in the initial mail.​


In the product analytics and DAS deployment if server pack is replaced and
> pointing to the same database we need to mount the following file
> directories as there are files will be updated during the server runtime.
> But only concern if this is the case it should happen for the vanilla pack
> as well.
>
>1. repository/data
>2. repository/config/analytics
>
> Thanks,
> SajithD
>
> On Mon, Jan 29, 2018 at 6:22 PM, Harsha Kumara  wrote:
>
>>
>>
>> On Mon, Jan 29, 2018 at 6:20 PM, Chaminda Jayawardena 
>> wrote:
>>
>>> Hi All,
>>>
>>> Getting below error continuously on an apim-analytics-2.10 server
>>> instance.
>>> We are using latest wum updated apim-analytics2.1.0 pack with fresh
>>> databases.
>>>
>>> Configured the pack using puppet in an apim cluster pattern-6[1].
>>>
>>> The error encountered only when the wum updated pack is used.
>>>
>>> Note: as suggested in several threads, I cleaned the databases and tried
>>> again but had no luck. Complete error log has been attached in the file -
>>> analytics_error.rtf
>>>
>>>
>>>
>>> *Caused by:
>>> org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsTableNotAvailableException:
>>> [-1234:ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUEST] does not exist*
>>>
>>> * at *org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRec
>>> ordStore.get(RDBMSAnalyticsRecordStore.java:420)
>>>
>>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>>> iceImpl.getByRange(AnalyticsDataServiceImpl.java:961)
>>>
>>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>>> iceImpl.get(AnalyticsDataServiceImpl.java:910)
>>>
>>> at org.wso2.carbon.analytics.spark.core.rdd.AnalyticsRDD.getPar
>>> titions(AnalyticsRDD.java:119)
>>>
>>> ... 100 more
>>>
>>>
>>> [1] https://docs.wso2.com/display/AM2xx/Using+Puppet+Modules
>>> +to+Set+up+WSO2+API-M+with+Pattern+6
>>>
>>> --
>>> Thanks & Regards
>>>
>>> *Chaminda Jayawardena*
>>> Associate Technical Lead - QA
>>> WSO2 Inc. - http://wso2.com
>>> +94-77-7725234 <+94%2077%20772%205234>
>>>
>>
>>
>>
>> --
>> Harsha Kumara
>> Software Engineer, WSO2 Inc.
>> Mobile: +94775505618 <+94%2077%20550%205618>
>> Blog:harshcreationz.blogspot.com
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> 
> Sajith Dimal
> Software Engineer
> Email : saji...@wso2.com
> Mobile : +94783101496
> WSO2 Inc. | http://wso2.com
> lean.enterprise.middleware
>



-- 
Thanks & Regards

*Chaminda Jayawardena*
Associate Technical Lead - QA
WSO2 Inc. - http://wso2.com
+94-77-7725234
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM-ANALYTICS-2.1.0] Error ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUES does not exist

[Chaminda Jayawardena]

Hi Rukshan,

All you mentioned are fine with the setup. Anyway, with same puppet
configs, it didn't give this error with the apim-analytics-2.1.0 pack and
issue comes only when wum updated pack placed there in the cluster. I
flushed all the dbs and verified.

Thanks,
Chaminda

On Mon, Jan 29, 2018 at 10:30 PM, Rukshan Premathunga 
wrote:

> Hi Chaminda,
>
> Did you clear both Store and Processed DB from the Analytics? Most of the
> time this could be due to configuration issue. Also does analytics
> carbon-db is fresh DB when instance get start?
> Also make sure carbon-DB is not shared and only pointed to Analytics.
>
> Thanks and Regards
>
> On Mon, Jan 29, 2018 at 6:22 PM, Harsha Kumara  wrote:
>
>>
>>
>> On Mon, Jan 29, 2018 at 6:20 PM, Chaminda Jayawardena 
>> wrote:
>>
>>> Hi All,
>>>
>>> Getting below error continuously on an apim-analytics-2.10 server
>>> instance.
>>> We are using latest wum updated apim-analytics2.1.0 pack with fresh
>>> databases.
>>>
>>> Configured the pack using puppet in an apim cluster pattern-6[1].
>>>
>>> The error encountered only when the wum updated pack is used.
>>>
>>> Note: as suggested in several threads, I cleaned the databases and tried
>>> again but had no luck. Complete error log has been attached in the file -
>>> analytics_error.rtf
>>>
>>>
>>>
>>> *Caused by:
>>> org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsTableNotAvailableException:
>>> [-1234:ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUEST] does not exist*
>>>
>>> * at *org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRec
>>> ordStore.get(RDBMSAnalyticsRecordStore.java:420)
>>>
>>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>>> iceImpl.getByRange(AnalyticsDataServiceImpl.java:961)
>>>
>>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>>> iceImpl.get(AnalyticsDataServiceImpl.java:910)
>>>
>>> at org.wso2.carbon.analytics.spark.core.rdd.AnalyticsRDD.getPar
>>> titions(AnalyticsRDD.java:119)
>>>
>>> ... 100 more
>>>
>>>
>>> [1] https://docs.wso2.com/display/AM2xx/Using+Puppet+Modules
>>> +to+Set+up+WSO2+API-M+with+Pattern+6
>>>
>>> --
>>> Thanks & Regards
>>>
>>> *Chaminda Jayawardena*
>>> Associate Technical Lead - QA
>>> WSO2 Inc. - http://wso2.com
>>> +94-77-7725234 <+94%2077%20772%205234>
>>>
>>
>>
>>
>> --
>> Harsha Kumara
>> Software Engineer, WSO2 Inc.
>> Mobile: +94775505618 <+94%2077%20550%205618>
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
> +94711822074 <+94%2071%20182%202074>
>



-- 
Thanks & Regards

*Chaminda Jayawardena*
Associate Technical Lead - QA
WSO2 Inc. - http://wso2.com
+94-77-7725234
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM-ANALYTICS-2.1.0] Error ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUES does not exist

[Rukshan Premathunga]

Hi Chaminda,

Did you clear both Store and Processed DB from the Analytics? Most of the
time this could be due to configuration issue. Also does analytics
carbon-db is fresh DB when instance get start?
Also make sure carbon-DB is not shared and only pointed to Analytics.

Thanks and Regards

On Mon, Jan 29, 2018 at 6:22 PM, Harsha Kumara  wrote:

>
>
> On Mon, Jan 29, 2018 at 6:20 PM, Chaminda Jayawardena 
> wrote:
>
>> Hi All,
>>
>> Getting below error continuously on an apim-analytics-2.10 server
>> instance.
>> We are using latest wum updated apim-analytics2.1.0 pack with fresh
>> databases.
>>
>> Configured the pack using puppet in an apim cluster pattern-6[1].
>>
>> The error encountered only when the wum updated pack is used.
>>
>> Note: as suggested in several threads, I cleaned the databases and tried
>> again but had no luck. Complete error log has been attached in the file -
>> analytics_error.rtf
>>
>>
>>
>> *Caused by:
>> org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsTableNotAvailableException:
>> [-1234:ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUEST] does not exist*
>>
>> * at *org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRec
>> ordStore.get(RDBMSAnalyticsRecordStore.java:420)
>>
>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>> iceImpl.getByRange(AnalyticsDataServiceImpl.java:961)
>>
>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>> iceImpl.get(AnalyticsDataServiceImpl.java:910)
>>
>> at org.wso2.carbon.analytics.spark.core.rdd.AnalyticsRDD.getPar
>> titions(AnalyticsRDD.java:119)
>>
>> ... 100 more
>>
>>
>> [1] https://docs.wso2.com/display/AM2xx/Using+Puppet+Modules
>> +to+Set+up+WSO2+API-M+with+Pattern+6
>>
>> --
>> Thanks & Regards
>>
>> *Chaminda Jayawardena*
>> Associate Technical Lead - QA
>> WSO2 Inc. - http://wso2.com
>> +94-77-7725234 <+94%2077%20772%205234>
>>
>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
Rukshan Chathuranga.
Software Engineer.
WSO2, Inc.
+94711822074
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Johann Nallathamby]

I also like the idea of writing the authenticated session cookie at the end
of the authentication sequence; even if it's a multi step authentication.
This will simply solve a lot of inconsistency issues we have I feel. Not
saying we can't solve it in any other way, but they might be bit more
complex.

Regards,
Johann.

On Mon, Jan 29, 2018 at 8:47 PM, Ishara Karunarathna 
wrote:

>
>
> On Mon, Jan 29, 2018 at 8:40 PM, Hasintha Indrajee 
> wrote:
>
>> So that's because we don't have a proper way of reverting it back. Hence
>> isn't it better to not to write cookies until a proper access of an
>> application takes place for this scenario ?. In multi step scenario it's
>> true that there is an idp session, but still the user is not properly
>> logged in since one of the steps failed. Hence next time the next step will
>> be prompted which means he doesn't have a valid session.
>>
>> The idea is if we can avoid writing cookies we can unify the post
>> authentication behaviours (missing mandatory claim handling, authorization,
>> etc)
>>
>
> As an improvement we can do this.
> But shared computer scenario is a rare use case. Even if you use a shared
> computer it's not a good practice to keep the browser session or use
> remember me option.
>
> -Ishara
>
>>
>> On Mon, Jan 29, 2018 at 8:26 PM, Ishara Karunarathna 
>> wrote:
>>
>>> HI Hsintha,
>>>
>>> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
>>> wrote:
>>>
 Multi-step authentication is a different case I think, We don't set
 cookies in an intermediate state. What if we use "remember me" ? So the
 cookie will be there even if we close the browswer. isn't it ?

>>> Think of a authentication steps.
>>> step1 : Federated authenticator
>>> step2 : Local authenticator.
>>>
>>> Then in the step 1 federated authenticator will create a session where
>>> 2nd authentication files. So in the 2nd time also user will automatically
>>> redirect to the federated authenticator and authenticated then fails in 2nd
>>> case.
>>>
>>> -Ishara
>>>

 On Mon, Jan 29, 2018 at 8:15 PM, Ishara Karunarathna 
 wrote:

> Hi Hasintha,
>
> Same can happen in multi-step authentication where a user successfully
> login wiht1st authenticator and fail in the 2nd case.
>
> On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee 
> wrote:
>
>> We have the feature of enabling authorization for service provider
>> [1]. Imagine a scenario where we login to an SP for the very first time 
>> and
>> authorization fails due to some violation of authorization policies. Even
>> if authorization fails we do set commonAuthId cookie in the response 
>> which
>> means the user has a valid SSO session from that point onwards.
>>
>> This can be seen in two perspectives.
>>
>> 1) The user is authenticated, but authorization fails, Hence we
>> should set the cookie for SSO irrespective of authorization decision.
>>
>> 2) But this may lead to an inconsistant state. Suppose this is the
>> only application the user is allowed to login. But due to some policy
>> violation, the first login fails. In a case of a shared computer this 
>> leads
>> to a deadlock where the user neither can't properly login nor proper
>> logout. We can use the workaround of calling commonAuthLogout=true. But
>> this will not do a proper logout. (logging out external idps). Hence in a
>> shared computer the user has no option.
>>
> I think in this case user should close the browser, then he won't get
> this issue. this is valid for the multi step authentication as well.
>
> -Ishara
>
>>
>> Hence I think we can avoid setting cookie until a user successfully
>> accesses at least a single application upon successful authentication and
>> authorization. So simply even if the user is authenticated for the very
>> first time, we will not set the cookie unless the user is authorized to
>> access that particular application. (This only applies to the very first
>> app the user is trying to login)
>>
>> WDYT ?
>>
>>
>> [1] https://docs.wso2.com/display/IS530/Configuring+Access+C
>> ontrol+Policy+for+a+Service+Provider
>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>
>
> --
> Ishara Karunarathna
> Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <071%20799%206791>
>
>
>


 --
 Hasintha Indrajee
 WSO2, Inc.
 Mobile:+94 771892453 <+94%2077%20189%202453>


>>>
>>>
>>> --
>>> Ishara Karunarathna
>>> Technical Lead
>>> WSO2 Inc. - lean . 

Re: [Dev] Cannot find the Doc Site for siddhi-map-csv

[Sriskandarajah Suhothayan]

Why this does not use Siddhi theme like other extensions?

On Thu, Jan 25, 2018 at 11:09 AM Kalaiyarasi Ganeshalingam <
kalaiyar...@wso2.com> wrote:

>
> Thanks Maheshika. I will check.
>
> Kalaiyarasi Ganeshalingam
> Associate Software Engineer| WSO2
> WSO2 Inc : http://wso2.org
> 
> Tel:+94 076 6792895
> LinkedIn :www.linkedin.com/in/kalaiyarasiganeshalingam
> Blogs : https://kalaiyarasig.blogspot.com/ 
>
> On Wed, Jan 24, 2018 at 11:05 PM, Maheshika Goonetilleke <
> mahesh...@wso2.com> wrote:
>
>> Hi Kalaiyarasi
>>
>> I add the /docs to gh-pages. Please check.
>>
>> On Wed, Jan 24, 2018 at 9:26 PM, Kalaiyarasi Ganeshalingam <
>> kalaiyar...@wso2.com> wrote:
>>
>>> + Maheshika.
>>>
>>> Kalaiyarasi Ganeshalingam
>>> Associate Software Engineer| WSO2
>>> WSO2 Inc : http://wso2.org
>>> 
>>> Tel:+94 076 6792895 <+94%2076%20679%202895>
>>> LinkedIn :www.linkedin.com/in/kalaiyarasiganeshalingam
>>> Blogs : https://kalaiyarasig.blogspot.com/ 
>>>
>>> On Wed, Jan 24, 2018 at 9:06 PM, Kalaiyarasi Ganeshalingam <
>>> kalaiyar...@wso2.com> wrote:
>>>
 Hi Mahesika,

 Can you generate the gh-page branch for the repo[1].

 [1] https://github.com/wso2-extensions/siddhi-map-csv

 Regards,
 Kalai

 Kalaiyarasi Ganeshalingam
 Associate Software Engineer| WSO2
 WSO2 Inc : http://wso2.org
 
 Tel:+94 076 6792895 <+94%2076%20679%202895>
 LinkedIn :www.linkedin.com/in/kalaiyarasiganeshalingam
 Blogs : https://kalaiyarasig.blogspot.com/
 

 On Wed, Jan 24, 2018 at 9:00 PM, Kalaiyarasi Ganeshalingam <
 kalaiyar...@wso2.com> wrote:

> Noted.
>
> Kalaiyarasi Ganeshalingam
> Associate Software Engineer| WSO2
> WSO2 Inc : http://wso2.org
> 
> Tel:+94 076 6792895 <+94%2076%20679%202895>
> LinkedIn :www.linkedin.com/in/kalaiyarasiganeshalingam
> Blogs : https://kalaiyarasig.blogspot.com/
> 
>
> On Wed, Jan 24, 2018 at 9:27 AM, Sriskandarajah Suhothayan <
> s...@wso2.com> wrote:
>
>> Hi Kalaiyarasi
>>
>> Can you make sure the necessary things are done for the doc site
>> too[1]?
>> Then the feature will be done done.
>>
>> [1]https://wso2-extensions.github.io/siddhi-map-csv/
>>
>> Regards
>> Suho
>>
>> --
>>
>> *S. Suhothayan*
>> Director
>> *WSO2 Inc. *
>> http://wso2.com  
>>
>>
>> *cell: (+94) 779 756 757 <077%20975%206757> | blog:
>> http://suhothayan.blogspot.com/ twitter:
>> http://twitter.com/suhothayan  | 
>> linked-in:
>> http://lk.linkedin.com/in/suhothayan 
>> *
>>
>
>

>>>
>>
>>
>> --
>>
>> Thanks & Best Regards,
>>
>> Maheshika Goonetilleke
>> Senior Engineering Process Coordinator
>>
>> *WSO2 Inc*
>> *email   : mahesh...@wso2.com *
>> *mobile : +94 773 596707 <+94%2077%20359%206707>*
>> *www: :http://wso2.com *lean . enterprise . middleware
>>
>>
>>
>>
>>
> --

*S. Suhothayan*
Director
*WSO2 Inc. *
http://wso2.com  


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
twitter: http://twitter.com/suhothayan
 | linked-in:
http://lk.linkedin.com/in/suhothayan *
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM-ANALYTICS-2.1.0] Error ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUES does not exist

[Sajith Perera]

Hi Chaminda

Is this single node analytics setup? could you attach the full server log
files?
In the product analytics and DAS deployment if server pack is replaced and
pointing to the same database we need to mount the following file
directories as there are files will be updated during the server runtime.
But only concern if this is the case it should happen for the vanilla pack
as well.

   1. repository/data
   2. repository/config/analytics

Thanks,
SajithD

On Mon, Jan 29, 2018 at 6:22 PM, Harsha Kumara  wrote:

>
>
> On Mon, Jan 29, 2018 at 6:20 PM, Chaminda Jayawardena 
> wrote:
>
>> Hi All,
>>
>> Getting below error continuously on an apim-analytics-2.10 server
>> instance.
>> We are using latest wum updated apim-analytics2.1.0 pack with fresh
>> databases.
>>
>> Configured the pack using puppet in an apim cluster pattern-6[1].
>>
>> The error encountered only when the wum updated pack is used.
>>
>> Note: as suggested in several threads, I cleaned the databases and tried
>> again but had no luck. Complete error log has been attached in the file -
>> analytics_error.rtf
>>
>>
>>
>> *Caused by:
>> org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsTableNotAvailableException:
>> [-1234:ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUEST] does not exist*
>>
>> * at *org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRec
>> ordStore.get(RDBMSAnalyticsRecordStore.java:420)
>>
>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>> iceImpl.getByRange(AnalyticsDataServiceImpl.java:961)
>>
>> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServ
>> iceImpl.get(AnalyticsDataServiceImpl.java:910)
>>
>> at org.wso2.carbon.analytics.spark.core.rdd.AnalyticsRDD.getPar
>> titions(AnalyticsRDD.java:119)
>>
>> ... 100 more
>>
>>
>> [1] https://docs.wso2.com/display/AM2xx/Using+Puppet+Modules
>> +to+Set+up+WSO2+API-M+with+Pattern+6
>>
>> --
>> Thanks & Regards
>>
>> *Chaminda Jayawardena*
>> Associate Technical Lead - QA
>> WSO2 Inc. - http://wso2.com
>> +94-77-7725234 <+94%2077%20772%205234>
>>
>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 

Sajith Dimal
Software Engineer
Email : saji...@wso2.com
Mobile : +94783101496
WSO2 Inc. | http://wso2.com
lean.enterprise.middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] How to recover from a java.net exception in a template?

[Thomas LEGRAND]

Hello,

I have a template where I *Call* a *Address* mediator. However, during the
runtime, I have a network problem which causes it to explode with a
graceful java.net.NoRouteToHostException. Of course, I will have to fix the
network part but, in the same time, I would like to be able to continue my
process.

My template is something like:

http://ws.apache.org/ns/synapse;>
> 
> 
>  name="getCommonConfigurationParameterSequence">
>  expression="fn:concat($ctx:commonConfigurationUrl, '/parameters/name/',
> $ctx:targetParamName)" name="uri.var.parameterRetrievalEndpoint"
> scope="default" type="STRING"/>
>  name="REST_URL_POSTFIX" scope="axis2"/>
>  name="Accept" scope="transport"/>
>  value="GET"/>
> 
> 
> 
> 
> 2
> fault
> 
> 
> 
> 
>

>

And my "recovery" sequence, named commonServiceFaultSequence , is like that:


> http://ws.apache.org/ns/synapse;>
> 
> 
> 
> 
>

Have you got any idea?

Regards,

Thomas
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Hasintha Indrajee]

So that's because we don't have a proper way of reverting it back. Hence
isn't it better to not to write cookies until a proper access of an
application takes place for this scenario ?. In multi step scenario it's
true that there is an idp session, but still the user is not properly
logged in since one of the steps failed. Hence next time the next step will
be prompted which means he doesn't have a valid session.

The idea is if we can avoid writing cookies we can unify the post
authentication behaviours (missing mandatory claim handling, authorization,
etc)

On Mon, Jan 29, 2018 at 8:26 PM, Ishara Karunarathna 
wrote:

> HI Hsintha,
>
> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
> wrote:
>
>> Multi-step authentication is a different case I think, We don't set
>> cookies in an intermediate state. What if we use "remember me" ? So the
>> cookie will be there even if we close the browswer. isn't it ?
>>
> Think of a authentication steps.
> step1 : Federated authenticator
> step2 : Local authenticator.
>
> Then in the step 1 federated authenticator will create a session where 2nd
> authentication files. So in the 2nd time also user will automatically
> redirect to the federated authenticator and authenticated then fails in 2nd
> case.
>
> -Ishara
>
>>
>> On Mon, Jan 29, 2018 at 8:15 PM, Ishara Karunarathna 
>> wrote:
>>
>>> Hi Hasintha,
>>>
>>> Same can happen in multi-step authentication where a user successfully
>>> login wiht1st authenticator and fail in the 2nd case.
>>>
>>> On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee 
>>> wrote:
>>>
 We have the feature of enabling authorization for service provider [1].
 Imagine a scenario where we login to an SP for the very first time and
 authorization fails due to some violation of authorization policies. Even
 if authorization fails we do set commonAuthId cookie in the response which
 means the user has a valid SSO session from that point onwards.

 This can be seen in two perspectives.

 1) The user is authenticated, but authorization fails, Hence we should
 set the cookie for SSO irrespective of authorization decision.

 2) But this may lead to an inconsistant state. Suppose this is the only
 application the user is allowed to login. But due to some policy violation,
 the first login fails. In a case of a shared computer this leads to a
 deadlock where the user neither can't properly login nor proper logout. We
 can use the workaround of calling commonAuthLogout=true. But this will not
 do a proper logout. (logging out external idps). Hence in a shared computer
 the user has no option.

>>> I think in this case user should close the browser, then he won't get
>>> this issue. this is valid for the multi step authentication as well.
>>>
>>> -Ishara
>>>

 Hence I think we can avoid setting cookie until a user successfully
 accesses at least a single application upon successful authentication and
 authorization. So simply even if the user is authenticated for the very
 first time, we will not set the cookie unless the user is authorized to
 access that particular application. (This only applies to the very first
 app the user is trying to login)

 WDYT ?


 [1] https://docs.wso2.com/display/IS530/Configuring+Access+C
 ontrol+Policy+for+a+Service+Provider



 --
 Hasintha Indrajee
 WSO2, Inc.
 Mobile:+94 771892453 <+94%2077%20189%202453>


>>>
>>>
>>> --
>>> Ishara Karunarathna
>>> Technical Lead
>>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>>
>>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>>> +94717996791 <071%20799%206791>
>>>
>>>
>>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>
>
> --
> Ishara Karunarathna
> Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <071%20799%206791>
>
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Unable to cache the response

[Keerthika Mahendralingam]

Thanks Riyafa, it is working fine with the curl command.



Thanks,
Keerthika.

On Mon, Jan 29, 2018 at 6:32 PM, Riyafa Abdul Hameed 
wrote:

> Hi Keerthika,
>
> Are you using Postman to make the calls? If so we have noticed in a
> previous instance that it does not get cached because Postman seemed to
> insert unnecessary headers? Can you try using curl requests? Or RESTer is a
> handy plugin for firefox.
> Or you can set headersToExcludeInHash to the value * and try:
> *
>
> Hope it helps.
>
> Regards,
> Riyafa
>
> On Mon, Jan 29, 2018 at 2:31 PM, Keerthika Mahendralingam <
> keerth...@wso2.com> wrote:
>
>> Hi All,
>>
>> I am using the cache mediator in the proxy. But the response is not
>> getting cached. I have tested this with EI 6.1.1-update17 and EI
>> 6.1.1-update18. For both, the response is fetched from the backend service
>> not from the cache. What could be the reason?
>>
>> I am using the following configuration:
>> 
>> http://ws.apache.org/ns/synapse;
>>name="connectMockito"
>>startOnLoad="true"
>>statistics="disable"
>>trace="disable"
>>transports="http,https">
>>
>>   
>>  
>> 
>>
>> 
>> 
>>GET
>>
>>(1|2)[0-9][0-9]
>>org.wso2.carbo
>> n.mediator.cache.digest.HttpRequestHashGenerator
>> 
>> 
>>  
>>  
>> 
>>http://demo2236300.mockable.io/testService
>> "/>
>> 
>>  
>>   
>>   
>>  
>>  
>>  
>>   
>>
>>
>> 
>>
>> * Log for the second call:*
>>
>> [2018-01-29 14:28:39,010] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "GET /services/connectMockito HTTP/1.1[\r][\n]"
>>
>> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Host: keerthikas-macbook-pro.local:8280[\r][\n]"
>>
>> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Connection: keep-alive[\r][\n]"
>>
>> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Cache-Control: no-cache[\r][\n]"
>>
>> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Content-Type: application/json[\r][\n]"
>>
>> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
>> 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132
>> Safari/537.36[\r][\n]"
>>
>> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Postman-Token: 48f7595e-3e2c-cee7-9652-a82c27
>> 2b67e2[\r][\n]"
>>
>> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Accept: */*[\r][\n]"
>>
>> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Accept-Encoding: gzip, deflate[\r][\n]"
>>
>> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "Accept-Language: en-US,en;q=0.9[\r][\n]"
>>
>> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
>> dispatcher-6 >> "[\r][\n]"
>>
>> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "GET /testService HTTP/1.1[\r][\n]"
>>
>> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Accept: */*[\r][\n]"
>>
>> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Cache-Control: no-cache[\r][\n]"
>>
>> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Postman-Token: 48f7595e-3e2c-cee7-9652-a82c27
>> 2b67e2[\r][\n]"
>>
>> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Accept-Encoding: gzip, deflate[\r][\n]"
>>
>> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Accept-Language: en-US,en;q=0.9[\r][\n]"
>>
>> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Content-Type: application/json[\r][\n]"
>>
>> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Host: demo2236300.mockable.io[\r][\n]"
>>
>> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "Connection: Keep-Alive[\r][\n]"
>>
>> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n]"
>>
>> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 << "[\r][\n]"
>>
>> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 >> "HTTP/1.1 200 OK[\r][\n]"
>>
>> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 >> "cache-control: no-cache[\r][\n]"
>>
>> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
>> dispatcher-4 >> 

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Hasintha Indrajee]

Multi-step authentication is a different case I think, We don't set cookies
in an intermediate state. What if we use "remember me" ? So the cookie will
be there even if we close the browswer. isn't it ?

On Mon, Jan 29, 2018 at 8:15 PM, Ishara Karunarathna 
wrote:

> Hi Hasintha,
>
> Same can happen in multi-step authentication where a user successfully
> login wiht1st authenticator and fail in the 2nd case.
>
> On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee 
> wrote:
>
>> We have the feature of enabling authorization for service provider [1].
>> Imagine a scenario where we login to an SP for the very first time and
>> authorization fails due to some violation of authorization policies. Even
>> if authorization fails we do set commonAuthId cookie in the response which
>> means the user has a valid SSO session from that point onwards.
>>
>> This can be seen in two perspectives.
>>
>> 1) The user is authenticated, but authorization fails, Hence we should
>> set the cookie for SSO irrespective of authorization decision.
>>
>> 2) But this may lead to an inconsistant state. Suppose this is the only
>> application the user is allowed to login. But due to some policy violation,
>> the first login fails. In a case of a shared computer this leads to a
>> deadlock where the user neither can't properly login nor proper logout. We
>> can use the workaround of calling commonAuthLogout=true. But this will not
>> do a proper logout. (logging out external idps). Hence in a shared computer
>> the user has no option.
>>
> I think in this case user should close the browser, then he won't get this
> issue. this is valid for the multi step authentication as well.
>
> -Ishara
>
>>
>> Hence I think we can avoid setting cookie until a user successfully
>> accesses at least a single application upon successful authentication and
>> authorization. So simply even if the user is authenticated for the very
>> first time, we will not set the cookie unless the user is authorized to
>> access that particular application. (This only applies to the very first
>> app the user is trying to login)
>>
>> WDYT ?
>>
>>
>> [1] https://docs.wso2.com/display/IS530/Configuring+Access+
>> Control+Policy+for+a+Service+Provider
>>
>>
>>
>> --
>> Hasintha Indrajee
>> WSO2, Inc.
>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>
>>
>
>
> --
> Ishara Karunarathna
> Technical Lead
> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>
> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
> +94717996791 <071%20799%206791>
>
>
>


-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] MTOM Attachment to secured Proxy

[Himasha Guruge]

Hi Roberto,

Are you trying to invoke HTTPS endpoint in SOAPUI? Are you using the
correct port?

Thanks,
Himasha

On Thu, Jan 25, 2018 at 4:34 PM, Roberto Sanz 
wrote:

> Hi,
> I´m using SOAPUI to test a secured proxy published on WSO2-EI-6.1.1. and
> i´m
> facing the following error:
>
> Error processing POST reguest for :
> /services/Alfresco_ObjectService_SSL_Proxy.Alfresco_ObjectService_SSL_
> ProxyHttpSoap11Endpoint.
> Error detail: null.
>
> it works if i dont apply security to the proxy.
>
> This is my proxy:
>
> 
> http://ws.apache.org/ns/synapse;
>name="Alfresco_ObjectService_SSL_Proxy"
>startOnLoad="true"
>statistics="disable"
>trace="disable"
>transports="http,https">
>
>   
>  
> 
>  
>   xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-wssecurity-secext-1.0.xsd"
>  action="remove"
>  name="wsse:Security"
>  scope="default"/>
>   value="true"/>
>  scope="axis2"
>type="STRING"
>value="multipart/related"/>
>  http://org.apache.synapse/xsd;
>expression="fn:concat('Basic ',
> base64Encode('test_fwk:test..246'))"
>name="Authorization"
>scope="transport"/>
>  
>  value="CreateWSSecurityAndForward"/>
>  
>  
>  key="conf:/RegistryResources/Endpoints/Alfresco/Alfresco_
> ObjectServiceAddressEndpoint.xml"/>
>  
>   
>   
>   xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-wssecurity-secext-1.0.xsd"
>  action="remove"
>  name="wsse:Security"
>  scope="default"/>
>  
>   
>
> key="conf:/RegistryResources/Endpoints/Alfresco/wsdl/ObjectService.wsdl">
>key="conf:/RegistryResources/Endpoints/Alfresco/schemas/cmis_msg"
>
> location="https://alf2.dev.sgai.csic.es/alfresco/cmisws/cmis?msg"/>
>key="conf:/RegistryResources/Endpoints/Alfresco/schemas/cmis_core"
>
> location="https://alf2.dev.sgai.csic.es/alfresco/cmisws/cmis?core"/>
>
>scenario2
>
>
>
> 
>
> This is my sec policy: (notice thats it´s SigOnly policy)
>
>  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy;
> xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-wssecurity-utility-1.0.xsd">
>  xmlns:wsoma="http://schemas.xmlsoap.org/ws/2004/09/policy/
> optimizedmimeserialization">
> 
> 
>  xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
> 
> 
> 
>  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/
> IncludeToken/AlwaysToRecipient">
> 
> 
> 
>
> 
> 
> 
> 
> 
> 
>  sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/
> IncludeToken/Never">
> 
> 
> 
>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
> 
> 
> 
> 
> 
>  xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy;>
> 
> 
> 
> 
>  xmlns:rampart="http://ws.apache.org/rampart/policy;>
> 
> 
> //xenc:EncryptedData/xenc:CipherData/
> xenc:CipherValue
> 
> 
>  uri="http://www.w3.org/2001/04/xmlenc#;>
> 
> 
> wso2carbon
> useReqSigCert
>
> true timestampPrecisionInMilliseconds>
> 300
> 300
> false
>
> org.wso2.carbon.security.util.
> SecurityTokenStore
> 
> 300
>
> 
>  cryptoKey="org.wso2.carbon.security.crypto.privatestore"
> provider="org.wso2.carbon.security.util.ServerCrypto">
>  name="org.wso2.carbon.security.crypto.alias">pocei.
> srv.sgai-dev.sistemas.csic.es
>  name="org.wso2.carbon.security.crypto.privatestore">
> wso2carbon.jks
>   

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Ishara Karunarathna]

On Mon, Jan 29, 2018 at 8:40 PM, Hasintha Indrajee 
wrote:

> So that's because we don't have a proper way of reverting it back. Hence
> isn't it better to not to write cookies until a proper access of an
> application takes place for this scenario ?. In multi step scenario it's
> true that there is an idp session, but still the user is not properly
> logged in since one of the steps failed. Hence next time the next step will
> be prompted which means he doesn't have a valid session.
>
> The idea is if we can avoid writing cookies we can unify the post
> authentication behaviours (missing mandatory claim handling, authorization,
> etc)
>

As an improvement we can do this.
But shared computer scenario is a rare use case. Even if you use a shared
computer it's not a good practice to keep the browser session or use
remember me option.

-Ishara

>
> On Mon, Jan 29, 2018 at 8:26 PM, Ishara Karunarathna 
> wrote:
>
>> HI Hsintha,
>>
>> On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
>> wrote:
>>
>>> Multi-step authentication is a different case I think, We don't set
>>> cookies in an intermediate state. What if we use "remember me" ? So the
>>> cookie will be there even if we close the browswer. isn't it ?
>>>
>> Think of a authentication steps.
>> step1 : Federated authenticator
>> step2 : Local authenticator.
>>
>> Then in the step 1 federated authenticator will create a session where
>> 2nd authentication files. So in the 2nd time also user will automatically
>> redirect to the federated authenticator and authenticated then fails in 2nd
>> case.
>>
>> -Ishara
>>
>>>
>>> On Mon, Jan 29, 2018 at 8:15 PM, Ishara Karunarathna 
>>> wrote:
>>>
 Hi Hasintha,

 Same can happen in multi-step authentication where a user successfully
 login wiht1st authenticator and fail in the 2nd case.

 On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee 
 wrote:

> We have the feature of enabling authorization for service provider
> [1]. Imagine a scenario where we login to an SP for the very first time 
> and
> authorization fails due to some violation of authorization policies. Even
> if authorization fails we do set commonAuthId cookie in the response which
> means the user has a valid SSO session from that point onwards.
>
> This can be seen in two perspectives.
>
> 1) The user is authenticated, but authorization fails, Hence we should
> set the cookie for SSO irrespective of authorization decision.
>
> 2) But this may lead to an inconsistant state. Suppose this is the
> only application the user is allowed to login. But due to some policy
> violation, the first login fails. In a case of a shared computer this 
> leads
> to a deadlock where the user neither can't properly login nor proper
> logout. We can use the workaround of calling commonAuthLogout=true. But
> this will not do a proper logout. (logging out external idps). Hence in a
> shared computer the user has no option.
>
 I think in this case user should close the browser, then he won't get
 this issue. this is valid for the multi step authentication as well.

 -Ishara

>
> Hence I think we can avoid setting cookie until a user successfully
> accesses at least a single application upon successful authentication and
> authorization. So simply even if the user is authenticated for the very
> first time, we will not set the cookie unless the user is authorized to
> access that particular application. (This only applies to the very first
> app the user is trying to login)
>
> WDYT ?
>
>
> [1] https://docs.wso2.com/display/IS530/Configuring+Access+C
> ontrol+Policy+for+a+Service+Provider
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


 --
 Ishara Karunarathna
 Technical Lead
 WSO2 Inc. - lean . enterprise . middleware |  wso2.com

 email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
 +94717996791 <071%20799%206791>



>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>> Ishara Karunarathna
>> Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791 <071%20799%206791>
>>
>>
>>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 
Ishara Karunarathna
Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Ishara Karunarathna]

Hi Hasintha,

Same can happen in multi-step authentication where a user successfully
login wiht1st authenticator and fail in the 2nd case.

On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee 
wrote:

> We have the feature of enabling authorization for service provider [1].
> Imagine a scenario where we login to an SP for the very first time and
> authorization fails due to some violation of authorization policies. Even
> if authorization fails we do set commonAuthId cookie in the response which
> means the user has a valid SSO session from that point onwards.
>
> This can be seen in two perspectives.
>
> 1) The user is authenticated, but authorization fails, Hence we should set
> the cookie for SSO irrespective of authorization decision.
>
> 2) But this may lead to an inconsistant state. Suppose this is the only
> application the user is allowed to login. But due to some policy violation,
> the first login fails. In a case of a shared computer this leads to a
> deadlock where the user neither can't properly login nor proper logout. We
> can use the workaround of calling commonAuthLogout=true. But this will not
> do a proper logout. (logging out external idps). Hence in a shared computer
> the user has no option.
>
I think in this case user should close the browser, then he won't get this
issue. this is valid for the multi step authentication as well.

-Ishara

>
> Hence I think we can avoid setting cookie until a user successfully
> accesses at least a single application upon successful authentication and
> authorization. So simply even if the user is authenticated for the very
> first time, we will not set the cookie unless the user is authorized to
> access that particular application. (This only applies to the very first
> app the user is trying to login)
>
> WDYT ?
>
>
> [1] https://docs.wso2.com/display/IS530/Configuring+
> Access+Control+Policy+for+a+Service+Provider
>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 
Ishara Karunarathna
Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Ishara Karunarathna]

HI Hsintha,

On Mon, Jan 29, 2018 at 8:19 PM, Hasintha Indrajee 
wrote:

> Multi-step authentication is a different case I think, We don't set
> cookies in an intermediate state. What if we use "remember me" ? So the
> cookie will be there even if we close the browswer. isn't it ?
>
Think of a authentication steps.
step1 : Federated authenticator
step2 : Local authenticator.

Then in the step 1 federated authenticator will create a session where 2nd
authentication files. So in the 2nd time also user will automatically
redirect to the federated authenticator and authenticated then fails in 2nd
case.

-Ishara

>
> On Mon, Jan 29, 2018 at 8:15 PM, Ishara Karunarathna 
> wrote:
>
>> Hi Hasintha,
>>
>> Same can happen in multi-step authentication where a user successfully
>> login wiht1st authenticator and fail in the 2nd case.
>>
>> On Mon, Jan 29, 2018 at 8:04 PM, Hasintha Indrajee 
>> wrote:
>>
>>> We have the feature of enabling authorization for service provider [1].
>>> Imagine a scenario where we login to an SP for the very first time and
>>> authorization fails due to some violation of authorization policies. Even
>>> if authorization fails we do set commonAuthId cookie in the response which
>>> means the user has a valid SSO session from that point onwards.
>>>
>>> This can be seen in two perspectives.
>>>
>>> 1) The user is authenticated, but authorization fails, Hence we should
>>> set the cookie for SSO irrespective of authorization decision.
>>>
>>> 2) But this may lead to an inconsistant state. Suppose this is the only
>>> application the user is allowed to login. But due to some policy violation,
>>> the first login fails. In a case of a shared computer this leads to a
>>> deadlock where the user neither can't properly login nor proper logout. We
>>> can use the workaround of calling commonAuthLogout=true. But this will not
>>> do a proper logout. (logging out external idps). Hence in a shared computer
>>> the user has no option.
>>>
>> I think in this case user should close the browser, then he won't get
>> this issue. this is valid for the multi step authentication as well.
>>
>> -Ishara
>>
>>>
>>> Hence I think we can avoid setting cookie until a user successfully
>>> accesses at least a single application upon successful authentication and
>>> authorization. So simply even if the user is authenticated for the very
>>> first time, we will not set the cookie unless the user is authorized to
>>> access that particular application. (This only applies to the very first
>>> app the user is trying to login)
>>>
>>> WDYT ?
>>>
>>>
>>> [1] https://docs.wso2.com/display/IS530/Configuring+Access+C
>>> ontrol+Policy+for+a+Service+Provider
>>>
>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453 <+94%2077%20189%202453>
>>>
>>>
>>
>>
>> --
>> Ishara Karunarathna
>> Technical Lead
>> WSO2 Inc. - lean . enterprise . middleware |  wso2.com
>>
>> email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
>> +94717996791 <071%20799%206791>
>>
>>
>>
>
>
> --
> Hasintha Indrajee
> WSO2, Inc.
> Mobile:+94 771892453 <+94%2077%20189%202453>
>
>


-- 
Ishara Karunarathna
Technical Lead
WSO2 Inc. - lean . enterprise . middleware |  wso2.com

email: isha...@wso2.com,   blog: isharaaruna.blogspot.com,   mobile:
+94717996791
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Setting commonAuth Cookie even after failing authorization in a fresh login attempt.

[Hasintha Indrajee]

We have the feature of enabling authorization for service provider [1].
Imagine a scenario where we login to an SP for the very first time and
authorization fails due to some violation of authorization policies. Even
if authorization fails we do set commonAuthId cookie in the response which
means the user has a valid SSO session from that point onwards.

This can be seen in two perspectives.

1) The user is authenticated, but authorization fails, Hence we should set
the cookie for SSO irrespective of authorization decision.

2) But this may lead to an inconsistant state. Suppose this is the only
application the user is allowed to login. But due to some policy violation,
the first login fails. In a case of a shared computer this leads to a
deadlock where the user neither can't properly login nor proper logout. We
can use the workaround of calling commonAuthLogout=true. But this will not
do a proper logout. (logging out external idps). Hence in a shared computer
the user has no option.

Hence I think we can avoid setting cookie until a user successfully
accesses at least a single application upon successful authentication and
authorization. So simply even if the user is authenticated for the very
first time, we will not set the cookie unless the user is authorized to
access that particular application. (This only applies to the very first
app the user is trying to login)

WDYT ?


[1]
https://docs.wso2.com/display/IS530/Configuring+Access+Control+Policy+for+a+Service+Provider



-- 
Hasintha Indrajee
WSO2, Inc.
Mobile:+94 771892453
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Registry database resource updating/loading policies

[Chandana Napagoda]

Hi Samitha,

Since this a user issue, you won't be able to directly update the RXT.
However there are multiple workarounds as well. I think the best option is
using the admin console to delete the RXT first and add it again.

Regards,
Chandana

On 29 Jan. 2018 5:31 pm, "Samitha Chathuranga"  wrote:

> Hi Chandana,
>
> So that means I cannot update RXT via Asset Type management UI?
>
> Regards,
> Samitha
>
> On Mon, Jan 29, 2018 at 12:21 PM, Chandana Napagoda 
> wrote:
>
>> Hi Samitha,
>>
>> The reason for this issue is, originally your RXT was saved to the
>> registry with "documentation" short name and when you are trying to update
>> RXT content, it will validate the original short name with the short name
>> available in the RXT content.
>>
>> Regards,
>> Chandana
>>
>> On 28 January 2018 at 18:02, Samitha Chathuranga 
>> wrote:
>>
>>> Hi Chandanda,
>>>
>>> On Sat, Jan 27, 2018 at 1:41 PM, Chandana Napagoda 
>>> wrote:
>>>
 Hi Samitha,

 If you have access to the admin console, is there any reason to update
 RXT content using registry instead of the Asset Type management UI?

>>> There is no specific reason.
>>>
 What is your actual requirement here? Do you want to update the RXT
 content without using Asset Type management UI(ex: using Java API)?

>>>
>>> The actual requirement is to update the RXT content via any approach.
>>> I think you meant editing via, *Home > Extensions > Configure >
>>> Artifact Types  > Artifact Source* in management console, "Asset Type
>>> management UI". But editing via this popped error alert that "Failed to
>>> save the configuration. RXT short name can't be modified".
>>>
>>> [image: Inline image 1]
>>>
>>> Seems no any field in this documentation.rxt (not only short name) can
>>> be modified. What I originally wanted to edit was storage path. i.e.
>>>
>>> /*appmgt*/applicationdata/provider/@{overview_api
>>> BasePath}/documentation/@{overview_name}
>>> to
>>> /*apimgt*/applicationdata/provider/@{overview_api
>>> BasePath}/documentation/@{overview_name}
>>>
>>> As editing via this approach was impossible, I updated via registry.
>>>
>>> Please note also the below fact I have mentioned previously.
>>>
>>> I tried this with wso2 cloud but not with a standalone apim pack. I just
 tested, this works without issues with standalone apim packs; rxt update is
 effected just after, without restarting, even without waiting for 15
 minutes to upload after deletion.

>>>
>>> Thanks,
>>> Samitha
>>>
>>>
 Regards,
 Chandana

 On 19 January 2018 at 18:36, Samitha Chathuranga 
 wrote:

> Hi Viraj,
>
> Thanks for your suggestions. I tested that with WSO2 Cloud(staging),
> but no luck.
>
> Regards,
> Samitha
>
> On Fri, Jan 19, 2018 at 12:02 PM, Viraj Warnakulasinghe <
> vir...@wso2.com> wrote:
>
>> Hi Samitha,
>>
>> I encountered previously mention issue with APIM 2.0.0. It may be
>> fixed with APIM 2.1.0. Better if you could check and verify in the WSO2
>> cloud.
>>
>> Regards,
>> Viraj
>>
>> On Fri, Jan 19, 2018 at 11:36 AM, Samitha Chathuranga <
>> sami...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> I have WSO2 APIM 2.1.0 server started and logged into management
 console with a tenant admin. Here I browse the registry and update a
 certain resource (i.e. /_system/governance/repository
 /components/org.wso2.carbon.governance/types/documentation.rxt).
 But this change seems not to effect until I restart the server. I am 
 not
 certain if there is a connection with the tenant load/unload, but even
 waiting more than 30 mins won't reload the updated resource.

 Correction; I tried this with wso2 cloud but not with a standalone
>>> apim pack. I just tested, this works without issues with standalone apim
>>> packs; rxt update is effected just after, without restarting, even 
>>> without
>>> waiting for 15 minutes to upload after deletion.
>>>
>>> @Viraj,
>>>
>>> Similar behavior encountered when updating in-flow mediation policy
 file to an API with the same name. Upload the file and have to wait 15
 minutes to publish again the API in order to update the resource. This
 occurred due to the registry cache.
 Could you please try removing existing resource from the registry
 and wait 15 minutes until the registry cache expiration and upload the
 resource file and check whether the resource is updated (without 
 restarting
 the server)?

>>> I will try this in WSO2 cloud.
>>> BTW what is the rationale behind the requirement to wait for cache
>>> expiration to upload the updated file, after deleting the resource? Why 
>>> the

Re: [Dev] Artifact synchronization in WSO2 Identity Server deployment patterns in Cloud Foundry BOSH

[Imesh Gunaratne]

Hi Chiranga,

On Fri, Jan 26, 2018 at 12:11 PM, Imesh Gunaratne  wrote:

> ​...
>
> At the same time we can check with the BOSH team whether they have already
> implemented a solution for this.
>

​I checked this with the PCF engineering team and according to them we may
need to handle this manually using the BOSH release. There seems to be no
support from the BOSH Director to handle this based on the infrastructure
platform.

Thanks
Imesh

>
> [1] https://bosh.io/docs/deployment-manifest.html#properties
>
> Thanks
> Imesh
>
> On Thu, Jan 25, 2018 at 3:20 PM, Chiranga Alwis  wrote:
>
>> Hi all,
>>
>> currently I am working on implementing Cloud Foundry (CF) BOSH releases
>> and Pivotal Cloud Foundry (PCF) Tiles for WSO2 Identity Server deployment
>> patterns.
>>
>> Currently, it has been understood that that there is no known concept in
>> BOSH for sharing volumes between BOSH instances [1].
>>
>> Upon research it was learnt that if needed to share volumes, the
>> deployment is required to include a Network File System (NFS) or a similar
>> network files system service running on top of the BOSH instances.
>>
>> Currently, I am looking into how we can achieve this target.
>>
>> Your thoughts and suggestions are highly appreciated.
>>
>> [1]: https://ultimateguidetobosh.com/instances/#persistent-volumes
>>
>> --
>> Yours sincerely,
>>
>> *Chiranga Alwis*
>> Software Engineer | WSO2
>>
>> *Mobile : *+94775930497 <+94%2077%20593%200497>
>> *Email: *chirangaal...@gmail.com
>> *LinkedIn: *https://lk.linkedin.com/in/chiranga-alwis-391342a9
>> *Medium:* https://medium.com/@chirangaalwis
>>
>> 
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Imesh Gunaratne*
> WSO2 Inc: http://wso2.com
> T: +94 11 214 5345 M: +94 77 374 2057 <+94%2077%20374%202057>
> W: https://medium.com/@imesh TW: @imesh
> lean. enterprise. middleware
>
>


-- 
*Imesh Gunaratne*
WSO2 Inc: http://wso2.com
T: +94 11 214 5345 M: +94 77 374 2057
W: https://medium.com/@imesh TW: @imesh
lean. enterprise. middleware
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Unable to cache the response

[Riyafa Abdul Hameed]

Hi Keerthika,

Are you using Postman to make the calls? If so we have noticed in a
previous instance that it does not get cached because Postman seemed to
insert unnecessary headers? Can you try using curl requests? Or RESTer is a
handy plugin for firefox.
Or you can set headersToExcludeInHash to the value * and try:
*

Hope it helps.

Regards,
Riyafa

On Mon, Jan 29, 2018 at 2:31 PM, Keerthika Mahendralingam <
keerth...@wso2.com> wrote:

> Hi All,
>
> I am using the cache mediator in the proxy. But the response is not
> getting cached. I have tested this with EI 6.1.1-update17 and EI
> 6.1.1-update18. For both, the response is fetched from the backend service
> not from the cache. What could be the reason?
>
> I am using the following configuration:
> 
> http://ws.apache.org/ns/synapse;
>name="connectMockito"
>startOnLoad="true"
>statistics="disable"
>trace="disable"
>transports="http,https">
>
>   
>  
> 
>
> 
> 
>GET
>
>(1|2)[0-9][0-9]
>org.wso2.carbon.mediator.cache.digest.
> HttpRequestHashGenerator
> 
> 
>  
>  
> 
>http://demo2236300.mockable.io/testService"/>
> 
>  
>   
>   
>  
>  
>  
>   
>
>
> 
>
> * Log for the second call:*
>
> [2018-01-29 14:28:39,010] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "GET /services/connectMockito HTTP/1.1[\r][\n]"
>
> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Host: keerthikas-macbook-pro.local:8280[\r][\n]"
>
> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Connection: keep-alive[\r][\n]"
>
> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Cache-Control: no-cache[\r][\n]"
>
> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Content-Type: application/json[\r][\n]"
>
> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
> 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132
> Safari/537.36[\r][\n]"
>
> [2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Postman-Token: 48f7595e-3e2c-cee7-9652-
> a82c272b67e2[\r][\n]"
>
> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Accept: */*[\r][\n]"
>
> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Accept-Encoding: gzip, deflate[\r][\n]"
>
> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "Accept-Language: en-US,en;q=0.9[\r][\n]"
>
> [2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
> dispatcher-6 >> "[\r][\n]"
>
> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "GET /testService HTTP/1.1[\r][\n]"
>
> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Accept: */*[\r][\n]"
>
> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Cache-Control: no-cache[\r][\n]"
>
> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Postman-Token: 48f7595e-3e2c-cee7-9652-
> a82c272b67e2[\r][\n]"
>
> [2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Accept-Encoding: gzip, deflate[\r][\n]"
>
> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Accept-Language: en-US,en;q=0.9[\r][\n]"
>
> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Content-Type: application/json[\r][\n]"
>
> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Host: demo2236300.mockable.io[\r][\n]"
>
> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "Connection: Keep-Alive[\r][\n]"
>
> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n]"
>
> [2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 << "[\r][\n]"
>
> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 >> "HTTP/1.1 200 OK[\r][\n]"
>
> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 >> "cache-control: no-cache[\r][\n]"
>
> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 >> "access-control-allow-origin: *[\r][\n]"
>
> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 >> "Content-Type: application/json; charset=UTF-8[\r][\n]"
>
> [2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
> dispatcher-4 >> "X-Cloud-Trace-Context: 4e909d0476e6249930df95cc5b5489
> 

Re: [Dev] [APIM-ANALYTICS-2.1.0] Error ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUES does not exist

[Harsha Kumara]

On Mon, Jan 29, 2018 at 6:20 PM, Chaminda Jayawardena 
wrote:

> Hi All,
>
> Getting below error continuously on an apim-analytics-2.10 server instance.
> We are using latest wum updated apim-analytics2.1.0 pack with fresh
> databases.
>
> Configured the pack using puppet in an apim cluster pattern-6[1].
>
> The error encountered only when the wum updated pack is used.
>
> Note: as suggested in several threads, I cleaned the databases and tried
> again but had no luck. Complete error log has been attached in the file -
> analytics_error.rtf
>
>
>
> *Caused by:
> org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsTableNotAvailableException:
> [-1234:ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUEST] does not exist*
>
> * at *org.wso2.carbon.analytics.datasource.rdbms.
> RDBMSAnalyticsRecordStore.get(RDBMSAnalyticsRecordStore.java:420)
>
> at org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.
> getByRange(AnalyticsDataServiceImpl.java:961)
>
> at org.wso2.carbon.analytics.dataservice.core.
> AnalyticsDataServiceImpl.get(AnalyticsDataServiceImpl.java:910)
>
> at org.wso2.carbon.analytics.spark.core.rdd.AnalyticsRDD.
> getPartitions(AnalyticsRDD.java:119)
>
> ... 100 more
>
>
> [1] https://docs.wso2.com/display/AM2xx/Using+Puppet+
> Modules+to+Set+up+WSO2+API-M+with+Pattern+6
>
> --
> Thanks & Regards
>
> *Chaminda Jayawardena*
> Associate Technical Lead - QA
> WSO2 Inc. - http://wso2.com
> +94-77-7725234 <+94%2077%20772%205234>
>



-- 
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [APIM-ANALYTICS-2.1.0] Error ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUES does not exist

[Chaminda Jayawardena]

Hi All,

Getting below error continuously on an apim-analytics-2.10 server instance.
We are using latest wum updated apim-analytics2.1.0 pack with fresh
databases.

Configured the pack using puppet in an apim cluster pattern-6[1].

The error encountered only when the wum updated pack is used.

Note: as suggested in several threads, I cleaned the databases and tried
again but had no luck. Complete error log has been attached in the file -
analytics_error.rtf



*Caused by:
org.wso2.carbon.analytics.datasource.commons.exception.AnalyticsTableNotAvailableException:
[-1234:ORG_WSO2_APIMGT_STATISTICS_PERHOURREQUEST] does not exist*

* at *
org.wso2.carbon.analytics.datasource.rdbms.RDBMSAnalyticsRecordStore.get(RDBMSAnalyticsRecordStore.java:420)

at
org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.getByRange(AnalyticsDataServiceImpl.java:961)

at
org.wso2.carbon.analytics.dataservice.core.AnalyticsDataServiceImpl.get(AnalyticsDataServiceImpl.java:910)

at
org.wso2.carbon.analytics.spark.core.rdd.AnalyticsRDD.getPartitions(AnalyticsRDD.java:119)

... 100 more


[1]
https://docs.wso2.com/display/AM2xx/Using+Puppet+Modules+to+Set+up+WSO2+API-M+with+Pattern+6

-- 
Thanks & Regards

*Chaminda Jayawardena*
Associate Technical Lead - QA
WSO2 Inc. - http://wso2.com
+94-77-7725234


analytics_error.rtf
Description: RTF file
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Unable to cache the response

[Keerthika Mahendralingam]

Hi All,

I am using the cache mediator in the proxy. But the response is not getting
cached. I have tested this with EI 6.1.1-update17 and EI 6.1.1-update18.
For both, the response is fetched from the backend service not from the
cache. What could be the reason?

I am using the following configuration:

http://ws.apache.org/ns/synapse;
   name="connectMockito"
   startOnLoad="true"
   statistics="disable"
   trace="disable"
   transports="http,https">
   
  
 

   


   GET
   
   (1|2)[0-9][0-9]

 
org.wso2.carbon.mediator.cache.digest.HttpRequestHashGenerator


 
 

   http://demo2236300.mockable.io/testService"/>

 
  
  
 
 
 
  
   
   


* Log for the second call:*

[2018-01-29 14:28:39,010] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "GET /services/connectMockito HTTP/1.1[\r][\n]"

[2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Host: keerthikas-macbook-pro.local:8280[\r][\n]"

[2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Connection: keep-alive[\r][\n]"

[2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Cache-Control: no-cache[\r][\n]"

[2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Content-Type: application/json[\r][\n]"

[2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X
10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132
Safari/537.36[\r][\n]"

[2018-01-29 14:28:39,011] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Postman-Token:
48f7595e-3e2c-cee7-9652-a82c272b67e2[\r][\n]"

[2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Accept: */*[\r][\n]"

[2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Accept-Encoding: gzip, deflate[\r][\n]"

[2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "Accept-Language: en-US,en;q=0.9[\r][\n]"

[2018-01-29 14:28:39,012] [EI-Core] DEBUG - wire HTTP-Listener I/O
dispatcher-6 >> "[\r][\n]"

[2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "GET /testService HTTP/1.1[\r][\n]"

[2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Accept: */*[\r][\n]"

[2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Cache-Control: no-cache[\r][\n]"

[2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Postman-Token:
48f7595e-3e2c-cee7-9652-a82c272b67e2[\r][\n]"

[2018-01-29 14:28:39,014] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Accept-Encoding: gzip, deflate[\r][\n]"

[2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Accept-Language: en-US,en;q=0.9[\r][\n]"

[2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Content-Type: application/json[\r][\n]"

[2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Host: demo2236300.mockable.io[\r][\n]"

[2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "Connection: Keep-Alive[\r][\n]"

[2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n]"

[2018-01-29 14:28:39,015] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 << "[\r][\n]"

[2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "HTTP/1.1 200 OK[\r][\n]"

[2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "cache-control: no-cache[\r][\n]"

[2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "access-control-allow-origin: *[\r][\n]"

[2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "Content-Type: application/json; charset=UTF-8[\r][\n]"

[2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "X-Cloud-Trace-Context:
4e909d0476e6249930df95cc5b54899a[\r][\n]"

[2018-01-29 14:28:39,582] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "Date: Mon, 29 Jan 2018 08:58:39 GMT[\r][\n]"

[2018-01-29 14:28:39,583] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "Server: Google Frontend[\r][\n]"

[2018-01-29 14:28:39,583] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "Content-Length: 27[\r][\n]"

[2018-01-29 14:28:39,583] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "[\r][\n]"

[2018-01-29 14:28:39,583] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> "{[\n]"

[2018-01-29 14:28:39,583] [EI-Core] DEBUG - wire HTTP-Sender I/O
dispatcher-4 >> " "msg": "Hello Worldaa"[\n]"

[2018-01-29 14:28:39,583] 

Re: [Dev] Deletion of Faulty Services Deployed via a Capp

[Thishani Lucas]

Hi Shazni,

That's the issue. To determine if it's a dataservice, again we need the
service data.

On Sat, Jan 27, 2018 at 10:56 PM, Shazni Nazeer  wrote:

> Hi Tishani,
>
> Isn't there a way to determine if it's a dataservice at the time of
> deletion. If you have a way, can't we special case the daataservice
> deletion without affecting other places that need archive name.
>
> On Thu, Jan 25, 2018 at 12:59 AM, Thishani Lucas 
> wrote:
>
>> Hi All,
>>
>> Earlier we had issues in the EI where we couldn't delete faulty services
>> and we could delete services deployed via capps. These are reported in the
>> public jiras [1] and [2] and the fixes are done respectively in [3] and
>> [4]. Now we have a scenario where we shouldn't allow deletion of faulty
>> services deployed via a capp.
>>
>> I tried to implement this by something similar to what I did in [5]
>> where, before sending the service names to be deleted, we check whether the
>> service is deployed via a capp. This worked perfectly fine with proxy
>> services. But for data services, it's throwing an error at the place where
>> service data is retrieved because for faulty data services, the service
>> name is returned as the archive name (/dataservices/name.dbs). If we fix
>> this, it would break the other places where the archive name is needed like
>> in [6]. Because of these issues, I'm putting this implementation on hold.
>>
>> Please provide your concerns about this issue.
>>
>> [1] https://wso2.org/jira/browse/ESBJAVA-4068
>> [2] https://wso2.org/jira/browse/ESBJAVA-4139
>> [3] https://github.com/wso2/carbon-deployment/pull/286
>> [4] https://github.com/wso2/carbon-deployment/pull/285
>> [5] https://github.com/wso2/carbon-deployment/blob/4.7.x/com
>> ponents/service-mgt/axis2-service-mgt/org.wso2.carbon.servic
>> e.mgt.ui/src/main/resources/web/service-mgt/delete_
>> service_groups_ajaxprocessor.jsp#L89
>> [6] https://github.com/wso2/carbon-deployment/blob/4.7.x/com
>> ponents/service-mgt/axis2-service-mgt/org.wso2.carbon.servic
>> e.mgt/src/main/java/org/wso2/carbon/service/mgt/ServiceAdmin.java#L779
>>
>> Thanks,
>> Thishani
>>
>> --
>> Regards,
>>
>> *Thishani Lucas*
>> *Software Engineer*
>> *WSO2 Lanka (Private) Limited**: http://wso2.com *
>> *lean.enterprise.middle-ware*
>>
>> *Tel: +94 77 2556931 <+94%2077%20255%206931> *
>>
>> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
>> *
>>
>> 
>>
>
>
>
> --
> Shazni Nazeer
>
> Mob : +94 37331
> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>
> Blogs :
>
> https://medium.com/@mshazninazeer
> http://shazninazeer.blogspot.com
>
> 
>



-- 
Regards,

*Thishani Lucas*
*Software Engineer*
*WSO2 Lanka (Private) Limited**: http://wso2.com *
*lean.enterprise.middle-ware*

*Tel: +94 77 2556931 *

*LinkedIn: https://www.linkedin.com/in/thishani-lucas/
*


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] //jsonOject and $ are printing different jsons (different data content) at same location in API.

[Riyafa Abdul Hameed]

Hi,

Your issue has been fixed and shall be included in future releases.

Thanks,
Riyafa

On Fri, Jan 19, 2018 at 1:39 PM, aditya shivankar <
shivankar.adit...@gmail.com> wrote:

> Respected SirThis issue does not exist in wso2ei-6.1.1
> But is present in  wso2ei-6.1.1-update7 wso2ei-6.1.1-update16 I cannot
> migrate to older version because I am using some fixes which are done in
> wso2ei-6.1.1-update7.
> Raised issue ://jsonOject and $ are printing different jsons (different
> data content) at same location in API #1771
> With Regards,Aditya
>
> On Fri, Jan 19, 2018 at 10:28 AM, aditya shivankar <
> shivankar.adit...@gmail.com> wrote:
>
>> Please provide the link to download the latest version wso2 EI.
>>
>> With Regards,
>> Aditya
>>
>> On Fri, Jan 19, 2018 at 10:18 AM, Riyafa Abdul Hameed 
>> wrote:
>>
>>> Hi Aditya,
>>>
>>> We observed this behavior. As I mentioned in my previous reply can you
>>> report an issue?
>>>
>>> Regards,
>>> Riyafa
>>>
>>> On Fri, Jan 19, 2018 at 10:09 AM, aditya shivankar <
>>> shivankar.adit...@gmail.com> wrote:
>>>
 Hi ,

 My Question is while printing //jsonObject  I am able to print enriched
 value tag "Value" as well.

 But while printing $ "value" element is missing . While both logs are
 printed at same location in flow.


 Log print of *//jsonObjec*t after enrichment:

 
 d8ccf265-6651-468f-8d1f-d935c3c7d857
 57
 *PartyId*
 

 Log print of* json-eval($) *at same place after enrichment : *Value
 tag missing*

 {
 "a": "d8ccf265-6651-468f-8d1f-d935c3c7d857",
 "b": "57"

 }


 My Question is *not *why we are printing xml for //jsonObject.
 Please guide.
 I think *$* and *//jsonObject *or *$body* are representation of same
 object just in different formats, at any point in flow.
 Then why //jsonOject and $ are printing different jsons at same
 location in API.

 Thanks,
 Aditya

 On Fri, Jan 19, 2018 at 9:35 AM, Senduran Balasubramaniyam <
 sendu...@wso2.com> wrote:

> Hi Aditya,
>
> //jsonObject is an XPATH expression. When you apply an XPATH
> evaluation on a JSON, ESB / EI internally convert the JSON to XML, that's
> why you are seeing XML for //jsonObject xpath evaluation.
> Since you are sending a JSON payload it is good to use $ (which is a
> JSON path)
>
> Regards
> Senduran
>
> On Fri, Jan 19, 2018 at 3:28 AM, aditya shivankar <
> shivankar.adit...@gmail.com> wrote:
>
>> Respected Sir,
>>
>> //jsonOject and $ are printing different jsons at same location in
>> API.
>>
>> Are not both suppose to have latest json payload,
>>
>> //jsonObject - latest json payload in xml format
>>
>> $ -  latest json payload in json format ?
>>
>> Input json:
>>
>> {
>> "token": "d8ccf265-6651-468f-8d1f-d935c3c7d857",
>> "partyId": "2920394"
>>
>>
>> }
>>
>> Log print of //jsonObject after enrichment:
>>
>> 
>> d8ccf265-6651-468f-8d1f-d935c3c7d857
>> 57
>> PartyId
>> 
>>
>> Log print of json-eval($) at same place after enrichment : Value tag
>> missing
>>
>> {
>> "a": "d8ccf265-6651-468f-8d1f-d935c3c7d857",
>> "b": "57"
>>
>> }
>>
>>
>> Please find attached Rest api "sample.xml"
>>
>>
>> I am facing this issue , when I have to assign current json payload,
>> to one element of new json I created in payload factory.
>>
>> Inside payloadFactory I defined something like this:
>> {
>>  "a" : $1 ,
>>  "b":"thampi"
>> }
>>
>> In args,
>>
>> Type :Expression , Value:$ , evaluator: json
>>
>> But it is assigning the payload which was present before
>> enrichment.which is wrong .
>>
>> Please guide.
>>
>>
>>
>> .
>>
>> [image: Inline image 2]
>>
>>
>> Thanks,
>> Aditya
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Senduran *
> Senior Software Engineer,
> WSO2, Inc.;  http://wso2.com/ 
> Mobile: +94 77 952 6548 <+94%2077%20952%206548>
>


 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev


>>>
>>>
>>> --
>>> Riyafa Abdul Hameed
>>> Software Engineer, WSO2 Lanka (Pvt) Ltd 
>>>
>>> Email: riy...@wso2.com 
>>> Website: https://riyafa.wordpress.com/ 
>>>   
>>>