Re: [Dev] [Architecture] [Vote] Release of WSO2 API Manager Tooling v3.2.0 RC2

[Uvindra Dias Jayasinha]

Tested the following,

   - Exporting/import APIs, API Products, Apps.
   - Environment specific parameters
   - Dynamic data scenarios

*[+] Stable - Go ahead and release*

On Tue, 25 Aug 2020 at 15:45, Naduni Pamudika  wrote:

> Hi All,
>
> Tested the following with API Manager Tooling 3.2.0 RC2 with API Manager
> 3.2.0 RC6 in the Linux environment.
>
>- Export/Import APIs, Applications and API Products from/to different
>APIM environments with latest APICTL.
>- Generate keys with APICTL.
>- Delete APIs, Applications (with keys, subscriptions) and API
>Products in APIM via APICTL.
>- Change the lifecycle status of an API deployed in APIM via APICTL.
>
> No blockers found.
> +1 to proceed with the release.
>
> On Tue, Aug 25, 2020 at 10:16 AM Lakshitha Gunasekara 
> wrote:
>
>> Hi All,
>>
>> Tested the following in APICTL 3.2.0-rc2 with WSO2 APIM 3.2.0-rc6.
>>
>>
>>1. Setting up environments (add/remove/listing)
>>2. API import with vcs deploy.
>>3. API/APP listing with limit parameters and searching with the query
>>parameters.
>>4. Formating the listing outputs to different formats.
>>5. Working with CA-signed certificates directly imported from the OS.
>>
>> No blockers found. +1 to proceed with the release.
>>
>> Thanks,
>> Lakshitha
>>
>>
>> On Tue, Aug 25, 2020 at 9:49 AM Shehani Rathnayake 
>> wrote:
>>
>>> Hi All,
>>>
>>> Tested the following in APICTL 3.2.0 - RC2, APIM 3.2.0 RC5.
>>>
>>> 1. Setting up/ listing and removing environments.
>>> 2. Importing and Exporting APIs
>>> 3. Install/ Uninstall api-operator
>>> 4. Kubernetes mode.
>>> 5. Add/Update/Delete APIs in Kubernetes cluster.
>>>
>>> No blockers found.
>>>
>>> *[+] Stable - Go ahead and release.*
>>>
>>> Thanks.
>>>
>>> On Tue, Aug 25, 2020 at 9:39 AM Hiranya Abeyrathne 
>>> wrote:
>>>
 Hi all,

 Tested the following in APICTL 3.2.0 - RC2.


 1. Setting up environments (add/remove/listing)
 2. API/APP import/export and updating
 3. API listing and searching
 4. API Product support basic functionalities
 5. Configuring environment specific params
 6. Lifecycle update of deployed API

 No blockers found.

 [+ Stable] +1 to proceed with the release.

 Thanks!
 Hiranya Abeyrathne
 Software Engineer,

 *WSO2, Inc. *

 lean. enterprise. middleware
 Mob: +94 70210 8657
 LinkedIn: https://www.linkedin.com/in/hiranya-kavishani/

 


 On Sat, Aug 22, 2020 at 12:55 PM Praminda Jayawardana <
 prami...@wso2.com> wrote:

> Tested pushing Microgateway APIs to API Manager using apictl.
> Tested compatibility of x-wso2 extensions.
>
> Didn't find any blockers.
>
> *[+] Stable - Go ahead and release.*
>
> On Mon, Aug 17, 2020 at 7:53 PM Wasura Wattearachchi 
> wrote:
>
>> Hi all,
>>
>> I tested the following scenarios with APIM 3.2.0 RC5.
>>
>>- Support for API Products from API Controller. (Tested with the
>>following users)
>>- Super tenant and tenant users with *Internal/devops* role
>>   (which was newly introduced in APIM 3.2.0)
>>   - Super tenant and tenant users with *admin* role
>>   - Super tenant and tenant users who do not have full privileges
>>   - Test scenarios basically include the following.
>>  - Import an API Product
>>  - Export an API Product
>>  - Generate Keys for an API Product
>>  - Delete an API Product
>>  - List API Products
>>   - Support for Different Endpoint Types from API Controller.
>>   - HTTP/REST (including load balancing and failover policies)
>>   - HTTP/SOAP (including load balancing and failover policies)
>>   - Dynamic
>>   - AWS Lambda
>>- GIT Integration with API Controller. (Tested the primary use
>>cases associated with the following commands.)
>>- apictl vcs init command
>>   - apictl vcs status command
>>   - apictl vcs deploy command (with APIs, API Products and
>>   Applications)
>>   - apictl set --vcs-deletion-enabled=true command and related
>>   use cases
>>   - apictl set --vcs-config-path /home/foo/vcs-config.yaml
>>   commanf and related use cases
>>   - Configuring Environment Specific Parameters
>>- List Environments, APIs and Applications
>>- Generate Keys for an API
>>- Initialize an API (including the dev first approach)
>>
>> Testing environment - Ubuntu 20.04 LTS, JDK 1.8.0_251
>>
>> No blockers found.
>>
>> *[+] Stable - Go ahead and release.*
>>
>> Thanks,
>> Wasura
>>
>> On Mon, Aug 17, 2020 at 10:56 AM Chamindu Udakara 
>> wrote:
>>
>>> Hi all,
>>>
>>> I have tested the following in APICTL 3.2.0 - RC2 with 

Re: [Dev] [DEV] [VOTE] Release WSO2 API Manager Tooling v3.1.0 RC4

[Uvindra Dias Jayasinha]

Tested the following:

Various scenarios involving super tenant, tenant, secondary user store users

1. Generate Keys
2. Export Apps

No blockers found

[+] Stable - Go ahead and release

On Fri, 3 Apr 2020 at 14:16, Naduni Pamudika  wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the fourth release candidate
> of WSO2 API Manager Tooling 3.1.0 version.
>
> The WSO2 API Manager tooling provides the capability to import and export
> APIs and Applications across multiple environments seamlessly. Hence it
> provides greater flexibility to create CI/CD pipelines for APIs and
> applications.
>
> Apart from migrating APIs and applications, it supports Kubernetes API
> operator to deploy and manage APIs in the Kubernetes cluster by reducing
> additional overheads for the DevOps.
>
> Please find the improvements and fixes related to this release in Fixed
> Issues
> 
> .
>
> Download the API Manager Tooling Distribution from here
> .
>
> The tag to be voted upon is
> https://github.com/wso2/product-apim-tooling/releases/tag/v3.1.0-rc4
>
> Documentation:
> https://apim.docs.wso2.com/en/next/learn/api-controller/getting-started-with-wso2-api-controller/
>
> Please download, test the tool and vote.
>
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
>
>
> Best Regards,
> WSO2 API Manager Team
>
> --
> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) nad...@wso2.com
> [image: http://wso2.com/signature] 
>
>

-- 
Regards,
Uvindra

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

Re: [Dev] [DEV] [VOTE] Release WSO2 API Manager Tooling v3.1.0 RC3

[Uvindra Dias Jayasinha]

Tested the following:

Various scenarios involving super tenant, tenant, secondary user store users

1. Generate Keys
2. Export Apps

No blockers found

[+] Stable - Go ahead and release

On Thu, 2 Apr 2020 at 19:30, Naduni Pamudika  wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the third release candidate
> of WSO2 API Manager Tooling 3.1.0 version.
>
> The WSO2 API Manager tooling provides the capability to import and export
> APIs and Applications across multiple environments seamlessly. Hence it
> provides greater flexibility to create CI/CD pipelines for APIs and
> applications.
>
> Apart from migrating APIs and applications, it supports Kubernetes API
> operator to deploy and manage APIs in the Kubernetes cluster by reducing
> additional overheads for the DevOps.
>
> Please find the improvements and fixes related to this release in Fixed
> Issues
> 
> .
>
> Download the API Manager Tooling Distribution from here
> .
>
> The tag to be voted upon is
> https://github.com/wso2/product-apim-tooling/releases/tag/v3.1.0-rc3
>
> Documentation:
> https://apim.docs.wso2.com/en/next/learn/api-controller/getting-started-with-wso2-api-controller/
>
> Please download, test the tool and vote.
>
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
>
>
> Best Regards,
> WSO2 API Manager Team
>
> --
> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) nad...@wso2.com
> [image: http://wso2.com/signature] 
>
>

-- 
Regards,
Uvindra

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

Re: [Dev] [Architecture] [VOTE] Release of WSO2 API Manager 3.0.0 RC3

[Uvindra Dias Jayasinha]

Tested Workflows for,

- API State change
- User Signup
- Application Creation
- Application Registration
- API Subscription
- API Product Subscription


No blockers found. +1 for release

On Fri, 25 Oct 2019 at 17:42, Dushani Wellappili  wrote:

> Tested the following,
>
> - Basic flow in API Creation, LifeCycle change, API Invocation for users
> with the separate creator, publisher permissions.
> - API Developer Portal visibility and Publisher access control
> - API Scopes
> - External Developer Portal Publishing
> - XACML
> - Developer Portal self signup
> - Admin Rest API v0.15 functionalities
> -Tested above for both tenant and super tenant in MSSQL 2017
>
> No blockers found. +1 for the release.
>
>
> *Dushani Wellappili*
> Senior Software Engineer - WSO2
>
> Email : dusha...@wso2.com
> Mobile : +94779367571
> Web : https://wso2.com/
>
>
>
>
> On Fri, Oct 25, 2019 at 3:04 PM Hasunie Adikari  wrote:
>
>> Hi,
>>
>> I have tested the following
>>
>> - Micro-gw API import and label import.
>> - Micro-gw analytics.
>> - API request/response validator.
>> - Self signup.
>> - Scope test.
>> - API invocation and analytics.
>> - Tested API manager scenarios in both super tenant and tenant.
>>
>> No blockers found. Hence, [+] Stable - go ahead and release.
>>
>> Regards,
>> Hasunie
>>
>> On Fri, Oct 25, 2019 at 2:52 PM Nalaka Senarathna 
>> wrote:
>>
>>> Hi All,
>>> Tested the followings.
>>> - Token cleanup
>>> - Caching
>>> - API /API product invocation and visibility
>>> - SDK feature
>>> - Pass end-user attributes to backend using JWT
>>> - Alert subscription
>>> - Basic flows in oracle and db2
>>>
>>> Stable and go ahead and release.
>>> Thanks & Regards.
>>> Nalaka
>>>
>>>
>>> On Fri, Oct 25, 2019 at 2:44 PM Hasunie Adikari 
>>> wrote:
>>>
 Hi,

 I have tested the following

 - Micro-gw API import and label import.
 - Micro-gw analytics.
 - API request/response validator.
 - Self signup.
 - Scope test.
 - API invocation and analytics.
 - Tested API manager scenarios in both super tenant and tenant.

 Regards,
 Hasunie


 On Fri, Oct 25, 2019 at 1:23 PM Dushan Silva  wrote:

> Hi,
> I have tested the following
> Authorization code grant type,
> JWT grant type,
> NTLM grant type,
> Password grant type,
> Client credentials grant type,
>
> Provisioning Out-of-Band OAuth Clients
> Application group sharing
> self registration
>
> No blockers found. +1 to go ahead and release.
>
>
>
> On Fri, Oct 25, 2019 at 12:20 PM Chamin Dias  wrote:
>
>> Hi,
>>
>> Tested the following scenarios in both the super tenant and tenant.
>> - API keys for securing APIs
>> - Localization / internationalisation
>> - Monetization (with in-built implementation)
>>
>> No blockers found. Hence, [+] Stable: go ahead and release.
>>
>> Thanks.
>>
>> On Fri, Oct 25, 2019 at 11:28 AM Mushthaq Rumy 
>> wrote:
>>
>>> Hi All,
>>>
>>> Hi All,
>>>
>>> Tested the following scenarios in both super tenant and tenant.
>>> - API Creation, Publishing, Subscribing and invocation of APIs
>>> - Tested Publisher Access Control
>>> - Tested Store Visibility
>>> - Identity management features such as self sign up, password reset,
>>> password policy, account locking.
>>>
>>> No blockers found. Hence, [+] Stable - go ahead and release.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>> On Fri, Oct 25, 2019 at 3:52 AM Samitha Chathuranga <
>>> sami...@wso2.com> wrote:
>>>
 Hi All,

 We are pleased to announce the second release candidate of WSO2 API
 Manager 3.0.0.

 This release fixes the following issues.

- Fixes : product-apim

 
- Fixes : carbon-apimgt

 
- Fixes : analytics-apim

 

 Source and distribution,
 Runtime :
 https://github.com/wso2/product-apim/releases/tag/v3.0.0-rc3
 Analytics :
 https://github.com/wso2/analytics-apim/releases/tag/v3.0.0-rc3
 APIM Tooling :
 https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.0-rc

 Please download, test the product and vote.

 [+] Stable - go ahead and release
 [-] Broken - do not release (explain why)

 Thanks,
 WSO2 API Manager Team


 --
 *Samitha 

Re: [Dev] [Architecture] [VOTE] Release of WSO2 API Manager 3.0.0 RC2

[Uvindra Dias Jayasinha]

Tested Workflows for,

- API State change
- User Signup
- Application Creation
- Application Registration
- API Subscription
- API Product Subscription


No blockers found. +1

On Thu, 24 Oct 2019 at 17:35, Ishara Cooray  wrote:

> Hi All,
>
> Tested the following.
> - API Creation, Publishing, Subscription in super tenant and tenant.
> - Reverse proxy configuration for publisher and devportal
> - CORS
> - Custom authorization header
> - Message Mediation Policies
>
> No blockers found. Hence +1.
>
> Thanks & Regards,
> Ishara Cooray
> Associate Technical Lead
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
>
> On Thu, Oct 24, 2019 at 4:19 PM Mushthaq Rumy  wrote:
>
>> Hi All,
>>
>> Tested the following scenarios.
>> - API Creation, Publishing and Subscription
>> - Tested Publisher Access Control
>> - Tested Store visibility
>> - Identity management features such as self sign up, password reset,
>> password policy, account locking.
>>
>> No blockers found. Hence +1.
>>
>> Thanks & Regards,
>> Mushthaq
>>
>> On Thu, Oct 24, 2019 at 4:15 PM Prasanna Dangalla 
>> wrote:
>>
>>> Hi All,
>>>
>>> Tested API Creation, Publishing, Subscription JWT & OAuth Token
>>> generation and throttling.
>>>
>>> Hence +1 from me.
>>>
>>> Thanks
>>> *Prasanna Dangalla* | Associate Technical Lead | WSO2 Inc.
>>> (m) +94 718 112 751 | (e) prasa...@wso2.com
>>> [image: Signature.jpg]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Oct 24, 2019 at 8:51 AM Mushthaq Rumy  wrote:
>>>
 Hi All,

 We are pleased to announce the second release candidate of WSO2 API
 Manager 3.0.0.

 This release fixes the following issues.

- Fixes : carbon-apimgt

 
- Fixes : product-apim

 
- Fixes : analytics-apim

 

 Source and distribution,
 Runtime :
 https://github.com/wso2/product-apim/releases/tag/v3.0.0-rc2
 Analytics :
 https://github.com/wso2/analytics-apim/releases/tag/v3.0.0-rc2
 APIM Tooling :
 https://github.com/wso2/product-apim-tooling/releases/tag/v3.0.0-rc

 Please download, test the product and vote.

 [+] Stable - go ahead and release
 [-] Broken - do not release (explain why)

 Thanks,
 WSO2 API Manager Team


 --
 Mushthaq Rumy
 *Senior Software Engineer*
 Mobile : +94 (0) 779 492140
 Email : musht...@wso2.com
 WSO2, Inc.; http://wso2.com/
 lean . enterprise . middleware.

 
 ___
 Architecture mailing list
 architect...@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> Mushthaq Rumy
>> *Senior Software Engineer*
>> Mobile : +94 (0) 779 492140
>> Email : musht...@wso2.com
>> WSO2, Inc.; http://wso2.com/
>> lean . enterprise . middleware.
>>
>> 
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Regards,
Uvindra

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

Re: [Dev] Regarding the HTTP status code to be used if the response is invalid

[Uvindra Dias Jayasinha]

I think 422 is the most appropriate given your use case of validating if a
message matches a given schema. So you can receive a valid JSON or XML(it's
not malformed hence it is not a bad request(400)), but it may not match
with the message schema definition you are matching against.

The specs dont seem to talk about processing from the perspective of the
response. I guess you can use the same code used for the request.

On Wed, 9 Jan 2019 at 14:54, Shalki Wenushika  wrote:

> Hi all,
>
> This is related to the mail thread subjected as “[Architecture]API schema
> based request/response validator for Microgateway”. I’m validating
> requests/responses coming to the microgateway and send error messages to
> the client if the request/response is invalid.
>
> When a client sends a request to the microgateway if the request is
> invalid I’m sending an error message with the HTTP status code
> 422(Unprocessable entity) to the client. And also I’m doing the response
> validation. If the response coming from the backend is invalid I send an
> error message to the client. I need to know what will be the most
> appropriate HTTP status code to be included in the error if the response is
> invalid.
>
> Thank you!
>
> --
>
> *Shalki Wenushika*
> *Software Engineering Intern*
> WSO2  (University of Moratuwa)
> *mobile *: *+94 716792399* |   *email *:
> 
> wenush...@wso2.com
>
>
>
>

-- 
Regards,
Uvindra

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

Re: [Dev] Test fails due to NoClassDefFoundError: Could not initialize class

[Uvindra Dias Jayasinha]

Since this is a unit test you have no option but to use power mock in order
to mock the PrivilegedCarbonContext.endTenantFlow() static function using
PowerMockito.mockStatic. I think we must be doing this already, not sure
why the test is suddenly failing. We have done this in APIProviderImplTest.

If you dont want to use power mock you will need to refactor the original
code to prevent calling the static function directly.

On Mon, 7 Jan 2019 at 13:16, Ishara Cooray  wrote:

> Hi,
> I am running into below error [1] while using below code snippet.
>
>> AuthorizationGrantCacheEntry cacheEntry = 
>> AuthorizationGrantCache.getInstance().getValueFromCacheByToken(cacheKey);
>> if (cacheEntry == null) {
>> return new HashMap();
>> }
>> Map userAttributes = cacheEntry.getUserAttributes();
>> Map userClaims = new HashMap();
>> for (Map.Entry entry : userAttributes.entrySet()) {
>> userClaims.put(entry.getKey().getRemoteClaim().getClaimUri(), 
>> entry.getValue());
>> }
>>
>>
> Because It fails to access PrivilegedCarbonContext at
>
> * PrivilegedCarbonContext.endTenantFlow();*
> This looks to me a concurrency access issue. *Does anyone has an idea of
> fixing this without using powermock?*
> If i use power mock , *it also fails Prepare classes for test at *
> @PrepareForTest()
>
>  PrivilegedCarbonContext.endTenantFlow();
>
>
> public V getValueFromCache(K key) {
>> if (!isEnabled()) {
>> return null;
>> }
>>
>> if(key == null) {
>> return null;
>> }
>>
>> try {
>> PrivilegedCarbonContext.startTenantFlow();
>> PrivilegedCarbonContext carbonContext = PrivilegedCarbonContext
>> .getThreadLocalCarbonContext();
>> carbonContext.setTenantId(MultitenantConstants.SUPER_TENANT_ID);
>> 
>> carbonContext.setTenantDomain(MultitenantConstants.SUPER_TENANT_DOMAIN_NAME);
>> Cache cache = getBaseCache();
>> if (cache != null && cache.get(key) != null) {
>> return (V) cache.get(key);
>> }
>> return null;
>> } finally {
>> PrivilegedCarbonContext.endTenantFlow();
>> }
>> }
>>
>> Need to fix the test case without using powermock.
>
>
> [1]
> testAbstractJWTGenerator(org.wso2.carbon.apimgt.keymgt.token.TokenGenTest)
> Time elapsed: 0 sec  <<< ERROR!
> java.lang.NoClassDefFoundError: Could not initialize class
> org.wso2.carbon.context.PrivilegedCarbonContext
> at
> org.wso2.carbon.identity.application.common.cache.BaseCache.getValueFromCache(BaseCache.java:158)
> at
> org.wso2.carbon.identity.oauth.cache.AuthorizationGrantCache.getValueFromCacheByToken(AuthorizationGrantCache.java:86)
> at
> org.wso2.carbon.apimgt.keymgt.token.JWTGenerator.getClaimsFromCache(JWTGenerator.java:129)
> at
> org.wso2.carbon.apimgt.keymgt.token.JWTGenerator.populateCustomClaims(JWTGenerator.java:98)
> at
> org.wso2.carbon.apimgt.keymgt.token.AbstractJWTGenerator.buildBody(AbstractJWTGenerator.java:190)
> at
> org.wso2.carbon.apimgt.keymgt.token.AbstractJWTGenerator.generateToken(AbstractJWTGenerator.java:143)
> at
> org.wso2.carbon.apimgt.keymgt.token.TokenGenTest.testAbstractJWTGenerator(TokenGenTest.java:81)
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>


-- 
Regards,
Uvindra

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

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Uvindra Dias Jayasinha]

@Bhathiya Jayasekara 
yes, this is also an option. In reality though very few customers upload
lots of additional docs. We could just rename DOC_META_DATA table to DOCS
and store the docs in that table itself. So at the very minimum we have a
swagger and ballerina definition per an API stored in the RESOURCES table.

Can we make a call on this soon? Implementation is getting delayed because
of this.

On Mon, 22 Oct 2018 at 21:08, Bhathiya Jayasekara  wrote:

> This looks ok. Btw, I was wondering if it's a good idea to have all files
> (swaggers, wsdls, docs etc.) in a single table. Won't that make the table
> grow faster and make querying slower? How about keeping a separate table
> for this? Then we can have a foreign key as well.
>
> Thanks,
> Bhathiya
>
> On Mon, Oct 22, 2018 at 2:57 PM Uvindra Dias Jayasinha 
> wrote:
>
>> +1, CONTENT  is fine
>>
>> On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy  wrote:
>>
>>> Hi Uvindra,
>>>
>>> Please find the data types below
>>>
>>> *AM_API_DOC_META_DATA*
>>> API_ID (This will be a foreign key referred to AM_API table) VARCHAR(255)
>>> RESOURCE_ID VARCHAR(255)
>>> DOC_CONTENT VARCHAR(1024)
>>>
>>> *AM_API_RESOURCES*
>>> RESOURCE_NAME VARCHAR(255)
>>>
>>> And I think we can change it DOC_CONTENT to CONTENT .
>>> WDYT?
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>> On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha 
>>> wrote:
>>>
>>>> HI Mushtaq,
>>>>
>>>> Can you provide the data types of the columns so that this is more
>>>> clear? I believe that DOC_CONTENT should be a VARCHAR, in that case better
>>>> to call it something like SHORT_CONTENT, since this communicates that it is
>>>> meant to share relatively short text values such as URL and inline text.
>>>> The name DOC_CONTENT is misleading and might suggest we can store larger
>>>> documents in this column.
>>>>
>>>> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> We had an internal discussion and decided to do some modifications in
>>>>> the DB Schema related to API Docs (AM_API_RESOURCES and
>>>>> AM_API_DOC_META_DATA). We will be removing the foreign key constraint 
>>>>> added
>>>>> to the  AM_API_DOC_META_DATA table as it it has a primary key referred to
>>>>> the primary key of AM_API_RESOURCES which is not a good practice.
>>>>>
>>>>> And the following columns will be added to the respective tables.
>>>>>
>>>>> *AM_API_DOC_META_DATA*
>>>>> API_ID (This will be a foreign key referred to AM_API table)
>>>>> RESOURCE_ID
>>>>> DOC_CONTENT
>>>>>
>>>>> *AM_API_RESOURCES*
>>>>> RESOURCE_NAME
>>>>>
>>>>> So the content of INLINE and URL of API documents will be saved in 
>>>>> *AM_API_DOC_META_DATA
>>>>> (*DOC_CONTENT column*) *and content of FILE of API documents will be
>>>>> saved in *AM_API_RESOURCES *which will have a reference in 
>>>>> *AM_API_DOC_META_DATA
>>>>> (*RESOURCE_ID column*)*.
>>>>>
>>>>> Thanks & Regards,
>>>>> Mushthaq
>>>>>
>>>>>
>>>>> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
>>>>>> uvin...@wso2.com> wrote:
>>>>>>
>>>>>>> Here is my take on this. When I originally designed the schema I
>>>>>>> wasn't taking into consideration any of the practical implications
>>>>>>> associated with API resources being saved and retrieved at DB level. But
>>>>>>> now that we are at implementation stage some of these implications are 
>>>>>>> much
>>>>>>> more clearer now.
>>>>>>>
>>>>>>> The AM_API_RESOURCES is a generic API resource table(For storing all
>>>>>>> file based resources associated with APIs). It will be storing the 
>>>>>>> Swagger
>>>>>>> file, Ballerina file and documentation associated with the API.
>>>>>>>
>>>>>>> The A

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Uvindra Dias Jayasinha]

+1, CONTENT  is fine

On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy  wrote:

> Hi Uvindra,
>
> Please find the data types below
>
> *AM_API_DOC_META_DATA*
> API_ID (This will be a foreign key referred to AM_API table) VARCHAR(255)
> RESOURCE_ID VARCHAR(255)
> DOC_CONTENT VARCHAR(1024)
>
> *AM_API_RESOURCES*
> RESOURCE_NAME VARCHAR(255)
>
> And I think we can change it DOC_CONTENT to CONTENT .
> WDYT?
>
> Thanks & Regards,
> Mushthaq
>
> On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha 
> wrote:
>
>> HI Mushtaq,
>>
>> Can you provide the data types of the columns so that this is more clear?
>> I believe that DOC_CONTENT should be a VARCHAR, in that case better to call
>> it something like SHORT_CONTENT, since this communicates that it is meant
>> to share relatively short text values such as URL and inline text. The name
>> DOC_CONTENT is misleading and might suggest we can store larger documents
>> in this column.
>>
>> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:
>>
>>> Hi All,
>>>
>>> We had an internal discussion and decided to do some modifications in
>>> the DB Schema related to API Docs (AM_API_RESOURCES and
>>> AM_API_DOC_META_DATA). We will be removing the foreign key constraint added
>>> to the  AM_API_DOC_META_DATA table as it it has a primary key referred to
>>> the primary key of AM_API_RESOURCES which is not a good practice.
>>>
>>> And the following columns will be added to the respective tables.
>>>
>>> *AM_API_DOC_META_DATA*
>>> API_ID (This will be a foreign key referred to AM_API table)
>>> RESOURCE_ID
>>> DOC_CONTENT
>>>
>>> *AM_API_RESOURCES*
>>> RESOURCE_NAME
>>>
>>> So the content of INLINE and URL of API documents will be saved in 
>>> *AM_API_DOC_META_DATA
>>> (*DOC_CONTENT column*) *and content of FILE of API documents will be
>>> saved in *AM_API_RESOURCES *which will have a reference in 
>>> *AM_API_DOC_META_DATA
>>> (*RESOURCE_ID column*)*.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>>
>>> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara  wrote:
>>>
>>>>
>>>>
>>>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
>>>> uvin...@wso2.com> wrote:
>>>>
>>>>> Here is my take on this. When I originally designed the schema I
>>>>> wasn't taking into consideration any of the practical implications
>>>>> associated with API resources being saved and retrieved at DB level. But
>>>>> now that we are at implementation stage some of these implications are 
>>>>> much
>>>>> more clearer now.
>>>>>
>>>>> The AM_API_RESOURCES is a generic API resource table(For storing all
>>>>> file based resources associated with APIs). It will be storing the Swagger
>>>>> file, Ballerina file and documentation associated with the API.
>>>>>
>>>>> The AM_API_DOC_META_DATA table is specialized to store additional meta
>>>>> data only associated with documentation.
>>>>>
>>>>> Practically we need to do two calls for document uploads and adding
>>>>> meta data because we are dealing with two different content
>>>>> types(application/json for meta data and multipart/form-data for the 
>>>>> file).
>>>>>
>>>>> All files have a name associated with them so it makes sense to have
>>>>> the file name in the AM_API_RESOURCES table. I don't think its a good idea
>>>>> to have a NULL value in a column that we are going to update later, this
>>>>> could lead to all kinds of complications that we will need to handle at
>>>>> code level. So its better to have the file name in AM_API_RESOURCES where
>>>>> we can ensure that we always have a valid name at the time of upload. It 
>>>>> is
>>>>> also very easy for us to enforce that a file name for a given type does 
>>>>> not
>>>>> get duplicated with a table level constraint if we go with this option.
>>>>>
>>>>> Joining between two tables like this in case we need to get the file
>>>>> name is trivial so I don't think we should let that affect us coming up
>>>>> with the best possible solution.
>>>>>
>>>> +1 it's a not good practice to add record which will upda

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Uvindra Dias Jayasinha]

HI Mushtaq,

Can you provide the data types of the columns so that this is more clear? I
believe that DOC_CONTENT should be a VARCHAR, in that case better to call
it something like SHORT_CONTENT, since this communicates that it is meant
to share relatively short text values such as URL and inline text. The name
DOC_CONTENT is misleading and might suggest we can store larger documents
in this column.

On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:

> Hi All,
>
> We had an internal discussion and decided to do some modifications in the
> DB Schema related to API Docs (AM_API_RESOURCES and AM_API_DOC_META_DATA).
> We will be removing the foreign key constraint added to the
> AM_API_DOC_META_DATA table as it it has a primary key referred to the
> primary key of AM_API_RESOURCES which is not a good practice.
>
> And the following columns will be added to the respective tables.
>
> *AM_API_DOC_META_DATA*
> API_ID (This will be a foreign key referred to AM_API table)
> RESOURCE_ID
> DOC_CONTENT
>
> *AM_API_RESOURCES*
> RESOURCE_NAME
>
> So the content of INLINE and URL of API documents will be saved in 
> *AM_API_DOC_META_DATA
> (*DOC_CONTENT column*) *and content of FILE of API documents will be
> saved in *AM_API_RESOURCES *which will have a reference in 
> *AM_API_DOC_META_DATA
> (*RESOURCE_ID column*)*.
>
> Thanks & Regards,
> Mushthaq
>
>
> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara  wrote:
>
>>
>>
>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha 
>> wrote:
>>
>>> Here is my take on this. When I originally designed the schema I wasn't
>>> taking into consideration any of the practical implications associated with
>>> API resources being saved and retrieved at DB level. But now that we are at
>>> implementation stage some of these implications are much more clearer now.
>>>
>>> The AM_API_RESOURCES is a generic API resource table(For storing all
>>> file based resources associated with APIs). It will be storing the Swagger
>>> file, Ballerina file and documentation associated with the API.
>>>
>>> The AM_API_DOC_META_DATA table is specialized to store additional meta
>>> data only associated with documentation.
>>>
>>> Practically we need to do two calls for document uploads and adding meta
>>> data because we are dealing with two different content
>>> types(application/json for meta data and multipart/form-data for the file).
>>>
>>> All files have a name associated with them so it makes sense to have the
>>> file name in the AM_API_RESOURCES table. I don't think its a good idea to
>>> have a NULL value in a column that we are going to update later, this could
>>> lead to all kinds of complications that we will need to handle at code
>>> level. So its better to have the file name in AM_API_RESOURCES where we can
>>> ensure that we always have a valid name at the time of upload. It is also
>>> very easy for us to enforce that a file name for a given type does not get
>>> duplicated with a table level constraint if we go with this option.
>>>
>>> Joining between two tables like this in case we need to get the file
>>> name is trivial so I don't think we should let that affect us coming up
>>> with the best possible solution.
>>>
>> +1 it's a not good practice to add record which will update from null to
>> some value cause of update going for another table.
>>
>>>
>>> So Im +1 for option 2. WDYT?
>>>
>>> On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy  wrote:
>>>
>>>> Adding @dev-wso2 
>>>>
>>>> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias  wrote:
>>>>
>>>>> Please discuss technical problems externally.
>>>>>
>>>>> On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy 
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> While I was implementing the view page for API document (File) I came
>>>>>> across an issue where we get the file name as null when using the
>>>>>> micro-service to get the content of the the API document.
>>>>>> While analyzing, when adding a file as an API document, I found out
>>>>>> that first we save only the doc metadata  and then we save the file 
>>>>>> content
>>>>>> using a second call.
>>>>>>
>>>>>> After analyzing the DB scripts I figured out that the fileName is
>>>>>> stored in AM_API_DOC_META_DATA tabl

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Uvindra Dias Jayasinha]

Here is my take on this. When I originally designed the schema I wasn't
taking into consideration any of the practical implications associated with
API resources being saved and retrieved at DB level. But now that we are at
implementation stage some of these implications are much more clearer now.

The AM_API_RESOURCES is a generic API resource table(For storing all file
based resources associated with APIs). It will be storing the Swagger file,
Ballerina file and documentation associated with the API.

The AM_API_DOC_META_DATA table is specialized to store additional meta data
only associated with documentation.

Practically we need to do two calls for document uploads and adding meta
data because we are dealing with two different content
types(application/json for meta data and multipart/form-data for the file).

All files have a name associated with them so it makes sense to have the
file name in the AM_API_RESOURCES table. I don't think its a good idea to
have a NULL value in a column that we are going to update later, this could
lead to all kinds of complications that we will need to handle at code
level. So its better to have the file name in AM_API_RESOURCES where we can
ensure that we always have a valid name at the time of upload. It is also
very easy for us to enforce that a file name for a given type does not get
duplicated with a table level constraint if we go with this option.

Joining between two tables like this in case we need to get the file name
is trivial so I don't think we should let that affect us coming up with the
best possible solution.

So Im +1 for option 2. WDYT?

On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy  wrote:

> Adding @dev-wso2 
>
> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias  wrote:
>
>> Please discuss technical problems externally.
>>
>> On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy  wrote:
>>
>>> Hi All,
>>>
>>> While I was implementing the view page for API document (File) I came
>>> across an issue where we get the file name as null when using the
>>> micro-service to get the content of the the API document.
>>> While analyzing, when adding a file as an API document, I found out that
>>> first we save only the doc metadata  and then we save the file content
>>> using a second call.
>>>
>>> After analyzing the DB scripts I figured out that the fileName is stored
>>> in AM_API_DOC_META_DATA table and the content is stored in
>>> AM_API_RESOURCES. So during the first call we do not have the file name and
>>> it is saved as null. During the second call the fileName is passed to the
>>> micro-service but it is not stored anywhere. Hence, the fileName is null
>>> when we get the content of the file. So to solve this issue, I thought of
>>> two solutions.
>>>
>>> 1. During the second call while adding a file document for API as we get
>>> the FileName to the micro-service we can retrieve the document metadata
>>> using the documentId and update the fileName apart from saving the content.
>>> Hence, it will be available when retrieving the content.
>>>
>>> 2. We can change the fileName field from AM_API_DOC_META_DATA to
>>> AM_API_RESOURCES as the content of the document is stored in this table.
>>> And while saving the content we can save it with the fileName. Hence, it
>>> will be available when retrieving the content.
>>>
>>> IMO as option 1 will have more DB calls, option 2 would be the preferred
>>> solution.
>>>
>>> Appreciate your valuable inputs.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>> --
>>> Mushthaq Rumy
>>> *Senior Software Engineer*
>>> Mobile : +94 (0) 779 492140
>>> Email : musht...@wso2.com
>>> WSO2, Inc.; http://wso2.com/
>>> lean . enterprise . middleware.
>>>
>>> 
>>>
>>
>>
>> --
>> *Nuwan Dias* | Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> [image: Signature.jpg]
>>
>
>
> --
> Mushthaq Rumy
> *Senior Software Engineer*
> Mobile : +94 (0) 779 492140
> Email : musht...@wso2.com
> WSO2, Inc.; http://wso2.com/
> lean . enterprise . middleware.
>
> 
>


-- 
Regards,
Uvindra

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

Re: [Dev] [APIM 2.6.0 to 3.0.0 Migration] Error handling in CLI tool

[Uvindra Dias Jayasinha]

I think the method currently used by the tool(log and handle at source of
issue) is fine. We don't gain anything by throwing this up to another level
and handling it there, it will just complicate the code. This style
currently used by the CLI tool is adequate since it is not a server that
needs to run continuously but a client application that should exist when
an error is encountered.

In our Java code that runs on the server, having the stack trace helps the
engineer to find the execution flow, but this makes no sense for a client
side CLI tool.

There is no such thing as a standard approach, only the approach that is
most suited for the application, which is different depending on the
application.

On 13 September 2018 at 11:37, Samitha Chathuranga  wrote:

> Hi,
>
> WSO2 APIM Import Export CLI tool (written in GO Lang) is to be modified to
> support exporting all the artifacts from 2.6.0 environment as bulks, for
> 3.0.0 migration process. There is a concern in how error handling should be
> implemented.
>
> Should it be in a way that all the errors are caught and thrown to the
> top-most level where we log the error messages, print error traces; which
> is the normal standard approach?
>
> Currently normal Import export tool uses below different approach to
> handle errors.
>
> *[pseudo code]* :
> if (error object is not nil or if some other boolean condition is false) {
> print some logs
> call HandleErrorAndExit(errorMessage, errorObject) function
> }
>
> For example [1] in ExecutePreCommandWithBasicAuth() function in
> import-export-cli/utils/tokenManagement.go ;
>
> if flagUsername != "" {
>// flagUsername is not blank
>if flagUsername != username {
>   // username entered with flag -u is not the same as username found
>   // in env_keys_all.yaml file
>   fmt.Println("Username entered with flag -u for the environment '" +
>  environment + "' is not the same as username found in file '" + 
> EnvKeysAllFilePath + "'")
>   fmt.Println("Execute '" + ProjectName + " reset-user -e " + environment 
> + "' to clear user data")
>   *HandleErrorAndExit*("Username mismatch", nil)
>} else {
>
> This function is called in import-api.go and export-api.go. For instance 
> whenever an export-api command is given, this
> ExecutePreCommandWithBasicAuth method is called, going through apiExport.go 
> and root.go and this tokenManagement.go files.
>
> But if an error occurred in a function in tokenManagement.go, error is 
> handled in that place itself (log error message/traces and
> exit the program), by calling HandleErrorAndExit(..). HandleErrorAndExit(..)  
> method logs the error messages/traces and exit the program.
> This is how errors are handled currently in the tool. AFAIU this approach is 
> followed as this is a CLI tool, which is
> directly used by the users.
>
> I am suggesting to do this in the standard approach of throwing the errors to 
> the top-most level and handling there when the tool
> is modified for the 3.0.0 migration support. It will facilitate user to get 
> to know of the complete error-occurrence flow.
>
> WDYT?
>
> [1] https://github.com/wso2/product-apim-tooling/blob/
> 30f4677cb8eb35fb09a8e7fa854a07fae8e1864c/import-export-cli/
> utils/tokenManagement.go#L155-L161
>
> --
> *Samitha Chathuranga*
> *Senior Software Engineer*, *WSO2 Inc.*
> lean.enterprise.middleware
> Mobile: +94715123761
>
> [image: http://wso2.com/signature] 
>



-- 
Regards,
Uvindra

Mobile: 33962
___
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?

[Uvindra Dias Jayasinha]

If someone tries to create a new API via REST API specifying a tier that
does not exist we should simply reject the creation of that API. We need to
validate that the specified tiers are valid in the API creation request

On 1 February 2018 at 12:41, Irham Iqbal  wrote:

> I have added an additional parameter to pass the api level throttling
> policy, so if that parameter has a value it will be saved in to the AM_API
> table so the throttling policy will be API level other wise that column
> will be null so it will be per resource policy.
>
> My question is, what if a request has a value for the above parameter
> which is not valid. As an example, if a value ABC has received and we
> don't have a policy with that name in our DB. In that case do we need to
> set the policy as "Unlimited" or null in the DB. Setting null will make
> the API as resource level policy.
>
>
> On Tue, Jan 30, 2018 at 10:48 AM, Anuruddha Liyanarachchi <
> anurudd...@wso2.com> wrote:
>
>> [+ 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",
>>> 

Re: [Dev] Did we thought about APIM 3.0.0 Audit log?

[Uvindra Dias Jayasinha]

There is a JIRA[1] for this that I moved to github


[1] https://wso2.org/jira/browse/APIMANAGER-5802

On 30 August 2017 at 11:07, Rukshan Premathunga  wrote:

> Hi all,
>
> In c4 we had separate log file to audit API and application related stuff.
> Is this already done in AM 3?
>
> Thanks and Regards
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
> +94711822074 <+94%2071%20182%202074>
>



-- 
Regards,
Uvindra

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

Re: [Dev] [APIM][C5] Splitting "Generate Keys" operation in Store REST API

[Uvindra Dias Jayasinha]

+1

On 20 June 2017 at 14:47, Bhathiya Jayasekara  wrote:

> Hi all,
>
> In the current implementation of store REST API, we have a single
> operation (aka. Generate Keys) to create OAuth application and generate
> access tokens, which requires 2 calls to key manager. IMO, if we split this
> operation into 2, the code becomes cleaner. On the other hand, the current
> implementation makes the code of out of band client registation[1] a bit
> complex as we don't have a way to only generate access tokens after
> providing keys explicitly.
>
> so, to make the code cleaner, I'm suggesting to split this "Generate Keys"
> operation into 2 as,
>
> 1) Create OAuth application (i.e. generate consumer key/secret)
> 2) Generate access tokens.
>
> If we do this, in the case of out-of-band client provisioning we can
> simply replace step 1 with "Provide Keys" call.
>
> In UI, there will be 2 buttons as "Generate Keys/Provide Keys" which
> generates or allows to add consumer key/secret, and "Generate Access Token"
> which generates application access token.
>
> Please let me know if you have any concerns about this.
>
> [1] https://docs.wso2.com/display/AM210/Provisioning+Out-of-
> Band+OAuth+Clients
>
> Thanks,
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>



-- 
Regards,
Uvindra

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

Re: [Dev] [C5] How to configure Data source configuration

[Uvindra Dias Jayasinha]

C5 uses HikariCP[1] in the carbon-datasources[2] implementation which is
dependent on a separate *-datasources.xml file to read configurations.

The problem Ishara has highlighted is the need for having separate
databases per a tenant. Due to this we cannot hard code the database name
in the datasources.xml. So a docker container needs be able to read
information such as the database name, user name, password via environment
variables and use these to update the datasources.xml before the product is
started.

Is there an alternative to the above approach?


[1]https://github.com/brettwooldridge/HikariCP
[2]https://github.com/wso2/carbon-datasources

On 4 April 2017 at 12:42, Ishara Cooray  wrote:

> Hi,
>
> In the current architecture, we use master-datasources.xml to configure
> data sources.
>
> But, with C5 effort we will need to dynamically load data source name to
> support multi tenancy. Since each tenant will have it's own data source.
>
> How are we going to support this?
> Can we configure the data source in deployment.yaml to read data source
> name from an environment variable?
>
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] [DEV][APIM][C5] - Caching requirement for OAuth2 protected microservices

[Uvindra Dias Jayasinha]

Its great if we can have some feedback about this, active C5 development
needs this moving forward.

@Azeez and @Kishanthan, do we have any preferences?

On 24 February 2017 at 13:12, Sagara Gunathunga <sag...@wso2.com> wrote:

>
>
>
>
>
> On Fri, Feb 24, 2017 at 7:28 AM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> This will function like any of the local container classes we
>> use(example: HashMap). I think its fine to use one of the available
>> implementations(such as Guava since we already have it as a dependency) for
>> this. Testing will reveal its suitability but I don't anticipate any issues
>> since this is not as complicated as a distributed cache.
>>
>
> It's ok to pick one of the local cache implementations but make sure you
> discuss with others without limiting to your own use case and pick a good
> one so that others can use the same for their local caching requirements,
> it's really ugly to use several local caching F/W across the platform other
> than really exceptional cases.
>
> Thanks !
>
>>
>> On 16 February 2017 at 22:45, Maduranga Siriwardena <madura...@wso2.com>
>> wrote:
>>
>>> Hi Rajith,
>>>
>>> I think this is a generic requirement for all the C5 based products
>>> rather than for this specific use case. So we need to come up with a
>>> solution that can be used across the platform.
>>>
>>> Thanks,
>>>
>>> On Thu, Feb 16, 2017 at 12:37 AM, Rajith Roshan <raji...@wso2.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> In C5 API Manager  back end REST APIs (micro services) are protected
>>>> using oauth2 token. Every time request comes to micro services, interceptor
>>>> will validate the access token sent in the authorization header of the
>>>> request. In order to validate the token we need to do a introspection call
>>>> to the key manager.  We can not do this introspection call to the key
>>>> manager for each and every request. We need a caching layer at the
>>>> interceptor level in order to cache the access tokens.
>>>>
>>>> We are going to use local cache with small cache timeout periods for
>>>> this. What are the best caching systems we can use for this.
>>>> We can use either JCache (javax.cache), google guava cache[1] which are
>>>> specially used as local caches. "Memcached" [2] is also another option but
>>>> mostly used in distributed systems.
>>>>
>>>> [1] - https://github.com/google/guava/wiki/CachesExplained
>>>> [2] - https://memcached.org/
>>>> --
>>>> Rajith Roshan
>>>> Software Engineer, WSO2 Inc.
>>>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>>>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Maduranga Siriwardena
>>> Software Engineer
>>> WSO2 Inc; http://wso2.com/
>>>
>>> Email: madura...@wso2.com
>>> Mobile: +94718990591 <+94%2071%20899%200591>
>>> Blog: http://madurangasblogs.blogspot.com/
>>> <http://wso2.com/signature>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Sagara Gunathunga
>
> Associate Director / Architect; WSO2, Inc.;  http://wso2.com
> V.P Apache Web Services;http://ws.apache.org/
> Linkedin; http://www.linkedin.com/in/ssagara
> Blog ;  http://ssagara.blogspot.com
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] [DEV][APIM][C5] - Caching requirement for OAuth2 protected microservices

[Uvindra Dias Jayasinha]

This will function like any of the local container classes we use(example:
HashMap). I think its fine to use one of the available implementations(such
as Guava since we already have it as a dependency) for this. Testing will
reveal its suitability but I don't anticipate any issues since this is not
as complicated as a distributed cache.

On 16 February 2017 at 22:45, Maduranga Siriwardena 
wrote:

> Hi Rajith,
>
> I think this is a generic requirement for all the C5 based products rather
> than for this specific use case. So we need to come up with a solution that
> can be used across the platform.
>
> Thanks,
>
> On Thu, Feb 16, 2017 at 12:37 AM, Rajith Roshan  wrote:
>
>> Hi all,
>>
>> In C5 API Manager  back end REST APIs (micro services) are protected
>> using oauth2 token. Every time request comes to micro services, interceptor
>> will validate the access token sent in the authorization header of the
>> request. In order to validate the token we need to do a introspection call
>> to the key manager.  We can not do this introspection call to the key
>> manager for each and every request. We need a caching layer at the
>> interceptor level in order to cache the access tokens.
>>
>> We are going to use local cache with small cache timeout periods for
>> this. What are the best caching systems we can use for this.
>> We can use either JCache (javax.cache), google guava cache[1] which are
>> specially used as local caches. "Memcached" [2] is also another option but
>> mostly used in distributed systems.
>>
>> [1] - https://github.com/google/guava/wiki/CachesExplained
>> [2] - https://memcached.org/
>> --
>> Rajith Roshan
>> Software Engineer, WSO2 Inc.
>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Maduranga Siriwardena
> Software Engineer
> WSO2 Inc; http://wso2.com/
>
> Email: madura...@wso2.com
> Mobile: +94718990591 <+94%2071%20899%200591>
> Blog: http://madurangasblogs.blogspot.com/
> 
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

On 10 January 2017 at 11:10, Akalanka Pagoda Arachchi <darsha...@wso2.com>
wrote:

> Replacing an empty string with a space is generally a bad practice in
> database perspective due to few reasons.
>
> 1. Issues with visibility (a DBA cannot tell the difference by directly
> looking at it)
> 2. As Madhawa pointed out, space is a different character and when we
> really want to represent a space in the column and differentiate between
> the empty and the space, it will be impossible.
> 3. Adds processing complexity
>
> The suggestion to use a space for empty strings is actually to denote an
> empty string by a special character since empty string is not supported in
> Oracle. Therefore instead of using a meaningless space character which
> introduces more complexity why not use a special string such as NULL or
> EMPTY?
>

These are good points, but by using a special string to represent an empty
string we don't avoid complexity to the code because we need to check the
value of what has been read from the DB and explicitly replace that with an
empty string before sending back to the client. This logic also breaks if
the user by chance sends that special string explicitly.

We have not found an elegant way of doing this that balances all sides. Its
a pity Oracle deviates from the standard practice of other DBs in this
regard.


>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 11:01 AM, Madhawa Gunasekara <madha...@wso2.com>
> wrote:
>
>> So what will happen if the user sends a space? So It's better to add a
>> configuration to avoid these situations. then user can handle this. WDYT ?
>>
>> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> To be more precise, if a user explicitly sends "" then we will set the
>>> value to space, enabling us to convert back to "".
>>>
>>> But if the field is not set(ignored by the user) then the default NULL
>>> will be saved. This will make things consistant across all DB's.
>>>
>>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha <uvin...@wso2.com>
>>> wrote:
>>>
>>>> Note that there is a clear break in the UX of the REST API if we allow
>>>> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
>>>> "" as NULL but this is incorrect in the REST/JSON world.
>>>>
>>>> If a user enters an empty string "" they will expect to get "" back,
>>>> which will not happen with Oracles default behaviour. Therefore in order to
>>>> keep consistency of the REST API I dont see an alternative other than
>>>> having space as the default value. We can get rid of the space when
>>>> returning by simply trimming the String so we don't need to have any
>>>> special filtering logic.
>>>>
>>>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
>>>> darsha...@wso2.com> wrote:
>>>>
>>>>> +1 to keep default as NULL instead of a space.
>>>>>
>>>>> Having a space will require adding trimming logic to the underlying
>>>>> code and methods like 'isNullOrEmpty' will bypass this string if there's a
>>>>> space.
>>>>>
>>>>> Thanks,
>>>>> Akalanka.
>>>>>
>>>>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray <lahi...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa <isu...@wso2.com>
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>>>>>>> uvin...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Setting a default value for empty fields being sent seems to be
>>>>>>>> best.
>>>>>>>>
>>>>>>>> Furthermore we can have default values set in our DTO objects in
>>>>>>>> case a given field is omitted altogether.
>>>>>>>>
>>>>>>>> So handling both the above scenarios can overcome the limitation in
>>>>>>>> Oracle.
>>>>>>>>
>>>>>>>> But I dont know if this is good for the REST API user experience,
>>>>>>>> when retrieving data that contains these default values.
>>>>&

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

This did come up in discussion. Functionally speaking a space is no
different to an empty String, though technically they are different. So it
will be a trade off to ignore explicitly sent spaces by users.

On 10 January 2017 at 11:01, Madhawa Gunasekara <madha...@wso2.com> wrote:

> So what will happen if the user sends a space? So It's better to add a
> configuration to avoid these situations. then user can handle this. WDYT ?
>
> On Tue, Jan 10, 2017 at 10:54 AM, Uvindra Dias Jayasinha <uvin...@wso2.com
> > wrote:
>
>> To be more precise, if a user explicitly sends "" then we will set the
>> value to space, enabling us to convert back to "".
>>
>> But if the field is not set(ignored by the user) then the default NULL
>> will be saved. This will make things consistant across all DB's.
>>
>> On 10 January 2017 at 10:41, Uvindra Dias Jayasinha <uvin...@wso2.com>
>> wrote:
>>
>>> Note that there is a clear break in the UX of the REST API if we allow
>>> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
>>> "" as NULL but this is incorrect in the REST/JSON world.
>>>
>>> If a user enters an empty string "" they will expect to get "" back,
>>> which will not happen with Oracles default behaviour. Therefore in order to
>>> keep consistency of the REST API I dont see an alternative other than
>>> having space as the default value. We can get rid of the space when
>>> returning by simply trimming the String so we don't need to have any
>>> special filtering logic.
>>>
>>> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <
>>> darsha...@wso2.com> wrote:
>>>
>>>> +1 to keep default as NULL instead of a space.
>>>>
>>>> Having a space will require adding trimming logic to the underlying
>>>> code and methods like 'isNullOrEmpty' will bypass this string if there's a
>>>> space.
>>>>
>>>> Thanks,
>>>> Akalanka.
>>>>
>>>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray <lahi...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa <isu...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>>>>>> uvin...@wso2.com> wrote:
>>>>>>
>>>>>>> Setting a default value for empty fields being sent seems to be best.
>>>>>>>
>>>>>>> Furthermore we can have default values set in our DTO objects in
>>>>>>> case a given field is omitted altogether.
>>>>>>>
>>>>>>> So handling both the above scenarios can overcome the limitation in
>>>>>>> Oracle.
>>>>>>>
>>>>>>> But I dont know if this is good for the REST API user experience,
>>>>>>> when retrieving data that contains these default values.
>>>>>>>
>>>>>> Additionally this could affect the user experience in UIs as well.
>>>>>>
>>>>>> How about we just keep a default value to NULL in DB level and then
>>>>>> filter it from UI? Since anyway Oracle treats zero length String as 
>>>>>> NULLs,
>>>>>> even if the user enters an empty String it will then be automatically. 
>>>>>> The
>>>>>> rest API will still return the default value if invoked directly though.
>>>>>>
>>>>>
>>>>> +1 to keep default as NULL which is more natural
>>>>> Further rather than filtering in the UI, how about directly do it in
>>>>> the query itself using COALESCE() built-in function (which is an ANSI
>>>>> standard and better performing than IS NULL)
>>>>>
>>>>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field
>>>>> value is null it will map to empty
>>>>>
>>>>>
>>>>>
>>>>>>> On 6 January 2017 at 15:28, Tharindu Dharmarathna <
>>>>>>> tharin...@wso2.com> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
>>>>>>>> th

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

To be more precise, if a user explicitly sends "" then we will set the
value to space, enabling us to convert back to "".

But if the field is not set(ignored by the user) then the default NULL will
be saved. This will make things consistant across all DB's.

On 10 January 2017 at 10:41, Uvindra Dias Jayasinha <uvin...@wso2.com>
wrote:

> Note that there is a clear break in the UX of the REST API if we allow
> pass empty strings to Oracle(due to the conversion to NULL). Oracle treats
> "" as NULL but this is incorrect in the REST/JSON world.
>
> If a user enters an empty string "" they will expect to get "" back, which
> will not happen with Oracles default behaviour. Therefore in order to keep
> consistency of the REST API I dont see an alternative other than having
> space as the default value. We can get rid of the space when returning by
> simply trimming the String so we don't need to have any special filtering
> logic.
>
> On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <darsha...@wso2.com>
> wrote:
>
>> +1 to keep default as NULL instead of a space.
>>
>> Having a space will require adding trimming logic to the underlying code
>> and methods like 'isNullOrEmpty' will bypass this string if there's a space.
>>
>> Thanks,
>> Akalanka.
>>
>> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray <lahi...@wso2.com> wrote:
>>
>>>
>>>
>>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa <isu...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <
>>>> uvin...@wso2.com> wrote:
>>>>
>>>>> Setting a default value for empty fields being sent seems to be best.
>>>>>
>>>>> Furthermore we can have default values set in our DTO objects in case
>>>>> a given field is omitted altogether.
>>>>>
>>>>> So handling both the above scenarios can overcome the limitation in
>>>>> Oracle.
>>>>>
>>>>> But I dont know if this is good for the REST API user experience, when
>>>>> retrieving data that contains these default values.
>>>>>
>>>> Additionally this could affect the user experience in UIs as well.
>>>>
>>>> How about we just keep a default value to NULL in DB level and then
>>>> filter it from UI? Since anyway Oracle treats zero length String as NULLs,
>>>> even if the user enters an empty String it will then be automatically. The
>>>> rest API will still return the default value if invoked directly though.
>>>>
>>>
>>> +1 to keep default as NULL which is more natural
>>> Further rather than filtering in the UI, how about directly do it in the
>>> query itself using COALESCE() built-in function (which is an ANSI standard
>>> and better performing than IS NULL)
>>>
>>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field value
>>> is null it will map to empty
>>>
>>>
>>>
>>>>> On 6 January 2017 at 15:28, Tharindu Dharmarathna <tharin...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
>>>>>> tharin...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> I faced $Subject in Oracle database while running integration test
>>>>>>> on C5 on top.
>>>>>>>
>>>>>>> *Observation*
>>>>>>>
>>>>>>> when insert empty string ("") it was save as null in database.
>>>>>>>
>>>>>>> While going through SO I had found [1] , which did happen in oracle
>>>>>>> database.
>>>>>>>
>>>>>>>
>>>>>>> We have come up with several ways to handle empty strings which user
>>>>>>> sends through the rest api.
>>>>>>>
>>>>>>> 1.  Validate the request and send error when giving empty strings
>>>>>>> 2.  Set default value like "N/A" into the fields which send as
>>>>>>> empty.
>>>>>>>
>>>>>>> Is there any other way to handle this problem ?.
>>>>>>>
>>>>>>> [1] - http://stackoverfl

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

Note that there is a clear break in the UX of the REST API if we allow pass
empty strings to Oracle(due to the conversion to NULL). Oracle treats "" as
NULL but this is incorrect in the REST/JSON world.

If a user enters an empty string "" they will expect to get "" back, which
will not happen with Oracles default behaviour. Therefore in order to keep
consistency of the REST API I dont see an alternative other than having
space as the default value. We can get rid of the space when returning by
simply trimming the String so we don't need to have any special filtering
logic.

On 10 January 2017 at 10:34, Akalanka Pagoda Arachchi <darsha...@wso2.com>
wrote:

> +1 to keep default as NULL instead of a space.
>
> Having a space will require adding trimming logic to the underlying code
> and methods like 'isNullOrEmpty' will bypass this string if there's a space.
>
> Thanks,
> Akalanka.
>
> On Tue, Jan 10, 2017 at 10:23 AM, Lahiru Cooray <lahi...@wso2.com> wrote:
>
>>
>>
>> On Mon, Jan 9, 2017 at 7:54 AM, Isuru Haththotuwa <isu...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 5:19 PM, Uvindra Dias Jayasinha <uvin...@wso2.com
>>> > wrote:
>>>
>>>> Setting a default value for empty fields being sent seems to be best.
>>>>
>>>> Furthermore we can have default values set in our DTO objects in case a
>>>> given field is omitted altogether.
>>>>
>>>> So handling both the above scenarios can overcome the limitation in
>>>> Oracle.
>>>>
>>>> But I dont know if this is good for the REST API user experience, when
>>>> retrieving data that contains these default values.
>>>>
>>> Additionally this could affect the user experience in UIs as well.
>>>
>>> How about we just keep a default value to NULL in DB level and then
>>> filter it from UI? Since anyway Oracle treats zero length String as NULLs,
>>> even if the user enters an empty String it will then be automatically. The
>>> rest API will still return the default value if invoked directly though.
>>>
>>
>> +1 to keep default as NULL which is more natural
>> Further rather than filtering in the UI, how about directly do it in the
>> query itself using COALESCE() built-in function (which is an ANSI standard
>> and better performing than IS NULL)
>>
>> eg: SELECT COALESCE(field_name,'')  as field_name  //if the field value
>> is null it will map to empty
>>
>>
>>
>>>> On 6 January 2017 at 15:28, Tharindu Dharmarathna <tharin...@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna <
>>>>> tharin...@wso2.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> I faced $Subject in Oracle database while running integration test on
>>>>>> C5 on top.
>>>>>>
>>>>>> *Observation*
>>>>>>
>>>>>> when insert empty string ("") it was save as null in database.
>>>>>>
>>>>>> While going through SO I had found [1] , which did happen in oracle
>>>>>> database.
>>>>>>
>>>>>>
>>>>>> We have come up with several ways to handle empty strings which user
>>>>>> sends through the rest api.
>>>>>>
>>>>>> 1.  Validate the request and send error when giving empty strings
>>>>>> 2.  Set default value like "N/A" into the fields which send as empty.
>>>>>>
>>>>>> Is there any other way to handle this problem ?.
>>>>>>
>>>>>> [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
>>>>>> string-in-oracle
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> *Tharindu Dharmarathna*Software Engineer
>>>>>> WSO2 Inc.; http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Tharindu Dharmarathna*Software Engineer
>>>>> WSO2 Inc.; http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Uvindra
>>>>
>>>> Mobile: 33962
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks and Regards,
>>>
>>> Isuru H.
>>> +94 716 358 048 <+94%2071%20635%208048>* <http://wso2.com/>*
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> *Lahiru Cooray*
>> Software Engineer
>> WSO2, Inc.;http://wso2.com/
>> lean.enterprise.middleware
>>
>> Mobile: +94 715 654154 <+94%2071%20565%204154>
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> *Darshana Akalanka Pagoda Arachchi,*
> *Senior Software Engineer, WSO2*
> *+94777118016 <+94%2077%20711%208016>*
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] [Oracle] How to handle insertion of empty string in oracle.

[Uvindra Dias Jayasinha]

Setting a default value for empty fields being sent seems to be best.

Furthermore we can have default values set in our DTO objects in case a
given field is omitted altogether.

So handling both the above scenarios can overcome the limitation in Oracle.

But I dont know if this is good for the REST API user experience, when
retrieving data that contains these default values.

On 6 January 2017 at 15:28, Tharindu Dharmarathna 
wrote:

>
>
> On Fri, Jan 6, 2017 at 3:26 PM, Tharindu Dharmarathna 
> wrote:
>
>> Hi All,
>>
>> I faced $Subject in Oracle database while running integration test on C5
>> on top.
>>
>> *Observation*
>>
>> when insert empty string ("") it was save as null in database.
>>
>> While going through SO I had found [1] , which did happen in oracle
>> database.
>>
>>
>> We have come up with several ways to handle empty strings which user
>> sends through the rest api.
>>
>> 1.  Validate the request and send error when giving empty strings
>> 2.  Set default value like "N/A" into the fields which send as empty.
>>
>> Is there any other way to handle this problem ?.
>>
>> [1] - http://stackoverflow.com/questions/13278773/null-vs-empty-
>> string-in-oracle
>>
>> Thanks
>>
>>
>> *Tharindu Dharmarathna*Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091 <+94%2077%20910%209091>*
>>
>
>
>
> --
>
> *Tharindu Dharmarathna*Software Engineer
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94779109091 <+94%2077%20910%209091>*
>



-- 
Regards,
Uvindra

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

Re: [Dev] [Architecture] [C5] MSF4J Interceptors need to be configurable.

[Uvindra Dias Jayasinha]

Hi Ishara,

Another possibility for supporting multiple auth types with what you have
proposed is to have a collection Authenticator interfaces(using a Map
possibly) at the RestAPISecurityInterceptor level. Depending on some
condition you could selectively choose what implementation to use at
runtime.

On 9 December 2016 at 07:32, Ishara Cooray  wrote:

> Please find my comments in line.
>
> Yes for the moment lets use this approach. Lets have 2 interceptors for
> authenticate and authorization. From that lets provide way to add pluggable
> authenticators and authorizers.
> I guess you mean having two interfaces for authenticate and
> authorization.What if we have two methods in one interface?Otherwise  we
> will have to maintain two configurations.
>
> Also we may be able to route request through multiple authenticators
> according to predefined order(when we need to support multiple auth types
> at once).
> +1
>
> Also its better both identity and APIM can use same approach as we all are
> doing same thing.
> Identity team is writing JAAS Login Modules
> @Thanuja,
> Do you have any input here
>
> Thanks & Regards,
> Ishara Cooray
> Senior Software Engineer
> Mobile : +9477 262 9512 <+94%2077%20262%209512>
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
> On Thu, Dec 8, 2016 at 9:06 PM, Sanjeewa Malalgoda 
> wrote:
>
>> Yes for the moment lets use this approach. Lets have 2 interceptors for
>> authenticate and authorization. From that lets provide way to add pluggable
>> authenticators and authorizers.
>> Also we may be able to route request through multiple authenticators
>> according to predefined order(when we need to support multiple auth types
>> at once).
>> Also its better both identity and APIM can use same approach as we all
>> are doing same thing.
>>
>>
>> Thanks,
>> sanjeewa.
>>
>> On Thu, Dec 8, 2016 at 6:59 PM, Ishara Cooray  wrote:
>>
>>> To overcome the above limitation where we cannot plug custom
>>> authentication, i came up with the below approach.
>>>
>>> Having one interceptor and delegate authentication to an interface.
>>> Implementation of the interface is configurable so that we can plug custom
>>> authentication as well.
>>>
>>> [image: Inline image 1]
>>>
>>> One limitation here is we can have only one auth type active at a time.
>>>
>>> Hi Sanjeewa,
>>>
>>> Shall we continue with this approach until we get a proper fix from
>>> msf4j?
>>> ​
>>>
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512 <077%20262%209512>
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Thu, Dec 8, 2016 at 11:23 AM, Ishara Cooray  wrote:
>>>
 Hi Thilina,
>
> And also if there are multiple interceptors and one interceptor
> returns false from its' preCaall then the invocation chain will not
> continue further.
>
> So Is this implies if preCall returns 'true' then the invocation chain
> will continue further?
>

 Yes

 I was thinking to return 'true' if particular auth header type(Basic,
 Bearer) is not found in an interceptor, so that it will check the other
 available interceptors.
 But i guess this approach may also fail if the request header type is
 not provided may be by mistake.
 Because all the interceptors will return true and will it be taken as a
 valid authorization?


 Thanks & Regards,
 Ishara Cooray
 Senior Software Engineer
 Mobile : +9477 262 9512 <+94%2077%20262%209512>
 WSO2, Inc. | http://wso2.com/
 Lean . Enterprise . Middleware

 On Wed, Dec 7, 2016 at 5:25 PM, Afkham Azeez  wrote:

>
>
> On Wed, Dec 7, 2016 at 5:17 PM, Ishara Cooray 
> wrote:
>
>> Hi Thilina,
>>
>> And also if there are multiple interceptors and one interceptor
>> returns false from its' preCaall then the invocation chain will not
>> continue further.
>>
>> So Is this implies if preCall returns 'true' then the invocation
>> chain will continue further?
>>
>
> Yes
>
>
>> If that is the case we can return true in our overridden preCall
>> method so that it goes to next Interceptor.
>>
>>
>> Thanks & Regards,
>> Ishara Cooray
>> Senior Software Engineer
>> Mobile : +9477 262 9512 <077%20262%209512>
>> WSO2, Inc. | http://wso2.com/
>> Lean . Enterprise . Middleware
>>
>> On Wed, Dec 7, 2016 at 2:33 PM, Afkham Azeez  wrote:
>>
>>> How about supporting JAXRS filters?
>>>
>>> On Wed, Dec 7, 2016 at 12:52 PM, Thusitha Thilina Dayaratne <
>>> thusit...@wso2.com> wrote:
>>>
 Hi Ishara,

 As you have mentioned, with the current architecture we can't set
 the specific interceptor for a particular service but rather to 

Re: [Dev] [dev][APIM 1.7] Alternatives for API creation/deletion audit logs

[Uvindra Dias Jayasinha]

HI Thilini,

If all you want to check is when an API is added or deleted then the same
approach of using trigger for AM_API table is enough. But what information
exactly do you need to collect for the audit?

On 27 October 2016 at 14:23, Thilini Cooray  wrote:

> Hi,
>
> APIM 1.7 does not support audit logs for operations such as API creation
> and deletion, application creation and deletion.
> I am looking for alternatives which can be used for collecting audit data.
>
> Since application data are only stored in AM_DB, we can collect
> application related audit data by adding a database trigger for
> AM_APPLICATION table.
>
> However, API details are stored in both AM_DB and Registry DB.
> Therefore what is the recommended way for collecting audit data for API
> creation and deletion?
>
> Will it be reliable enough to just add a database trigger for AM_API table
> for insertions and deletions ?
>
> Thanks.
>
> --
> Best Regards,
>
> *Thilini Cooray*
> Software Engineer
> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20774%20570112>
> E-mail : thili...@wso2.com
>
> WSO2 Inc. www.wso2.com
> lean.enterprise.middleware
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] Do we support viewing user information (profiles) across tenants?

[Uvindra Dias Jayasinha]

+1 to *Option 1*, I don't think we should try and get user profile details
from across tenants. If you want to, you should login to the respective
tenant explicitly to get that information. I think knowing the name of the
tenant user is enough in this case.

On 26 October 2016 at 13:40, Chamin Dias  wrote:

> Hi,
>
> This is related to public JIRA : https://wso2.org/jira/
> browse/APIMANAGER-5384
>
> In API Publisher, there is a table to show “Top API Users”. It shows the
> users who has used the API frequently.
>
> In the below example, “stuer1” and “stuer2” are users in the super tenant
> space while “hruser1” and “hruser2” are users in a separate tenant (i.e -
> hr.com)
>
> [image: Inline image 4]
>
> When we click the name of the user, it shows the details of the user. (i.e
> - profile details)
>
> [image: Inline image 3]
> In a multi-tenant environment, it only shows the profiles of the same
> tenant. It does not show the profiles details of users from other tenants.
> Reason for the issue is that the code is using super tenant credentials to
> retrieve user profile of a tenant user [1].
>
> *Question : In a multi-tenant environment is it OK to show the details of
> the users (i.e - profile) in other tenants?*
>
> As per the discussions we had with APIM and IS teams (got to know that the
> code does not allow to view user details across tenants), there were few
> opinions.
>
> *Option 1* - If we allow this, it violates the tenant boundary. Hence we
> should not show profile details. (or show profiles of users from same
> tenant *only*)
>
> *Option 2 *- Requirement is OK. We should support viewing user profiles
> across tenants.
>
> We have done the following to check if we can get the profile of a user
> from another tenant, but it failed, so if we are going to support this
> requirement, is there a way we can achieve this?
>
> String tenantDomain = MultitenantUtils.getTenantDomain(APIUtil.
> replaceEmailDomainBack(username));
> int tenantId = ServiceReferenceHolder.
> getInstance().getRealmService().getTenantManager()
> .getTenantId(tenantDomain);
> String tenantAdminUserName = ServiceReferenceHolder.
> getInstance().getRealmService()
> .getTenantUserRealm(tenantId).getRealmConfiguration().
> getAdminUserName();
>
> String tenantAdminPassword = ServiceReferenceHolder.
> getInstance().getRealmService().getTenantUserRealm(tenantId)
> .getRealmConfiguration().getAdminPassword();
>
> //Then used the credentials of the tenant admin like this.
>
> CarbonUtils.setBasicAccessSecurityHeaders(tenantAdminUserName,
> tenantAdminPassword, gatewayServiceClient);
>
> UserProfileDTO[] profiles = stub.getUserProfiles(username);
> for (UserProfileDTO dto : profiles) {
> if (APIConstants.USER_DEFAULT_PROFILE.equals(dto.getProfileName())) {
> return dto;
> }
> }
>
> Please share your ideas on this.
>
> Thanks.
>
> [1] https://github.com/wso2/carbon-apimgt/blob/master/
> components/apimgt/org.wso2.carbon.apimgt.impl/src/main/
> java/org/wso2/carbon/apimgt/impl/utils/APIUtil.java#L2210-2210
>
> --
> Chamin Dias
> *Software Engineer*
> Mobile : +94 (0) 716 097455 <%2B94%20%280%29%20773%20451194>
> Email : cham...@wso2.com
> Blog : https://chamindias.wordpress.com/
>



-- 
Regards,
Uvindra

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

Re: [Dev] Why not ship creator and publisher roles pre-built in API-M?

[Uvindra Dias Jayasinha]

Thats a good point Samisa.

We have the subscriber role by default because we need it to set the
permissions for users that sign up from the API store. All other user
creations need to happen through the carbon admin console anyway so I guess
we havent added those other roles by default.

But I see no reason why we cannot have these roles already created to make
it easier for the end user.


On 14 September 2016 at 08:57, Samisa Abeysinghe  wrote:

> We ship subscriber role with proper permissions set.
>
> https://docs.wso2.com/display/AM200/Adding+User+Roles describes creator
> and publisher roles.
> But the vanilla product does not have them.
>
> Why not create and ship them with proper permissions pre-set? Why only
> subscriber role?
>
> Thanks,
> Samisa...
>
>
> Samisa Abeysinghe
>
> Vice President Delivery
>
> WSO2 Inc.
> http://wso2.com
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] Opening the JSON interface instead of SOAP to the clients(applications)

[Uvindra Dias Jayasinha]

You can simply write a standard JAX-RS application that supports
application/json and deploy this in WSO2 AS which can be exposed to
external users to call. Here[1] is an example.

[1]
http://www.mkyong.com/webservices/jax-rs/json-example-with-jersey-jackson/

On 12 September 2016 at 11:50, 郑文兴  wrote:

> Dear gurus,
>
>
>
> We are ongoing the customizing our application based on the WSO2
> Application Server, appreciated for your advices on how to provide the JSON
> interface to the external users(applications) instead of SOAP? Is it easy
> to make it?
>
>
>
> Thanks, Wenxing
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] [VOTE][RC3] Release - WSO2 API Manager mediation policy tooling 2.0.0 RC3.

[Uvindra Dias Jayasinha]

[+] Stable - go ahead and release

On 30 August 2016 at 17:28, Roshan Wijesena  wrote:

> Hi All,
>
> This is the 3rd Release Candidate of WSO2 API Manager mediation policy
> tooling 2.0.0.
>
> Please download, test the product and vote. The vote will be open for 72
> hours or as needed.
>
> *Source and distribution*
>
> *Tooling*  : https://github.com/wso2/devstudio-tooling-apim/
> releases/tag/Released-release-2.0.3-RC3-2016-08-30-105251
>
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-] Broken - do not release (explain why)
>
> Thanks,
> WSO2 APIM team.
>
> --
> Roshan Wijesena.
> Senior Software Engineer-WSO2 Inc.
> Mobile: *+94719154640 <%2B94719154640>*
> Email: ros...@wso2.com
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>



-- 
Regards,
Uvindra

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

Re: [Dev] [Architecture] [VOTE] Release WSO2 API Manager 2.0.0 RC5

[Uvindra Dias Jayasinha]

Tested below with secure vault with custom key store

1. API creation and publication with different user roles and invocation
tenant/super tenant
2. Stats tenant/super tenant(Store and Publisher)
3. Log Analyzer tenant/super tenant
4. API creation and publication with different user roles for tenant/super
tenant

No issues found

[+] Stable - go ahead and release.

On 28 July 2016 at 02:02, Abimaran Kugathasan  wrote:

> *WSO2 API Manager 2.0.0-RC5 Released*
>
> This is the 5th Release Candidate of the WSO2 API Manager 2.0.0
>
> Source & binary distribution files of API Manager 2.0.0-RC5 :
>
>  Runtime : 
> *https://github.com/wso2/product-apim/releases/tag/v2.0.0-rc5
> *
>  Analytics : 
> *https://github.com/wso2/analytics-apim/releases/tag/v2.0.0-rc5
> *
>
> Please download, test the product and vote. Vote will be open for 72
> hours or as needed.
> Refer to github readme for guides.
>
> Please vote as follows.
> [+] Stable - go ahead and release
> [-]  Broken - do not release (please explain why)
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer - API Technologies
>
> Email : abima...@wso2.com
> Mobile : +94 773922820
>
> 
> 
>   
> 
>
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] [Architecture] [VOTE] Release WSO2 API Manager 2.0.0 RC4

[Uvindra Dias Jayasinha]

Tested below with secure vault with custom key store

1. API publication and invocation tenant and super tenant
2. Stats tenant and super tenant(Store and Publisher)
3. Log Analyzer tenant and super tenant

No issues found

[+] Stable - go ahead and release.


On 22 July 2016 at 12:20, Roshan Wijesena  wrote:

> Tested below with DB2 and SQL server 2008.
>
> * Basic APIM functionality.
> * Alert subscriptions.
> * Log analyzer in a multi-tenant environment.
>
> No issues found
>
> [+] Stable - go ahead and release.
>
>
>
> On Fri, Jul 22, 2016 at 11:28 AM, Rukshan Premathunga 
> wrote:
>
>> Tested analytics and smoke tested APIM on db2, mssql, mysql, mysql5.7,
>> oracle, postgre and h2.
>>
>> No issues found.
>>
>> [+] - Stable - go ahead and release
>>
>> Thanks.
>>
>> On Fri, Jul 22, 2016 at 10:48 AM, Thilini Cooray 
>> wrote:
>>
>>> Tested
>>>
>>>- API import-export
>>>- Store Self Sign-up
>>>- Store search
>>>- Tested main functionalities with MySQL, PostgreSQL and on Windows
>>>
>>> No issues found.
>>>
>>> [+] - Stable - go ahead and release
>>>
>>> Thanks.
>>>
>>>
>>> On Fri, Jul 22, 2016 at 1:25 AM, Abimaran Kugathasan 
>>> wrote:
>>>
 *WSO2 API Manager 2.0.0-RC4 Released*

 This is the 4th Release Candidate of the WSO2 API Manager 2.0.0

 Source & binary distribution files of API Manager 2.0.0-RC4 :

  Runtime :
 https://github.com/wso2/product-apim/releases/tag/v2.0.0-rc4
  Analytics :
 https://github.com/wso2/analytics-apim/releases/tag/v2.0.0-rc3

 Please download, test the product and vote. Vote will be open for 72
 hours or as needed.
 Refer to github readme for guides.

 Please vote as follows.
 [+] Stable - go ahead and release
 [-]  Broken - do not release (please explain why)


 --
 Thanks
 Abimaran Kugathasan
 Senior Software Engineer

 Email : abima...@wso2.com
 Mobile : +94 773922820

 
 
   
 


 ___
 Architecture mailing list
 architect...@wso2.org
 https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


>>>
>>>
>>> --
>>> Best Regards,
>>>
>>> *Thilini Cooray*
>>> Software Engineer
>>> Mobile : +94 (0) 774 570 112 <%2B94%20%280%29%20773%20451194>
>>> E-mail : thili...@wso2.com
>>>
>>> WSO2 Inc. www.wso2.com
>>> lean.enterprise.middleware
>>>
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>>
>> --
>> Rukshan Chathuranga.
>> Software Engineer.
>> WSO2, Inc.
>>
>> ___
>> Architecture mailing list
>> architect...@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Roshan Wijesena.
> Senior Software Engineer-WSO2 Inc.
> Mobile: *+94719154640 <%2B94719154640>*
> Email: ros...@wso2.com
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>
> ___
> Architecture mailing list
> architect...@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] Fixing APIMANAGER-4202 at carbon-mediation level

[Uvindra Dias Jayasinha]

Thanks Viraj

On 5 July 2016 at 15:52, Viraj Senevirathne <vir...@wso2.com> wrote:

> PR is merged https://github.com/wso2/carbon-mediation/pull/671.
>
> On Tue, Jul 5, 2016 at 3:44 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> Ping!
>>
>> ESB Team can we get the above PR merged please?
>>
>> On 27 June 2016 at 19:26, Uvindra Dias Jayasinha <uvin...@wso2.com>
>> wrote:
>>
>>> Thanks Kishanthan
>>>
>>> If we were to fix this by calling startTenantFlow() the fix would be a
>>> lot more complicated and may lead to other issues. So I have tested the
>>> original fix done by Jagath in this case and didn't run into any issues
>>> functional wise. Though I could not recreate the issue in the first place
>>> so we still dont know what causes this exactly.
>>>
>>> @ChanakaF, I have sent the PR with the fix that I tested[1], please merge
>>>
>>> [1] https://github.com/wso2/carbon-mediation/pull/671
>>>
>>> On 27 June 2016 at 17:15, Kishanthan Thangarajah <kishant...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jun 27, 2016 at 12:13 PM, Uvindra Dias Jayasinha <
>>>> uvin...@wso2.com> wrote:
>>>>
>>>>> Before I just apply the stated fix I would like some feedback from the
>>>>> Carbon team regarding what maybe causing this issue.
>>>>>
>>>>> So here is what we are seeing so far,
>>>>>
>>>>> 1. IllegalStateException is being thrown by
>>>>> CarbonContextDataHolder.setTenantDomain()
>>>>>
>>>>> 2. The logic in setTenantDomain() is as follows,
>>>>>   a) If the this.tenantDomain of the CarbonContextDataHolder is
>>>>> null or is equal to the super tenant domain then its fine
>>>>>
>>>>>   b) But if the this.tenantDomain of the CarbonContextDataHolder
>>>>> is Not Equal to the tenant domain value that is being set then there is a
>>>>> chance for the IllegalStateException to be thrown.
>>>>>
>>>>> So what this seems to indicate is that you cannot call
>>>>> setTenantDomain() if the current tenantDomain within the carbon context is
>>>>> already set to another tenants domain. This could be due to
>>>>> startTenantFlow() not being called before setting the tenant domain. Could
>>>>> this be the cause?
>>>>>
>>>>
>>>> If the tenant domain is already set, then it can not be set again
>>>> within the same thread flow, unless you start a new tenant flow or setting
>>>> a tenant domain other than super tenant.
>>>>
>>>> Starting a new tenant flow means, the current ContextHolder instance
>>>> will be pushed onto the stack and then the thread would see a new
>>>> ContextHolder instance until that tenant flow is properly ended (popped
>>>> from the stack), which then the thread would see the previous ContextHolder
>>>> instance which was there before starting the tenant flow.
>>>>
>>>>
>>>>> On 24 June 2016 at 14:44, Uvindra Dias Jayasinha <uvin...@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Problem is the issue is intermittent so its difficult to verify but I
>>>>>> will test the fix out and send a PR
>>>>>>
>>>>>> On 24 June 2016 at 13:52, Chanaka Fernando <chana...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Uvindra,
>>>>>>>
>>>>>>> Could you please verify the fix and send us a PR so that we can
>>>>>>> merge it?
>>>>>>>
>>>>>>> On Fri, Jun 24, 2016 at 1:02 PM, Uvindra Dias Jayasinha <
>>>>>>> uvin...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> The original issue encountered in [1] was fixed via the resolution
>>>>>>>> of [2].
>>>>>>>>
>>>>>>>> But now this has been reopened and in this case the same issue has
>>>>>>>> got exposed, but on this occasion the call stack is different. This is
>>>>>>>> happening when setting the tenant info at [3]. So we need to apply the 
>>>>>>>> same
>>>>>>>> fix that wa

Re: [Dev] Fixing APIMANAGER-4202 at carbon-mediation level

[Uvindra Dias Jayasinha]

Ping!

ESB Team can we get the above PR merged please?

On 27 June 2016 at 19:26, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote:

> Thanks Kishanthan
>
> If we were to fix this by calling startTenantFlow() the fix would be a lot
> more complicated and may lead to other issues. So I have tested the
> original fix done by Jagath in this case and didn't run into any issues
> functional wise. Though I could not recreate the issue in the first place
> so we still dont know what causes this exactly.
>
> @ChanakaF, I have sent the PR with the fix that I tested[1], please merge
>
> [1] https://github.com/wso2/carbon-mediation/pull/671
>
> On 27 June 2016 at 17:15, Kishanthan Thangarajah <kishant...@wso2.com>
> wrote:
>
>>
>>
>> On Mon, Jun 27, 2016 at 12:13 PM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> Before I just apply the stated fix I would like some feedback from the
>>> Carbon team regarding what maybe causing this issue.
>>>
>>> So here is what we are seeing so far,
>>>
>>> 1. IllegalStateException is being thrown by
>>> CarbonContextDataHolder.setTenantDomain()
>>>
>>> 2. The logic in setTenantDomain() is as follows,
>>>   a) If the this.tenantDomain of the CarbonContextDataHolder is null
>>> or is equal to the super tenant domain then its fine
>>>
>>>   b) But if the this.tenantDomain of the CarbonContextDataHolder is
>>> Not Equal to the tenant domain value that is being set then there is a
>>> chance for the IllegalStateException to be thrown.
>>>
>>> So what this seems to indicate is that you cannot call setTenantDomain()
>>> if the current tenantDomain within the carbon context is already set to
>>> another tenants domain. This could be due to startTenantFlow() not being
>>> called before setting the tenant domain. Could this be the cause?
>>>
>>
>> If the tenant domain is already set, then it can not be set again within
>> the same thread flow, unless you start a new tenant flow or setting a
>> tenant domain other than super tenant.
>>
>> Starting a new tenant flow means, the current ContextHolder instance will
>> be pushed onto the stack and then the thread would see a new ContextHolder
>> instance until that tenant flow is properly ended (popped from the stack),
>> which then the thread would see the previous ContextHolder instance which
>> was there before starting the tenant flow.
>>
>>
>>> On 24 June 2016 at 14:44, Uvindra Dias Jayasinha <uvin...@wso2.com>
>>> wrote:
>>>
>>>> Problem is the issue is intermittent so its difficult to verify but I
>>>> will test the fix out and send a PR
>>>>
>>>> On 24 June 2016 at 13:52, Chanaka Fernando <chana...@wso2.com> wrote:
>>>>
>>>>> Hi Uvindra,
>>>>>
>>>>> Could you please verify the fix and send us a PR so that we can merge
>>>>> it?
>>>>>
>>>>> On Fri, Jun 24, 2016 at 1:02 PM, Uvindra Dias Jayasinha <
>>>>> uvin...@wso2.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> The original issue encountered in [1] was fixed via the resolution of
>>>>>> [2].
>>>>>>
>>>>>> But now this has been reopened and in this case the same issue has
>>>>>> got exposed, but on this occasion the call stack is different. This is
>>>>>> happening when setting the tenant info at [3]. So we need to apply the 
>>>>>> same
>>>>>> fix that was done in resolving [2] to the WSO2Registry class when setting
>>>>>> the tenant info.
>>>>>>
>>>>>> Can we get this fixed?
>>>>>>
>>>>>>
>>>>>> [1] https://wso2.org/jira/browse/APIMANAGER-4202
>>>>>> [2] https://wso2.org/jira/browse/ESBJAVA-4333
>>>>>> [3]
>>>>>> https://github.com/wso2/carbon-mediation/blob/v4.6.1-BETA3/components/mediation-registry/org.wso2.carbon.mediation.registry/src/main/java/org/wso2/carbon/mediation/registry/WSO2Registry.java#L747
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>> Uvindra
>>>>>>
>>>>>> Mobile: 33962
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thank you and Best Regards,
>>>>> Chanaka Fernando
>>>>> Senior Technical Lead
>>>>> WSO2, Inc.; http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> mobile: +94 773337238
>>>>> Blog : http://soatutorials.blogspot.com
>>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>>> Twitter:https://twitter.com/chanakaudaya
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Uvindra
>>>>
>>>> Mobile: 33962
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>>
>> --
>> *Kishanthan Thangarajah*
>> Technical Lead,
>> Platform Technologies Team,
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - +94773426635
>> Blog - *http://kishanthan.wordpress.com
>> <http://kishanthan.wordpress.com>*
>> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>



-- 
Regards,
Uvindra

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

Re: [Dev] [API Store] Switching through Side Panes and them moving around while switching does not look cool

[Uvindra Dias Jayasinha]

I found the moving side pain very distracting as well, what are we
achieving by moving the side pain in that way?

Normally with the fixed panel you grow accustomed to the position of things
over time and you can click on these quickly without having to directly
look at them. But now you need to directly look at the panel to locate the
position of what you want to click on, slowing you down.

On 1 July 2016 at 08:29, Joseph Fonseka  wrote:

> From the experience we had thus far with the new store theme almost all
> the new users complained / mentioned about this behavior. But after some
> time they get used to it.
>
> On Fri, Jul 1, 2016 at 7:54 AM, Chamara Ariyarathne 
> wrote:
>
>> Totally agree. and I'm not suggesting something like a T pattern or
>> something.
>>
>> My concern is the Menu Items in the F moving around in a weird way.
>> If those heat graphs in that article are true then I'm pretty sure the
>> reader will get totally distracted by that action.
>>
>> On Fri, Jul 1, 2016 at 4:36 AM, Dakshika Jayathilaka 
>> wrote:
>>
>>> Hi all,
>>>
>>> IMO this is the expected behavior for this type of menu. If the user
>>> view this page first time, they can see related menu options which are
>>> available and corresponding actions to each menu item will display within
>>> the action bar(next to the menu in same level).
>>>
>>> Intentionally we don't maintain the order in this menu, cause user can
>>> select appropriate action, depending on his or her desire. We consider
>>> F-pattern[1] on this and user will drive accordingly.
>>>
>>> [1]
>>> https://www.nngroup.com/articles/f-shaped-pattern-reading-web-content/
>>>
>>> Regards,
>>>
>>> *Dakshika Jayathilaka*
>>> PMC Member & Committer of Apache Stratos
>>> Associate Technical Lead
>>> WSO2, Inc.
>>> lean.enterprise.middleware
>>> 0771100911
>>>
>>> On Tue, Jun 28, 2016 at 3:11 PM, Roshan Wijesena 
>>> wrote:
>>>
 [+ adding Joe/Thusitha]

 On Tue, Jun 28, 2016 at 3:08 PM, Chamara Ariyarathne  wrote:

> Created a jira for this.
> https://wso2.org/jira/browse/APIMANAGER-5131
>
> Please share your ideas on this.
>
> --
> *Chamara Ariyarathne*
> Associate Technical Lead - QA
> WSO2 Inc; http://www.wso2.com/
> Mobile; *+94772786766 <%2B94772786766>*
>



 --
 Roshan Wijesena.
 Senior Software Engineer-WSO2 Inc.
 Mobile: *+94719154640 <%2B94719154640>*
 Email: ros...@wso2.com
 *WSO2, Inc. :** wso2.com *
 lean.enterprise.middleware.

>>>
>>>
>>
>>
>> --
>> *Chamara Ariyarathne*
>> Associate Technical Lead - QA
>> WSO2 Inc; http://www.wso2.com/
>> Mobile; *+94772786766 <%2B94772786766>*
>>
>
>
>
> --
>
> --
> *Joseph Fonseka*
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] Fixing APIMANAGER-4202 at carbon-mediation level

[Uvindra Dias Jayasinha]

Thanks Kishanthan

If we were to fix this by calling startTenantFlow() the fix would be a lot
more complicated and may lead to other issues. So I have tested the
original fix done by Jagath in this case and didn't run into any issues
functional wise. Though I could not recreate the issue in the first place
so we still dont know what causes this exactly.

@ChanakaF, I have sent the PR with the fix that I tested[1], please merge

[1] https://github.com/wso2/carbon-mediation/pull/671

On 27 June 2016 at 17:15, Kishanthan Thangarajah <kishant...@wso2.com>
wrote:

>
>
> On Mon, Jun 27, 2016 at 12:13 PM, Uvindra Dias Jayasinha <uvin...@wso2.com
> > wrote:
>
>> Before I just apply the stated fix I would like some feedback from the
>> Carbon team regarding what maybe causing this issue.
>>
>> So here is what we are seeing so far,
>>
>> 1. IllegalStateException is being thrown by
>> CarbonContextDataHolder.setTenantDomain()
>>
>> 2. The logic in setTenantDomain() is as follows,
>>   a) If the this.tenantDomain of the CarbonContextDataHolder is null
>> or is equal to the super tenant domain then its fine
>>
>>   b) But if the this.tenantDomain of the CarbonContextDataHolder is
>> Not Equal to the tenant domain value that is being set then there is a
>> chance for the IllegalStateException to be thrown.
>>
>> So what this seems to indicate is that you cannot call setTenantDomain()
>> if the current tenantDomain within the carbon context is already set to
>> another tenants domain. This could be due to startTenantFlow() not being
>> called before setting the tenant domain. Could this be the cause?
>>
>
> If the tenant domain is already set, then it can not be set again within
> the same thread flow, unless you start a new tenant flow or setting a
> tenant domain other than super tenant.
>
> Starting a new tenant flow means, the current ContextHolder instance will
> be pushed onto the stack and then the thread would see a new ContextHolder
> instance until that tenant flow is properly ended (popped from the stack),
> which then the thread would see the previous ContextHolder instance which
> was there before starting the tenant flow.
>
>
>> On 24 June 2016 at 14:44, Uvindra Dias Jayasinha <uvin...@wso2.com>
>> wrote:
>>
>>> Problem is the issue is intermittent so its difficult to verify but I
>>> will test the fix out and send a PR
>>>
>>> On 24 June 2016 at 13:52, Chanaka Fernando <chana...@wso2.com> wrote:
>>>
>>>> Hi Uvindra,
>>>>
>>>> Could you please verify the fix and send us a PR so that we can merge
>>>> it?
>>>>
>>>> On Fri, Jun 24, 2016 at 1:02 PM, Uvindra Dias Jayasinha <
>>>> uvin...@wso2.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> The original issue encountered in [1] was fixed via the resolution of
>>>>> [2].
>>>>>
>>>>> But now this has been reopened and in this case the same issue has got
>>>>> exposed, but on this occasion the call stack is different. This is
>>>>> happening when setting the tenant info at [3]. So we need to apply the 
>>>>> same
>>>>> fix that was done in resolving [2] to the WSO2Registry class when setting
>>>>> the tenant info.
>>>>>
>>>>> Can we get this fixed?
>>>>>
>>>>>
>>>>> [1] https://wso2.org/jira/browse/APIMANAGER-4202
>>>>> [2] https://wso2.org/jira/browse/ESBJAVA-4333
>>>>> [3]
>>>>> https://github.com/wso2/carbon-mediation/blob/v4.6.1-BETA3/components/mediation-registry/org.wso2.carbon.mediation.registry/src/main/java/org/wso2/carbon/mediation/registry/WSO2Registry.java#L747
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Uvindra
>>>>>
>>>>> Mobile: 33962
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thank you and Best Regards,
>>>> Chanaka Fernando
>>>> Senior Technical Lead
>>>> WSO2, Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> mobile: +94 773337238
>>>> Blog : http://soatutorials.blogspot.com
>>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>>> Twitter:https://twitter.com/chanakaudaya
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>
>
>
> --
> *Kishanthan Thangarajah*
> Technical Lead,
> Platform Technologies Team,
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile - +94773426635
> Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>*
> Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>*
>



-- 
Regards,
Uvindra

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

Re: [Dev] Fixing APIMANAGER-4202 at carbon-mediation level

[Uvindra Dias Jayasinha]

Ping! Need your feedback Carbon team.

On 27 June 2016 at 12:13, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote:

> Before I just apply the stated fix I would like some feedback from the
> Carbon team regarding what maybe causing this issue.
>
> So here is what we are seeing so far,
>
> 1. IllegalStateException is being thrown by
> CarbonContextDataHolder.setTenantDomain()
>
> 2. The logic in setTenantDomain() is as follows,
>   a) If the this.tenantDomain of the CarbonContextDataHolder is null
> or is equal to the super tenant domain then its fine
>
>   b) But if the this.tenantDomain of the CarbonContextDataHolder is
> Not Equal to the tenant domain value that is being set then there is a
> chance for the IllegalStateException to be thrown.
>
> So what this seems to indicate is that you cannot call setTenantDomain()
> if the current tenantDomain within the carbon context is already set to
> another tenants domain. This could be due to startTenantFlow() not being
> called before setting the tenant domain. Could this be the cause?
>
> On 24 June 2016 at 14:44, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote:
>
>> Problem is the issue is intermittent so its difficult to verify but I
>> will test the fix out and send a PR
>>
>> On 24 June 2016 at 13:52, Chanaka Fernando <chana...@wso2.com> wrote:
>>
>>> Hi Uvindra,
>>>
>>> Could you please verify the fix and send us a PR so that we can merge it?
>>>
>>> On Fri, Jun 24, 2016 at 1:02 PM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> The original issue encountered in [1] was fixed via the resolution of
>>>> [2].
>>>>
>>>> But now this has been reopened and in this case the same issue has got
>>>> exposed, but on this occasion the call stack is different. This is
>>>> happening when setting the tenant info at [3]. So we need to apply the same
>>>> fix that was done in resolving [2] to the WSO2Registry class when setting
>>>> the tenant info.
>>>>
>>>> Can we get this fixed?
>>>>
>>>>
>>>> [1] https://wso2.org/jira/browse/APIMANAGER-4202
>>>> [2] https://wso2.org/jira/browse/ESBJAVA-4333
>>>> [3]
>>>> https://github.com/wso2/carbon-mediation/blob/v4.6.1-BETA3/components/mediation-registry/org.wso2.carbon.mediation.registry/src/main/java/org/wso2/carbon/mediation/registry/WSO2Registry.java#L747
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Uvindra
>>>>
>>>> Mobile: 33962
>>>>
>>>
>>>
>>>
>>> --
>>> Thank you and Best Regards,
>>> Chanaka Fernando
>>> Senior Technical Lead
>>> WSO2, Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 773337238
>>> Blog : http://soatutorials.blogspot.com
>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>>> Twitter:https://twitter.com/chanakaudaya
>>>
>>>
>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>



-- 
Regards,
Uvindra

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

Re: [Dev] Fixing APIMANAGER-4202 at carbon-mediation level

[Uvindra Dias Jayasinha]

Before I just apply the stated fix I would like some feedback from the
Carbon team regarding what maybe causing this issue.

So here is what we are seeing so far,

1. IllegalStateException is being thrown by
CarbonContextDataHolder.setTenantDomain()

2. The logic in setTenantDomain() is as follows,
  a) If the this.tenantDomain of the CarbonContextDataHolder is null or
is equal to the super tenant domain then its fine

  b) But if the this.tenantDomain of the CarbonContextDataHolder is Not
Equal to the tenant domain value that is being set then there is a chance
for the IllegalStateException to be thrown.

So what this seems to indicate is that you cannot call setTenantDomain() if
the current tenantDomain within the carbon context is already set to
another tenants domain. This could be due to startTenantFlow() not being
called before setting the tenant domain. Could this be the cause?

On 24 June 2016 at 14:44, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote:

> Problem is the issue is intermittent so its difficult to verify but I will
> test the fix out and send a PR
>
> On 24 June 2016 at 13:52, Chanaka Fernando <chana...@wso2.com> wrote:
>
>> Hi Uvindra,
>>
>> Could you please verify the fix and send us a PR so that we can merge it?
>>
>> On Fri, Jun 24, 2016 at 1:02 PM, Uvindra Dias Jayasinha <uvin...@wso2.com
>> > wrote:
>>
>>> Hi All,
>>>
>>> The original issue encountered in [1] was fixed via the resolution of
>>> [2].
>>>
>>> But now this has been reopened and in this case the same issue has got
>>> exposed, but on this occasion the call stack is different. This is
>>> happening when setting the tenant info at [3]. So we need to apply the same
>>> fix that was done in resolving [2] to the WSO2Registry class when setting
>>> the tenant info.
>>>
>>> Can we get this fixed?
>>>
>>>
>>> [1] https://wso2.org/jira/browse/APIMANAGER-4202
>>> [2] https://wso2.org/jira/browse/ESBJAVA-4333
>>> [3]
>>> https://github.com/wso2/carbon-mediation/blob/v4.6.1-BETA3/components/mediation-registry/org.wso2.carbon.mediation.registry/src/main/java/org/wso2/carbon/mediation/registry/WSO2Registry.java#L747
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>
>>
>>
>> --
>> Thank you and Best Regards,
>> Chanaka Fernando
>> Senior Technical Lead
>> WSO2, Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 773337238
>> Blog : http://soatutorials.blogspot.com
>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
>> Twitter:https://twitter.com/chanakaudaya
>>
>>
>>
>>
>>
>
>
> --
> Regards,
> Uvindra
>
> Mobile: 33962
>



-- 
Regards,
Uvindra

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

Re: [Dev] Fixing APIMANAGER-4202 at carbon-mediation level

[Uvindra Dias Jayasinha]

Problem is the issue is intermittent so its difficult to verify but I will
test the fix out and send a PR

On 24 June 2016 at 13:52, Chanaka Fernando <chana...@wso2.com> wrote:

> Hi Uvindra,
>
> Could you please verify the fix and send us a PR so that we can merge it?
>
> On Fri, Jun 24, 2016 at 1:02 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> Hi All,
>>
>> The original issue encountered in [1] was fixed via the resolution of [2].
>>
>> But now this has been reopened and in this case the same issue has got
>> exposed, but on this occasion the call stack is different. This is
>> happening when setting the tenant info at [3]. So we need to apply the same
>> fix that was done in resolving [2] to the WSO2Registry class when setting
>> the tenant info.
>>
>> Can we get this fixed?
>>
>>
>> [1] https://wso2.org/jira/browse/APIMANAGER-4202
>> [2] https://wso2.org/jira/browse/ESBJAVA-4333
>> [3]
>> https://github.com/wso2/carbon-mediation/blob/v4.6.1-BETA3/components/mediation-registry/org.wso2.carbon.mediation.registry/src/main/java/org/wso2/carbon/mediation/registry/WSO2Registry.java#L747
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>
>
>
> --
> Thank you and Best Regards,
> Chanaka Fernando
> Senior Technical Lead
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 773337238
> Blog : http://soatutorials.blogspot.com
> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0
> Twitter:https://twitter.com/chanakaudaya
>
>
>
>
>


-- 
Regards,
Uvindra

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

[Dev] Fixing APIMANAGER-4202 at carbon-mediation level

[Uvindra Dias Jayasinha]

Hi All,

The original issue encountered in [1] was fixed via the resolution of [2].

But now this has been reopened and in this case the same issue has got
exposed, but on this occasion the call stack is different. This is
happening when setting the tenant info at [3]. So we need to apply the same
fix that was done in resolving [2] to the WSO2Registry class when setting
the tenant info.

Can we get this fixed?


[1] https://wso2.org/jira/browse/APIMANAGER-4202
[2] https://wso2.org/jira/browse/ESBJAVA-4333
[3]
https://github.com/wso2/carbon-mediation/blob/v4.6.1-BETA3/components/mediation-registry/org.wso2.carbon.mediation.registry/src/main/java/org/wso2/carbon/mediation/registry/WSO2Registry.java#L747


-- 
Regards,
Uvindra

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

Re: [Dev] [APIM] Issue while using Conditional Group

[Uvindra Dias Jayasinha]

Hi Amila,

I think it defeats the purpose if we need to evaluate conditions again on
the GW side(GW starts to do part of the decision manager role), is it
possible to fix this by asking CEP to provide the aggregate result of all
the available conditions?



On 11 June 2016 at 12:12, Amila De Silva  wrote:

> Hi All,
>
> This is related to the discussion had with Harsha on a particular
> behaviour observed when having Conditional Groups.
>
> Suppose we have a throttling policy like below;
>
> *default* - 1000 req/min
>
> *Condition* - 50 req/min if IP is 10.100.0.5
>
>
> The expected behaviour is, if requests are coming from 10.100.0.5, only to
> allow 50 req/min, but if coming from a different destination, allow 1000.
>
> But we observed that, when requests coming from 10.100.0.5 have been
> throttled out after utilising it’s full quota (50 req/min) , GW won’t
> accept any requests even from a different destination.
>
>
> While investigating the issue found that it was due to the way we enforce
> throttling at the GW.
>
> If we consider creating the above condition, then;
>
> 1. Two Condition elements gets created (one for the default and the other
> for the actual condition) and get saved in the DB.
>
> 2. Two execution plans are created to handle the conditions and are
> deployed in the CEP.
>
>
> As APIs are invoked
>
> 1. CEP runs the queries and correctly evaluates which condition has been
> fulfilled .Say that we are invoking with the specified IP, then CEP will
> keep incrementing the counter related to IP based condition.
>
> 2. Once the limit has reached, CEP publishes the condition which has been
> throttled out.
>
> 3. When GW start to enforce throttling, it simply gets all the throttling
> conditions attached with the resource. So now the resource has two
> conditions attached - the default one and the ip based one.
>
> 4. GW doesn’t determine which condition should be checked (If a request is
> made from a different destination GW should look at the default condition,
> but with the current implementation it doesn’t) . It simply checks if any
> of the conditions attached with the resource have been throttled out.
>
>
> Due to this, if one of the conditions engaged with the request gets
> throttled out, no additional request can make through the GW, until time
> duration elapses.
>
>
> This is a bug and we have to fix this, but we also have to be aware of the
> downsides of fixing this;
>
> If we are to correctly fix this,
>
> 1. First at the GW, we have to determine which condition is applicable for
> the incoming request.
>
> 2. To do this, some additional data has to be sent from KM side. Currently
> only condition name is sent, but we'll need the entire definition of the
> condition.
>
> 3. Since the current Admin Dashboard also allows, specifying JWT claims as
> conditions, while checking certain conditions we’d have to go to the extent
> of decoding the JWT and iterate through claims.
>
> Due to these checks, when conditional groups are used, users would have to
> expect a performance drop.
>
> --
> *Amila De Silva*
>
> WSO2 Inc.
> mobile :(+94) 775119302
>
>


-- 
Regards,
Uvindra

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

Re: [Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Uvindra Dias Jayasinha]

The same tables are present in both scripts, can you confirm if all the
tables in the IS script are present in the APIM script? If so then only
running the APIM script will be sufficient and we will need to update the
documnetation

On 10 June 2016 at 17:41, Sewmini Jayaweera <sewm...@wso2.com> wrote:

> Hi Uvindra,
>
> I used pre configured IS to configure IS as key manager. But due to [1] I
> could not start api manager using -Dsetup. Therefore I sourced tables
> manually by following [2]. According to [2] we need to source
> /dbscripts/apimgt/mysql.sql and
> /dbscripts/identity/mysql.sql. in order to create tables in AM
> DB.
>
> As you told I get above errors for the db script I source after the first
> script. When using IS preconfigured pack should I source both?
>
> [1]. https://wso2.org/jira/browse/CARBON-15913
> [2].
> https://docs.wso2.com/display/CLUSTER44x/Configuring+the+Identity+Server+5.1.0+as+a+Key+Manager+with+API+Manager+1.10.0
>
> Sewmini Jayaweera
> *Software Engineer - QA Team*
> Mobile: +94 (0) 773 381 250
> sewm...@wso2.com
>
> On Fri, Jun 10, 2016 at 5:02 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> So this has nothing to do with the TIMESTAMP issue, this is because you
>> have already run the script once before and now its failing because primary
>> keys are being duplicated
>>
>> On 10 June 2016 at 16:56, Sewmini Jayaweera <sewm...@wso2.com> wrote:
>>
>>> Hi Uvindra,
>>>
>>> As per my observation in some mysql servers the script attached in my
>>> previous mail works but for me I had to add 'DEFAULT CURRENT_TIMESTAMP'
>>> option for REG_LAST_UPDATED_TIME and REG_CREATED_TIME columns of
>>> 'REG_RESOURCE_HISTORY' tables in addition to   'REG_RESOURCE' table.
>>>
>>>  I could fix mysql.sql script inside IS yet when I change TIMESTAMP
>>> columns by given DEFAULT CURRENT_TIMESTAMP' option for mysql.sql script in
>>> /dbscripts/apimgt/mysql.sql I got below error at the time I
>>> sourced it.
>>>
>>>
>>> source /Users/sewmini/Desktop/wso2am-1.10.0/dbscripts/apimgt/mysql.sql;
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1062 (23000): Duplicate entry 'WSO2 Identity Server' for key
>>> 'PRIMARY'
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.01 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1061 (42000): Duplicate key name 'IDX_AT_CK_AU'
>>>
>>> ERROR 1061 (42000): Duplicate key name 'IDX_TC'
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1061 (42000): Duplicate key name 'APPLICATION_NAME_CONSTRAINT'
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1022 (23000): Can't write; duplicate key in table '#sql-72cd_8'
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1022 (23000): Can't write; duplicate key in table '#sql-72cd_8'
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1022 (23000): Can't write; duplicate key in table '#sql-72cd_8'
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1022 (23000): Can't write; duplicate key in table '#sql-72cd_8'
>>>
>>> Query OK, 0 rows affected, 1 warning (0.00 sec)
>>>
>>> ERROR 1022 (23000): Can't write; duplicate key in table '#sql-72cd_8'
>&

Re: [Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Uvindra Dias Jayasinha]

cted (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.01 sec)
>
> Query OK, 0 rows affected (0.00 sec)
>
> Records: 0  Duplicates: 0  Warnings: 0
> I have also attached the script I used.
>
> Regards,
> Sewmini
>
>
> Sewmini Jayaweera
> *Software Engineer - QA Team*
> Mobile: +94 (0) 773 381 250
> sewm...@wso2.com
>
> On Fri, Jun 10, 2016 at 11:47 AM, Uvindra Dias Jayasinha <uvin...@wso2.com
> > wrote:
>
>> Ok I just executed one of the problematic table creation statements that
>> Sewmini has encountered on my own MySQL 5.7.12 distribution,
>>
>> CREATE TABLE IF NOT EXISTS REG_RESOURCE (
>>REG_PATH_ID INTEGER NOT NULL,
>>REG_NAMEVARCHAR(256),
>>REG_VERSION INTEGER NOT NULL AUTO_INCREMENT,
>>REG_MEDIA_TYPE  VARCHAR(500),
>>REG_CREATOR VARCHAR(31) NOT NULL,
>>REG_CREATED_TIMETIMESTAMP NOT NULL DEFAULT
>> CURRENT_TIMESTAMP,
>>REG_LAST_UPDATORVARCHAR(31),
>>REG_LAST_UPDATED_TIMETIMESTAMP NOT NULL DEFAULT
>> CURRENT_TIMESTAMP,
>>REG_DESCRIPTION VARCHAR(1000),
>>REG_CONTENT_ID  INTEGER,
>>REG_TENANT_ID INTEGER DEFAULT 0,
>>REG_UUID VARCHAR(100) NOT NULL,
>>CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION,
>> REG_TENANT_ID)
>> )ENGINE INNODB;
>>
>>
>> This gets created without an issue for me
>>
>> Even a table like,
>>
>> CREATE TABLE IF NOT EXISTS IDN_STS_STORE (
>> ID INTEGER AUTO_INCREMENT,
>> TOKEN_ID VARCHAR(255) NOT NULL,
>> TOKEN_CONTENT BLOB(1024) NOT NULL,
>> CREATE_DATE TIMESTAMP NOT NULL,
>> EXPIRE_DATE TIMESTAMP NOT NULL,
>> STATE INTEGER DEFAULT 0,
>> PRIMARY KEY (ID)
>> )ENGINE INNODB;
>>
>> which simply uses NOT NULL for TIMESTAMP gets created without an issue
>> for me.
>>
>>
>> My mode is same as Sewmini's,
>>
>> mysql> SELECT @@SESSION.sql_mode AS MODE;
>>
>> +---+
>> |
>> MODE
>> |
>>
>> +---+
>> |
>> ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
>> |
>>
>> +---+
>>
>>
>> So not sure why this is only failing for Sewmini.
>>
>>
>> On 10 June 2016 at 11:23, Sewmini Jayaweera <sewm...@wso2.com> wrote:
>>
>>> Hi Uvindra,
>>>
>>> I still could not get the issue resolved even after adding 'DEFAULT
>>> CURRENT_TIMESTAMP'  in TIMESTAMP columns which had given 'DEFUALT 0'
>>>
>>> I have attached edited script (is510/dbscripts/mysql.sql) and the errors
>>> I got when sourcing the script. Could you please have a look at this.
>>>
>>> Below is the MySQL mode in my server.
>>>
>>>
>>> +---+
>>>
>>> | @@sql_mode
>>> |
>>>
>>>
>>> +---+
>>>
>>> |
>>> ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTIT

Re: [Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Uvindra Dias Jayasinha]

Ok I just executed one of the problematic table creation statements that
Sewmini has encountered on my own MySQL 5.7.12 distribution,

CREATE TABLE IF NOT EXISTS REG_RESOURCE (
   REG_PATH_ID INTEGER NOT NULL,
   REG_NAMEVARCHAR(256),
   REG_VERSION INTEGER NOT NULL AUTO_INCREMENT,
   REG_MEDIA_TYPE  VARCHAR(500),
   REG_CREATOR VARCHAR(31) NOT NULL,
   REG_CREATED_TIMETIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
   REG_LAST_UPDATORVARCHAR(31),
   REG_LAST_UPDATED_TIMETIMESTAMP NOT NULL DEFAULT
CURRENT_TIMESTAMP,
   REG_DESCRIPTION VARCHAR(1000),
   REG_CONTENT_ID  INTEGER,
   REG_TENANT_ID INTEGER DEFAULT 0,
   REG_UUID VARCHAR(100) NOT NULL,
   CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION,
REG_TENANT_ID)
)ENGINE INNODB;


This gets created without an issue for me

Even a table like,

CREATE TABLE IF NOT EXISTS IDN_STS_STORE (
ID INTEGER AUTO_INCREMENT,
TOKEN_ID VARCHAR(255) NOT NULL,
TOKEN_CONTENT BLOB(1024) NOT NULL,
CREATE_DATE TIMESTAMP NOT NULL,
EXPIRE_DATE TIMESTAMP NOT NULL,
STATE INTEGER DEFAULT 0,
PRIMARY KEY (ID)
)ENGINE INNODB;

which simply uses NOT NULL for TIMESTAMP gets created without an issue for
me.


My mode is same as Sewmini's,

mysql> SELECT @@SESSION.sql_mode AS MODE;
+---+
|
MODE
|
+---+
|
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
|
+---+


So not sure why this is only failing for Sewmini.


On 10 June 2016 at 11:23, Sewmini Jayaweera <sewm...@wso2.com> wrote:

> Hi Uvindra,
>
> I still could not get the issue resolved even after adding 'DEFAULT
> CURRENT_TIMESTAMP'  in TIMESTAMP columns which had given 'DEFUALT 0'
>
> I have attached edited script (is510/dbscripts/mysql.sql) and the errors I
> got when sourcing the script. Could you please have a look at this.
>
> Below is the MySQL mode in my server.
>
>
> +---+
>
> | @@sql_mode
>   |
>
>
> +---+
>
> |
> ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
> |
>
>
> +---+
>
> Regards,
>
> Sewmini
>
> Sewmini Jayaweera
> *Software Engineer - QA Team*
> Mobile: +94 (0) 773 381 250
> sewm...@wso2.com
>
> On Thu, Jun 9, 2016 at 10:56 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> Note that the above feature(auto initialize time stamp columns) was
>> introduced in MYSQL 5.6.5[1], so this kind of change to the scripts will
>> not be compatible with older MySQL versions.
>>
>>
>> [1]
>> http://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html#idm139923373307456
>>
>> On 9 June 2016 at 22:50, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote:
>>
>>> Lets just try DEFAULT CURRENT_TIMESTAMP for all TIMESTAMP fields.
>>>
>>> Avoid using ON UPDATE CURRENT_TIMESTAMP, our code already explicitly
>>> updates time stamp fields where required so we do not want MySQL to do this
>>> for us.
>>>
>>> On 9 June 2016 at 22:43, Sewmini Jayaweera <sewm...@wso2.com> wrote:
>>>
>>>> [Adding Uvindra and Maduranga]
>>>>
>>>> Sewmini Jayaweera
>>>> *Software Engineer - QA Team*
>>>> Mobile: +94 (0) 773 381 250
>>>> sewm...@wso2.com
>>>>
>>>> On Thu, Jun 9, 2016 at 12:16 PM, Sewmini Jayaweera <sewm...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> I get "ERROR 1067 (42000): Invalid default value for
>>>>> 'REG_LAST_UPDATED_TIME' error when sourcing
>>>>>

Re: [Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Uvindra Dias Jayasinha]

Note that the above feature(auto initialize time stamp columns) was
introduced in MYSQL 5.6.5[1], so this kind of change to the scripts will
not be compatible with older MySQL versions.


[1]
http://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html#idm139923373307456

On 9 June 2016 at 22:50, Uvindra Dias Jayasinha <uvin...@wso2.com> wrote:

> Lets just try DEFAULT CURRENT_TIMESTAMP for all TIMESTAMP fields.
>
> Avoid using ON UPDATE CURRENT_TIMESTAMP, our code already explicitly
> updates time stamp fields where required so we do not want MySQL to do this
> for us.
>
> On 9 June 2016 at 22:43, Sewmini Jayaweera <sewm...@wso2.com> wrote:
>
>> [Adding Uvindra and Maduranga]
>>
>> Sewmini Jayaweera
>> *Software Engineer - QA Team*
>> Mobile: +94 (0) 773 381 250
>> sewm...@wso2.com
>>
>> On Thu, Jun 9, 2016 at 12:16 PM, Sewmini Jayaweera <sewm...@wso2.com>
>> wrote:
>>
>>> Hi All,
>>>
>>> I get "ERROR 1067 (42000): Invalid default value for
>>> 'REG_LAST_UPDATED_TIME' error when sourcing
>>> '/dbscripts/mysql.sql, even after removing 'DEFAULT 0'
>>>  Please find further information below.
>>>
>>> *1. Issue description*
>>>
>>> CREATE TABLE IF NOT EXISTS REG_RESOURCE(
>>> REG_PATH_ID INTEGER NOT NULL,
>>> REG_NAMEVARCHAR(256),
>>> REG_VERSION INTEGER NOT NULL AUTO_INCREMENT,
>>> REG_MEDIA_TYPE  VARCHAR(500),
>>> REG_CREATOR VARCHAR(31) NOT NULL,
>>> REG_CREATED_TIMETIMESTAMP NOT NULL,
>>> REG_LAST_UPDATORVARCHAR(31),
>>> REG_LAST_UPDATED_TIMETIMESTAMP NOT NULL,
>>> REG_DESCRIPTION VARCHAR(1000),
>>> REG_CONTENT_ID  INTEGER,
>>> REG_TENANT_ID INTEGER DEFAULT 0,
>>> REG_UUID VARCHAR(100) NOT NULL,
>>> CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION,
>>> REG_TENANT_ID)
>>> )ENGINE INNODB;
>>>
>>> When creating above table "ERROR 1067 (42000): Invalid default value for
>>> 'REG_LAST_UPDATED_TIME' error occurred and table didn't get created. Please
>>> note that this error shows *only when there are two timestamp columns* 
>>> (REG_CREATED_TIME
>>> and REG_LAST_UPDATED_TIME) in the table.
>>>
>>> *2. What happens when there are two time stamp columns?*
>>>
>>> According to [1] when we have two timestamp columns not declared an
>>> explicit 'DEFAULT' or 'ON UPDATE' clause, first column is automatically
>>> assigned the DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP
>>> attributes, while the second one is assigned the '-00-00 00:00:00' (the
>>> “zero” timestamp).
>>>
>>> *3. Why are we getting the Error explained In issue description?*
>>>
>>> When 'strict SQL mode' and ' NO_ZERO_DATE' mode is enabled in MySQL
>>> server the “zero” timestamp is not allowed and it gives an error [2]. In
>>> MySQL 5.7 by default 'NO_ZERO_DATE' mode is enabled.
>>>
>>> *4.Question*
>>>
>>> As a fix I found below
>>>  1. Setting MySQL mode to  'ALLOW_INVALID_DATES' [3].
>>> EX: SET SQL_MODE='ALLOW_INVALID_DATES';
>>>
>>> *Is it okay to use this or is there a much more appropriate way of doing
>>> that? *
>>>
>>> [1].
>>> http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp
>>> [2].
>>> http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date
>>> [3].
>>> http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_allow_invalid_dates
>>>
>>>
>>> Thank You,
>>> Best Regards,
>>> Sewmini.
>>>
>>>
>>>
>>> Sewmini Jayaweera
>>> *Software Engineer - QA Team*
>>> Mobile: +94 (0) 773 381 250
>>> sewm...@wso2.com
>>>
>>> On Wed, May 25, 2016 at 12:13 PM, Kishanthan Thangarajah <
>>> kishant...@wso2.com> wrote:
>>>
>>>> We can verify and fix this for 4.4.6.
>>>>
>>>> On Tue, May 24, 2016 at 3:17 PM, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>> This issue is still open.
>>>>>
>>>>> If we don't fix this before kernel 4.4.6, none of our new products are
>>>>> going to be compatible with MySQL 5.7. Which would be a major l

Re: [Dev] [GREG] Invalid value error for REG_CREATED_TIME column in REG_RESOURCE with mysql 5.7

[Uvindra Dias Jayasinha]

Lets just try DEFAULT CURRENT_TIMESTAMP for all TIMESTAMP fields.

Avoid using ON UPDATE CURRENT_TIMESTAMP, our code already explicitly
updates time stamp fields where required so we do not want MySQL to do this
for us.

On 9 June 2016 at 22:43, Sewmini Jayaweera  wrote:

> [Adding Uvindra and Maduranga]
>
> Sewmini Jayaweera
> *Software Engineer - QA Team*
> Mobile: +94 (0) 773 381 250
> sewm...@wso2.com
>
> On Thu, Jun 9, 2016 at 12:16 PM, Sewmini Jayaweera 
> wrote:
>
>> Hi All,
>>
>> I get "ERROR 1067 (42000): Invalid default value for
>> 'REG_LAST_UPDATED_TIME' error when sourcing
>> '/dbscripts/mysql.sql, even after removing 'DEFAULT 0'
>>  Please find further information below.
>>
>> *1. Issue description*
>>
>> CREATE TABLE IF NOT EXISTS REG_RESOURCE(
>> REG_PATH_ID INTEGER NOT NULL,
>> REG_NAMEVARCHAR(256),
>> REG_VERSION INTEGER NOT NULL AUTO_INCREMENT,
>> REG_MEDIA_TYPE  VARCHAR(500),
>> REG_CREATOR VARCHAR(31) NOT NULL,
>> REG_CREATED_TIMETIMESTAMP NOT NULL,
>> REG_LAST_UPDATORVARCHAR(31),
>> REG_LAST_UPDATED_TIMETIMESTAMP NOT NULL,
>> REG_DESCRIPTION VARCHAR(1000),
>> REG_CONTENT_ID  INTEGER,
>> REG_TENANT_ID INTEGER DEFAULT 0,
>> REG_UUID VARCHAR(100) NOT NULL,
>> CONSTRAINT PK_REG_RESOURCE PRIMARY KEY(REG_VERSION,
>> REG_TENANT_ID)
>> )ENGINE INNODB;
>>
>> When creating above table "ERROR 1067 (42000): Invalid default value for
>> 'REG_LAST_UPDATED_TIME' error occurred and table didn't get created. Please
>> note that this error shows *only when there are two timestamp columns* 
>> (REG_CREATED_TIME
>> and REG_LAST_UPDATED_TIME) in the table.
>>
>> *2. What happens when there are two time stamp columns?*
>>
>> According to [1] when we have two timestamp columns not declared an
>> explicit 'DEFAULT' or 'ON UPDATE' clause, first column is automatically
>> assigned the DEFAULT CURRENT_TIMESTAMP and ON UPDATE CURRENT_TIMESTAMP
>> attributes, while the second one is assigned the '-00-00 00:00:00' (the
>> “zero” timestamp).
>>
>> *3. Why are we getting the Error explained In issue description?*
>>
>> When 'strict SQL mode' and ' NO_ZERO_DATE' mode is enabled in MySQL
>> server the “zero” timestamp is not allowed and it gives an error [2]. In
>> MySQL 5.7 by default 'NO_ZERO_DATE' mode is enabled.
>>
>> *4.Question*
>>
>> As a fix I found below
>>  1. Setting MySQL mode to  'ALLOW_INVALID_DATES' [3].
>> EX: SET SQL_MODE='ALLOW_INVALID_DATES';
>>
>> *Is it okay to use this or is there a much more appropriate way of doing
>> that? *
>>
>> [1].
>> http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_explicit_defaults_for_timestamp
>> [2].
>> http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date
>> [3].
>> http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_allow_invalid_dates
>>
>>
>> Thank You,
>> Best Regards,
>> Sewmini.
>>
>>
>>
>> Sewmini Jayaweera
>> *Software Engineer - QA Team*
>> Mobile: +94 (0) 773 381 250
>> sewm...@wso2.com
>>
>> On Wed, May 25, 2016 at 12:13 PM, Kishanthan Thangarajah <
>> kishant...@wso2.com> wrote:
>>
>>> We can verify and fix this for 4.4.6.
>>>
>>> On Tue, May 24, 2016 at 3:17 PM, Nuwan Dias  wrote:
>>>
 This issue is still open.

 If we don't fix this before kernel 4.4.6, none of our new products are
 going to be compatible with MySQL 5.7. Which would be a major limitation in
 the platform.

 Thanks,
 NuwanD.

 On Tue, May 10, 2016 at 4:15 PM, Chandana Napagoda 
 wrote:

> Hi Janaka,
>
> Please note that, this fix will be available in the next kernel
> release.
>
> Regards,
> Chandana
> On May 10, 2016 3:14 PM, "Thilini Cooray"  wrote:
>
>> Hi,
>>
>> A public JIRA is raised in [1].
>>
>> [1] https://wso2.org/jira/browse/REGISTRY-3610
>>
>> Thanks.
>>
>> On Tue, May 10, 2016 at 12:11 PM, Janaka Ranabahu 
>> wrote:
>>
>>> Hi Thushara
>>>
>>> On Tue, May 10, 2016 at 12:06 PM, Thushara Ranawaka <
>>> thusha...@wso2.com> wrote:
>>>
 Hi Thilini,

 AFAIU you workaround need to be updated with the current
 timestamp[1][2]. Setting default value to zero is not nice. You might 
 have
 to figure out the correct syntax for other DB types and test against 
 them.

>>> ​What Thilini is pointing is an issue in the Registry database
>>> creation script. Hence we will create a public JIRA and assign it to you
>>> guys. Please fix them.
>>>
>>> We can not modify the Registry database creation script since API
>>> Manager would not capture the complete scenarios of G-Reg.
>>>

Re: [Dev] [APIM] Changing Default Tier Limits and Names

[Uvindra Dias Jayasinha]

I think we need to setup a meeting to discuss the impact on existing users,
there could be lots of things we need to consider.

On 26 May 2016 at 11:31, Sam Sivayogam  wrote:

> What if we ship the 2.0.0 with the new tier definitions(new tier names,
> new limits) and during migration we can check if there is any subscriptions
> for the old tiers in version 1.10 and if there is existing subscriptions,
> we can add those old tiers to 2.0.0 database using in the migration tool.
> In that way existing subscriptions will be able get the old tier
> information WDYT ?
>
> Thanks,
> Sam
>
> On Thu, May 26, 2016 at 10:47 AM, Lakmali Baminiwatta 
> wrote:
>
>> I think when migrating, we can't change the names/limits of exiting tiers
>> since it will be a problem to existing subscriptions. So IMO, instead of
>> renaming tiers, we should add these new resource level and app level tiers
>> while keeping the old ones as well.
>>
>> Thanks,
>> Lakmali
>>
>> On 26 May 2016 at 10:23, Nuwan Dias  wrote:
>>
>>> Changing the names of the Resource Tiers and User Quota will be a
>>> problem for migrating users :(.
>>>
>>> If these tier names are recorded in the DB only, we can simply write an
>>> sql script that replaces the old names with the new ones. But if they are
>>> recorded in the rxt/swagger, we'll have more problems.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Wed, May 25, 2016 at 2:51 PM, Harsha Kumara  wrote:
>>>
 Hi All,

 Currently we are using very small number for our default tier values.
 We are going to change them to more meaningful counts. Here are the current
 limits. Also with the change of quota calculation and undesirability we
 think of change the tier names as well.

 Subscription Level Tiers

- Gold - 20 req/min
- Silver - 5 req/min
- Bronze - 1 req/min



 Resource Level Tiers

- Ultimate - 20 req/min
- Plus - 5  req/min
- Basic -1 req/min


 Application Level Tiers

- Large - 20 req/min
- Medium - 5 req/min
- Small -1 req/min


 Unauthenticated Tier - 60  req/min

 *Proposed Limits*

 Subscription Level Tiers

- Gold - 5000  req/min
- Silver - 2000 req/min
- Bronze - 1000 req/min

 Resource Level Tiers

- 50KPerMin - 5 req/min
- 20KPerMin - 2 req/min
- 10KPerMin - 1  req/min

 Application Level Tiers -> Per User Quota

- 50PerMin - 50 req/min
- 20PerMin  - 20 req/min
- 10PerMin  - 10 req/min

 Unauthenticated Tier - 500  req/min

 Thanks,
 Harsha

 --
 Harsha Kumara
 Software Engineer, WSO2 Inc.
 Mobile: +94775505618
 Blog:harshcreationz.blogspot.com

>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Technical Lead - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>>
>>
>>
>>
>> --
>> Lakmali Baminiwatta
>> Senior Software Engineer
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> mobile:  +94 71 2335936
>> blog : lakmali.com
>>
>>
>
>
> --
> *Sam Sivayogam*
>
> Software Engineer
> Mobile  : +94 772 906 439
> Office   : +94 112 145 345
> *WSO2, Inc. :** wso2.com *
> lean.enterprise.middleware.
>



-- 
Regards,
Uvindra

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

Re: [Dev] APIM snapse file system migration

[Uvindra Dias Jayasinha]

I think the only way is to complicate the migration instructions,

If user has customized any sequences they need to copy them over manually
to latest pack and we will use those.(Discalimer to user: You maybe missing
out on the latest changes shipped with the default sequences in the latest
pack)

Migration client doesn't need to do anything then, its not in a position to
make a proper decision anyway.

But its pretty clear this is a hole in our extensibility. We dont provide
official extension points to make changes in the areas that these specific
sequences address, forcing uses to change the default sequences that are
shipped which makes upgrading a pain. We should address this in a future
release

On 13 January 2016 at 05:23, Nuwan Dias  wrote:

>
>
> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta 
> wrote:
>
>> Hi all,
>>
>> In our migration guide, currently what we instruct is to copy & replace
>> repository/deployment/server/synapse-config/default directory and
>> repository/tenants from previous APIM version to new APIM version. Here we
>> mention to skip replacing  _TokenAPI_.xml, _RevokeAPI_.xml and
>> _AuthorizeAPI_.xml files by which latest files of those will be remained.
>>
>> But with this approach, it will replace other system sequences with old
>> ones (ex: _auth_failure_handler_.xml, _cors_request_handler_.xml, main.xml,
>> fault.xml, etc). So some of the fixes went to those will be missed out. We
>> have two ways to include those changes to the new version.
>>
>> 1. Include the missing changes through migration client.
>> 2. Get the latest sequences from the new version pack and replace
>> corresponded sequences of each tenant through migration client.
>>
>> Some of the changes done to these sequences are minor changes like adding
>> a drop mediator after send, changing a regex value, removing a property
>> etc. Since some of the users may have already done own customizations to
>> these sequences, trying to add changes to existing ones may lead to
>> complications.
>> So I think it would be better to ask the users to add their changes (if
>> there are any) to default sequences in the
>> pack(repository/resources/apim-synapse-config) prior running the migration
>> client and then through the client we can replace existing ones. WDYT?
>>
>
> This part is tricky. Since we do not know the amount nor nature of
> customisations they may have done, can we guarantee the migration client
> will do its job properly since it doesn't know the content/state of the
> file before it starts to execute on it?
>
>
>
>> Thanks,
>> Lakmali
>>
>> --
>> Lakmali Baminiwatta
>> Senior Software Engineer
>> WSO2, Inc.: http://wso2.com
>> lean.enterprise.middleware
>> mobile:  +94 71 2335936
>> blog : lakmali.com
>>
>>
>
>
> --
> Nuwan Dias
>
> Technical Lead - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>



-- 
Regards,
Uvindra

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

Re: [Dev] APIM snapse file system migration

[Uvindra Dias Jayasinha]

Ok if we allow these to be extended then we should not be adding our logic
from the product here, but seems that we have made improvements within the
extensible part.

We should add our changes to a default sequence that is used unless it has
been overridden by a custom sequence that has been defined for this purpose
by the user. That way we can upgrade the default sequences and users who
haven't overridden it get to use it.

But seems that the way thing are now we can achieve the same affect by
asking users to copy the sequences over if they have made any
customizations. Either way if they have done customizations they need to
copy them. So we can simply ask them to do that and not try to migrate
automatically.


:) Agree with Lakmali, who replied on the other thread, user should only
copy the sequences if they have customized them. No need to do anything
with the migration client

On 13 January 2016 at 07:26, Nuwan Dias <nuw...@wso2.com> wrote:

>
>
> On Wed, Jan 13, 2016 at 5:51 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> I think the only way is to complicate the migration instructions,
>>
>> If user has customized any sequences they need to copy them over manually
>> to latest pack and we will use those.(Discalimer to user: You maybe missing
>> out on the latest changes shipped with the default sequences in the latest
>> pack)
>>
>> Migration client doesn't need to do anything then, its not in a position
>> to make a proper decision anyway.
>>
>> But its pretty clear this is a hole in our extensibility. We dont provide
>> official extension points to make changes in the areas that these specific
>> sequences address, forcing uses to change the default sequences that are
>> shipped which makes upgrading a pain. We should address this in a future
>> release
>>
>
> The sole purpose of these sequences are for extensibility. Ex: To change
> the message type of a auth failure error. So its understandable that people
> edit them.
>
>>
>> On 13 January 2016 at 05:23, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta <lakm...@wso2.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> In our migration guide, currently what we instruct is to copy & replace
>>>> repository/deployment/server/synapse-config/default directory and
>>>> repository/tenants from previous APIM version to new APIM version. Here we
>>>> mention to skip replacing  _TokenAPI_.xml, _RevokeAPI_.xml and
>>>> _AuthorizeAPI_.xml files by which latest files of those will be remained.
>>>>
>>>> But with this approach, it will replace other system sequences with old
>>>> ones (ex: _auth_failure_handler_.xml, _cors_request_handler_.xml, main.xml,
>>>> fault.xml, etc). So some of the fixes went to those will be missed out. We
>>>> have two ways to include those changes to the new version.
>>>>
>>>> 1. Include the missing changes through migration client.
>>>> 2. Get the latest sequences from the new version pack and replace
>>>> corresponded sequences of each tenant through migration client.
>>>>
>>>> Some of the changes done to these sequences are minor changes like
>>>> adding a drop mediator after send, changing a regex value, removing a
>>>> property etc. Since some of the users may have already done own
>>>> customizations to these sequences, trying to add changes to existing ones
>>>> may lead to complications.
>>>> So I think it would be better to ask the users to add their changes (if
>>>> there are any) to default sequences in the
>>>> pack(repository/resources/apim-synapse-config) prior running the migration
>>>> client and then through the client we can replace existing ones. WDYT?
>>>>
>>>
>>> This part is tricky. Since we do not know the amount nor nature of
>>> customisations they may have done, can we guarantee the migration client
>>> will do its job properly since it doesn't know the content/state of the
>>> file before it starts to execute on it?
>>>
>>>
>>>
>>>> Thanks,
>>>> Lakmali
>>>>
>>>> --
>>>> Lakmali Baminiwatta
>>>> Senior Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> lean.enterprise.middleware
>>>> mobile:  +94 71 2335936
>>>> blog : lakmali.com
>>>>
>>>>
>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Technical Lead - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>>
>>
>>
>>
>> --
>> Regards,
>> Uvindra
>>
>> Mobile: 33962
>>
>
>
>
> --
> Nuwan Dias
>
> Technical Lead - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>



-- 
Regards,
Uvindra

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

Re: [Dev] APIM snapse file system migration

[Uvindra Dias Jayasinha]

Ya this is fine but it has a real impact on complicating the migration.
This issue has been there with migrating previous releases as well. We need
to put more thought into reducing migration complexity when we add new
features, more complications means more issues to deal with and lots of
time consumed.

On 13 January 2016 at 07:47, Nuwan Dias <nuw...@wso2.com> wrote:

>
>
> On Wed, Jan 13, 2016 at 6:07 PM, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> Ok if we allow these to be extended then we should not be adding our
>> logic from the product here, but seems that we have made improvements
>> within the extensible part.
>>
>
> They are being modified for extending the extension support :). Ex: We
> have the ability to change the message type of an error response. So we
> allow users to modify a property on the sequence to do that. In the next
> release we figure out that we can also change the status code using the
> same mechanism. So we add another property on the same sequence so users
> can change the status code as well using extensions. Therefore there are
> valid cases for modifying these sequences during feature releases.
>
>>
>> We should add our changes to a default sequence that is used unless it
>> has been overridden by a custom sequence that has been defined for this
>> purpose by the user. That way we can upgrade the default sequences and
>> users who haven't overridden it get to use it.
>>
>> But seems that the way thing are now we can achieve the same affect by
>> asking users to copy the sequences over if they have made any
>> customizations. Either way if they have done customizations they need to
>> copy them. So we can simply ask them to do that and not try to migrate
>> automatically.
>>
>>
>> :) Agree with Lakmali, who replied on the other thread, user should only
>> copy the sequences if they have customized them. No need to do anything
>> with the migration client
>>
>> On 13 January 2016 at 07:26, Nuwan Dias <nuw...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Jan 13, 2016 at 5:51 PM, Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
>>>> I think the only way is to complicate the migration instructions,
>>>>
>>>> If user has customized any sequences they need to copy them over
>>>> manually to latest pack and we will use those.(Discalimer to user: You
>>>> maybe missing out on the latest changes shipped with the default sequences
>>>> in the latest pack)
>>>>
>>>> Migration client doesn't need to do anything then, its not in a
>>>> position to make a proper decision anyway.
>>>>
>>>> But its pretty clear this is a hole in our extensibility. We dont
>>>> provide official extension points to make changes in the areas that these
>>>> specific sequences address, forcing uses to change the default sequences
>>>> that are shipped which makes upgrading a pain. We should address this in a
>>>> future release
>>>>
>>>
>>> The sole purpose of these sequences are for extensibility. Ex: To change
>>> the message type of a auth failure error. So its understandable that people
>>> edit them.
>>>
>>>>
>>>> On 13 January 2016 at 05:23, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta <lakm...@wso2.com
>>>>> > wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> In our migration guide, currently what we instruct is to copy &
>>>>>> replace repository/deployment/server/synapse-config/default directory and
>>>>>> repository/tenants from previous APIM version to new APIM version. Here 
>>>>>> we
>>>>>> mention to skip replacing  _TokenAPI_.xml, _RevokeAPI_.xml and
>>>>>> _AuthorizeAPI_.xml files by which latest files of those will be remained.
>>>>>>
>>>>>> But with this approach, it will replace other system sequences with
>>>>>> old ones (ex: _auth_failure_handler_.xml, _cors_request_handler_.xml,
>>>>>> main.xml, fault.xml, etc). So some of the fixes went to those will be
>>>>>> missed out. We have two ways to include those changes to the new version.
>>>>>>
>>>>>> 1. Include the missing changes through migration client.
>>>>>> 2. Get the

Re: [Dev] APIM snapse file system migration

[Uvindra Dias Jayasinha]

@Lakmali, +1, we can do it this way.


@All, just a suggestion for next time, it would be great if we could
leverage the API Import/Export feature to move existing APIs over to the
new product version, since its available in the product. Users dont need to
manually copy them over then. WDYT?

On 13 January 2016 at 09:48, Uvindra Dias Jayasinha <uvin...@wso2.com>
wrote:

> Ya this is fine but it has a real impact on complicating the migration.
> This issue has been there with migrating previous releases as well. We need
> to put more thought into reducing migration complexity when we add new
> features, more complications means more issues to deal with and lots of
> time consumed.
>
> On 13 January 2016 at 07:47, Nuwan Dias <nuw...@wso2.com> wrote:
>
>>
>>
>> On Wed, Jan 13, 2016 at 6:07 PM, Uvindra Dias Jayasinha <uvin...@wso2.com
>> > wrote:
>>
>>> Ok if we allow these to be extended then we should not be adding our
>>> logic from the product here, but seems that we have made improvements
>>> within the extensible part.
>>>
>>
>> They are being modified for extending the extension support :). Ex: We
>> have the ability to change the message type of an error response. So we
>> allow users to modify a property on the sequence to do that. In the next
>> release we figure out that we can also change the status code using the
>> same mechanism. So we add another property on the same sequence so users
>> can change the status code as well using extensions. Therefore there are
>> valid cases for modifying these sequences during feature releases.
>>
>>>
>>> We should add our changes to a default sequence that is used unless it
>>> has been overridden by a custom sequence that has been defined for this
>>> purpose by the user. That way we can upgrade the default sequences and
>>> users who haven't overridden it get to use it.
>>>
>>> But seems that the way thing are now we can achieve the same affect by
>>> asking users to copy the sequences over if they have made any
>>> customizations. Either way if they have done customizations they need to
>>> copy them. So we can simply ask them to do that and not try to migrate
>>> automatically.
>>>
>>>
>>> :) Agree with Lakmali, who replied on the other thread, user should only
>>> copy the sequences if they have customized them. No need to do anything
>>> with the migration client
>>>
>>> On 13 January 2016 at 07:26, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 13, 2016 at 5:51 PM, Uvindra Dias Jayasinha <
>>>> uvin...@wso2.com> wrote:
>>>>
>>>>> I think the only way is to complicate the migration instructions,
>>>>>
>>>>> If user has customized any sequences they need to copy them over
>>>>> manually to latest pack and we will use those.(Discalimer to user: You
>>>>> maybe missing out on the latest changes shipped with the default sequences
>>>>> in the latest pack)
>>>>>
>>>>> Migration client doesn't need to do anything then, its not in a
>>>>> position to make a proper decision anyway.
>>>>>
>>>>> But its pretty clear this is a hole in our extensibility. We dont
>>>>> provide official extension points to make changes in the areas that these
>>>>> specific sequences address, forcing uses to change the default sequences
>>>>> that are shipped which makes upgrading a pain. We should address this in a
>>>>> future release
>>>>>
>>>>
>>>> The sole purpose of these sequences are for extensibility. Ex: To
>>>> change the message type of a auth failure error. So its understandable that
>>>> people edit them.
>>>>
>>>>>
>>>>> On 13 January 2016 at 05:23, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta <
>>>>>> lakm...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> In our migration guide, currently what we instruct is to copy &
>>>>>>> replace repository/deployment/server/synapse-config/default directory 
>>>>>>> and
>>>>>>> repository/tenants from previous APIM version to new APIM version. Here 
>>>>

Re: [Dev] APIM snapse file system migration

[Uvindra Dias Jayasinha]

Hi Nuwan, I was only referring to using this to move the synapse configs
over, since users need to copy these over manually currently. But if there
is no value in doing it this way then its fine. I understand that the
exported API package has a lot more information that we dont really need
for this purpose since we are reusing the same registry

On 13 January 2016 at 11:06, Lakmali Baminiwatta <lakm...@wso2.com> wrote:

>
>
> On 13 January 2016 at 18:34, Lakmali Baminiwatta <lakm...@wso2.com> wrote:
>
>> If we don't involve migration client to handle this, AFAIU we have below
>> approaches.
>>
>> 1. If they don't have customizations:
>>
>>- Option 1:  Copy everything from old synapse config to new synapse
>>config. Later replace default sequences, apis of ST and tenants from the
>>latest resources.
>>- Option 2:  Provide an instructions to avoid copying these sequences
>>from old pack to new pack, which will remain the latest sequences. Note
>>that have ~10 sequences. This needs to be taken care for each tenant as
>>well.
>>
>> Apparently we can't go with option 2, since in tenant space, default
> sequences are added only in the very first tenant load (adds if auth
> failure sequence is not there). So we can't just rely on that. Hence I
> think we should do as Option 1.
>
> 2. If there are customizations: Apply the customizations to default latest
>> sequences and replace in ST and tenant spaces.
>>
>> Thanks,
>> Lakmali
>>
>>
>>
>> On 13 January 2016 at 18:08, Lakmali Baminiwatta <lakm...@wso2.com>
>> wrote:
>>
>>> According to the current instructions, latest sequences get replaced by
>>> the old sequences. So what I am suggesting is that we can assume that it's
>>> the responsibility of the person who does the migration to add the
>>> customizations to latest default sequences which reside in
>>> repository/resources/apim-synapse-config and then migration client will
>>> blindly replace old sequences with those.
>>>
>>> On 13 January 2016 at 17:56, Nuwan Dias <nuw...@wso2.com> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 13, 2016 at 5:51 PM, Uvindra Dias Jayasinha <
>>>> uvin...@wso2.com> wrote:
>>>>
>>>>> I think the only way is to complicate the migration instructions,
>>>>>
>>>>> If user has customized any sequences they need to copy them over
>>>>> manually to latest pack and we will use those.(Discalimer to user: You
>>>>> maybe missing out on the latest changes shipped with the default sequences
>>>>> in the latest pack)
>>>>>
>>>>> Migration client doesn't need to do anything then, its not in a
>>>>> position to make a proper decision anyway.
>>>>>
>>>>> But its pretty clear this is a hole in our extensibility. We dont
>>>>> provide official extension points to make changes in the areas that these
>>>>> specific sequences address, forcing uses to change the default sequences
>>>>> that are shipped which makes upgrading a pain. We should address this in a
>>>>> future release
>>>>>
>>>>
>>>> The sole purpose of these sequences are for extensibility. Ex: To
>>>> change the message type of a auth failure error. So its understandable that
>>>> people edit them.
>>>>
>>>>>
>>>>> On 13 January 2016 at 05:23, Nuwan Dias <nuw...@wso2.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, Jan 13, 2016 at 3:30 PM, Lakmali Baminiwatta <
>>>>>> lakm...@wso2.com> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> In our migration guide, currently what we instruct is to copy &
>>>>>>> replace repository/deployment/server/synapse-config/default directory 
>>>>>>> and
>>>>>>> repository/tenants from previous APIM version to new APIM version. Here 
>>>>>>> we
>>>>>>> mention to skip replacing  _TokenAPI_.xml, _RevokeAPI_.xml and
>>>>>>> _AuthorizeAPI_.xml files by which latest files of those will be 
>>>>>>> remained.
>>>>>>>
>>>>>>> But with this approach, it will replace other system sequences with
>>>>>>> old ones (ex: _auth_failure_handler_.xml, _cors_req

Re: [Dev] Null pointer exception from api gateway component when logging as the tenant-admin

[Uvindra Dias Jayasinha]

Hi Harsha,

This seems to be happening because you dont have the default sequences that
are shipped with the APIM pack. When you login to the tenant for the first
time the sequence are copied over to that tenant space, but you dont have
these in the MDM pack. The Error and Warning above the NPE also shows that
this is the case.

We have not handled the scenario where the gateway feature would be used in
when an actual synapse gateway does not exist. We need to validate the
gateway type and only carry this step out if the gateway type is synapse to
avoid the NPE.

On 14 October 2015 at 23:07, Harshan Liyanage  wrote:

> Hi all,
>
> I'm getting the below exception when logging as the tenant-admin (latest
> EMM build). We are using org.wso2.carbon.apimgt.gateway.feature.group
> version 4.3.0-SNAPSHOT at the moment.
>
> Could please someone from APIM team can shed a light on this issue?
>
> [2015-10-14 23:00:18,924] hars...@wso2.com [1] [MDM] WARN
> {org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator} -  Could not
> create
> /home/harshan/development/cdm/wso2mdm-2.0.0-SNAPSHOT/repository/tenants/1/synapse-configs/default/sequences
> [2015-10-14 23:00:18,925] hars...@wso2.com [1] [MDM]ERROR
> {org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator} -  Error
> while reading API manager specific synapse
> sequencesjava.io.FileNotFoundException: File
> '/home/harshan/development/cdm/wso2mdm-2.0.0-SNAPSHOT/repository/resources/apim-synapse-config/_auth_failure_handler_.xml'
> does not exist
> [2015-10-14 23:00:18,927] hars...@wso2.com [1] [MDM]ERROR
> {org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator} -  Couldn't
> serialise the initial synapse configuration for the domain : wso2.com
> java.lang.NullPointerException
> at
> org.apache.synapse.config.xml.MultiXMLConfigurationSerializer.serializeSequence(MultiXMLConfigurationSerializer.java:470)
> at
> org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator.createTenantSynapseConfigHierarchy(TenantServiceCreator.java:234)
> at
> org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator.createdConfigurationContext(TenantServiceCreator.java:141)
> at
> org.wso2.carbon.core.multitenancy.utils.TenantAxisUtils.createTenantConfigurationContext(TenantAxisUtils.java:357)
> at
> org.wso2.carbon.core.multitenancy.utils.TenantAxisUtils.getTenantConfigurationContext(TenantAxisUtils.java:148)
> at
> org.wso2.carbon.core.services.util.CarbonAuthenticationUtil.onSuccessAdminLogin(CarbonAuthenticationUtil.java:134)
> at
> org.wso2.carbon.core.services.authentication.AuthenticationAdmin.login(AuthenticationAdmin.java:117)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:212)
> at
> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:117)
> at
> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
> at
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:110)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
> at
> org.apache.axis2.transport.local.LocalTransportReceiver.processMessage(LocalTransportReceiver.java:169)
> at
> org.apache.axis2.transport.local.LocalTransportReceiver.processMessage(LocalTransportReceiver.java:82)
> at
> org.wso2.carbon.core.transports.local.CarbonLocalTransportSender.finalizeSendWithToAddress(CarbonLocalTransportSender.java:45)
> at
> org.apache.axis2.transport.local.LocalTransportSender.invoke(LocalTransportSender.java:77)
> at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:442)
> at
> org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:430)
> at
> org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:225)
> at
> org.apache.axis2.client.OperationClient.execute(OperationClient.java:149)
> at
> org.wso2.carbon.authenticator.stub.AuthenticationAdminStub.login(AuthenticationAdminStub.java:659)
> at
> org.wso2.carbon.authenticator.proxy.AuthenticationAdminClient.login(AuthenticationAdminClient.java:64)
> at
> org.wso2.carbon.ui.DefaultCarbonAuthenticator.doAuthentication(DefaultCarbonAuthenticator.java:119)
> at
> org.wso2.carbon.ui.AbstractCarbonUIAuthenticator.handleSecurity(AbstractCarbonUIAuthenticator.java:218)
> at
> org.wso2.carbon.ui.BasicAuthUIAuthenticator.authenticate(BasicAuthUIAuthenticator.java:83)
> at
> org.wso2.carbon.ui.CarbonUILoginUtil.handleLogin(CarbonUILoginUtil.java:377)
> at
> org.wso2.carbon.ui.CarbonSecuredHttpContext.handleSecurity(CarbonSecuredHttpContext.java:244)
> at
> 

Re: [Dev] Null pointer exception from api gateway component when logging as the tenant-admin

[Uvindra Dias Jayasinha]

Ok, to confirm what Amila is saying, Harsha can you check the value of the
** element in the api-manager.xml of MDM? The value should be
*None*.



On 15 October 2015 at 10:05, Amila De Silva <ami...@wso2.com> wrote:

> Hi Uvindra,
>
> IIRC TenantServiceCreator ( the task which deploys synapse artifacts upon
> a TenantLoading) is only registered, if the Gateway type is Synapse. If we
>  set it to None, then that task should not get registered.
>
>
> On Thursday, October 15, 2015, Uvindra Dias Jayasinha <uvin...@wso2.com>
> wrote:
>
>> Hi Harsha,
>>
>> This seems to be happening because you dont have the default sequences
>> that are shipped with the APIM pack. When you login to the tenant for the
>> first time the sequence are copied over to that tenant space, but you dont
>> have these in the MDM pack. The Error and Warning above the NPE also shows
>> that this is the case.
>>
>> We have not handled the scenario where the gateway feature would be used
>> in when an actual synapse gateway does not exist. We need to validate the
>> gateway type and only carry this step out if the gateway type is synapse to
>> avoid the NPE.
>>
>> On 14 October 2015 at 23:07, Harshan Liyanage <hars...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> I'm getting the below exception when logging as the tenant-admin (latest
>>> EMM build). We are using org.wso2.carbon.apimgt.gateway.feature.group
>>> version 4.3.0-SNAPSHOT at the moment.
>>>
>>> Could please someone from APIM team can shed a light on this issue?
>>>
>>> [2015-10-14 23:00:18,924] hars...@wso2.com [1] [MDM] WARN
>>> {org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator} -  Could not
>>> create
>>> /home/harshan/development/cdm/wso2mdm-2.0.0-SNAPSHOT/repository/tenants/1/synapse-configs/default/sequences
>>> [2015-10-14 23:00:18,925] hars...@wso2.com [1] [MDM]ERROR
>>> {org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator} -  Error
>>> while reading API manager specific synapse
>>> sequencesjava.io.FileNotFoundException: File
>>> '/home/harshan/development/cdm/wso2mdm-2.0.0-SNAPSHOT/repository/resources/apim-synapse-config/_auth_failure_handler_.xml'
>>> does not exist
>>> [2015-10-14 23:00:18,927] hars...@wso2.com [1] [MDM]ERROR
>>> {org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator} -  Couldn't
>>> serialise the initial synapse configuration for the domain : wso2.com
>>> java.lang.NullPointerException
>>> at
>>> org.apache.synapse.config.xml.MultiXMLConfigurationSerializer.serializeSequence(MultiXMLConfigurationSerializer.java:470)
>>> at
>>> org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator.createTenantSynapseConfigHierarchy(TenantServiceCreator.java:234)
>>> at
>>> org.wso2.carbon.apimgt.gateway.internal.TenantServiceCreator.createdConfigurationContext(TenantServiceCreator.java:141)
>>> at
>>> org.wso2.carbon.core.multitenancy.utils.TenantAxisUtils.createTenantConfigurationContext(TenantAxisUtils.java:357)
>>> at
>>> org.wso2.carbon.core.multitenancy.utils.TenantAxisUtils.getTenantConfigurationContext(TenantAxisUtils.java:148)
>>> at
>>> org.wso2.carbon.core.services.util.CarbonAuthenticationUtil.onSuccessAdminLogin(CarbonAuthenticationUtil.java:134)
>>> at
>>> org.wso2.carbon.core.services.authentication.AuthenticationAdmin.login(AuthenticationAdmin.java:117)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>>> at
>>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:606)
>>> at
>>> org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:212)
>>> at
>>> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:117)
>>> at
>>> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
>>> at
>>> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:110)
>>> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
>>> at
>>> org.apache.axis2.transport.local.LocalTransportReceiver.processMessage(LocalTransportReceiver.java:169)
>>> at
>>> org.apache.axis2.transport.local.LocalTransportReceiver.processMessage(LocalTransportRe

Re: [Dev] How to handle REST_URL_POSTFIX property when Query Parameter values are defined

[Uvindra Dias Jayasinha]

In conclusion we will handling this in the following way,

if a given endpoint URL contains a ? character we will ideitify this as a
scenario where query parameters are used and we will add the property
name=REST_URL_POSTFIX scope=axis2 action=remove/ so that it applied
for the given endpoint.

This will be handled at velocity template level.



On 24 July 2015 at 15:04, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 I found the following on SO[1] which is the exact same problem we are
 discussing here. The solution for it provided here[2]. So is this the way
 we should go about it? We can adjust our velocity_template to generate the
 synapse config conditionally. That way no need to do any changes to
 publisher and the fix will be seamless from a user perspective.


 [1]
 http://stackoverflow.com/questions/19978652/wso2-esb-http-endpoint-uri-parameters
 [2]
 http://stackoverflow.com/questions/19774923/wso2-esb-4-7-0-api-url-mapping

 On 24 July 2015 at 14:49, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 Ok so from what you saying is that even though we are setting that
 attribute at resource level it is not getting considered at endpoint level.
 So have been doing things incorrectly? How is the correct way of achieving
 this functionality with synapse?

 On 24 July 2015 at 14:46, Isuru Udana isu...@wso2.com wrote:

 It's related to the API Resource not to the HTTP Endpoint.

 Please note that there is no relationship between how we define resource
 url (whether it is url-template or url-mapping) with the HTTP Endpoint url.
 And we can't even introduce a such relationship.



 On Fri, Jul 24, 2015 at 2:41 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 Im referring to the attribute in the* resource* tag, that how we are
 triggering the different functionalities

 On 24 July 2015 at 14:39, Isuru Udana isu...@wso2.com wrote:

 In both scenarios you can see, HTTP Endpoint contains an url-template.

 endpoint name=admin--pathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx?name={uri.var.name}
 /

   /endpoint

  endpoint name=admin--noPathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx/

   /endpoint

 On Fri, Jul 24, 2015 at 2:35 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 Attached are two synpase files generated with API Manager for the
 above use cases. Ok end of the day we need to support both attributes, 
 its
 critical to API Manager functionality. Do you agree that from a 
 functional
 perspective our expectation is correct? Because there is nothing to stop
 someone from writing an API in this manner.

 On 24 July 2015 at 14:23, Isuru Udana isu...@wso2.com wrote:



 On Fri, Jul 24, 2015 at 2:10 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 In our velocity template we are conditionally deciding when the
 url-mapping attribute or uri-template attribute should be used in the
 synapse config generated for each API, eher is the velocity template 
 logic,

 #if($resource.getUriTemplate().contains({) ||
 ($resource.getUriTemplate().contains(*) 
 !$resource.getUriTemplate().endsWith(/*)))
 *uri-template=*$resource.getUriTemplate()
 #else
 *url-mapping=*$resource.getUriTemplate()
 #end

 So we are specifying this attribute based on API Managers
 requirement. The synapse engine does not consider this as invalid
 so we expect that the synapse engine should honour the attribute 
 defined.

 HTTP Endpoint in synapse doesn't support url-mapping attribute. Can
 you post a sample generated API Config with this ?


 So we need the functionality of both the uri-template and
 url-mapping attributes for our HTTP endpoint based APIs, but not at the
 same time obviously. Its either one or the other for a given resource.

 There is no relationship between API resources and HTTP endpoint

 By specifying these two attributes we are already implying that we
 are expecting different functionality(the user expects the same). So 
 its a
 bit difficult justifying having to manually set this from the 
 publisher.

 WDYT?

 +1. If we can handle this automatically without a user interaction,
 that's the best way to handle it. And we need to consider the impact of 
 the
 changes (config migration issues, etc.)


 On 24 July 2015 at 13:45, Isuru Udana isu...@wso2.com wrote:

 Hi Uvindra,

 I think the correct approach is to completely remove
 REST_URL_POSTFIX getting appended for HTTP Endpoint. And append only 
 if the
 user configure to do so.
 Initially we implemented HTTP Endpoint in that way. But somehow
 implementation has changed now.
 I am not sure whether we are too late to revert to the original
 implementation now.

 If we cannot revert back,
 For ESB, we can simply remove the REST_URL_POSTFIX from the config
 and for AM, we need a easy way to do that from UI.

 On Fri, Jul 24

Re: [Dev] How to handle REST_URL_POSTFIX property when Query Parameter values are defined

[Uvindra Dias Jayasinha]

Ok so from what you saying is that even though we are setting that
attribute at resource level it is not getting considered at endpoint level.
So have been doing things incorrectly? How is the correct way of achieving
this functionality with synapse?

On 24 July 2015 at 14:46, Isuru Udana isu...@wso2.com wrote:

 It's related to the API Resource not to the HTTP Endpoint.

 Please note that there is no relationship between how we define resource
 url (whether it is url-template or url-mapping) with the HTTP Endpoint url.
 And we can't even introduce a such relationship.



 On Fri, Jul 24, 2015 at 2:41 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Im referring to the attribute in the* resource* tag, that how we are
 triggering the different functionalities

 On 24 July 2015 at 14:39, Isuru Udana isu...@wso2.com wrote:

 In both scenarios you can see, HTTP Endpoint contains an url-template.

 endpoint name=admin--pathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx?name={uri.var.name}/

   /endpoint

  endpoint name=admin--noPathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx/

   /endpoint

 On Fri, Jul 24, 2015 at 2:35 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 Attached are two synpase files generated with API Manager for the above
 use cases. Ok end of the day we need to support both attributes, its
 critical to API Manager functionality. Do you agree that from a functional
 perspective our expectation is correct? Because there is nothing to stop
 someone from writing an API in this manner.

 On 24 July 2015 at 14:23, Isuru Udana isu...@wso2.com wrote:



 On Fri, Jul 24, 2015 at 2:10 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 In our velocity template we are conditionally deciding when the
 url-mapping attribute or uri-template attribute should be used in the
 synapse config generated for each API, eher is the velocity template 
 logic,

 #if($resource.getUriTemplate().contains({) ||
 ($resource.getUriTemplate().contains(*) 
 !$resource.getUriTemplate().endsWith(/*)))
 *uri-template=*$resource.getUriTemplate()
 #else
 *url-mapping=*$resource.getUriTemplate()
 #end

 So we are specifying this attribute based on API Managers requirement
 . The synapse engine does not consider this as invalid so we expect
 that the synapse engine should honour the attribute defined.

 HTTP Endpoint in synapse doesn't support url-mapping attribute. Can
 you post a sample generated API Config with this ?


 So we need the functionality of both the uri-template and url-mapping
 attributes for our HTTP endpoint based APIs, but not at the same time
 obviously. Its either one or the other for a given resource.

 There is no relationship between API resources and HTTP endpoint

 By specifying these two attributes we are already implying that we
 are expecting different functionality(the user expects the same). So its 
 a
 bit difficult justifying having to manually set this from the publisher.

 WDYT?

 +1. If we can handle this automatically without a user interaction,
 that's the best way to handle it. And we need to consider the impact of 
 the
 changes (config migration issues, etc.)


 On 24 July 2015 at 13:45, Isuru Udana isu...@wso2.com wrote:

 Hi Uvindra,

 I think the correct approach is to completely remove
 REST_URL_POSTFIX getting appended for HTTP Endpoint. And append only if 
 the
 user configure to do so.
 Initially we implemented HTTP Endpoint in that way. But somehow
 implementation has changed now.
 I am not sure whether we are too late to revert to the original
 implementation now.

 If we cannot revert back,
 For ESB, we can simply remove the REST_URL_POSTFIX from the config
 and for AM, we need a easy way to do that from UI.

 On Fri, Jul 24, 2015 at 1:31 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 We need to come up with $subject.

 The issue related to this has been highlighted in [1]

 The REST_URL_POSTFIX property appends the url-mapping of a given
 resource to the end of the api endpoint in synapse. This is applied by
 synapse for all APIs that are defined.

 For example,

 *API URL* - http://localhost:8280/noPathParam/1.0/
 *Endpoint URL* - http://localhost:8281/sampleAPI
 *GET Resource(url-mapping)* - somepath

 Now invoking the above GET resource of the API,

GET
 http://localhost:8280/noPathParam/1.0/somepath

 will translate to,

 GET http://localhost:8281/sampleAPI/somepath



 The problem happens when there are Query Parameters. Since resource
 url-mapping or uri-template attribute is getting appended by default 
 to the
 end of the URL, it is getting added after the Query Parameter, as 
 follows,


 *API URL* - http://localhost:8280/pathParam/1.0/
 *Endpoint URL* -
 http://localhost:8281/sampleAPI

Re: [Dev] How to handle REST_URL_POSTFIX property when Query Parameter values are defined

[Uvindra Dias Jayasinha]

Attached are two synpase files generated with API Manager for the above use
cases. Ok end of the day we need to support both attributes, its critical
to API Manager functionality. Do you agree that from a functional
perspective our expectation is correct? Because there is nothing to stop
someone from writing an API in this manner.

On 24 July 2015 at 14:23, Isuru Udana isu...@wso2.com wrote:



 On Fri, Jul 24, 2015 at 2:10 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 In our velocity template we are conditionally deciding when the
 url-mapping attribute or uri-template attribute should be used in the
 synapse config generated for each API, eher is the velocity template logic,

 #if($resource.getUriTemplate().contains({) ||
 ($resource.getUriTemplate().contains(*) 
 !$resource.getUriTemplate().endsWith(/*)))
 *uri-template=*$resource.getUriTemplate()
 #else
 *url-mapping=*$resource.getUriTemplate()
 #end

 So we are specifying this attribute based on API Managers requirement.
 The synapse engine does not consider this as invalid so we expect that the
 synapse engine should honour the attribute defined.

 HTTP Endpoint in synapse doesn't support url-mapping attribute. Can you
 post a sample generated API Config with this ?


 So we need the functionality of both the uri-template and url-mapping
 attributes for our HTTP endpoint based APIs, but not at the same time
 obviously. Its either one or the other for a given resource.

 There is no relationship between API resources and HTTP endpoint

 By specifying these two attributes we are already implying that we are
 expecting different functionality(the user expects the same). So its a bit
 difficult justifying having to manually set this from the publisher.

 WDYT?

 +1. If we can handle this automatically without a user interaction, that's
 the best way to handle it. And we need to consider the impact of the
 changes (config migration issues, etc.)


 On 24 July 2015 at 13:45, Isuru Udana isu...@wso2.com wrote:

 Hi Uvindra,

 I think the correct approach is to completely remove REST_URL_POSTFIX
 getting appended for HTTP Endpoint. And append only if the user configure
 to do so.
 Initially we implemented HTTP Endpoint in that way. But somehow
 implementation has changed now.
 I am not sure whether we are too late to revert to the original
 implementation now.

 If we cannot revert back,
 For ESB, we can simply remove the REST_URL_POSTFIX from the config and
 for AM, we need a easy way to do that from UI.

 On Fri, Jul 24, 2015 at 1:31 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 We need to come up with $subject.

 The issue related to this has been highlighted in [1]

 The REST_URL_POSTFIX property appends the url-mapping of a given
 resource to the end of the api endpoint in synapse. This is applied by
 synapse for all APIs that are defined.

 For example,

 *API URL* - http://localhost:8280/noPathParam/1.0/
 *Endpoint URL* - http://localhost:8281/sampleAPI
 *GET Resource(url-mapping)* - somepath

 Now invoking the above GET resource of the API,

GET http://localhost:8280/noPathParam/1.0/somepath

 will translate to,

 GET http://localhost:8281/sampleAPI/somepath



 The problem happens when there are Query Parameters. Since resource
 url-mapping or uri-template attribute is getting appended by default to the
 end of the URL, it is getting added after the Query Parameter, as follows,


 *API URL* - http://localhost:8280/pathParam/1.0/
 *Endpoint URL* - http://localhost:8281/sampleAPI?name={uri.var.name}
 *GET Resource(url-template)* - {name}

 Now invoking the above GET resource of the API

GET http://localhost:8280/pathParam/1.0/somename


 will translate to,

 GET http://localhost:8281/sampleAPI?name=
 *somename/somename*

 instead of the expected,

 GET http://localhost:8281/sampleAPI?name=somename


 So the problem here is that synapse treats both url-mapping and
 url-template resources the same way. What should happen is that the
 REST_URL_POSTFIX property should only be considered if the url-mapping
 attribute is specified *and not when uri-template attribute exists*.

 There is no url mapping involved with HTTP endpoint (only url template
 is there). And there is no relationship between API resources and HTTP
 Endpoint.

 Thanks.



 So can we get this fixed at synapse level? We believe this is the
 correct place to solve this issue


 [1] https://wso2.org/jira/browse/APIMANAGER-4002

 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 *Isuru Udana*
 Associate Technical Lead
 WSO2 Inc.; http://wso2.com
 email: isu...@wso2.com cell: +94 77 3791887
 blog: http://mytecheye.blogspot.com/




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 *Isuru Udana*
 Associate Technical Lead
 WSO2 Inc.; http://wso2.com
 email: isu...@wso2.com cell: +94 77 3791887
 blog: http://mytecheye.blogspot.com

Re: [Dev] How to handle REST_URL_POSTFIX property when Query Parameter values are defined

[Uvindra Dias Jayasinha]

Im referring to the attribute in the* resource* tag, that how we are
triggering the different functionalities

On 24 July 2015 at 14:39, Isuru Udana isu...@wso2.com wrote:

 In both scenarios you can see, HTTP Endpoint contains an url-template.

 endpoint name=admin--pathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx?name={uri.var.name}/

   /endpoint

  endpoint name=admin--noPathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx/

   /endpoint

 On Fri, Jul 24, 2015 at 2:35 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Attached are two synpase files generated with API Manager for the above
 use cases. Ok end of the day we need to support both attributes, its
 critical to API Manager functionality. Do you agree that from a functional
 perspective our expectation is correct? Because there is nothing to stop
 someone from writing an API in this manner.

 On 24 July 2015 at 14:23, Isuru Udana isu...@wso2.com wrote:



 On Fri, Jul 24, 2015 at 2:10 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 In our velocity template we are conditionally deciding when the
 url-mapping attribute or uri-template attribute should be used in the
 synapse config generated for each API, eher is the velocity template logic,

 #if($resource.getUriTemplate().contains({) ||
 ($resource.getUriTemplate().contains(*) 
 !$resource.getUriTemplate().endsWith(/*)))
 *uri-template=*$resource.getUriTemplate()
 #else
 *url-mapping=*$resource.getUriTemplate()
 #end

 So we are specifying this attribute based on API Managers requirement.
 The synapse engine does not consider this as invalid so we expect that the
 synapse engine should honour the attribute defined.

 HTTP Endpoint in synapse doesn't support url-mapping attribute. Can you
 post a sample generated API Config with this ?


 So we need the functionality of both the uri-template and url-mapping
 attributes for our HTTP endpoint based APIs, but not at the same time
 obviously. Its either one or the other for a given resource.

 There is no relationship between API resources and HTTP endpoint

 By specifying these two attributes we are already implying that we are
 expecting different functionality(the user expects the same). So its a bit
 difficult justifying having to manually set this from the publisher.

 WDYT?

 +1. If we can handle this automatically without a user interaction,
 that's the best way to handle it. And we need to consider the impact of the
 changes (config migration issues, etc.)


 On 24 July 2015 at 13:45, Isuru Udana isu...@wso2.com wrote:

 Hi Uvindra,

 I think the correct approach is to completely remove REST_URL_POSTFIX
 getting appended for HTTP Endpoint. And append only if the user configure
 to do so.
 Initially we implemented HTTP Endpoint in that way. But somehow
 implementation has changed now.
 I am not sure whether we are too late to revert to the original
 implementation now.

 If we cannot revert back,
 For ESB, we can simply remove the REST_URL_POSTFIX from the config and
 for AM, we need a easy way to do that from UI.

 On Fri, Jul 24, 2015 at 1:31 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 We need to come up with $subject.

 The issue related to this has been highlighted in [1]

 The REST_URL_POSTFIX property appends the url-mapping of a given
 resource to the end of the api endpoint in synapse. This is applied by
 synapse for all APIs that are defined.

 For example,

 *API URL* - http://localhost:8280/noPathParam/1.0/
 *Endpoint URL* - http://localhost:8281/sampleAPI
 *GET Resource(url-mapping)* - somepath

 Now invoking the above GET resource of the API,

GET http://localhost:8280/noPathParam/1.0/somepath

 will translate to,

 GET http://localhost:8281/sampleAPI/somepath



 The problem happens when there are Query Parameters. Since resource
 url-mapping or uri-template attribute is getting appended by default to 
 the
 end of the URL, it is getting added after the Query Parameter, as 
 follows,


 *API URL* - http://localhost:8280/pathParam/1.0/
 *Endpoint URL* - http://localhost:8281/sampleAPI?name={uri.var.name}
 *GET Resource(url-template)* - {name}

 Now invoking the above GET resource of the API

GET http://localhost:8280/pathParam/1.0/somename


 will translate to,

 GET http://localhost:8281/sampleAPI?name=
 *somename/somename*

 instead of the expected,

 GET http://localhost:8281/sampleAPI?name=somename


 So the problem here is that synapse treats both url-mapping and
 url-template resources the same way. What should happen is that the
 REST_URL_POSTFIX property should only be considered if the url-mapping
 attribute is specified *and not when uri-template attribute exists*.

 There is no url

Re: [Dev] How to handle REST_URL_POSTFIX property when Query Parameter values are defined

[Uvindra Dias Jayasinha]

In our velocity template we are conditionally deciding when the url-mapping
attribute or uri-template attribute should be used in the synapse config
generated for each API, eher is the velocity template logic,

#if($resource.getUriTemplate().contains({) ||
($resource.getUriTemplate().contains(*) 
!$resource.getUriTemplate().endsWith(/*)))
*uri-template=*$resource.getUriTemplate()
#else
*url-mapping=*$resource.getUriTemplate()
#end

So we are specifying this attribute based on API Managers requirement. The
synapse engine does not consider this as invalid so we expect that the
synapse engine should honour the attribute defined.

So we need the functionality of both the uri-template and url-mapping
attributes for our HTTP endpoint based APIs, but not at the same time
obviously. Its either one or the other for a given resource. By specifying
these two attributes we are already implying that we are expecting
different functionality(the user expects the same). So its a bit difficult
justifying having to manually set this from the publisher.

WDYT?

On 24 July 2015 at 13:45, Isuru Udana isu...@wso2.com wrote:

 Hi Uvindra,

 I think the correct approach is to completely remove REST_URL_POSTFIX
 getting appended for HTTP Endpoint. And append only if the user configure
 to do so.
 Initially we implemented HTTP Endpoint in that way. But somehow
 implementation has changed now.
 I am not sure whether we are too late to revert to the original
 implementation now.

 If we cannot revert back,
 For ESB, we can simply remove the REST_URL_POSTFIX from the config and for
 AM, we need a easy way to do that from UI.

 On Fri, Jul 24, 2015 at 1:31 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 We need to come up with $subject.

 The issue related to this has been highlighted in [1]

 The REST_URL_POSTFIX property appends the url-mapping of a given resource
 to the end of the api endpoint in synapse. This is applied by synapse for
 all APIs that are defined.

 For example,

 *API URL* - http://localhost:8280/noPathParam/1.0/
 *Endpoint URL* - http://localhost:8281/sampleAPI
 *GET Resource(url-mapping)* - somepath

 Now invoking the above GET resource of the API,

GET http://localhost:8280/noPathParam/1.0/somepath

 will translate to,

 GET http://localhost:8281/sampleAPI/somepath



 The problem happens when there are Query Parameters. Since resource
 url-mapping or uri-template attribute is getting appended by default to the
 end of the URL, it is getting added after the Query Parameter, as follows,


 *API URL* - http://localhost:8280/pathParam/1.0/
 *Endpoint URL* - http://localhost:8281/sampleAPI?name={uri.var.name}
 *GET Resource(url-template)* - {name}

 Now invoking the above GET resource of the API

GET http://localhost:8280/pathParam/1.0/somename


 will translate to,

 GET http://localhost:8281/sampleAPI?name=
 *somename/somename*

 instead of the expected,

 GET http://localhost:8281/sampleAPI?name=somename


 So the problem here is that synapse treats both url-mapping and
 url-template resources the same way. What should happen is that the
 REST_URL_POSTFIX property should only be considered if the url-mapping
 attribute is specified *and not when uri-template attribute exists*.

 There is no url mapping involved with HTTP endpoint (only url template is
 there). And there is no relationship between API resources and HTTP
 Endpoint.

 Thanks.



 So can we get this fixed at synapse level? We believe this is the correct
 place to solve this issue


 [1] https://wso2.org/jira/browse/APIMANAGER-4002

 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 *Isuru Udana*
 Associate Technical Lead
 WSO2 Inc.; http://wso2.com
 email: isu...@wso2.com cell: +94 77 3791887
 blog: http://mytecheye.blogspot.com/




-- 
Regards,
Uvindra

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

[Dev] How to handle REST_URL_POSTFIX property when Query Parameter values are defined

[Uvindra Dias Jayasinha]

We need to come up with $subject.

The issue related to this has been highlighted in [1]

The REST_URL_POSTFIX property appends the url-mapping of a given resource
to the end of the api endpoint in synapse. This is applied by synapse for
all APIs that are defined.

For example,

*API URL* - http://localhost:8280/noPathParam/1.0/
*Endpoint URL* - http://localhost:8281/sampleAPI
*GET Resource(url-mapping)* - somepath

Now invoking the above GET resource of the API,

   GET http://localhost:8280/noPathParam/1.0/somepath

will translate to,

GET http://localhost:8281/sampleAPI/somepath



The problem happens when there are Query Parameters. Since resource
url-mapping or uri-template attribute is getting appended by default to the
end of the URL, it is getting added after the Query Parameter, as follows,


*API URL* - http://localhost:8280/pathParam/1.0/
*Endpoint URL* - http://localhost:8281/sampleAPI?name={uri.var.name}
*GET Resource(url-template)* - {name}

Now invoking the above GET resource of the API

   GET http://localhost:8280/pathParam/1.0/somename


will translate to,

GET http://localhost:8281/sampleAPI?name=
*somename/somename*

instead of the expected,

GET http://localhost:8281/sampleAPI?name=somename


So the problem here is that synapse treats both url-mapping and
url-template resources the same way. What should happen is that the
REST_URL_POSTFIX property should only be considered if the url-mapping
attribute is specified *and not when uri-template attribute exists*.


So can we get this fixed at synapse level? We believe this is the correct
place to solve this issue


[1] https://wso2.org/jira/browse/APIMANAGER-4002

-- 
Regards,
Uvindra

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

Re: [Dev] How to handle REST_URL_POSTFIX property when Query Parameter values are defined

[Uvindra Dias Jayasinha]

I found the following on SO[1] which is the exact same problem we are
discussing here. The solution for it provided here[2]. So is this the way
we should go about it? We can adjust our velocity_template to generate the
synapse config conditionally. That way no need to do any changes to
publisher and the fix will be seamless from a user perspective.


[1]
http://stackoverflow.com/questions/19978652/wso2-esb-http-endpoint-uri-parameters
[2]
http://stackoverflow.com/questions/19774923/wso2-esb-4-7-0-api-url-mapping

On 24 July 2015 at 14:49, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 Ok so from what you saying is that even though we are setting that
 attribute at resource level it is not getting considered at endpoint level.
 So have been doing things incorrectly? How is the correct way of achieving
 this functionality with synapse?

 On 24 July 2015 at 14:46, Isuru Udana isu...@wso2.com wrote:

 It's related to the API Resource not to the HTTP Endpoint.

 Please note that there is no relationship between how we define resource
 url (whether it is url-template or url-mapping) with the HTTP Endpoint url.
 And we can't even introduce a such relationship.



 On Fri, Jul 24, 2015 at 2:41 PM, Uvindra Dias Jayasinha uvin...@wso2.com
  wrote:

 Im referring to the attribute in the* resource* tag, that how we are
 triggering the different functionalities

 On 24 July 2015 at 14:39, Isuru Udana isu...@wso2.com wrote:

 In both scenarios you can see, HTTP Endpoint contains an url-template.

 endpoint name=admin--pathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx?name={uri.var.name}/

   /endpoint

  endpoint name=admin--noPathParam_APIproductionEndpoint_0

  http uri-template=
 http://ws.cdyne.com/phoneverify/phoneverify.asmx/

   /endpoint

 On Fri, Jul 24, 2015 at 2:35 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 Attached are two synpase files generated with API Manager for the
 above use cases. Ok end of the day we need to support both attributes, its
 critical to API Manager functionality. Do you agree that from a functional
 perspective our expectation is correct? Because there is nothing to stop
 someone from writing an API in this manner.

 On 24 July 2015 at 14:23, Isuru Udana isu...@wso2.com wrote:



 On Fri, Jul 24, 2015 at 2:10 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 In our velocity template we are conditionally deciding when the
 url-mapping attribute or uri-template attribute should be used in the
 synapse config generated for each API, eher is the velocity template 
 logic,

 #if($resource.getUriTemplate().contains({) ||
 ($resource.getUriTemplate().contains(*) 
 !$resource.getUriTemplate().endsWith(/*)))
 *uri-template=*$resource.getUriTemplate()
 #else
 *url-mapping=*$resource.getUriTemplate()
 #end

 So we are specifying this attribute based on API Managers requirement
 . The synapse engine does not consider this as invalid so we expect
 that the synapse engine should honour the attribute defined.

 HTTP Endpoint in synapse doesn't support url-mapping attribute. Can
 you post a sample generated API Config with this ?


 So we need the functionality of both the uri-template and
 url-mapping attributes for our HTTP endpoint based APIs, but not at the
 same time obviously. Its either one or the other for a given resource.

 There is no relationship between API resources and HTTP endpoint

 By specifying these two attributes we are already implying that we
 are expecting different functionality(the user expects the same). So 
 its a
 bit difficult justifying having to manually set this from the publisher.

 WDYT?

 +1. If we can handle this automatically without a user interaction,
 that's the best way to handle it. And we need to consider the impact of 
 the
 changes (config migration issues, etc.)


 On 24 July 2015 at 13:45, Isuru Udana isu...@wso2.com wrote:

 Hi Uvindra,

 I think the correct approach is to completely remove
 REST_URL_POSTFIX getting appended for HTTP Endpoint. And append only 
 if the
 user configure to do so.
 Initially we implemented HTTP Endpoint in that way. But somehow
 implementation has changed now.
 I am not sure whether we are too late to revert to the original
 implementation now.

 If we cannot revert back,
 For ESB, we can simply remove the REST_URL_POSTFIX from the config
 and for AM, we need a easy way to do that from UI.

 On Fri, Jul 24, 2015 at 1:31 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 We need to come up with $subject.

 The issue related to this has been highlighted in [1]

 The REST_URL_POSTFIX property appends the url-mapping of a given
 resource to the end of the api endpoint in synapse. This is applied by
 synapse for all APIs that are defined.

 For example,

 *API URL* - http://localhost:8280/noPathParam/1.0/
 *Endpoint URL* - http://localhost

Re: [Dev] Error when generating/refreshing keys in APIM 1.9.0

[Uvindra Dias Jayasinha]

According to the exception seems there is a duplicate entry value when
trying to insert into AM_APPLICATION_REGISTRATION table. Seems that the
same Application is getting registered multiple times. Can you let us know
the exacts steps you are following?

On 24 July 2015 at 16:13, Amalka Subasinghe ama...@wso2.com wrote:

 Hi,

 I'm upgrading API Manager to 1.9.0 in App Factory setup.

 When generating/refreshing keys I'm getting following exception.
 I removed consumer key from AM_APPLICATION_KEY_MAPPING and try to generate
 the key again - but the exception is still throwing

 Any idea about this?

 TID: [0] [AM] [2015-07-24 10:23:06,385]  INFO
 {JAGGERY.site.blocks.subscription.subscription-add.ajax.subscription-add:jag}
 -
 generateApplicationKey
 {JAGGERY.site.blocks.subscription.subscription-add.ajax.subscription-add:jag}
 TID: [0] [AM] [2015-07-24 10:23:06,389]  INFO
 {JAGGERY.site.blocks.subscription.subscription-add.ajax.subscription-add:jag}
 -  -store.getApplicationKey-
 {JAGGERY.site.blocks.subscription.subscription-add.ajax.subscription-add:jag}
 TID: [0] [AM] [2015-07-24 10:23:06,469] ERROR
 {org.wso2.carbon.apimgt.impl.dao.ApiMgtDAO} -  Error occurred while
 creating an Application Registration Entry for Application :
 DefaultApplication {org.wso2.carbon.apimgt.impl.dao.ApiMgtDAO}
 com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException:
 Duplicate entry '1-1-PRODUCTION' for key 'SUBSCRIBER_ID'
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
 Method)
 at
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 at
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
 at com.mysql.jdbc.Util.handleNewInstance(Util.java:411)
 at com.mysql.jdbc.Util.getInstance(Util.java:386)
 at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1041)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4237)
 at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4169)
 at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2617)
 at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2778)
 at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2825)
 at
 com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:2156)
 at
 com.mysql.jdbc.PreparedStatement.execute(PreparedStatement.java:1379)
 at
 org.wso2.carbon.apimgt.impl.dao.ApiMgtDAO.createApplicationRegistrationEntry(ApiMgtDAO.java:308)
 at
 org.wso2.carbon.apimgt.impl.workflow.ApplicationRegistrationSimpleWorkflowExecutor.complete(ApplicationRegistrationSimpleWorkflowExecutor.java:80)
 at
 org.wso2.carbon.apimgt.impl.workflow.ApplicationRegistrationSimpleWorkflowExecutor.execute(ApplicationRegistrationSimpleWorkflowExecutor.java:58)
 at
 org.wso2.carbon.apimgt.impl.APIConsumerImpl.requestApprovalForApplicationRegistration(APIConsumerImpl.java:2179)
 at
 org.wso2.carbon.apimgt.impl.UserAwareAPIConsumer.requestApprovalForApplicationRegistration(UserAwareAPIConsumer.java:34)
 at
 org.wso2.carbon.apimgt.hostobjects.APIStoreHostObject.jsFunction_getApplicationKey(APIStoreHostObject.java:751)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:606)
 at org.mozilla.javascript.MemberBox.invoke(MemberBox.java:126)
 at org.mozilla.javascript.FunctionObject.call(FunctionObject.java:386)
 at
 org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:52)
 at
 org.jaggeryjs.rhino.store.modules.subscription.c2._c_anonymous_2(/store/modules/subscription/key.jag:41)
 at
 org.jaggeryjs.rhino.store.modules.subscription.c2.call(/store/modules/subscription/key.jag)
 at
 org.mozilla.javascript.ScriptRuntime.applyOrCall(ScriptRuntime.java:2430)
 at
 org.mozilla.javascript.BaseFunction.execIdCall(BaseFunction.java:269)
 at
 org.mozilla.javascript.IdFunctionObject.call(IdFunctionObject.java:97)
 at
 org.mozilla.javascript.optimizer.OptRuntime.call2(OptRuntime.java:42)
 at
 org.jaggeryjs.rhino.store.modules.subscription.c0._c_anonymous_9(/store/modules/subscription/module.jag:32)
 at
 org.jaggeryjs.rhino.store.modules.subscription.c0.call(/store/modules/subscription/module.jag)
 at
 org.mozilla.javascript.optimizer.OptRuntime.callN(OptRuntime.java:52)
 at
 org.jaggeryjs.rhino.store.site.blocks.subscription.subscription_add.ajax.c0._c_anonymous_1(/store/site/blocks/subscription/subscription-add/ajax/subscription-add.jag:240)
 at
 

Re: [Dev] API Manager associating a new version of an API with its previous version

[Uvindra Dias Jayasinha]

I think what is trying to be achieved here is to iterate through all
existing versions of a given API and subscribe to all applications that
those API versions have subscribed to in the latest version.

For example,

*foo:1.0.0* is subscribed to by *Application1* and *foo:2.0.0* is
subscribed to by *Application2*. So with current logic *foo:3.0.0* will be
subscribed to by both *Application1* and *Application2*.

The problem is when both* foo:1.0.0* and *foo:2.0.0* are subscribed to
*Application1*.Then when publishing *foo:3.0.0 *we get the Subscription
Already Exists exception thrown in the JIRA ticket.

Instead of blindly trying to insert and triggering the exception we can
check to see if there is already an entry for a given ApiID, ApplicationID
and TierID in the AM_SUBSCRIPTION table. If there is already(as we can see
in the above example which is valid) then we simply should not add the
subscription. No rxt or DB changes needed, WDYT?


On 22 July 2015 at 13:56, Nuwan Dias nuw...@wso2.com wrote:

 Adding this to the rxt is the correct way IMO. But we have to be careful
 when fixing this for API Manager 1.9.1. We cannot do migrations for 1.9.1.
 Hence cannot introduce rxt changes. Since the error trace is harmless, I
 think we should comment and ignore the error for 1.9.1 and make it a point
 to fix properly in 1.10.

 Thanks,
 NuwanD.

 On Wed, Jul 22, 2015 at 1:54 PM, Sanjeewa Malalgoda sanje...@wso2.com
 wrote:

 Adding new field to rxt would be ideal IMO. I noticed some users already
 reported this issue.

 Thanks,
 sanjeewa.

 On Wed, Jul 22, 2015 at 1:00 PM, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 What if we keep the parent apiID in the asset itself, rather than in
 new DB column. (by adding the field to api.rxt)

 Cheers,
 Ruwan

 On Wed, Jul 22, 2015 at 12:44 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 The correct way I can think of solving this is to store the apiID of
 the version that is being copied from in the newly created api object so
 that we can make the association later on when we are publishing the new
 api version.

 This means we will need to add a new column to the AM_API table to
 store this, hence Im trying to see if  there is an alternative.



 On 22 July 2015 at 12:38, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Thanks for the suggestion Ruwan, but we are not on ES yet and wont be
 for sometime so we wont be able to exploit that feature.

 On 22 July 2015 at 12:32, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 We are having same issue and being solved in AppM 1.1.0. We were
 informed that ES 2.0 has grouping capability. So we may be exploit that 
 to
 correlate versions. We plan to back-port some ES 2.0 functions to ES 1
 branch to get this done.

 SajithAR working on this.

 Cheers,
 Ruwan


 On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 This applies to API Manager 1.9.0, but this is true for previous
 versions as well. When trying to fix the following ticket[1] I came 
 across
 this scenario,

1. API named *foo* with versions *1.0.0* and *2.0.0* has
existing subscriptions.
2. Create a new version of the same API *3.0.0* from *2.0.0*.
3. Publish API *foo:3.0.0* with the Require  Re-Subscription
option disabled.
4. What should happen is that the subscriptions of *foo:2.0.0*
should be applied to *foo:3.0.0 *automatically


 The problem is step *2 *and *3* above are separate so there is
 currently no association between *foo:2.0.0* and *foo:3.0.0*.

 So how do we determine which API version *foo:3.0.0* was created
 from so that we can transfer that APIs subscriptions at the time of
 publishing?

 Is there a way to do this without adding a new attribute to the
 newly created API to indicate whihc version it was copied from?

 [1] https://wso2.org/jira/browse/APIMANAGER-3971
 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736

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




 --

 *Sanjeewa Malalgoda*
 WSO2 Inc.
 Mobile : +94713068779

  http://sanjeewamalalgoda.blogspot.com/blog
 :http://sanjeewamalalgoda.blogspot.com/
 http://sanjeewamalalgoda.blogspot.com/



 ___
 Dev mailing list

[Dev] API Manager associating a new version of an API with its previous version

[Uvindra Dias Jayasinha]

This applies to API Manager 1.9.0, but this is true for previous versions
as well. When trying to fix the following ticket[1] I came across this
scenario,

   1. API named *foo* with versions *1.0.0* and *2.0.0* has existing
   subscriptions.
   2. Create a new version of the same API *3.0.0* from *2.0.0*.
   3. Publish API *foo:3.0.0* with the Require  Re-Subscription option
   disabled.
   4. What should happen is that the subscriptions of *foo:2.0.0* should
   be applied to *foo:3.0.0 *automatically


The problem is step *2 *and *3* above are separate so there is currently no
association between *foo:2.0.0* and *foo:3.0.0*.

So how do we determine which API version *foo:3.0.0* was created from so
that we can transfer that APIs subscriptions at the time of publishing?

Is there a way to do this without adding a new attribute to the newly
created API to indicate whihc version it was copied from?

[1] https://wso2.org/jira/browse/APIMANAGER-3971
-- 
Regards,
Uvindra

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

Re: [Dev] API Manager associating a new version of an API with its previous version

[Uvindra Dias Jayasinha]

The correct way I can think of solving this is to store the apiID of the
version that is being copied from in the newly created api object so that
we can make the association later on when we are publishing the new api
version.

This means we will need to add a new column to the AM_API table to store
this, hence Im trying to see if  there is an alternative.



On 22 July 2015 at 12:38, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 Thanks for the suggestion Ruwan, but we are not on ES yet and wont be for
 sometime so we wont be able to exploit that feature.

 On 22 July 2015 at 12:32, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 We are having same issue and being solved in AppM 1.1.0. We were informed
 that ES 2.0 has grouping capability. So we may be exploit that to correlate
 versions. We plan to back-port some ES 2.0 functions to ES 1 branch to get
 this done.

 SajithAR working on this.

 Cheers,
 Ruwan


 On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 This applies to API Manager 1.9.0, but this is true for previous
 versions as well. When trying to fix the following ticket[1] I came across
 this scenario,

1. API named *foo* with versions *1.0.0* and *2.0.0* has
existing subscriptions.
2. Create a new version of the same API *3.0.0* from *2.0.0*.
3. Publish API *foo:3.0.0* with the Require  Re-Subscription
option disabled.
4. What should happen is that the subscriptions of *foo:2.0.0*
should be applied to *foo:3.0.0 *automatically


 The problem is step *2 *and *3* above are separate so there is
 currently no association between *foo:2.0.0* and *foo:3.0.0*.

 So how do we determine which API version *foo:3.0.0* was created from
 so that we can transfer that APIs subscriptions at the time of publishing?

 Is there a way to do this without adding a new attribute to the newly
 created API to indicate whihc version it was copied from?

 [1] https://wso2.org/jira/browse/APIMANAGER-3971
 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736




 --
 Regards,
 Uvindra

 Mobile: 33962




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager associating a new version of an API with its previous version

[Uvindra Dias Jayasinha]

@Sajith, we already have those options you have mentioned in API Manager,
if we are publishing a new version of an API either we can choose to make
the users of the API to re-subscribe or we can automatically transfer over
the subscriptions from the previous version.

On 22 July 2015 at 14:25, Sajith Ariyarathna sajit...@wso2.com wrote:

 Hi Uvindra,

 As pointed out by RuwanA, AppM had a similar problem when creating a new
 version of a web app based on an existing version. In AppM, when
 'Publish'ing version *2.0.0* of web app *Foo* (which was created from
 *Foo* version *1.0.0*), version *1.0.0* is 'Un-publish'ed (because only
 one version of a web app is shown to end-users in the store) and subscriptions
 from version *1.0.0* are moved to version *2.0.0*. This is not exactly
 your situation in APIM, but you can see that subscriptions are moved to the
 new version when it is 'Publish'ed.

 Suggestion: you should give the option to the Publisher to decide whether
 to copy or move subscriptions to the new version. You can give 03 options,
 Copy Subscriptions to v2.0.0, Move Subscriptions to v2.0.0 and Do
 Nothing. I believe it will improve the user experience for API Publisher.

 As suggested by RuwanA, keeping the 'parentID' in the asset or in the DB
 will also help to maintain a version hierarchy and in future releases you
 can use that data to do API grouping or to show a versioning tree.

 Thanks and Regards.


 On Wed, Jul 22, 2015 at 1:00 PM, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 What if we keep the parent apiID in the asset itself, rather than in
 new DB column. (by adding the field to api.rxt)

 Cheers,
 Ruwan

 On Wed, Jul 22, 2015 at 12:44 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 The correct way I can think of solving this is to store the apiID of the
 version that is being copied from in the newly created api object so that
 we can make the association later on when we are publishing the new api
 version.

 This means we will need to add a new column to the AM_API table to store
 this, hence Im trying to see if  there is an alternative.



 On 22 July 2015 at 12:38, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Thanks for the suggestion Ruwan, but we are not on ES yet and wont be
 for sometime so we wont be able to exploit that feature.

 On 22 July 2015 at 12:32, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 We are having same issue and being solved in AppM 1.1.0. We were
 informed that ES 2.0 has grouping capability. So we may be exploit that to
 correlate versions. We plan to back-port some ES 2.0 functions to ES 1
 branch to get this done.

 SajithAR working on this.

 Cheers,
 Ruwan


 On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 This applies to API Manager 1.9.0, but this is true for previous
 versions as well. When trying to fix the following ticket[1] I came 
 across
 this scenario,

1. API named *foo* with versions *1.0.0* and *2.0.0* has
existing subscriptions.
2. Create a new version of the same API *3.0.0* from *2.0.0*.
3. Publish API *foo:3.0.0* with the Require  Re-Subscription
option disabled.
4. What should happen is that the subscriptions of *foo:2.0.0*
should be applied to *foo:3.0.0 *automatically


 The problem is step *2 *and *3* above are separate so there is
 currently no association between *foo:2.0.0* and *foo:3.0.0*.

 So how do we determine which API version *foo:3.0.0* was created
 from so that we can transfer that APIs subscriptions at the time of
 publishing?

 Is there a way to do this without adding a new attribute to the newly
 created API to indicate whihc version it was copied from?

 [1] https://wso2.org/jira/browse/APIMANAGER-3971
 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736

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




 --
 Sajith Ariyarathna
 Software Engineer; WSO2, Inc.;  http://wso2.com/
 mobile: +94 77 6602284, +94 71 3951048




-- 
Regards,
Uvindra

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

Re: [Dev] Source code for wso2 API Manager 1.8

[Uvindra Dias Jayasinha]

Hi Rohit,

API Manager 1.8.0 is not on github and is only available via our public svn
repo, please refer[1].

API Manager source code is here[2] and you will need to refer to this
pom[3] to identify which component source versions to refer to for API
Manager 1.8.0

[1] https://docs.wso2.com/display/AM180/Building+from+Source
[2]
https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/components/apimgt/
[3]
https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/product-releases/chunk-14/components/pom.xml

On 22 July 2015 at 11:12, rohit rohitab...@gmail.com wrote:

 Hello All,

 Where Can I find source code for  wso2 API Manager 1.8? I was able to find
 source for 1.9 at github
 Thanks in advance.



 --
 View this message in context:
 http://wso2-oxygen-tank.10903.n7.nabble.com/Source-code-for-wso2-API-Manager-1-8-tp122130.html
 Sent from the WSO2 Development mailing list archive at Nabble.com.
 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager associating a new version of an API with its previous version

[Uvindra Dias Jayasinha]

Let me summarise,

If the requirement is to only transfer the subscriptions of the API version
we are copying from, then we need to store the parent API version in the
rxt or the DB as has been already suggested.

But if the requirement is to transfer all subscriptions of an existing APIs
versions to the new API we can simply do a duplicate check before trying to
insert subscription data which is a simple fix.

So which is the correct functionality?


On 22 July 2015 at 14:36, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 @Sajith, we already have those options you have mentioned in API Manager,
 if we are publishing a new version of an API either we can choose to make
 the users of the API to re-subscribe or we can automatically transfer over
 the subscriptions from the previous version.

 On 22 July 2015 at 14:25, Sajith Ariyarathna sajit...@wso2.com wrote:

 Hi Uvindra,

 As pointed out by RuwanA, AppM had a similar problem when creating a new
 version of a web app based on an existing version. In AppM, when
 'Publish'ing version *2.0.0* of web app *Foo* (which was created from
 *Foo* version *1.0.0*), version *1.0.0* is 'Un-publish'ed (because only
 one version of a web app is shown to end-users in the store) and 
 subscriptions
 from version *1.0.0* are moved to version *2.0.0*. This is not exactly
 your situation in APIM, but you can see that subscriptions are moved to the
 new version when it is 'Publish'ed.

 Suggestion: you should give the option to the Publisher to decide whether
 to copy or move subscriptions to the new version. You can give 03 options,
 Copy Subscriptions to v2.0.0, Move Subscriptions to v2.0.0 and Do
 Nothing. I believe it will improve the user experience for API Publisher.

 As suggested by RuwanA, keeping the 'parentID' in the asset or in the DB
 will also help to maintain a version hierarchy and in future releases you
 can use that data to do API grouping or to show a versioning tree.

 Thanks and Regards.


 On Wed, Jul 22, 2015 at 1:00 PM, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 What if we keep the parent apiID in the asset itself, rather than in
 new DB column. (by adding the field to api.rxt)

 Cheers,
 Ruwan

 On Wed, Jul 22, 2015 at 12:44 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 The correct way I can think of solving this is to store the apiID of
 the version that is being copied from in the newly created api object so
 that we can make the association later on when we are publishing the new
 api version.

 This means we will need to add a new column to the AM_API table to
 store this, hence Im trying to see if  there is an alternative.



 On 22 July 2015 at 12:38, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Thanks for the suggestion Ruwan, but we are not on ES yet and wont be
 for sometime so we wont be able to exploit that feature.

 On 22 July 2015 at 12:32, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 We are having same issue and being solved in AppM 1.1.0. We were
 informed that ES 2.0 has grouping capability. So we may be exploit that 
 to
 correlate versions. We plan to back-port some ES 2.0 functions to ES 1
 branch to get this done.

 SajithAR working on this.

 Cheers,
 Ruwan


 On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 This applies to API Manager 1.9.0, but this is true for previous
 versions as well. When trying to fix the following ticket[1] I came 
 across
 this scenario,

1. API named *foo* with versions *1.0.0* and *2.0.0* has
existing subscriptions.
2. Create a new version of the same API *3.0.0* from *2.0.0*.
3. Publish API *foo:3.0.0* with the Require  Re-Subscription
option disabled.
4. What should happen is that the subscriptions of *foo:2.0.0*
should be applied to *foo:3.0.0 *automatically


 The problem is step *2 *and *3* above are separate so there is
 currently no association between *foo:2.0.0* and *foo:3.0.0*.

 So how do we determine which API version *foo:3.0.0* was created
 from so that we can transfer that APIs subscriptions at the time of
 publishing?

 Is there a way to do this without adding a new attribute to the
 newly created API to indicate whihc version it was copied from?

 [1] https://wso2.org/jira/browse/APIMANAGER-3971
 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com

Re: [Dev] API Manager associating a new version of an API with its previous version

[Uvindra Dias Jayasinha]

Ticket has been updated with the requirement, please add 1.10 release to
API Manager JIRA to set the fix version so that this can be prioritised.

On 22 July 2015 at 15:10, Nuwan Dias nuw...@wso2.com wrote:



 On Wed, Jul 22, 2015 at 2:55 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Let me summarise,

 If the requirement is to only transfer the subscriptions of the API
 version we are copying from, then we need to store the parent API version
 in the rxt or the DB as has been already suggested.


 I believe this is the correct requirement and the solution.

 Note: We should only copy the active subscriptions. Not the ones on hold
 due to workflow approvals.


 But if the requirement is to transfer all subscriptions of an existing
 APIs versions to the new API we can simply do a duplicate check before
 trying to insert subscription data which is a simple fix.

 So which is the correct functionality?


 I think for 1.9.1, we should just live with the duplicate check since
 we're unable to do any rxt changes. But make a note in 1.10 so we do not
 iterate through all versions and copy subscriptions of all versions.


 On 22 July 2015 at 14:36, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 @Sajith, we already have those options you have mentioned in API
 Manager, if we are publishing a new version of an API either we can choose
 to make the users of the API to re-subscribe or we can automatically
 transfer over the subscriptions from the previous version.

 On 22 July 2015 at 14:25, Sajith Ariyarathna sajit...@wso2.com wrote:

 Hi Uvindra,

 As pointed out by RuwanA, AppM had a similar problem when creating a
 new version of a web app based on an existing version. In AppM, when
 'Publish'ing version *2.0.0* of web app *Foo* (which was created from
 *Foo* version *1.0.0*), version *1.0.0* is 'Un-publish'ed (because only
 one version of a web app is shown to end-users in the store) and 
 subscriptions
 from version *1.0.0* are moved to version *2.0.0*. This is not exactly
 your situation in APIM, but you can see that subscriptions are moved to the
 new version when it is 'Publish'ed.

 Suggestion: you should give the option to the Publisher to decide
 whether to copy or move subscriptions to the new version. You can give 03
 options, Copy Subscriptions to v2.0.0, Move Subscriptions to v2.0.0 and
 Do Nothing. I believe it will improve the user experience for API
 Publisher.

 As suggested by RuwanA, keeping the 'parentID' in the asset or in the
 DB will also help to maintain a version hierarchy and in future releases
 you can use that data to do API grouping or to show a versioning tree.

 Thanks and Regards.


 On Wed, Jul 22, 2015 at 1:00 PM, Ruwan Abeykoon ruw...@wso2.com
 wrote:

 Hi Uvindra,
 What if we keep the parent apiID in the asset itself, rather than
 in new DB column. (by adding the field to api.rxt)

 Cheers,
 Ruwan

 On Wed, Jul 22, 2015 at 12:44 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 The correct way I can think of solving this is to store the apiID of
 the version that is being copied from in the newly created api object so
 that we can make the association later on when we are publishing the new
 api version.

 This means we will need to add a new column to the AM_API table to
 store this, hence Im trying to see if  there is an alternative.



 On 22 July 2015 at 12:38, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Thanks for the suggestion Ruwan, but we are not on ES yet and wont
 be for sometime so we wont be able to exploit that feature.

 On 22 July 2015 at 12:32, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 We are having same issue and being solved in AppM 1.1.0. We were
 informed that ES 2.0 has grouping capability. So we may be exploit 
 that to
 correlate versions. We plan to back-port some ES 2.0 functions to ES 1
 branch to get this done.

 SajithAR working on this.

 Cheers,
 Ruwan


 On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 This applies to API Manager 1.9.0, but this is true for previous
 versions as well. When trying to fix the following ticket[1] I came 
 across
 this scenario,

1. API named *foo* with versions *1.0.0* and *2.0.0* has
existing subscriptions.
2. Create a new version of the same API *3.0.0* from
*2.0.0*.
3. Publish API *foo:3.0.0* with the Require
Re-Subscription option disabled.
4. What should happen is that the subscriptions of
*foo:2.0.0* should be applied to *foo:3.0.0 *automatically


 The problem is step *2 *and *3* above are separate so there is
 currently no association between *foo:2.0.0* and *foo:3.0.0*.

 So how do we determine which API version *foo:3.0.0* was
 created from so that we can transfer that APIs subscriptions at the 
 time of
 publishing?

 Is there a way to do this without adding a new attribute to the
 newly created API to indicate whihc version it was copied from?

 [1] https://wso2.org/jira/browse/APIMANAGER-3971

Re: [Dev] API Manager associating a new version of an API with its previous version

[Uvindra Dias Jayasinha]

Hi Ruwan,

Updating the rxt is a good option, thanks for suggesting. But since this
will lead to a data migration we cant do it for 1.9.1 release, so we will
prioritise the fix for the 1.10 release.

On 22 July 2015 at 13:00, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 What if we keep the parent apiID in the asset itself, rather than in
 new DB column. (by adding the field to api.rxt)

 Cheers,
 Ruwan

 On Wed, Jul 22, 2015 at 12:44 PM, Uvindra Dias Jayasinha uvin...@wso2.com
  wrote:

 The correct way I can think of solving this is to store the apiID of the
 version that is being copied from in the newly created api object so that
 we can make the association later on when we are publishing the new api
 version.

 This means we will need to add a new column to the AM_API table to store
 this, hence Im trying to see if  there is an alternative.



 On 22 July 2015 at 12:38, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Thanks for the suggestion Ruwan, but we are not on ES yet and wont be
 for sometime so we wont be able to exploit that feature.

 On 22 July 2015 at 12:32, Ruwan Abeykoon ruw...@wso2.com wrote:

 Hi Uvindra,
 We are having same issue and being solved in AppM 1.1.0. We were
 informed that ES 2.0 has grouping capability. So we may be exploit that to
 correlate versions. We plan to back-port some ES 2.0 functions to ES 1
 branch to get this done.

 SajithAR working on this.

 Cheers,
 Ruwan


 On Wed, Jul 22, 2015 at 12:21 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 This applies to API Manager 1.9.0, but this is true for previous
 versions as well. When trying to fix the following ticket[1] I came across
 this scenario,

1. API named *foo* with versions *1.0.0* and *2.0.0* has
existing subscriptions.
2. Create a new version of the same API *3.0.0* from *2.0.0*.
3. Publish API *foo:3.0.0* with the Require  Re-Subscription
option disabled.
4. What should happen is that the subscriptions of *foo:2.0.0*
should be applied to *foo:3.0.0 *automatically


 The problem is step *2 *and *3* above are separate so there is
 currently no association between *foo:2.0.0* and *foo:3.0.0*.

 So how do we determine which API version *foo:3.0.0* was created
 from so that we can transfer that APIs subscriptions at the time of
 publishing?

 Is there a way to do this without adding a new attribute to the newly
 created API to indicate whihc version it was copied from?

 [1] https://wso2.org/jira/browse/APIMANAGER-3971
 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962

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




 --

 *Ruwan Abeykoon*
 *Architect,*
 *WSO2, Inc. http://wso2.com http://wso2.com/ *
 *lean.enterprise.middleware.*

 email: ruw...@wso2.com
 phone:(+94) 39736




-- 
Regards,
Uvindra

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

Re: [Dev] The table 'UM_USER_ROLE' is full

[Uvindra Dias Jayasinha]

Doesn't look like an issue with the script itself, this could happen
because you have run out of disk space on the DB cluster or the table has
reached its max allocated size, see following links,

http://stackoverflow.com/questions/730579/error-1114-hy000-the-table-is-full
http://stackoverflow.com/questions/21850287/error-1114-hy000-the-table-xxx-is-full
http://stackoverflow.com/questions/19639343/error-while-executing-sql-file-error-1114-mysql-table-is-full

On 3 July 2015 at 12:06, Nirodha Pramod niro...@wso2.com wrote:

 Hi,

 The script was taken from the AM 1.9.0 registry database script.

 -Nirodha

 On Fri, Jul 3, 2015 at 12:05 PM, Nirodha Pramod niro...@wso2.com wrote:

 Hi,

 I get the below set of errors when running the registry database script
 on a mysql NDB cluster. Could this be a script issue or Mysql config issue?

 Any thought on this would be appreciated.




 Query OK, 0 rows affected (0.24 sec)

 Query OK, 0 rows affected (0.20 sec)

 ERROR 1114 (HY000): The table 'UM_ROLE_PERMISSION' is full
 Query OK, 0 rows affected (0.21 sec)

 ERROR 1114 (HY000): The table 'UM_USER_ROLE' is full
 ERROR 1114 (HY000): The table 'UM_SHARED_USER_ROLE' is full
 ERROR 1296 (HY000): Got error 708 'No more attribute metadata records
 (increase MaxNoOfAttributes)' from NDBCLUSTER
 ERROR 1114 (HY000): The table 'UM_USER_ATTRIBUTE' is full
 ERROR 1114 (HY000): The table 'UM_DIALECT' is full
 ERROR 1296 (HY000): Got error 708 'No more attribute metadata records
 (increase MaxNoOfAttributes)' from NDBCLUSTER
 ERROR 1114 (HY000): The table 'UM_PROFILE_CONFIG' is full
 ERROR 1114 (HY000): The table 'UM_HYBRID_ROLE' is full
 ERROR 1296 (HY000): Got error 708 'No more attribute metadata records
 (increase MaxNoOfAttributes)' from NDBCLUSTER
 ERROR 1114 (HY000): The table 'UM_SYSTEM_ROLE' is full
 ERROR 1114 (HY000): The table 'UM_SYSTEM_USER_ROLE' is full
 ERROR 1114 (HY000): The table 'UM_HYBRID_REMEMBER_ME' is full
 ERROR 1114 (HY000): The table 'UM_CUSTOM_USERSTORE' is full

 ​Thanks,
 Nirodha​

 --

 *Nirodha Gallage*
 Associate Technical Lead, QA.
 WSO2 Inc.: http://wso2.com/
 Mobile: +94716429078




 --

 *Nirodha Gallage*
 Associate Technical Lead, QA.
 WSO2 Inc.: http://wso2.com/
 Mobile: +94716429078

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




-- 
Regards,
Uvindra

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

Re: [Dev] [APIM][1.6] Authorization scheme not checked for access token generation

[Uvindra Dias Jayasinha]

Currently we are not taking any action using the auth scheme hence we dont
process it at all. Since this is a specialized endpoint we are not we only
dealing with auth Headers.

We could check the auth scheme for the sake of simply sending an error
message back if it is invalid but other than that the scheme itself is of
no value to us in this case, all that is required is the base64 encoded
hash. There is no functional issue with the way things work currently, this
is only a matter of correctness when it comes to honouring the spec
perfectly.

On 11 June 2015 at 14:34, Shani Ranasinghe sh...@wso2.com wrote:

 Hi,

 I have tested APIM 1.6 with grant type is password, and used Authorization
 header as both Bearer [1], and Basic [2], and passed the value
 base64encode(consumer key:consumer secret), as follows. Both of them return
 the same access token.

 After talking offline with Uvindra, I came to know that the is this
 authorization scheme is not being checked from the code, but only the value
 is used, and hence the observation.

 Even though functionally it is alright, according to specification it is
 not the correct way to pass the values.

 Is it as designed? Should we not check the authorization scheme?

 [1] curl -k -d
 grant_type=passwordusername=usernamepassword=passwordscope=PRODUCTION
 -H Authorization: Basic base64encode(consumer key : consumer secret) ,
 Content-Type: application/x-www-form-urlencoded
 https://localhost:8243/token


 [2] curl -k -d
 grant_type=passwordusername=usernamepassword=passwordscope=PRODUCTION
 -H Authorization: Bearer base64encode(consumer key : consumer secret) ,
 Content-Type: application/x-www-form-urlencoded
 https://localhost:8243/token

 --
 Thanks and Regards
 *,Shani Ranasinghe*
 Senior Software Engineer
 WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 77 2273555
 Blog: http://waysandmeans.blogspot.com/
 linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab




-- 
Regards,
Uvindra

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

Re: [Dev] Writing wire logs to a separate file other than the wso2carbon.log

[Uvindra Dias Jayasinha]

Ok found the solution to this,

You simply need to add the *additivity* property with the value false as
follows,

log4j.logger.org.apache.synapse.transport.http.wire=DEBUG, WIRE_LOGFILE
log4j.*additivity*.org.apache.synapse.transport.http.wire=*false*


This will prevent the log request from propagating up the hierarchy of
parent loggers(and the log4j.rootLogger in this case). So it will only be
handled by the WIRE_LOGFILE appender and be written to
ESB_HOME/repository/logs/wso2wire.log
without being sent to other appenders(such as the CARBON_LOGFILE appender
which is responsible for writing the wso2carbon.log)


On 10 June 2015 at 12:37, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 I've defined a custom appender in the log4j.properties of ESB 4.8.1 as
 follows.


 # WIRE_LOGFILE is set to be a DailyRollingFileAppender using a
 PatternLayout.

 log4j.appender.WIRE_LOGFILE=org.wso2.custom.logging.appenders.WireDailyRollingFileAppender
 # Log file will be overridden by the configuration setting in the DB
 # This path should be relative to WSO2 Carbon Home

 log4j.appender.WIRE_LOGFILE.File=${carbon.home}/repository/logs/${instance.log}/wso2wire${instance.log}.log
 log4j.appender.WIRE_LOGFILE.Append=true

 log4j.appender.WIRE_LOGFILE.layout=org.wso2.carbon.utils.logging.TenantAwarePatternLayout
 # ConversionPattern will be overridden by the configuration setting in the
 DB
 log4j.appender.WIRE_LOGFILE.layout.ConversionPattern=TID: [%T] [%S] [%d]
 %P%5p {%c} - %x %m {%c}%n
 log4j.appender.WIRE_LOGFILE.layout.TenantPattern=%U%@%D [%T] [%S]
 log4j.appender.WIRE_LOGFILE.threshold=DEBUG


 Then I associated the wire logs entry with this appender,

 log4j.logger.org.apache.synapse.transport.http.wire=DEBUG, WIRE_LOGFILE


 So now when I invoke the Echo service of ESB the wire logs are getting
 printed to ESB_HOME/repository/logs/wso2wire.log file as expected.


 But its also getting printed in the wso2carbon.log, this is what I don't
 want. So how do I stop the wire log from getting printed in the
 wso2carbon.log?


 --
 Regards,
 Uvindra

 Mobile: 33962




-- 
Regards,
Uvindra

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

[Dev] Writing wire logs to a separate file other than the wso2carbon.log

[Uvindra Dias Jayasinha]

I've defined a custom appender in the log4j.properties of ESB 4.8.1 as
follows.


# WIRE_LOGFILE is set to be a DailyRollingFileAppender using a
PatternLayout.
log4j.appender.WIRE_LOGFILE=org.wso2.custom.logging.appenders.WireDailyRollingFileAppender
# Log file will be overridden by the configuration setting in the DB
# This path should be relative to WSO2 Carbon Home
log4j.appender.WIRE_LOGFILE.File=${carbon.home}/repository/logs/${instance.log}/wso2wire${instance.log}.log
log4j.appender.WIRE_LOGFILE.Append=true
log4j.appender.WIRE_LOGFILE.layout=org.wso2.carbon.utils.logging.TenantAwarePatternLayout
# ConversionPattern will be overridden by the configuration setting in the
DB
log4j.appender.WIRE_LOGFILE.layout.ConversionPattern=TID: [%T] [%S] [%d]
%P%5p {%c} - %x %m {%c}%n
log4j.appender.WIRE_LOGFILE.layout.TenantPattern=%U%@%D [%T] [%S]
log4j.appender.WIRE_LOGFILE.threshold=DEBUG


Then I associated the wire logs entry with this appender,

log4j.logger.org.apache.synapse.transport.http.wire=DEBUG, WIRE_LOGFILE


So now when I invoke the Echo service of ESB the wire logs are getting
printed to ESB_HOME/repository/logs/wso2wire.log file as expected.


But its also getting printed in the wso2carbon.log, this is what I don't
want. So how do I stop the wire log from getting printed in the
wso2carbon.log?


-- 
Regards,
Uvindra

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

Re: [Dev] [APIM] Modifying Key Caches on API Manager

[Uvindra Dias Jayasinha]

+1, Looks good to me.

On 6 May 2015 at 11:34, Amila De Silva ami...@wso2.com wrote:

 Hi All,

 When caching is enabled on Gateway, KeyValidationInfoDTO object is kept in
 the cache against a cache key having the following structure;

 cacheKey = accessToken + : + apiContext + / + apiVersion + resourceUri
 + : + httpVerb + : + authLevel;

 This structure makes cache retrievals efficient, but poses several
 problems when removing entries.

 For example, when removing an API subscribed under an Application, we have
 to delete cache entries associated with that API. But since the cache key
 is a composition of several parts, finding cache entries related to a given
 API is not a straightforward task.

 With the existing implementation, following steps are performed when
 removing entries linked with a particular API,
 a. Finding all Applications the API is subscribed to
 b. Getting all active tokens issued for those Applications.
 c. Creating all possible cache keys that could be present in the key cache.
 d. Calling cache.remove on all the keys created

 Since we have access to the database in which tokens are stored, we have
 the ability of finding all the tokens associated with an API. But when
 having a third party Key Manager, this option won't work. Therefore a
 different mechanism is needed to find Cache entries associated with an API.

 Proposed solution is to introduce a second cache, which acts as an index
 for the main (existing) cache. Structure of the existing cache and the
 cache Key will remain the same.

 *Structure of the new cache *

 The combination of apicontext, version will be used as the cache key and
 the entry will be an APIEntry. Structure of the APIEntry will be like this.

 [image: Inline image 4]

 When needed to delete cache entries for an API, first the Index cache will
 be looked up using API context + version as the key. This will return all
 the ApplicationEntries which are present in the main cache and also to
 which the API has subscribed to. ApplicationEntry will have a list of cache
 keys, which are present in the main cache, and which contains a token
 obtained under the enclosing Application.

 We have to add entries to the Indexing cache at the same time we add a new
 entry to main cache.

 Will explain how different invalidation tasks are performed by only using
 these two caches in a mail to follow.

 Would highly appreciate your thoughts on this approach.




-- 
Regards,
Uvindra

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

Re: [Dev] [APIM] Modifying Key Caches on API Manager

[Uvindra Dias Jayasinha]

Both scenarios can happen actually so we need to cater for both, obviously
refresh and revoke will be more common. So what's wrong with having two
index caches? If memory is an issue we can specify a max index cache size.

On 6 May 2015 at 16:49, Amila De Silva ami...@wso2.com wrote:

 Hi Nuwan,

 APIEntry was brought to the top most level, with the intention of making
 the cache clearing optimal when API/Subscription update happens.
 However if we are to clear the cache more efficiently while revoke and
 refresh happens, then we have to think of a different structure. Then
 ApplicationEntry would have to be brought to the top most level, and
 ApplicationEntry would have a list of TokenEntries instead of APIEntries. A
 TokenEntry being the object at the leaf level would have all the cache
 keys, starting with a specific access token.

 [image: Inline image 1]

 I think with one type of Index we can only make one type of removal more
 efficient. Either we have to choose which operation we need to make more
 efficient, or else we have introduce two index caches.

 AmilaD

 On Wed, May 6, 2015 at 3:10 PM, Nuwan Dias nuw...@wso2.com wrote:

 This approach will work for clearing caches when an API update or an
 Application/Subscription update happens. Which are quite rare occurrences
 of a production system. IMO what happens more frequently in a running
 system is the refresh and revoke of actual end user tokens (based on the
 behaviour of the applications). I still don't see how we can easily clear a
 cache entry on that kind of a scenario through this approach. Does that
 process become easier in some way as well?

 Thanks,
 NuwanD.

 On Wed, May 6, 2015 at 7:20 PM, Sanjeewa Malalgoda sanje...@wso2.com
 wrote:

 Yes i think this should work and it will make our life easy :)

 Lets isolate user flows associated with cache. Please add if i missed
 anything.

 01. Invoke API and then we need to add validation information to cache.
 02. Delete Application -  delete all tokens associated with application
 03. Remove subscription -  remove cache entries associated with
 unsubscribed API.
 04. Remove API - remove cache entries associated with API.
 05. Regenerate access token - remove cache entry for previous token.
 06. Revoke access token - then remove all cache entries assicated with
 revoked token.
 07. Revoke access tokens by application , user - remove cache entries.

 Also as discussed need to check the effect of having 2 cache with 2
 different validity periods. And what happen if one cache expired while
 other is still pointing to it.
  Lets carefully evaluate these flows and fix this.

 Thanks,
 sanjeewa.

 On Wed, May 6, 2015 at 11:44 AM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 +1, Looks good to me.

 On 6 May 2015 at 11:34, Amila De Silva ami...@wso2.com wrote:

 Hi All,

 When caching is enabled on Gateway, KeyValidationInfoDTO object is
 kept in the cache against a cache key having the following structure;

 cacheKey = accessToken + : + apiContext + / + apiVersion +
 resourceUri + : + httpVerb + : + authLevel;

 This structure makes cache retrievals efficient, but poses several
 problems when removing entries.

 For example, when removing an API subscribed under an Application, we
 have to delete cache entries associated with that API. But since the cache
 key is a composition of several parts, finding cache entries related to a
 given API is not a straightforward task.

 With the existing implementation, following steps are performed when
 removing entries linked with a particular API,
 a. Finding all Applications the API is subscribed to
 b. Getting all active tokens issued for those Applications.
 c. Creating all possible cache keys that could be present in the key
 cache.
 d. Calling cache.remove on all the keys created

 Since we have access to the database in which tokens are stored, we
 have the ability of finding all the tokens associated with an API. But 
 when
 having a third party Key Manager, this option won't work. Therefore a
 different mechanism is needed to find Cache entries associated with an 
 API.

 Proposed solution is to introduce a second cache, which acts as an
 index for the main (existing) cache. Structure of the existing cache and
 the cache Key will remain the same.

 *Structure of the new cache *

 The combination of apicontext, version will be used as the cache key
 and the entry will be an APIEntry. Structure of the APIEntry will be like
 this.

 [image: Inline image 4]

 When needed to delete cache entries for an API, first the Index cache
 will be looked up using API context + version as the key. This will return
 all the ApplicationEntries which are present in the main cache and also to
 which the API has subscribed to. ApplicationEntry will have a list of 
 cache
 keys, which are present in the main cache, and which contains a token
 obtained under the enclosing Application.

 We have to add entries to the Indexing cache at the same time we add a
 new

Re: [Dev] API Manager - deleting an API

[Uvindra Dias Jayasinha]

Hi Chalitha,

You should first remove any existing subscriptions[1] before you delete a
given API.

What is your use case for deleting APIs without user authentication?

[1]
https://docs.wso2.com/display/AM180/Store+APIs#StoreAPIs-RemoveaSubscription


On 17 April 2015 at 14:45, Chalitha Kulathunga chalit...@wso2.com wrote:

 Hi Yvonne  Harsha,

 @Yvonne - yes, I'm going to delete subscribed APIs as well. If it can
 cause any issues, please let me know.

 @Harsha - I will try the suggested approach.

 Thank you  Regards,
 Chalitha

 On Fri, Apr 17, 2015 at 1:02 PM, Harsha Kumara hars...@wso2.com wrote:

 Hi Chalitha,

 You should be able to get the instance of the APIProvider as follow

 apiProvider = APIManagerFactory.getInstance().getAPIProvider(loggedUser);

 [1] -
 https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/src/main/java/org/wso2/carbon/apimgt/impl/APIManagerFactory.java

 Thanks,
 Harsha

 On Fri, Apr 17, 2015 at 12:42 PM, Yvonne Wickramasinghe yvo...@wso2.com
 wrote:

 Hi Chalitha,

 Just a quick question. Are we going to allow deleting subscribed APIs as
 well?

 Regards,

 On Fri, Apr 17, 2015 at 12:33 PM, Chalitha Kulathunga 
 chalit...@wso2.com wrote:

 Hi Thilini  Harsha,

 @Thilini - Remove an API needs the user to be authenticated. I'm
 looking for a solution that doesn't require user authentication. The idea
 is to delete APIs which belongs to a particular tenant from the out side,
 through an existing or a modified method call.

 @Harsha - sorry I was wrong previously, the impl package is exported
 but the  *APIProviderImpl.java *class cannot be accessed out side the
 package since it is not public. The class also contains the following
 description:

 /**
  * This class provides the core API provider functionality. It is 
 implemented in a very
  * self-contained and 'pure' manner, without taking requirements like 
 security into account,
  * which are subject to frequent change. Due to this 'pure' nature and the 
 significance of
  * the class to the overall API management functionality, the visibility 
 of the class has
  * been reduced to package level. This means we can still use it for 
 internal purposes and
  * possibly even extend it, but it's totally off the limits of the users. 
 Users wishing to
  * programmatically access this functionality should use one of the 
 extensions of this
  * class which is visible to them. These extensions may add additional 
 features like
  * security to this class.
  */


 Thank you very much for your suggestions.
 Regards,





 On Thu, Apr 16, 2015 at 8:04 PM, Harsha Kumara hars...@wso2.com
 wrote:

 Hi Chalitha,

 Which version that you tried to use of apimgt.impl dependency?
 According to [1] and [2], the impl package has exported. You won't be able
 to use the APIMgtDAO, because deleting API involve deleting resources from
 registry as well.

 [1] -
 https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.impl/pom.xml#L214
 [2] -
 https://svn.wso2.org/repos/wso2/carbon/platform/trunk/components/apimgt/org.wso2.carbon.apimgt.impl/pom.xml

 Thanks,
 Harsha

 On Thu, Apr 16, 2015 at 7:08 PM, Chalitha Kulathunga 
 chalit...@wso2.com wrote:

 Hi all,

 I'm looking for a proper way(methods) to *delete an published API
 and all its data* in WSO2 API Manager.

 The *deleteAPI* method available in *APIProviderImpl.java* class in
 org.wso2.carbon.apimgt.impl package(bundle) is not public and also
 not exported in the pom.xml. Therefore, it cannot be accessed from the
 outside.

 *APIMgtDAO.java* class in org.wso2.carbon.apimgt.impl.dao package
  also provides a similar but public method however I'm not certain 
 whether
 it is suitable for my purpose. Could someone please recommend me a 
 standard
 way to delete an API.


 Thanks  Regards

 --
 *Chalitha Sanyuja Kulathunga*
 *Software Engineer*
 WSO2 Inc.; http://wso2.com
 email: chalit...@wso2.com cell: +94 77 5927581 %2B94%2077%207779495

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




 --
 Harsha Kumara
 Software Engineer, WSO2 Inc.
 Mobile: +94775505618
 Blog:harshcreationz.blogspot.com




 --
 *Chalitha Sanyuja Kulathunga*
 *Software Engineer*
 WSO2 Inc.; http://wso2.com
 email: chalit...@wso2.com cell: +94 77 5927581 %2B94%2077%207779495

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




 --

 *Yvonne Wickramasinghe*
 Senior Product Manager; WSO2, Inc.; http://wso2.com
 email: yvo...@wso2.com; mobile (Sri Lanka): +94 71 516 3732




 --
 Harsha Kumara
 Software Engineer, WSO2 Inc.
 Mobile: +94775505618
 Blog:harshcreationz.blogspot.com




 --
 *Chalitha Sanyuja Kulathunga*
 *Software Engineer*
 WSO2 Inc.; http://wso2.com
 email: chalit...@wso2.com cell: +94 77 5927581 %2B94%2077%207779495

 ___
 Dev 

Re: [Dev] [APIM] Adding sequence to a API to log In-flow messages not working. API Manager 1.9.0 SNAPSHOT

[Uvindra Dias Jayasinha]

If you havent updated the velocity_template in API Manager with your custom
handler then you will loose it from the synapse configuration when you do a
save and publish. publishing will cause the contents of the synapse config
to get updated with the default values in the template.

On 1 April 2015 at 17:26, Saneth Dharmakeerthi sane...@wso2.com wrote:

 HI All,

 I try to add LogMediator  to In-Flow in a API and noted following things.

- I add sequence to the In-flow to log the messages as [1]. But no
massage was logged.
- I did the same thing with APIM 1.8.0, the LogMediator works fine but
with 1.8.0 the added custom handlers get removed from the synapse
configuration all the time  when we click save and publish button after
the sequences is changed.

 Is there any reason for this behaviour, Did i miss any steps in here.



 [1]​
  Screen Shot 2015-04-01 at 4.40.00 PM.png
 https://docs.google.com/a/wso2.com/file/d/0B2mfjA37km5Uem9MSDFHLXBNQWc/edit?usp=drive_web
 ​

 Thanks and Best Regards,

 Saneth Dharmakeerthi
 Senior Software Engineer
 WSO2, Inc.
 Mobile: +94772325511




-- 
Regards,
Uvindra

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

Re: [Dev] Don't commit to APIM old test modules

[Uvindra Dias Jayasinha]

If anyone is in the middle of writing a test in the module please reply to
this thread. We need to ensure that we have stable pack with all tests in
newly created modules passing before we can remove the old test modules.
Lets try and get this done ASAP.

I think there are a few new team members missing on this mail, can someone
please add them?(Im not sure who they are :) )

On 13 March 2015 at 12:19, Krishantha Samaraweera krishan...@wso2.com
wrote:

 Hi APIM Team,

 Automation team is migrating test suites from old test framework to new
 one. I've already removed old test modules from integration module POM and
 applied the pull request four days ago, updated mail thread can be found at
  [APIM] Please merge pull request

 Note that only following modules are enabled now.


 modulesmoduletests-common/modulemoduletests-integration/module 
 !--moduletests-ui-integration/module--
 !--moduletests-platform/module-- /modules

 Can you please refine from committing to old test modules. We kept those
 old modules until test migration is over. Now I think its not a good idea
 to keep those modules and will remove them soon.

 Let me know if you have any concern with removing old test modules.

 Following test modules will be removed shortly. And we will take care of
 migrating tests in those modules to our new modules properly.

 1. tests-new
 2. tests-ui
 3. tests.

 Thanks,
 Krishatnha.


 --
 Krishantha Samaraweera
 Senior Technical Lead - Test Automation
 Mobile: +94 77 7759918
 WSO2, Inc.; http://wso2.com/
 lean . enterprise . middlewear.




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager New integration module structure for framework version 4.3.1.

[Uvindra Dias Jayasinha]

Since APIM 1.9.0 was on svn earlier we were using the automation framework
4.2.7. But now since 1.9.0 has moved to git(but we are still using Carbon
4.2.0) do we need to change anything? We are still using version 4.2.7 of
TAF.

On 19 February 2015 at 10:27, Dharshana Warusavitharana dharsha...@wso2.com
 wrote:

 Hi All,

 Please find status of the platform scenario automation of APIM platform
 based scenarios on [1].
 We have currently coverup initial scenarios with IS and BAM integration.

 [1].
 https://docs.google.com/a/wso2.com/spreadsheets/d/10iTMvum6PpuFBMKuBG1oM7miYphv5fmhTCVxMGZG8g8/edit#gid=0

 Thank you,
 Dharshana.


 On Fri, Jan 23, 2015 at 9:32 AM, Dharshana Warusavitharana 
 dharsha...@wso2.com wrote:

 Ye Nuwan we already discussed this too. We will break submodules when we
 are moving with scenarios. This is initial phase.

 Thank You,
 Dharshana

 On Fri, Jan 23, 2015 at 6:32 AM, Nuwan Wimalasekara nuw...@wso2.com
 wrote:

 Hi Dharshana,
 It would be grate if we can create a sub modules under tests-integration
 and test-ui-integration rather than putting the test classes inside the
 root module(tests-integration) from this moment, There might be an
 requirement having multi test module inside tests-integration. In ESB, we
 have multi test module. In future , It will required for API manager too.


 Thanks,
 Nuwanw

 On Thu, Jan 22, 2015 at 4:45 AM, Dharshana Warusavitharana 
 dharsha...@wso2.com wrote:

 Hi All,

 Test framework 4.3.1 has being introduced to the APIM integration test
 module under following structure.

 Moving forward automation team would implement tests based on the test
 structure 4.3.1.

 integration
 ├
 ├── pom.xml
 ├── tests-common
 │   ├── admin-clients
 │   ├── integration-test-utils
 │   └── ui-pages
 ├── tests-integration
 │   ├── pom.xml
 │   └── src
 │   └── test
 │   ├── java
 │   │   └── org
 │   │   └── wso2
 │   │   └── am
 │   │   └── integration
 │   │   └── tests
 │   │   ├── server
 │   │   │   └── mgt
 │   │   │   ├──
 ApiMgtServerStartupTestCase.java
 │   │   │   └──
 OSGIServerBundleStatusTestCase.java
 │   │   └── workflow
 │   └── resources
 ├── tests-platform
 │   ├── pom.xml
 │   └── resources
 ├── tests-ui-integration
 │   ├── pom.xml

 Please note the APIM will move to 1.9.0 release with the SVN so we need
 o stick to the repository noted in [1].


 [1].
 http://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/apimgt/1.9.0/

 --

 Dharshana Warusavitharana
 Senior Software Engineer , Test Automation
 WSO2 Inc. http://wso2.com
 email : dharsha...@wso2.com dharsha...@wso2.com
 Tel  : +94 11 214 5345
 Fax :+94 11 2145300
 cell : +94770342233
 blog : http://dharshanaw.blogspot.com

 lean . enterprise . middleware

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




 --
 Nuwan Wimalasekara
 Senior Software Engineer - Test Automation
 WSO2, Inc.: http://wso2.com
 lean. enterprise. middleware

 phone: +94 71 668 4620






 --

 Dharshana Warusavitharana
 Senior Software Engineer , Test Automation
 WSO2 Inc. http://wso2.com
 email : dharsha...@wso2.com dharsha...@wso2.com
 Tel  : +94 11 214 5345
 Fax :+94 11 2145300
 cell : +94770342233
 blog : http://dharshanaw.blogspot.com

 lean . enterprise . middleware




 --

 Dharshana Warusavitharana
 Senior Software Engineer , Test Automation
 WSO2 Inc. http://wso2.com
 email : dharsha...@wso2.com dharsha...@wso2.com
 Tel  : +94 11 214 5345
 Fax :+94 11 2145300
 cell : +94770342233
 blog : http://dharshanaw.blogspot.com

 lean . enterprise . middleware

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




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 - Help with velocity template file

[Uvindra Dias Jayasinha]

No need to apologize, that is exactly what this mailing list is for.

You need to use to escape the '$' character, try this,

http://velocity.apache.org/tools/devel/generic/EscapeTool.html#getDollar%28%29


On 10 February 2015 at 06:06, satheesh sathee...@gmail.com wrote:

 I apologize for asking this on the dedicated DEV forum... I am not able to
 get any answers elsewhere. I am hoping someone here can guide me.

 I am modifying the velocity_template.xml file so that any new API published
 will use the input and output transformations that I would need. I am stuck
 at the response part due to JSON and $ character. The first block below is
 from my velocity_template.xml and second block is from the generated API
 from source view. Can someone help me on how I can preserve the entire
 expression under args section?

 /payloadFactory media-type=json
format
 {
   apiName: $1,
   apiVersion: $2,
   runResponse:
 {
 runId: $3,
 runStart: $4,
 runEnd: $5,
 flowResponse: $6,
 flowResult: $7
 }
 }
 /format
args
   arg evaluator=xml
 expression=get-property('apiName')/
   arg evaluator=xml
 expression=get-property('apiVersion')/
   arg evaluator=json
 expression=$.runResponse.runReturn.item[0].value/
   arg evaluator=json
 expression=$.runResponse.runReturn.item[3].value/
   arg evaluator=json
 expression=$.runResponse.runReturn.item[4].value/
   arg evaluator=json
 expression=$.runResponse.runReturn.item[5].value/
   arg evaluator=json
 expression=$.runResponse.runReturn.item[6].value/

/args
 /payloadFactory/

 *Generated API*

 /payloadFactory media-type=json
format
 {
   apiName: $1,
   apiVersion: $2,
   runResponse:
 {
 runId: $3,
 runStart: $4,
 runEnd: $5,
 flowResponse: $6,
 flowResult: $7
 }
 }
 /format
args
   arg evaluator=xml
 expression=get-property('apiName')/
   arg evaluator=xml
 expression=get-property('apiVersion')/
   arg evaluator=json
 expression=.runResponse[0].value/
   arg evaluator=json
 expression=.runResponse[3].value/
   arg evaluator=json
 expression=.runResponse[4].value/
   arg evaluator=json
 expression=.runResponse[5].value/
   arg evaluator=json
 expression=.runResponse[6].value/
/args
 /payloadFactory/




 --
 View this message in context:
 http://wso2-oxygen-tank.10903.n7.nabble.com/API-Manager-1-8-0-Help-with-velocity-template-file-tp111988.html
 Sent from the WSO2 Development mailing list archive at Nabble.com.
 ___
 Dev mailing list
 Dev@wso2.org
 http://wso2.org/cgi-bin/mailman/listinfo/dev




-- 
Regards,
Uvindra

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

Re: [Dev] Converting JSON to SOAP and vise versa in ESB

[Uvindra Dias Jayasinha]

Thanks Harsha, that worked!

The issue was caused by sending the following value in the payloadFactory
of the insequence,


payloadFactory media-type=xml
format

* soapenv:Envelope
xmlns:soapenv=http://schemas.xmlsoap.org/soap/envelope/
http://schemas.xmlsoap.org/soap/envelope/
xmlns:web=http://www.w3schools.com/webservices/
http://www.w3schools.com/webservices/
soapenv:Header/soapenv:*






*Header  soapenv:Body
web:CelsiusToFahrenheit
web:Celsius$1/web:Celsius
/web:CelsiusToFahrenheit  /soapenv:Body
/soapenv:Envelope*
/format
   args
   arg evaluator=json expression=$.celsius/arg
/args
 /payloadFactory


But when I changed it to this as in Harshas example,


payloadFactory media-type=xml
format


* web:CelsiusToFahrenheit xmlns:web=http://www.w3schools.com/webservices/
http://www.w3schools.com/webservices/
web:Celsius$1/web:Celsius   /web:CelsiusToFahrenheit*
/format
args
   arg evaluator=json expression=$.celsius/arg
/args
 /payloadFactory

It started working. Thanks for the help everyone, it would be nice to know
the reason behind this if anyone can let me know, is it because you should
not try and add the SOAP envelope and header tags manually as this will be
generated automatically when the address endpoint is defined as soap11?
Better error messages would have helped diagnose this issue faster.



On 8 February 2015 at 09:27, Harsha Kumara hars...@wso2.com wrote:

 Hi Uvindra,

 I checked with this with esb 4.8.1 fresh pack. It worked fine with below
 config. Please find my api config and response.

  api name=tempAPI context=/temp
   resource methods=POST GET
  inSequence
 log level=custom
property name=IN_MESSAGE

  
 value=gtgtgtgtgtgtgtgtIN_MESSAGE/
 /log
 property name=messageType value=application/xml
 scope=axis2/
 property name=FORCE_HTTP_1.0 value=true scope=axis2/
 property name=DISABLE_CHUNKING value=true scope=axis2/
 payloadFactory media-type=xml
format
   web:CelsiusToFahrenheit xmlns:web=
 http://www.w3schools.com/webservices/;
  web:Celsius$1/web:Celsius
   /web:CelsiusToFahrenheit
/format
args
   arg evaluator=json expression=$.celsius/
/args
 /payloadFactory
 send
endpoint
   address uri=
 http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit
 
format=soap11/
/endpoint
 /send
  /inSequence
  outSequence
 log level=custom
property name=OUT_MESSAGE

  
 value=gtgtgtgtgtgtgtgtOUT_MESSAGE/
 /log
 property name=messageType value=application/json
 scope=axis2/
 script language=jsvar temp =
 mc.getPayloadXML()..*::CelsiusToFahrenheitResult.toString();
 mc.setPayloadJSON({Temp : {Faran : temp}});/script
 send/
  /outSequence
   /resource
/api

 curl -i -POST -H 'Accept: application/json' -H
 'Content-Type:application/json' -d '{celsius:12}'
 http://192.168.1.4:8280/temp

 HTTP/1.1 200 OK
 X-AspNet-Version: 4.0.30319
 Content-Type: application/json
 X-Powered-By: ASP.NET
 Cache-Control: private, max-age=0,public
 Date: Sun, 08 Feb 2015 03:48:50 GMT
 Server: WSO2-PassThrough-HTTP
 Transfer-Encoding: chunked

 {Temp:{Faran:53.6}}

 Thanks,
 Harsha

 On Sat, Feb 7, 2015 at 9:55 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 With wire logs on the issue becomes a bit more clear,





 21:34:56,129  POST /temp HTTP/1.1[\r][\n]
 21:34:56,130  User-Agent: curl/7.35.0[\r][\n]
 21:34:56,130  Host: 10.0.3.1:8281[\r][\n]
 21:34:56,130  Accept: application/json[\r][\n]
 21:34:56,130  Content-Type:application/json[\r][\n]
 21:34:56,130  Content-Length: 14[\r][\n]
 21:34:56,130  [\r][\n]
 21:34:56,131  {celsius:12}
 21:34:56,175 LogMediator  IN_MESSAGE =
 IN_MESSAGE
 21:34:56,216 TimeoutHandler  This engine will expire all callbacks after
 : 120 seconds, irrespective of the timeout action, after the specified or
 optional timeout
 21:34:56,296  POST /webservices/tempconvert.asmx?op=CelsiusToFahrenheit
 HTTP/1.0[\r][\n]
 21:34:56,297  Content-Type: text/xml[\r][\n]
 21:34:56,297  Accept: application/json[\r][\n]
 21:34:56,297  Content-Length: 292[\r][\n]
 21:34:56,297  Host: www.w3schools.com:80[\r][\n]
 21:34:56,298  Connection: Keep-Alive[\r][\n]
 21:34:56,298  User-Agent: Synapse-PT-HttpComponents-NIO[\r][\n

Re: [Dev] Converting JSON to SOAP and vise versa in ESB

[Uvindra Dias Jayasinha]

 it worked for me with my config I mean how Uvindra can't ?

 *xxx-MacBook-Pro:bin dushan$ curl -i -POST -H 'Accept: application/json'
 -H 'Content-Type:application/json' -d
 '{celsius:12}' http://192.168.56.1:8281/temp
 http://192.168.56.1:8281/temp*
 *HTTP/1.1 200 OK*
 *X-AspNet-Version: 4.0.30319*
 *Content-Type: application/json*
 *X-Powered-By: ASP.NET http://asp.net/*
 *Cache-Control: private, max-age=0,public*
 *Date: Fri, 06 Feb 2015 17:19:20 GMT*
 *Server: WSO2-PassThrough-HTTP*
 *Transfer-Encoding: chunked*

 *{Temp:53.6}xxx-xxx-Pro:bin xx$*



 On Sat, Feb 7, 2015 at 9:51 AM, Malaka Silva mal...@wso2.com wrote:

 Can you share the wire logs?

 On Sat, Feb 7, 2015 at 12:50 PM, Uvindra Dias Jayasinha uvin...@wso2.com
  wrote:

 The Premature end of file exception is still happening even when I add
 those two properties in, this is a parser error happening on our end in the
 insequence itself. I still cant understand why this isnt working.

 On 7 February 2015 at 12:15, Chanaka Fernando chana...@wso2.com wrote:

 Hi Uvindra,

 According to the website, they expect content-length header in the
 request. You can use the below two property mediators to send the
 content-length always.

 property name=FORCE_HTTP_CONTENT_LENGTH value=true
 scope=axis2/property
  property name=COPY_CONTENT_LENGTH_FROM_INCOMING
 value=true scope=axis2/property


 Try the above properties prior to the send mediator.


 Thanks,
 Chanaka

 On Fri, Feb 6, 2015 at 11:28 PM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 Ok tried that Dushan, but now I get a different exception when I hit
 the insequence


 23:24:38,849 LogMediator  IN_MESSAGE =
 IN_MESSAGE
 RelayUtils  Error while building Passthrough stream
 org.apache.axiom.om.OMException: javax.xml.stream.XMLStreamException:
 ParseError at [row,col]:[1,1]
 Message: Premature end of file.
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296)
 at
 org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.getSOAPEnvelope(StAXSOAPModelBuilder.java:204)
 at
 org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.init(StAXSOAPModelBuilder.java:154)
 at
 org.apache.axiom.om.impl.AbstractOMMetaFactory.createStAXSOAPModelBuilder(AbstractOMMetaFactory.java:73)
 at
 org.apache.axiom.om.impl.AbstractOMMetaFactory.createSOAPModelBuilder(AbstractOMMetaFactory.java:79)
 at
 org.apache.axiom.om.OMXMLBuilderFactory.createSOAPModelBuilder(OMXMLBuilderFactory.java:196)
 at
 org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:55)
 at
 org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:118)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:107)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:68)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
 at
 org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
 at org.apache.synapse.rest.Resource.process(Resource.java:297)
 at org.apache.synapse.rest.API.process(API.java:298)
 at
 org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:76)
 at
 org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:50)
 at
 org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage(SynapseCallbackReceiver.java:488)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive(SynapseCallbackReceiver.java:170)
 at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
 at
 org.apache.synapse.transport.passthru.ClientWorker.run(ClientWorker.java:225)
 at
 org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: javax.xml.stream.XMLStreamException: ParseError at
 [row,col]:[1,1]
 Message: Premature end of file.
 at
 com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:594)
 at
 org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
 at
 org.apache.axiom.util.stax.dialect.DisallowDoctypeDeclStreamReaderWrapper.next(DisallowDoctypeDeclStreamReaderWrapper.java:34)
 at
 org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225

Re: [Dev] Converting JSON to SOAP and vise versa in ESB

[Uvindra Dias Jayasinha]

The Premature end of file exception is still happening even when I add
those two properties in, this is a parser error happening on our end in the
insequence itself. I still cant understand why this isnt working.

On 7 February 2015 at 12:15, Chanaka Fernando chana...@wso2.com wrote:

 Hi Uvindra,

 According to the website, they expect content-length header in the
 request. You can use the below two property mediators to send the
 content-length always.

 property name=FORCE_HTTP_CONTENT_LENGTH value=true
 scope=axis2/property
  property name=COPY_CONTENT_LENGTH_FROM_INCOMING value=true
 scope=axis2/property


 Try the above properties prior to the send mediator.


 Thanks,
 Chanaka

 On Fri, Feb 6, 2015 at 11:28 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Ok tried that Dushan, but now I get a different exception when I hit the
 insequence


 23:24:38,849 LogMediator  IN_MESSAGE =
 IN_MESSAGE
 RelayUtils  Error while building Passthrough stream
 org.apache.axiom.om.OMException: javax.xml.stream.XMLStreamException:
 ParseError at [row,col]:[1,1]
 Message: Premature end of file.
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296)
 at
 org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.getSOAPEnvelope(StAXSOAPModelBuilder.java:204)
 at
 org.apache.axiom.soap.impl.builder.StAXSOAPModelBuilder.init(StAXSOAPModelBuilder.java:154)
 at
 org.apache.axiom.om.impl.AbstractOMMetaFactory.createStAXSOAPModelBuilder(AbstractOMMetaFactory.java:73)
 at
 org.apache.axiom.om.impl.AbstractOMMetaFactory.createSOAPModelBuilder(AbstractOMMetaFactory.java:79)
 at
 org.apache.axiom.om.OMXMLBuilderFactory.createSOAPModelBuilder(OMXMLBuilderFactory.java:196)
 at
 org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:55)
 at
 org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:118)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:107)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:68)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
 at
 org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
 at org.apache.synapse.rest.Resource.process(Resource.java:297)
 at org.apache.synapse.rest.API.process(API.java:298)
 at
 org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:76)
 at
 org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:50)
 at
 org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage(SynapseCallbackReceiver.java:488)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive(SynapseCallbackReceiver.java:170)
 at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
 at
 org.apache.synapse.transport.passthru.ClientWorker.run(ClientWorker.java:225)
 at
 org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: javax.xml.stream.XMLStreamException: ParseError at
 [row,col]:[1,1]
 Message: Premature end of file.
 at
 com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:594)
 at
 org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
 at
 org.apache.axiom.util.stax.dialect.DisallowDoctypeDeclStreamReaderWrapper.next(DisallowDoctypeDeclStreamReaderWrapper.java:34)
 at
 org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
 at
 org.apache.axiom.util.stax.dialect.SJSXPStreamReaderWrapper.next(SJSXPStreamReaderWrapper.java:138)
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:681)
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:214)
 ... 25 more
 23:24:39,141 SequenceMediator  Error while building message
 org.apache.axis2.AxisFault: Error while building Passthrough stream
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.handleException(RelayUtils.java:236)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:111)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate

Re: [Dev] Converting JSON to SOAP and vise versa in ESB

[Uvindra Dias Jayasinha]

: chunked

 {Temp:53.6}xxx-xxx-Pro:bin xx$

 On Thu, Feb 5, 2015 at 1:10 AM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Thanks Sampath and Asanka,

 Tried both your suggestions and now Im getting different exception

 RelayUtils  Error while building Passthrough stream
 org.apache.axiom.om.OMException: javax.xml.stream.XMLStreamException:
 ParseError at [row,col]:[3,68]
 Message: DOCTYPE is not allowed
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296)
 at
 org.apache.axiom.om.impl.llom.OMDocumentImpl.getOMDocumentElement(OMDocumentImpl.java:109)
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.getDocumentElement(StAXOMBuilder.java:570)
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.getDocumentElement(StAXOMBuilder.java:566)
 at
 org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:129)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:107)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:68)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
 at
 org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
 at org.apache.synapse.rest.Resource.process(Resource.java:297)
 at org.apache.synapse.rest.API.process(API.java:298)
 at
 org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:76)
 at
 org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:50)
 at
 org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage(SynapseCallbackReceiver.java:488)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive(SynapseCallbackReceiver.java:170)
 at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
 at
 org.apache.synapse.transport.passthru.ClientWorker.run(ClientWorker.java:225)
 at
 org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
 at
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: javax.xml.stream.XMLStreamException: ParseError at
 [row,col]:[3,68]
 Message: DOCTYPE is not allowed
 at
 com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:594)
 at
 org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
 at
 org.apache.axiom.util.stax.dialect.DisallowDoctypeDeclStreamReaderWrapper.next(DisallowDoctypeDeclStreamReaderWrapper.java:34)
 at
 org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
 at
 org.apache.axiom.util.stax.dialect.SJSXPStreamReaderWrapper.next(SJSXPStreamReaderWrapper.java:138)
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:681)
 at
 org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:214)
 ... 22 more
 11:30:13,251 SequenceMediator  Error while building message
 org.apache.axis2.AxisFault: Error while building Passthrough stream
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.handleException(RelayUtils.java:236)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:111)
 at
 org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:68)
 at
 org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
 at
 org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
 at org.apache.synapse.rest.Resource.process(Resource.java:297)
 at org.apache.synapse.rest.API.process(API.java:298)
 at
 org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:76)
 at
 org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:50)
 at
 org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage(SynapseCallbackReceiver.java:488)
 at
 org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive(SynapseCallbackReceiver.java:170)
 at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
 at
 org.apache.synapse.transport.passthru.ClientWorker.run(ClientWorker.java:225)
 at
 org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172

Re: [Dev] Converting JSON to SOAP and vise versa in ESB

[Uvindra Dias Jayasinha]

 by: org.apache.axiom.om.OMException:
javax.xml.stream.XMLStreamException: ParseError at [row,col]:[3,68]
Message: DOCTYPE is not allowed
at
org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:296)
at
org.apache.axiom.om.impl.llom.OMDocumentImpl.getOMDocumentElement(OMDocumentImpl.java:109)
at
org.apache.axiom.om.impl.builder.StAXOMBuilder.getDocumentElement(StAXOMBuilder.java:570)
at
org.apache.axiom.om.impl.builder.StAXOMBuilder.getDocumentElement(StAXOMBuilder.java:566)
at
org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:129)
at
org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:107)
... 17 more
Caused by: javax.xml.stream.XMLStreamException: ParseError at
[row,col]:[3,68]
Message: DOCTYPE is not allowed
at
com.sun.org.apache.xerces.internal.impl.XMLStreamReaderImpl.next(XMLStreamReaderImpl.java:594)
at
org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
at
org.apache.axiom.util.stax.dialect.DisallowDoctypeDeclStreamReaderWrapper.next(DisallowDoctypeDeclStreamReaderWrapper.java:34)
at
org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
at
org.apache.axiom.util.stax.dialect.SJSXPStreamReaderWrapper.next(SJSXPStreamReaderWrapper.java:138)
at
org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:681)
at
org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:214)
... 22 more

Any ideas?


On 5 February 2015 at 07:48, Asanka Dissanayake asan...@wso2.com wrote:

 Hi Uvindra,
 Seems message failing during the building. And it picks the wrong
 formatter it seems. Set the content header in the curl as follows.

 curl -i -POST -H 'Accept: application/json' -H
 'Content-Type:application/json' -d '{celsius:12}' http://IP
 Address:8280/api context

 Thanks,
 Asanka D

 On Wed, Feb 4, 2015 at 9:03 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Im trying out Payload and Script mediator functionality to call this SOAP
 service,


 http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit


 by simulating a REST API using ESB 4.8.1, here is the synapse
 configuration I have defined


 api xmlns=http://ws.apache.org/ns/synapse; name=tempAPI
 context=/temp
resource methods=POST GET
   inSequence
  log level=custom
 property name=IN_MESSAGE
 value=IN_MESSAGE/property
  /log
  property name=messageType value=application/xml
 scope=axis2/property
  payloadFactory media-type=xml
 format
soapenv:Envelope xmlns:soapenv=
 http://schemas.xmlsoap.org/soap/envelope/; xmlns:web=
 http://www.w3schools.com/webservices/;
   soapenv:Header/soapenv:Header
   soapenv:Body
  web:CelsiusToFahrenheit
 web:Celsius$1/web:Celsius
  /web:CelsiusToFahrenheit
   /soapenv:Body
/soapenv:Envelope
 /format
 args
arg evaluator=json expression=$.celsius/arg
 /args
  /payloadFactory
  send
 endpoint
address uri=
 http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit;
 format=soap11/address
 /endpoint
  /send
   /inSequence
   outSequence
  log level=custom
 property name=OUT_MESSAGE
 value=OUT_MESSAGE/property
  /log
  property name=messageType value=application/json
 scope=axis2/property
  script language=jsvar temp =
 mc.getPayloadXML()..*::CelsiusToFahrenheitResponse.CelsiusToFahrenheitResult.toString();
 mc.setPayloadJSON({
 Temp : {Faran :
 temp} });/script
  send/send
   /outSequence
/resource
 /api


 When I invoke the above using,

 curl -i -POST -H 'Accept: application/json' -d '{celsius:12}' http://IP
 Address:8280/api context

 I get the following exception,

 6:53:00,577 RelayUtils  Error while building Passthrough stream
 java.lang.StringIndexOutOfBoundsException: String index out of range: -1
 at java.lang.String.substring(String.java:1937)
 at
 org.apache.axis2.builder.XFormURLEncodedBuilder.extractParametersFromRequest(XFormURLEncodedBuilder.java:174)
 at
 org.apache.axis2.builder.XFormURLEncodedBuilder.processDocument(XFormURLEncodedBuilder.java:112)
 at
 org.apache.synapse.commons.builders.XFormURLEncodedBuilder.processDocument(XFormURLEncodedBuilder.java:36)
 at
 org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:118

[Dev] Converting JSON to SOAP and vise versa in ESB

[Uvindra Dias Jayasinha]

Im trying out Payload and Script mediator functionality to call this SOAP
service,

http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit


by simulating a REST API using ESB 4.8.1, here is the synapse configuration
I have defined


api xmlns=http://ws.apache.org/ns/synapse; name=tempAPI context=/temp
   resource methods=POST GET
  inSequence
 log level=custom
property name=IN_MESSAGE
value=IN_MESSAGE/property
 /log
 property name=messageType value=application/xml
scope=axis2/property
 payloadFactory media-type=xml
format
   soapenv:Envelope xmlns:soapenv=
http://schemas.xmlsoap.org/soap/envelope/; xmlns:web=
http://www.w3schools.com/webservices/;
  soapenv:Header/soapenv:Header
  soapenv:Body
 web:CelsiusToFahrenheit
web:Celsius$1/web:Celsius
 /web:CelsiusToFahrenheit
  /soapenv:Body
   /soapenv:Envelope
/format
args
   arg evaluator=json expression=$.celsius/arg
/args
 /payloadFactory
 send
endpoint
   address uri=
http://www.w3schools.com/webservices/tempconvert.asmx?op=CelsiusToFahrenheit;
format=soap11/address
/endpoint
 /send
  /inSequence
  outSequence
 log level=custom
property name=OUT_MESSAGE
value=OUT_MESSAGE/property
 /log
 property name=messageType value=application/json
scope=axis2/property
 script language=jsvar temp =
mc.getPayloadXML()..*::CelsiusToFahrenheitResponse.CelsiusToFahrenheitResult.toString();
mc.setPayloadJSON({
Temp : {Faran :
temp} });/script
 send/send
  /outSequence
   /resource
/api


When I invoke the above using,

curl -i -POST -H 'Accept: application/json' -d '{celsius:12}' http://IP
Address:8280/api context

I get the following exception,

6:53:00,577 RelayUtils  Error while building Passthrough stream
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1937)
at
org.apache.axis2.builder.XFormURLEncodedBuilder.extractParametersFromRequest(XFormURLEncodedBuilder.java:174)
at
org.apache.axis2.builder.XFormURLEncodedBuilder.processDocument(XFormURLEncodedBuilder.java:112)
at
org.apache.synapse.commons.builders.XFormURLEncodedBuilder.processDocument(XFormURLEncodedBuilder.java:36)
at
org.apache.synapse.transport.passthru.util.DeferredMessageBuilder.getDocument(DeferredMessageBuilder.java:118)
at
org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:107)
at
org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
at
org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:68)
at
org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:47)
at
org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:131)
at org.apache.synapse.rest.Resource.process(Resource.java:297)
at org.apache.synapse.rest.API.process(API.java:341)
at
org.apache.synapse.rest.RESTRequestHandler.dispatchToAPI(RESTRequestHandler.java:76)
at
org.apache.synapse.rest.RESTRequestHandler.process(RESTRequestHandler.java:63)
at
org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:220)
at
org.apache.synapse.core.axis2.SynapseMessageReceiver.receive(SynapseMessageReceiver.java:83)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at
org.apache.synapse.transport.passthru.ServerWorker.processNonEntityEnclosingRESTHandler(ServerWorker.java:344)
at
org.apache.synapse.transport.passthru.ServerWorker.processEntityEnclosingRequest(ServerWorker.java:385)
at
org.apache.synapse.transport.passthru.ServerWorker.run(ServerWorker.java:183)
at
org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
06:53:00,578 SequenceMediator  Error while building message
org.apache.axis2.AxisFault: Error while building Passthrough stream
at
org.apache.synapse.transport.passthru.util.RelayUtils.handleException(RelayUtils.java:236)
at
org.apache.synapse.transport.passthru.util.RelayUtils.builldMessage(RelayUtils.java:111)
at
org.apache.synapse.transport.passthru.util.RelayUtils.buildMessage(RelayUtils.java:82)
at

Re: [Dev] Greg build failure in APIM features installation

[Uvindra Dias Jayasinha]

Hi Roshan,

Your pull request has been merged

On 22 January 2015 at 11:12, Roshan Wijesena ros...@wso2.com wrote:

 [Looping Ruwan]

 On Thu, Jan 22, 2015 at 11:10 AM, Roshan Wijesena ros...@wso2.com wrote:

 Hi Nuwan/Ruwan

 Please merge the pull request to wso2-dev/apimgt [1].

 https://github.com/wso2-dev/carbon-apimgt/pull/19

 Hi Chandana,

 Please let me know if you still have this issue even after apply these
 changes.

 Regards
 Roshan.

 On Wed, Jan 21, 2015 at 10:12 PM, Chandana Napagoda chand...@wso2.com
 wrote:

 Hi APIM Team,

 Greg build is failing[1] in the p2 profile generation while installing
 APIM features. Can you please look into these build issue ASAP.

 [1]. https://wso2.org/jenkins/job/product-greg/350/console

 Installation failed.
 Cannot complete the install because one or more required items could not
 be found.
  Software being installed: WSO2 Carbon - Api management Server
 Interceptor Feature 4.3.0.SNAPSHOT (org.wso2.carbon.apimgt.
 interceptor.feature.group 4.3.0.SNAPSHOT)
  Missing requirement: org.wso2.carbon.apimgt.interceptor 4.3.0.SNAPSHOT
 (org.wso2.carbon.apimgt.interceptor 4.3.0.SNAPSHOT) requires 'package
 org.wso2.carbon.core 4.3.0.SNAPSHOT' but it could not be found
  Cannot satisfy dependency:
   From: WSO2 Carbon - Api management Server Interceptor Feature
 4.3.0.SNAPSHOT (org.wso2.carbon.apimgt.interceptor.feature.group
 4.3.0.SNAPSHOT)
   To: org.wso2.carbon.apimgt.interceptor [4.3.0.SNAPSHOT]
 Application failed, log file location: 
 https://wso2.org/jenkins/job/product-greg/ws/.repository/org/eclipse/tycho/tycho-p2-runtime/0.13.0/eclipse/configuration/1421853249326.log
 

 Regards,
 Chandana

 --
 *Chandana Napagoda*
 Senior Software Engineer
 WSO2 Inc. - http://wso2.org

 *Email  :  chand...@wso2.com chand...@wso2.com**Mobile : +94718169299
 %2B94718169299*

 *Blog  :http://cnapagoda.blogspot.com
 http://cnapagoda.blogspot.com*




 --
 Roshan Wijesena.
 Senior Software Engineer-WSO2 Inc.
 Mobile: *+94719154640 %2B94719154640*
 Email: ros...@wso2.com
 *WSO2, Inc. :** wso2.com http://wso2.com/*
 lean.enterprise.middleware.




 --
 Roshan Wijesena.
 Senior Software Engineer-WSO2 Inc.
 Mobile: *+94719154640 %2B94719154640*
 Email: ros...@wso2.com
 *WSO2, Inc. :** wso2.com http://wso2.com/*
 lean.enterprise.middleware.




-- 
Regards,
Uvindra

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

[Dev] [DEV][Synapse] Sending a JSON response to an API invocation

[Uvindra Dias Jayasinha]

Hi All,

Im trying to send a simple JSON response when an API gets invoked, but I
can only manage a SOAP envelope as the response, here is the synapse
configuration,

?xml version=1.0 encoding=UTF-8?api xmlns=
http://ws.apache.org/ns/synapse; name=HealthCheck_API
context=/check_health
resource methods=POST GET url-mapping=/*
inSequence
header name=To action=remove/
property name=RESPONSE value=true/
property name=NO_ENTITY_BODY scope=axis2 action=remove/
payloadFactory media-type=json
format{ status: okay }/format
/payloadFactory
property name=messageType value=application/json
scope=axis2/
property name=ContentType value=application/json
scope=axis2/
send/
/inSequence
/resource
/api


This what Im getting now,

?xml version='1.0' encoding='UTF-8'?soapenv:Envelope xmlns:soapenv=
http://www.w3.org/2003/05/soap-envelope
soapenv:Bodystatusokay/status/soapenv:Body/soapenv:Envelope


This is what I want,

{ status: okay }

What am I missing? Thanks

-- 
Regards,
Uvindra

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

Re: [Dev] [DEV][Synapse] Sending a JSON response to an API invocation

[Uvindra Dias Jayasinha]

This is using API Manager 1.4 which uses synapse version 2.1.1.wso2v5

On 16 December 2014 at 11:11, Uvindra Dias Jayasinha uvin...@wso2.com
wrote:

 Hi All,

 Im trying to send a simple JSON response when an API gets invoked, but I
 can only manage a SOAP envelope as the response, here is the synapse
 configuration,

 ?xml version=1.0 encoding=UTF-8?api xmlns=
 http://ws.apache.org/ns/synapse; name=HealthCheck_API
 context=/check_health
 resource methods=POST GET url-mapping=/*
 inSequence
 header name=To action=remove/
 property name=RESPONSE value=true/
 property name=NO_ENTITY_BODY scope=axis2 action=remove/
 payloadFactory media-type=json
 format{ status: okay }/format
 /payloadFactory
 property name=messageType value=application/json
 scope=axis2/
 property name=ContentType value=application/json
 scope=axis2/
 send/
 /inSequence
 /resource
 /api


 This what Im getting now,

 ?xml version='1.0' encoding='UTF-8'?soapenv:Envelope xmlns:soapenv=
 http://www.w3.org/2003/05/soap-envelope
 soapenv:Bodystatusokay/status/soapenv:Body/soapenv:Envelope


 This is what I want,

 { status: okay }

 What am I missing? Thanks

 --
 Regards,
 Uvindra

 Mobile: 33962



-- 
Regards,
Uvindra

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

Re: [Dev] [DEV][Synapse] Sending a JSON response to an API invocation

[Uvindra Dias Jayasinha]

Okay Shafreen helped diagnose this, the axis2.xml of API Manager 1.4 the
default JSON message formatter enabled is this,


messageFormatter contentType=application/json

class=org.wso2.carbon.relay.ExpandingMessageFormatter/


when the above is used the JSON formatting does not occur as expected, but
when this is commented and the below formatter is enabled instead,


messageFormatter contentType=application/json

class=org.apache.axis2.json.JSONMessageFormatter/

it works. Thanks Shafreen.










On 16 December 2014 at 11:16, Uvindra Dias Jayasinha uvin...@wso2.com
wrote:

 This is using API Manager 1.4 which uses synapse version 2.1.1.wso2v5

 On 16 December 2014 at 11:11, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Hi All,

 Im trying to send a simple JSON response when an API gets invoked, but I
 can only manage a SOAP envelope as the response, here is the synapse
 configuration,

 ?xml version=1.0 encoding=UTF-8?api xmlns=
 http://ws.apache.org/ns/synapse; name=HealthCheck_API
 context=/check_health
 resource methods=POST GET url-mapping=/*
 inSequence
 header name=To action=remove/
 property name=RESPONSE value=true/
 property name=NO_ENTITY_BODY scope=axis2 action=remove/
 payloadFactory media-type=json
 format{ status: okay }/format
 /payloadFactory
 property name=messageType value=application/json
 scope=axis2/
 property name=ContentType value=application/json
 scope=axis2/
 send/
 /inSequence
 /resource
 /api


 This what Im getting now,

 ?xml version='1.0' encoding='UTF-8'?soapenv:Envelope xmlns:soapenv=
 http://www.w3.org/2003/05/soap-envelope
 soapenv:Bodystatusokay/status/soapenv:Body/soapenv:Envelope


 This is what I want,

 { status: okay }

 What am I missing? Thanks

 --
 Regards,
 Uvindra

 Mobile: 33962



 --
 Regards,
 Uvindra

 Mobile: 33962



-- 
Regards,
Uvindra

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

Re: [Dev] [DEV][Synapse] Sending a JSON response to an API invocation

[Uvindra Dias Jayasinha]

Thanks Isuru, here is the final syanpse configuration with this change,

?xml version=1.0 encoding=UTF-8?api xmlns=
http://ws.apache.org/ns/synapse; name=HealthCheck_API
context=/check_health
resource methods=POST GET url-mapping=/*
inSequence
builder class=org.apache.axis2.json.JSONBuilder
formatterClass=org.apache.axis2.json.JSONMessageFormatter/
header name=To action=remove/
property name=RESPONSE value=true/
property name=NO_ENTITY_BODY scope=axis2 action=remove/
payloadFactory media-type=json
format{ status: okay }/format
/payloadFactory
property name=messageType value=application/json
scope=axis2/
 send/
/inSequence
/resource
/api


This works with the default axis2.xml message formatter configurations
available in API Manager 1.4, so no changes are required at axis2.xml level.


On 16 December 2014 at 12:17, Isuru Udana isu...@wso2.com wrote:

 Hi Uvindra,

 It is not safe to change the message formatter in API manager 1.4 as it
 uses binary relay and the changes will affect globally.

 Instead of doing changes to axis2.xml message builder/formatters we can
 build the message using the builder mediator at the API.

 builder class=org.apache.axis2.json.JSONBuilder
 formatterClass=org.apache.axis2.json.JSONMessageFormatter/builder

 Thanks.

 On Tue, Dec 16, 2014 at 11:39 AM, Uvindra Dias Jayasinha uvin...@wso2.com
  wrote:

 Okay Shafreen helped diagnose this, the axis2.xml of API Manager 1.4 the
 default JSON message formatter enabled is this,


 messageFormatter contentType=application/json

 class=org.wso2.carbon.relay.ExpandingMessageFormatter/


 when the above is used the JSON formatting does not occur as expected,
 but when this is commented and the below formatter is enabled instead,


 messageFormatter contentType=application/json

 class=org.apache.axis2.json.JSONMessageFormatter/

 it works. Thanks Shafreen.










 On 16 December 2014 at 11:16, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 This is using API Manager 1.4 which uses synapse version 2.1.1.wso2v5

 On 16 December 2014 at 11:11, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Hi All,

 Im trying to send a simple JSON response when an API gets invoked, but
 I can only manage a SOAP envelope as the response, here is the synapse
 configuration,

 ?xml version=1.0 encoding=UTF-8?api xmlns=
 http://ws.apache.org/ns/synapse; name=HealthCheck_API
 context=/check_health
 resource methods=POST GET url-mapping=/*
 inSequence
 header name=To action=remove/
 property name=RESPONSE value=true/
 property name=NO_ENTITY_BODY scope=axis2 action=remove/
 payloadFactory media-type=json
 format{ status: okay }/format
 /payloadFactory
 property name=messageType value=application/json
 scope=axis2/
 property name=ContentType value=application/json
 scope=axis2/
 send/
 /inSequence
 /resource
 /api


 This what Im getting now,

 ?xml version='1.0' encoding='UTF-8'?soapenv:Envelope xmlns:soapenv=
 http://www.w3.org/2003/05/soap-envelope
 soapenv:Bodystatusokay/status/soapenv:Body/soapenv:Envelope


 This is what I want,

 { status: okay }

 What am I missing? Thanks

 --
 Regards,
 Uvindra

 Mobile: 33962



 --
 Regards,
 Uvindra

 Mobile: 33962



 --
 Regards,
 Uvindra

 Mobile: 33962

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



 --
 *Isuru Udana*
 Senior
 *Software Engineer*
 WSO2 Inc.; http://wso2.com
 email: isu...@wso2.com cell: +94 77 3791887
 blog: http://mytecheye.blogspot.com/
 twitter: http://twitter.com/isudana



-- 
Regards,
Uvindra

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

[Dev] [DEV][IS] LDAP vs JDBC user store

[Uvindra Dias Jayasinha]

What is the advantage/disadvantage(if any) of using the embeded LDAP user
store Vs a JDBC user store in IS? Thanks

-- 
Regards,
Uvindra

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

Re: [Dev] [DEV][API-M] - SSO Cofiguration Documentation issue

[Uvindra Dias Jayasinha]

Even if that works still we will need to do the change to the
documentation, since if we follow the official documented method for
enabling SSO it does not work for tenant users.

On 29 October 2014 20:39, Nuwan Dias nuw...@wso2.com wrote:

 What if you define the SP as a 'SaaS Application', doesn't it work? It
 used to work with 1.7.0 and IS 5.0.0 AFAIR.

 On Wed, Oct 29, 2014 at 1:51 AM, Yasassri Ratnayake yasas...@wso2.com
 wrote:

 Hi All,

 When enabling SSO for Publisher and Store. A new config element should be
 added to identity.xml file in the IS Node in-order for tenant users to
 login, If the element is not included the following error will be shown in
 the API-M console.

 ERROR - jaggery_acs:jag SAML response signature is verification failed.

 This is reported at [1], please do the needful to fix this.

 [1] - https://wso2.org/jira/browse/DOCUMENTATION-1219

 With Regards,
 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 pack 20-10-2014

[Uvindra Dias Jayasinha]

We made this change to fix[1], we changed all the DB scripts so that they
would be consistent, but looks like now Oracle has an issue with this :(

So we will revert it back on the other scripts to CURRENT_TIMESTAMP as
default(which was what existed previously) and only have a 0 as default for
the MySQL DB script since there is no way of maintaining consistency across
all scripts for this case anymore.



[1] - https://wso2.org/jira/browse/APIMANAGER-2981

On 28 October 2014 16:23, Evanthika Amarasiri evanth...@wso2.com wrote:

 Hi Uvindra,

 The Oracle DB script of the latest API-M pack (27th Oct) fails due to the
 following of the AM_WORKFLOWS table.

 *WF_CREATED_TIME TIMESTAMP DEFAULT 0,*

 Since testing on the setup was blocked from this  issue, we updated the
 script as below.

 *WF_CREATED_TIME TIMESTAMP DEFAULT CURRENT_TIMESTAMP*

 Jira reported at [1]

 [1] - https://wso2.org/jira/browse/APIMANAGER-3021

 Regards,
 Evanthika

 On Wed, Oct 22, 2014 at 3:22 PM, Yasassri Ratnayake yasas...@wso2.com
 wrote:

 Thanks, We will be using the provided scripts for time being.

 On Wed, Oct 22, 2014 at 2:52 PM, Uvindra Dias Jayasinha uvin...@wso2.com
  wrote:

 Ticket has been resolved and the updated scripts can be obtained from
 here till a new pack is issued,


 https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/apimgt/1.8.0/modules/distribution/resources/sql/

  You can use these scripts instead of the ones in the 20 October pack to
 create databases for your testing

 On 22 October 2014 10:02, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Yes you can use the scripts from the previous pack to continue but
 refrain from testing any *work flow* related functionality until we
 resolve this for the moment.

 We will change this so that it is backward compatible.

 On 22 October 2014 09:59, Yasassri Ratnayake yasas...@wso2.com wrote:

 Hi Uvindra,

 I'm using *mysql 5.5.40*. Till you fix this issue is it OK if we use
 the scripts from the 6th October pack since this issue is blocking us.

 With regards,

 On Wed, Oct 22, 2014 at 9:50 AM, Uvindra Dias Jayasinha 
 uvin...@wso2.com wrote:

 The change to the script was introduced via the resolution of this
 ticket,

 https://wso2.org/jira/browse/APIMANAGER-2536

 This issue is MySQL version dependent and does not occur on version
 5.6.5 and above. Most probably this was tested on a newer version of 
 MySQL
 during development and therefore did not cause any issues.

 On 22 October 2014 09:41, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 I am looking into this, the script has been changed recently

 On 22 October 2014 07:53, Yasassri Ratnayake yasas...@wso2.com
 wrote:

 Hi All,

 There seems to be an Syntax error in the mysql DB scripts(apim
 scripts), and due to this some of the tables do not get created. I have
 reported this at [1]. Since this is a blocking issue pls provide a fix
 ASAP.

 When the server is started with -Dsetup parameter the server
 doesn't even throw an error indicating that the DB scripts haven't 
 executed
 properly.  Isn't this another concern?

 [1] - https://wso2.org/jira/browse/APIMANAGER-2981
 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*





-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 pack 20-10-2014

[Uvindra Dias Jayasinha]

I am looking into this, the script has been changed recently

On 22 October 2014 07:53, Yasassri Ratnayake yasas...@wso2.com wrote:

 Hi All,

 There seems to be an Syntax error in the mysql DB scripts(apim scripts),
 and due to this some of the tables do not get created. I have reported this
 at [1]. Since this is a blocking issue pls provide a fix ASAP.

 When the server is started with -Dsetup parameter the server doesn't even
 throw an error indicating that the DB scripts haven't executed properly.
 Isn't this another concern?

 [1] - https://wso2.org/jira/browse/APIMANAGER-2981
 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 pack 20-10-2014

[Uvindra Dias Jayasinha]

The change to the script was introduced via the resolution of this ticket,

https://wso2.org/jira/browse/APIMANAGER-2536

This issue is MySQL version dependent and does not occur on version 5.6.5
and above. Most probably this was tested on a newer version of MySQL during
development and therefore did not cause any issues.

On 22 October 2014 09:41, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 I am looking into this, the script has been changed recently

 On 22 October 2014 07:53, Yasassri Ratnayake yasas...@wso2.com wrote:

 Hi All,

 There seems to be an Syntax error in the mysql DB scripts(apim scripts),
 and due to this some of the tables do not get created. I have reported this
 at [1]. Since this is a blocking issue pls provide a fix ASAP.

 When the server is started with -Dsetup parameter the server doesn't even
 throw an error indicating that the DB scripts haven't executed properly.
 Isn't this another concern?

 [1] - https://wso2.org/jira/browse/APIMANAGER-2981
 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




 --
 Regards,
 Uvindra

 Mobile: 33962




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 pack 20-10-2014

[Uvindra Dias Jayasinha]

Yes you can use the scripts from the previous pack to continue but refrain
from testing any *work flow* related functionality until we resolve this
for the moment.

We will change this so that it is backward compatible.

On 22 October 2014 09:59, Yasassri Ratnayake yasas...@wso2.com wrote:

 Hi Uvindra,

 I'm using *mysql 5.5.40*. Till you fix this issue is it OK if we use the
 scripts from the 6th October pack since this issue is blocking us.

 With regards,

 On Wed, Oct 22, 2014 at 9:50 AM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 The change to the script was introduced via the resolution of this ticket,

 https://wso2.org/jira/browse/APIMANAGER-2536

 This issue is MySQL version dependent and does not occur on version 5.6.5
 and above. Most probably this was tested on a newer version of MySQL during
 development and therefore did not cause any issues.

 On 22 October 2014 09:41, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 I am looking into this, the script has been changed recently

 On 22 October 2014 07:53, Yasassri Ratnayake yasas...@wso2.com wrote:

 Hi All,

 There seems to be an Syntax error in the mysql DB scripts(apim
 scripts), and due to this some of the tables do not get created. I have
 reported this at [1]. Since this is a blocking issue pls provide a fix
 ASAP.

 When the server is started with -Dsetup parameter the server doesn't
 even throw an error indicating that the DB scripts haven't executed
 properly.  Isn't this another concern?

 [1] - https://wso2.org/jira/browse/APIMANAGER-2981
 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 pack 20-10-2014

[Uvindra Dias Jayasinha]

Ticket has been resolved and the updated scripts can be obtained from here
till a new pack is issued,

https://svn.wso2.org/repos/wso2/carbon/platform/branches/turing/products/apimgt/1.8.0/modules/distribution/resources/sql/

 You can use these scripts instead of the ones in the 20 October pack to
create databases for your testing

On 22 October 2014 10:02, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 Yes you can use the scripts from the previous pack to continue but refrain
 from testing any *work flow* related functionality until we resolve this
 for the moment.

 We will change this so that it is backward compatible.

 On 22 October 2014 09:59, Yasassri Ratnayake yasas...@wso2.com wrote:

 Hi Uvindra,

 I'm using *mysql 5.5.40*. Till you fix this issue is it OK if we use the
 scripts from the 6th October pack since this issue is blocking us.

 With regards,

 On Wed, Oct 22, 2014 at 9:50 AM, Uvindra Dias Jayasinha uvin...@wso2.com
  wrote:

 The change to the script was introduced via the resolution of this
 ticket,

 https://wso2.org/jira/browse/APIMANAGER-2536

 This issue is MySQL version dependent and does not occur on version
 5.6.5 and above. Most probably this was tested on a newer version of MySQL
 during development and therefore did not cause any issues.

 On 22 October 2014 09:41, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 I am looking into this, the script has been changed recently

 On 22 October 2014 07:53, Yasassri Ratnayake yasas...@wso2.com wrote:

 Hi All,

 There seems to be an Syntax error in the mysql DB scripts(apim
 scripts), and due to this some of the tables do not get created. I have
 reported this at [1]. Since this is a blocking issue pls provide a fix
 ASAP.

 When the server is started with -Dsetup parameter the server doesn't
 even throw an error indicating that the DB scripts haven't executed
 properly.  Isn't this another concern?

 [1] - https://wso2.org/jira/browse/APIMANAGER-2981
 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Yasassri Ratnayake
 Software Engineer - QA
 WSO2 Inc ; http://wso2.com
 lean.enterprise.middleware
 *Mobile : +94715933168 %2B94715933168*
 *Blog : http://yasassriratnayake.blogspot.com/
 http://yasassriratnayake.blogspot.com/*




 --
 Regards,
 Uvindra

 Mobile: 33962




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 pack 20-10-2014

[Uvindra Dias Jayasinha]

p2-repo has also been uploaded to the above svn location

On 21 October 2014 10:27, Uvindra Dias Jayasinha uvin...@wso2.com wrote:

 will do, still building it

 On 21 October 2014 10:24, Abimaran Kugathasan abima...@wso2.com wrote:

 Hi Uvindra,

 Is it possible to commit p2 repo also here?

 On Mon, Oct 20, 2014 at 7:22 PM, Uvindra Dias Jayasinha uvin...@wso2.com
  wrote:

 Hi All,

 $subject can be found at,

 https://svn.wso2.org/repos/wso2/scratch/chunk13-release/20-10-2014/

 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Thanks
 Abimaran Kugathasan

 Software Engineer | WSO2 Inc
 Data  APIs Technologies Team
 Mobile : +94 773922820

 http://stackoverflow.com/users/515034
 http://lk.linkedin.com/in/abimaran
 http://www.lkabimaran.blogspot.com/  https://github.com/abimaran
 https://twitter.com/abimaran




 --
 Regards,
 Uvindra

 Mobile: 33962




-- 
Regards,
Uvindra

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

Re: [Dev] API Manager 1.8.0 pack 20-10-2014

[Uvindra Dias Jayasinha]

will do, still building it

On 21 October 2014 10:24, Abimaran Kugathasan abima...@wso2.com wrote:

 Hi Uvindra,

 Is it possible to commit p2 repo also here?

 On Mon, Oct 20, 2014 at 7:22 PM, Uvindra Dias Jayasinha uvin...@wso2.com
 wrote:

 Hi All,

 $subject can be found at,

 https://svn.wso2.org/repos/wso2/scratch/chunk13-release/20-10-2014/

 --
 Regards,
 Uvindra

 Mobile: 33962




 --
 Thanks
 Abimaran Kugathasan

 Software Engineer | WSO2 Inc
 Data  APIs Technologies Team
 Mobile : +94 773922820

 http://stackoverflow.com/users/515034
 http://lk.linkedin.com/in/abimaran
 http://www.lkabimaran.blogspot.com/  https://github.com/abimaran
 https://twitter.com/abimaran




-- 
Regards,
Uvindra

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