From cstolte at ebsco.com  Tue May  3 10:48:49 2016
From: cstolte at ebsco.com (Christopher Stolte)
Date: Tue, 3 May 2016 14:48:49 +0000
Subject: [Apiman-user] Changing gateway endpoints
In-Reply-To: <5716417A.9060304@redhat.com>
References: <BLUPR0101MB1506055E8E45C5A47B35579BBB6B0@BLUPR0101MB1506.prod.exchangelabs.com>,
	<5716417A.9060304@redhat.com>
Message-ID: <BLUPR0101MB1506618C3D5DFBCF5BDB2DC5BB7A0@BLUPR0101MB1506.prod.exchangelabs.com>

Upon further investigation, it seems that APIMAN dictates the URL structure for a managed endpoint. Namely:

 /ORG_ID/API_ID/VERSION/path/to/resource

I found this enforced, for example, in io.apiman.gateway.platforms.servlet.GatewayServlet#readRequest(request).

Is that true? Would I need to change that code (and probably other code too) in order to deploy to an arbitrary URL structure?
Also, I didn't have much luck using port 80 for SSL. (I tried changing the socket-binding in standalone.xml). What I really want is a managed endpoint like this:

https://mydomain.com/apis/arbitrary/endpoint/resource

I don't know if this is possible shy of code changes - has anyone else attempted this or similar? Thanks for any pointers or guidance!

________________________________________
From: Eric Wittmann <eric.wittmann at redhat.com>
Sent: Tuesday, April 19, 2016 10:32:26 AM
To: Christopher Stolte; apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Changing gateway endpoints

Assuming you are running apiman in WildFly or EAP (typical use) here is
what you need to do to change the apiman endpoint:

1) Modify the "jboss-web.xml" file inside the apiman-gateway.war file
(you can find it in WEB-INF).

2) Change the <context-root> to whatever you want it to be

3) Deploy the changed WAR to EAP/WildFly

4) Profit!

Here is the file in question within the apiman source code:

https://github.com/apiman/apiman/blob/master/gateway/platforms/war/wildfly8/gateway/src/main/webapp/WEB-INF/jboss-web.xml#L3

If you are running apiman on tomcat or jetty, you'll need to do
something different - so let me know. :)

-Eric

On 4/18/2016 3:33 PM, Christopher Stolte wrote:
> Hi All,
>
>
> I am trying to change the gateway endpoint so that managed endpoints for
> my services have a public URL under my control (for example maybe
> http://my.domain.com/apis).  I found this discussion:
>
>
> http://lists.jboss.org/pipermail/apiman-user/2015-October/000324.html
>
>
> Is changing the gateway WAR the only way to achieve this?  Maybe I'm
> missing a more obvious way to affect the managed endpoint?  If that is
> the way to go about it, can someone give me an idea of where in the code
> to do that?
>
>
> Thanks for any help!
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From eric.wittmann at redhat.com  Tue May  3 11:52:36 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 3 May 2016 11:52:36 -0400
Subject: [Apiman-user] Changing gateway endpoints
In-Reply-To: <BLUPR0101MB1506618C3D5DFBCF5BDB2DC5BB7A0@BLUPR0101MB1506.prod.exchangelabs.com>
References: <BLUPR0101MB1506055E8E45C5A47B35579BBB6B0@BLUPR0101MB1506.prod.exchangelabs.com>
	<5716417A.9060304@redhat.com>
	<BLUPR0101MB1506618C3D5DFBCF5BDB2DC5BB7A0@BLUPR0101MB1506.prod.exchangelabs.com>
Message-ID: <f0426718-cacc-be38-5b79-18ba07ea0ce0@redhat.com>

Yes I think I didn't understand your question last time.

Currently the full managed endpoint in apiman looks like this:

http(s)://host:port/apiman-gateway/ORG_ID/API_ID/VERSION/path/to/blah

The instructions I sent last time would only allow you to change the 
"apiman-gateway" part of the URL, which is what I thought you were 
looking for (e.g. to change that to /apis).

The rest of the URL is dictated by code, as you observed.  We have an 
outstanding Feature Request which would allow each API to specify a 
custom endpoint URL, rather than forcing the format above.  However we 
haven't yet implemented that feature.

Your only choices in the short term would be to modify apiman code, or 
maintain your own mappings and implement something like a servlet filter 
to enforce them.

As for HTTPS - you don't want to use port 80 for HTTPS.  The default 
port for SSL is 443 - so if you want the following URL to work:

https://host/path/to/something

...then you want to set your SSL port to be 443 (that's the default port 
your browser will use when connecting via https).

-Eric



On 5/3/2016 10:48 AM, Christopher Stolte wrote:
> Upon further investigation, it seems that APIMAN dictates the URL structure for a managed endpoint. Namely:
>
>  /ORG_ID/API_ID/VERSION/path/to/resource
>
> I found this enforced, for example, in io.apiman.gateway.platforms.servlet.GatewayServlet#readRequest(request).
>
> Is that true? Would I need to change that code (and probably other code too) in order to deploy to an arbitrary URL structure?
> Also, I didn't have much luck using port 80 for SSL. (I tried changing the socket-binding in standalone.xml). What I really want is a managed endpoint like this:
>
> https://mydomain.com/apis/arbitrary/endpoint/resource
>
> I don't know if this is possible shy of code changes - has anyone else attempted this or similar? Thanks for any pointers or guidance!
>
> ________________________________________
> From: Eric Wittmann <eric.wittmann at redhat.com>
> Sent: Tuesday, April 19, 2016 10:32:26 AM
> To: Christopher Stolte; apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Changing gateway endpoints
>
> Assuming you are running apiman in WildFly or EAP (typical use) here is
> what you need to do to change the apiman endpoint:
>
> 1) Modify the "jboss-web.xml" file inside the apiman-gateway.war file
> (you can find it in WEB-INF).
>
> 2) Change the <context-root> to whatever you want it to be
>
> 3) Deploy the changed WAR to EAP/WildFly
>
> 4) Profit!
>
> Here is the file in question within the apiman source code:
>
> https://github.com/apiman/apiman/blob/master/gateway/platforms/war/wildfly8/gateway/src/main/webapp/WEB-INF/jboss-web.xml#L3
>
> If you are running apiman on tomcat or jetty, you'll need to do
> something different - so let me know. :)
>
> -Eric
>
> On 4/18/2016 3:33 PM, Christopher Stolte wrote:
>> Hi All,
>>
>>
>> I am trying to change the gateway endpoint so that managed endpoints for
>> my services have a public URL under my control (for example maybe
>> http://my.domain.com/apis).  I found this discussion:
>>
>>
>> http://lists.jboss.org/pipermail/apiman-user/2015-October/000324.html
>>
>>
>> Is changing the gateway WAR the only way to achieve this?  Maybe I'm
>> missing a more obvious way to affect the managed endpoint?  If that is
>> the way to go about it, can someone give me an idea of where in the code
>> to do that?
>>
>>
>> Thanks for any help!
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>

From cstolte at ebsco.com  Tue May  3 16:36:58 2016
From: cstolte at ebsco.com (Christopher Stolte)
Date: Tue, 3 May 2016 20:36:58 +0000
Subject: [Apiman-user] Changing gateway endpoints
In-Reply-To: <f0426718-cacc-be38-5b79-18ba07ea0ce0@redhat.com>
References: <BLUPR0101MB1506055E8E45C5A47B35579BBB6B0@BLUPR0101MB1506.prod.exchangelabs.com>
	<5716417A.9060304@redhat.com>
	<BLUPR0101MB1506618C3D5DFBCF5BDB2DC5BB7A0@BLUPR0101MB1506.prod.exchangelabs.com>,
	<f0426718-cacc-be38-5b79-18ba07ea0ce0@redhat.com>
Message-ID: <BLUPR0101MB1506EA4378CD364D99B0A9E0BB7A0@BLUPR0101MB1506.prod.exchangelabs.com>


Thanks again for your comments Eric - very helpful.
________________________________________
From: Eric Wittmann <eric.wittmann at redhat.com>
Sent: Tuesday, May 3, 2016 11:52:36 AM
To: Christopher Stolte; apiman-user at lists.jboss.org
Subject: Re: [Apiman-user] Changing gateway endpoints

Yes I think I didn't understand your question last time.

Currently the full managed endpoint in apiman looks like this:

http(s)://host:port/apiman-gateway/ORG_ID/API_ID/VERSION/path/to/blah

The instructions I sent last time would only allow you to change the
"apiman-gateway" part of the URL, which is what I thought you were
looking for (e.g. to change that to /apis).

The rest of the URL is dictated by code, as you observed.  We have an
outstanding Feature Request which would allow each API to specify a
custom endpoint URL, rather than forcing the format above.  However we
haven't yet implemented that feature.

Your only choices in the short term would be to modify apiman code, or
maintain your own mappings and implement something like a servlet filter
to enforce them.

As for HTTPS - you don't want to use port 80 for HTTPS.  The default
port for SSL is 443 - so if you want the following URL to work:

https://host/path/to/something

...then you want to set your SSL port to be 443 (that's the default port
your browser will use when connecting via https).

-Eric



On 5/3/2016 10:48 AM, Christopher Stolte wrote:
> Upon further investigation, it seems that APIMAN dictates the URL structure for a managed endpoint. Namely:
>
>  /ORG_ID/API_ID/VERSION/path/to/resource
>
> I found this enforced, for example, in io.apiman.gateway.platforms.servlet.GatewayServlet#readRequest(request).
>
> Is that true? Would I need to change that code (and probably other code too) in order to deploy to an arbitrary URL structure?
> Also, I didn't have much luck using port 80 for SSL. (I tried changing the socket-binding in standalone.xml). What I really want is a managed endpoint like this:
>
> https://mydomain.com/apis/arbitrary/endpoint/resource
>
> I don't know if this is possible shy of code changes - has anyone else attempted this or similar? Thanks for any pointers or guidance!
>
> ________________________________________
> From: Eric Wittmann <eric.wittmann at redhat.com>
> Sent: Tuesday, April 19, 2016 10:32:26 AM
> To: Christopher Stolte; apiman-user at lists.jboss.org
> Subject: Re: [Apiman-user] Changing gateway endpoints
>
> Assuming you are running apiman in WildFly or EAP (typical use) here is
> what you need to do to change the apiman endpoint:
>
> 1) Modify the "jboss-web.xml" file inside the apiman-gateway.war file
> (you can find it in WEB-INF).
>
> 2) Change the <context-root> to whatever you want it to be
>
> 3) Deploy the changed WAR to EAP/WildFly
>
> 4) Profit!
>
> Here is the file in question within the apiman source code:
>
> https://github.com/apiman/apiman/blob/master/gateway/platforms/war/wildfly8/gateway/src/main/webapp/WEB-INF/jboss-web.xml#L3
>
> If you are running apiman on tomcat or jetty, you'll need to do
> something different - so let me know. :)
>
> -Eric
>
> On 4/18/2016 3:33 PM, Christopher Stolte wrote:
>> Hi All,
>>
>>
>> I am trying to change the gateway endpoint so that managed endpoints for
>> my services have a public URL under my control (for example maybe
>> http://my.domain.com/apis).  I found this discussion:
>>
>>
>> http://lists.jboss.org/pipermail/apiman-user/2015-October/000324.html
>>
>>
>> Is changing the gateway WAR the only way to achieve this?  Maybe I'm
>> missing a more obvious way to affect the managed endpoint?  If that is
>> the way to go about it, can someone give me an idea of where in the code
>> to do that?
>>
>>
>> Thanks for any help!
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>


From 00hf11 at gmail.com  Thu May 12 12:47:57 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Thu, 12 May 2016 13:47:57 -0300
Subject: [Apiman-user] Question about Test Gateway endpoint
Message-ID: <CABv=XZUj1+QXHwxvt5+DkJQtnsKc2_HU_GGmMiduzqki2OOX=A@mail.gmail.com>

Hi all,

>From REST docs:

'This endpoint is used to test the Gateway's settings prior to either
creating or updating it. The information will be used to attempt to create
a link between the API Manager and the Gateway, by simply trying to ping
the Gateway's "status" endpoint.'

This part:
'The information will be used to attempt to create a link between the API
Manager and the Gateway'

( http://www.apiman.io/latest/api-manager-restdocs.html )


This means the endpoint 'http://localhost:8080/apiman/gateways/' [PUT]
is used for/to/only Apiman itself ? This can be used by other clients or it
no makes much sense ?

Thanks !
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160512/a055b85c/attachment.html 

From cmoullia at redhat.com  Thu May 12 16:30:04 2016
From: cmoullia at redhat.com (Charles Moulliard)
Date: Thu, 12 May 2016 22:30:04 +0200
Subject: [Apiman-user] Disable SSL/TLS for Oauth
Message-ID: <CAPb1sSs4ktpiADKGv-HGVF1NSgd3ThV7yWs2X2sWAYvcKi6G1g@mail.gmail.com>

Hi,

Can we disable SSL/TLS when we use Keycloak Oauth plugin to avoid this
message ""OAuth2 token was transmitted without required transport security
(TLS, SSL)." ?

Regards

Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160512/15e3ff96/attachment.html 

From marc.savy at redhat.com  Fri May 13 07:05:17 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Fri, 13 May 2016 13:05:17 +0200
Subject: [Apiman-user] Disable SSL/TLS for Oauth
In-Reply-To: <CAPb1sSs4ktpiADKGv-HGVF1NSgd3ThV7yWs2X2sWAYvcKi6G1g@mail.gmail.com>
References: <CAPb1sSs4ktpiADKGv-HGVF1NSgd3ThV7yWs2X2sWAYvcKi6G1g@mail.gmail.com>
Message-ID: <CAA7j38+ze1jug5m_2nxRD9Tqp1dud2oEN-Jeho2f7tk1cLbj5g@mail.gmail.com>

On 12 May 2016 at 22:30, Charles Moulliard <cmoullia at redhat.com> wrote:
> Can we disable SSL/TLS when we use Keycloak Oauth plugin to avoid this
> message ""OAuth2 token was transmitted without required transport security
> (TLS, SSL)." ?

Yes, you should be able to untick "require transport security" or edit
your policy's JSON config (see:
http://www.apiman.io/latest/user-guide.html#_oauth_policy_keycloak).

It's generally not a good idea to use OAuth2 without transport
security, however.

From cmoullia at redhat.com  Fri May 13 08:41:17 2016
From: cmoullia at redhat.com (Charles Moulliard)
Date: Fri, 13 May 2016 14:41:17 +0200
Subject: [Apiman-user] Disable SSL/TLS for Oauth
In-Reply-To: <CAA7j38+ze1jug5m_2nxRD9Tqp1dud2oEN-Jeho2f7tk1cLbj5g@mail.gmail.com>
References: <CAPb1sSs4ktpiADKGv-HGVF1NSgd3ThV7yWs2X2sWAYvcKi6G1g@mail.gmail.com>
	<CAA7j38+ze1jug5m_2nxRD9Tqp1dud2oEN-Jeho2f7tk1cLbj5g@mail.gmail.com>
Message-ID: <CAPb1sSt1RAderFzM9oqPd+7zfh2t7w5Lkocj3VgTpQZGn2bH7A@mail.gmail.com>

Thx.

Remark : This is only required for a demo as currently the Apiman-gateway
Kubernetes App doesn't run as HTTPS Server but only as HTTP Server. I will
make the modifications next week to be able to use it as HTTP or HTTPS
Server by adding Openshift Route with TLS Termination passthrough

On Fri, May 13, 2016 at 1:05 PM, Marc Savy <marc.savy at redhat.com> wrote:

> On 12 May 2016 at 22:30, Charles Moulliard <cmoullia at redhat.com> wrote:
> > Can we disable SSL/TLS when we use Keycloak Oauth plugin to avoid this
> > message ""OAuth2 token was transmitted without required transport
> security
> > (TLS, SSL)." ?
>
> Yes, you should be able to untick "require transport security" or edit
> your policy's JSON config (see:
> http://www.apiman.io/latest/user-guide.html#_oauth_policy_keycloak).
>
> It's generally not a good idea to use OAuth2 without transport
> security, however.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160513/770f1248/attachment.html 

From eric.wittmann at redhat.com  Mon May 16 09:42:34 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 16 May 2016 09:42:34 -0400
Subject: [Apiman-user] Question about Test Gateway endpoint
In-Reply-To: <CABv=XZUj1+QXHwxvt5+DkJQtnsKc2_HU_GGmMiduzqki2OOX=A@mail.gmail.com>
References: <CABv=XZUj1+QXHwxvt5+DkJQtnsKc2_HU_GGmMiduzqki2OOX=A@mail.gmail.com>
Message-ID: <5739CE4A.5080002@redhat.com>

This endpoint 'http://localhost:8080/apiman/gateways/' [PUT] is used to 
test whether a particular Gateway configuration would likely work if it 
were added via the endpoint 'http://localhost:8080/apiman/gateways/' [POST].

This is used by the UI on both the New Gateway and Edit Gateway pages. 
See the attached screenshot for details.  When the user clicks the "Test 
Gateway" button, the UI sends the gateway configuration details from the 
form to validate whether the settings are likely correct.  The API 
Manager (/apiman) will try to make a connection to the API Gateway to 
see if it can be reached and whether authentication succeeds.  If all 
goes well, the user can be reasonably certain that she has inputted 
correct information in the form.

-Eric


On 5/12/2016 12:47 PM, Helio Frota wrote:
> Hi all,
>
>  From REST docs:
>
> 'This endpoint is used to test the Gateway's settings prior to either
> creating or updating it. The information will be used to attempt to
> create a link between the API Manager and the Gateway, by simply trying
> to ping the Gateway's "status" endpoint.'
>
> This part:
> 'The information will be used to attempt to create a link between the
> API Manager and the Gateway'
>
> ( http://www.apiman.io/latest/api-manager-restdocs.html )
>
>
> This means the endpoint 'http://localhost:8080/apiman/gateways/' [PUT]
> is used for/to/only Apiman itself ? This can be used by other clients or
> it no makes much sense ?
>
> Thanks !
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scap.PNG
Type: image/png
Size: 49122 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20160516/39acd596/attachment-0001.png 

From 00hf11 at gmail.com  Mon May 16 09:46:38 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Mon, 16 May 2016 10:46:38 -0300
Subject: [Apiman-user] Question about Test Gateway endpoint
In-Reply-To: <5739CE4A.5080002@redhat.com>
References: <CABv=XZUj1+QXHwxvt5+DkJQtnsKc2_HU_GGmMiduzqki2OOX=A@mail.gmail.com>
	<5739CE4A.5080002@redhat.com>
Message-ID: <CABv=XZUTyrY1Dx-0LFcG-FR7fHs54rs4GBn0=Mm9Y1wdPzt=9A@mail.gmail.com>

Very enlightening and informative thank you : ]



On Mon, May 16, 2016 at 10:42 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> This endpoint 'http://localhost:8080/apiman/gateways/' [PUT] is used to
> test whether a particular Gateway configuration would likely work if it
> were added via the endpoint 'http://localhost:8080/apiman/gateways/'
> [POST].
>
> This is used by the UI on both the New Gateway and Edit Gateway pages. See
> the attached screenshot for details.  When the user clicks the "Test
> Gateway" button, the UI sends the gateway configuration details from the
> form to validate whether the settings are likely correct.  The API Manager
> (/apiman) will try to make a connection to the API Gateway to see if it can
> be reached and whether authentication succeeds.  If all goes well, the user
> can be reasonably certain that she has inputted correct information in the
> form.
>
> -Eric
>
>
>
> On 5/12/2016 12:47 PM, Helio Frota wrote:
>
>> Hi all,
>>
>>  From REST docs:
>>
>> 'This endpoint is used to test the Gateway's settings prior to either
>> creating or updating it. The information will be used to attempt to
>> create a link between the API Manager and the Gateway, by simply trying
>> to ping the Gateway's "status" endpoint.'
>>
>> This part:
>> 'The information will be used to attempt to create a link between the
>> API Manager and the Gateway'
>>
>> ( http://www.apiman.io/latest/api-manager-restdocs.html )
>>
>>
>> This means the endpoint 'http://localhost:8080/apiman/gateways/' [PUT]
>> is used for/to/only Apiman itself ? This can be used by other clients or
>> it no makes much sense ?
>>
>> Thanks !
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160516/a3e9f8e2/attachment.html 

From amit.joshi at markit.com  Tue May 17 11:16:15 2016
From: amit.joshi at markit.com (Amit Joshi)
Date: Tue, 17 May 2016 15:16:15 +0000
Subject: [Apiman-user] APIMAN MTLS struggles: ssuggestions
Message-ID: <0874655a5d12478da1b3b3b8173ecfb6@NJ4PDMSGDAG02.markit.partners>

Hello,

I have been following the information in the blog post: http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/2016/01/22/mtls-mutual-auth-redux.html  but has a tough time. I had a simple Java test program that worked against the Api with setting the has a trust store etc. using system properties:

        System.setProperty("javax.net.ssl.trustStore", System.getProperty("truststore.path"));
        System.setProperty("javax.net.ssl.trustStorePassword", System.getProperty("keystore.password"));
        System.setProperty("javax.net.ssl.keyStore", System.getProperty("keystore.path"));
        System.setProperty("javax.net.ssl.keyStorePassword", System.getProperty("keystore.password"));
        System.setProperty("javax.net.ssl.keyStoreType", System.getProperty("keystore.type"));

However, when I try to do the same , but using APIMan (and setting the properties in the apiman.properties file) to gateway the API it fails as below. I tried setting the -Djavax.net.debug.all  (as suggested in the article) which gives a lot more in the logs but all I could see that looked relevant: "Warning: no suitable certificate found - continuing without client authentication" which made no sense since I have the correct cert and it works with the test program.
I finally figured out the issue - the MTLS setup does not allow you to pass in the keyStoreType and my keystore was PKCS12 and not JKS.

Couple of suggestions as a result:

*         Add the ability to set the keyStoreType so we won't have to convert them

*         Also the stacktrace gets truncated in the output (see below) and its very difficult to diagnose what the problem is - something I think would have been minutes if I could have seen the message about not being able to load the keystore took hours.

*         Also I want to be able to automatically use different keystores based on the api or logged-in user or url etc. My thought was to extend the HttpConnectorFactory and override the TlsOptions. However the class has all the properties private with no getters/setters and so it is difficult to do so that. This means I have to pretty much make a copy of the class instead of just a custom extension . Would be good if the class had public or at least protected getters/setters there so I could override the keystore based on some rules..

Results when running against apiman but with a pkcs12 keystore:
Using the Advanced Rest Client app for Chrome. I see the following as a response
X-Gateway-Error: Not connected.
500  Internal Server Error
And the response looks as follows. Note that the message is generic "Not connected" and the stack trace is missing any information about why the connection failed.

{
  "responseCode": 500,
  "message": "Not connected.",
  "trace": "io.apiman.gateway.engine.beans.exceptions.ConnectorException: Not connected.\n\tat io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:332)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$1(ApiRequestExecutorImpl.java:234)\n\tat io.apiman.gateway.engine.io.AbstractStream.handleBody(AbstractStream.java:107)\n\tat io.apiman.gateway.engine.policy.Chain.write(Chain.java:181)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$1.write(ApiRequestExecutorImpl.java:525)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:169)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:161)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.handleStream(ApiRequestExecutorImpl.java:517)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$3(ApiRequestExecutorImpl.java:243)\n\tat io.apiman.gateway.engine.policy.Chain.handleHead(Chain.java:211)\n\tat io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:150)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:246)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:419)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$5(ApiRequestExecutorImpl.java:269)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:123)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:112)\n\tat io.apiman.gateway.engine.es.CachingESRegistry.getApi(CachingESRegistry.java:115)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper.getApi(SecureRegistryWrapper.java:112)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:252)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)\n\tat io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)\n\tat io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat java.lang.Thread.run(Thread.java:745)\nCaused by: java.io.IOException: Not connected.\n\tat io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:319)\n\t... 48 more\n"
}

Regards,

Amit Joshi



________________________________

This e-mail, including accompanying communications and attachments, is strictly confidential and only for the intended recipient. Any retention, use or disclosure not expressly authorised by Markit is prohibited. This email is subject to all waivers and other terms at the following link: http://www.markit.com/en/about/legal/email-disclaimer.page

Please visit http://www.markit.com/en/about/contact/contact-us.page for contact information on our offices worldwide.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160517/db1ccf79/attachment-0001.html 

From eric.wittmann at redhat.com  Wed May 18 09:05:15 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 18 May 2016 09:05:15 -0400
Subject: [Apiman-user] Question about Test Gateway endpoint
In-Reply-To: <BLUPR01MB392C6E570C94AAEFED2056BC2480@BLUPR01MB392.prod.exchangelabs.com>
References: <CABv=XZUj1+QXHwxvt5+DkJQtnsKc2_HU_GGmMiduzqki2OOX=A@mail.gmail.com>
	<5739CE4A.5080002@redhat.com>
	<BLUPR01MB392205E0AA08F129ECE818FC2770@BLUPR01MB392.prod.exchangelabs.com>
	<8c9485ef-4bcd-af13-9659-d01b9a51a2f1@redhat.com>
	<BLUPR01MB392C6E570C94AAEFED2056BC2480@BLUPR01MB392.prod.exchangelabs.com>
Message-ID: <05a5641e-7d6d-1b93-52a4-094de2652abe@redhat.com>

I don't have a specific timeline for this, but Swagger would definitely 
be the first to be implemented.  There is more of a preference for 
Swagger within Red Hat and also in the apiman community (from what I can 
tell) vs. RAML.

-Eric

On 5/17/2016 1:39 PM, Subbarao Denduluri wrote:
> Thanks for your reply Eric. Actually is there priotity in your timelines to support Swagger or Raml.  Like which particular technology would be available first to import if at all you are planning to support either of these
>
> Thanks
> Subba
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Tuesday, May 17, 2016 8:34 AM
> To: Subbarao Denduluri <sdenduluri at ebsco.com>
> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>
> Unfortunately we don't yet have support for importing APIs into the manager from swagger.  It's something that we *want* but haven't implemented yet.  There is an "Import APIs" UI already, which is designed to support things like:
>
> * swagger
> * raml
> * wadl
> * wsdl
>
> However, currently it only supports the internal "API Catalog" concept that apiman has.
>
> -Eric
>
>
> On 5/16/2016 4:29 PM, Subbarao Denduluri wrote:
>> Hello Eric,
>>
>>        I have a question on Apiman swagger integration.  I am looking into apiman support for an api import from a swagger file.  Does Apiman have support like that?
>>
>> Thanks!
>>
>>
>> -----Original Message-----
>> From: apiman-user-bounces at lists.jboss.org
>> [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Eric
>> Wittmann
>> Sent: Monday, May 16, 2016 9:43 AM
>> To: Helio Frota <00hf11 at gmail.com>; apiman-user
>> <apiman-user at lists.jboss.org>
>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>
>> This endpoint 'http://localhost:8080/apiman/gateways/' [PUT] is used to test whether a particular Gateway configuration would likely work if it were added via the endpoint 'http://localhost:8080/apiman/gateways/' [POST].
>>
>> This is used by the UI on both the New Gateway and Edit Gateway pages.
>> See the attached screenshot for details.  When the user clicks the "Test Gateway" button, the UI sends the gateway configuration details from the form to validate whether the settings are likely correct.  The API Manager (/apiman) will try to make a connection to the API Gateway to see if it can be reached and whether authentication succeeds.  If all goes well, the user can be reasonably certain that she has inputted correct information in the form.
>>
>> -Eric
>>
>>
>> On 5/12/2016 12:47 PM, Helio Frota wrote:
>>> Hi all,
>>>
>>>  From REST docs:
>>>
>>> 'This endpoint is used to test the Gateway's settings prior to either
>>> creating or updating it. The information will be used to attempt to
>>> create a link between the API Manager and the Gateway, by simply
>>> trying to ping the Gateway's "status" endpoint.'
>>>
>>> This part:
>>> 'The information will be used to attempt to create a link between the
>>> API Manager and the Gateway'
>>>
>>> ( http://www.apiman.io/latest/api-manager-restdocs.html )
>>>
>>>
>>> This means the endpoint 'http://localhost:8080/apiman/gateways/'
>>> [PUT] is used for/to/only Apiman itself ? This can be used by other
>>> clients or it no makes much sense ?
>>>
>>> Thanks !
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>

From marc.savy at redhat.com  Wed May 18 09:17:32 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 18 May 2016 14:17:32 +0100
Subject: [Apiman-user] APIMAN MTLS struggles: ssuggestions
In-Reply-To: <0874655a5d12478da1b3b3b8173ecfb6@NJ4PDMSGDAG02.markit.partners>
References: <0874655a5d12478da1b3b3b8173ecfb6@NJ4PDMSGDAG02.markit.partners>
Message-ID: <CAA7j38J4TYxNPWHsSUG_gENqyyA1YNbZtS2Ozzov4sPwkT5MjA@mail.gmail.com>

Hi Amit,

I've just returned from a work trip abroad, but just to let you know I've
noticed this email and will address it in detail shortly.

We're always keen for high quality feedback, so thank you very much!

Regards,
Marc

On Tuesday, May 17, 2016, Amit Joshi <amit.joshi at markit.com> wrote:

> Hello,
>
>
>
> I have been following the information in the blog post:
> http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/2016/01/22/mtls-mutual-auth-redux.html
>  but has a tough time. I had a simple Java test program that worked against
> the Api with setting the has a trust store etc. using system properties:
>
>
>
>         System.setProperty("javax.net.ssl.trustStore",
> System.getProperty("truststore.path"));
>
>         System.setProperty("javax.net.ssl.trustStorePassword",
> System.getProperty("keystore.password"));
>
>         System.setProperty("javax.net.ssl.keyStore",
> System.getProperty("keystore.path"));
>
>         System.setProperty("javax.net.ssl.keyStorePassword",
> System.getProperty("keystore.password"));
>
>         System.setProperty("javax.net.ssl.keyStoreType",
> System.getProperty("keystore.type"));
>
>
>
> However, when I try to do the same , but using APIMan (and setting the
> properties in the apiman.properties file) to gateway the API it fails as
> below. I tried setting the ?Djavax.net.debug.all  (as suggested in the
> article) which gives a lot more in the logs but all I could see that looked
> relevant: ?Warning: no suitable certificate found - continuing without
> client authentication? which made no sense since I have the correct cert
> and it works with the test program.
>
> I finally figured out the issue ? the MTLS setup does not allow you to
> pass in the keyStoreType and my keystore was PKCS12 and not JKS.
>
>
>
> Couple of suggestions as a result:
>
> ?         Add the ability to set the keyStoreType so we won?t have to
> convert them
>
> ?         Also the stacktrace gets truncated in the output (see below)
> and its very difficult to diagnose what the problem is ? something I think
> would have been minutes if I could have seen the message about not being
> able to load the keystore took hours.
>
> ?         Also I want to be able to automatically use different keystores
> based on the api or logged-in user or url etc. My thought was to extend the
> HttpConnectorFactory and override the TlsOptions. However the class has all
> the properties private with no getters/setters and so it is difficult to do
> so that. This means I have to pretty much make a copy of the class instead
> of just a custom extension . Would be good if the class had public or at
> least protected getters/setters there so I could override the keystore
> based on some rules..
>
>
>
> Results when running against apiman but with a pkcs12 keystore:
>
> Using the Advanced Rest Client app for Chrome. I see the following as a
> response
>
> X-Gateway-Error: Not connected.
>
> 500  Internal Server Error
>
> And the response looks as follows. Note that the message is generic ?Not
> connected? and the stack trace is missing any information about why the
> connection failed.
>
>
>
> {
>
>   "responseCode": 500,
>
>   "message": "Not connected.",
>
>   "trace": "io.apiman.gateway.engine.beans.exceptions.ConnectorException:
> Not connected.\n\tat
> io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:332)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$1(ApiRequestExecutorImpl.java:234)\n\tat
> io.apiman.gateway.engine.io.AbstractStream.handleBody(AbstractStream.java:107)\n\tat
> io.apiman.gateway.engine.policy.Chain.write(Chain.java:181)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$1.write(ApiRequestExecutorImpl.java:525)\n\tat
> io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:169)\n\tat
> io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:161)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.handleStream(ApiRequestExecutorImpl.java:517)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$3(ApiRequestExecutorImpl.java:243)\n\tat
> io.apiman.gateway.engine.policy.Chain.handleHead(Chain.java:211)\n\tat
> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:150)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:246)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:419)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$5(ApiRequestExecutorImpl.java:269)\n\tat
> io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:123)\n\tat
> io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:112)\n\tat
> io.apiman.gateway.engine.es.CachingESRegistry.getApi(CachingESRegistry.java:115)\n\tat
> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getApi(SecureRegistryWrapper.java:112)\n\tat
> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:252)\n\tat
> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat
> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat
> io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat
> io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat
> io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat
> org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
> io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat
> io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
> io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat
> io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat
> io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat
> io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat
> io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat
> io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
> org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
> io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)\n\tat
> io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)\n\tat
> io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat
> io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)\n\tat
> io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat
> io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by: java.io.IOException: Not
> connected.\n\tat
> io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:319)\n\t...
> 48 more\n"
>
> }
>
>
>
> Regards,
>
>
>
> Amit Joshi
>
>
>
>
>
> ------------------------------
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any retention,
> use or disclosure not expressly authorised by Markit is prohibited. This
> email is subject to all waivers and other terms at the following link:
> http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page for
> contact information on our offices worldwide.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160518/c1bdcd44/attachment-0001.html 

From marc.savy at redhat.com  Wed May 18 09:19:13 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 18 May 2016 14:19:13 +0100
Subject: [Apiman-user] Question about Test Gateway endpoint
In-Reply-To: <05a5641e-7d6d-1b93-52a4-094de2652abe@redhat.com>
References: <CABv=XZUj1+QXHwxvt5+DkJQtnsKc2_HU_GGmMiduzqki2OOX=A@mail.gmail.com>
	<5739CE4A.5080002@redhat.com>
	<BLUPR01MB392205E0AA08F129ECE818FC2770@BLUPR01MB392.prod.exchangelabs.com>
	<8c9485ef-4bcd-af13-9659-d01b9a51a2f1@redhat.com>
	<BLUPR01MB392C6E570C94AAEFED2056BC2480@BLUPR01MB392.prod.exchangelabs.com>
	<05a5641e-7d6d-1b93-52a4-094de2652abe@redhat.com>
Message-ID: <CAA7j38+4vAEWLpL5dvQ9Bk8NgkPnHZAA61dyoscJB5NoJYr-eA@mail.gmail.com>

Agreed - especially as Swagger is the basis for the Open API
Initiative (OAI)(https://openapis.org/).

On 18 May 2016 at 14:05, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> I don't have a specific timeline for this, but Swagger would definitely
> be the first to be implemented.  There is more of a preference for
> Swagger within Red Hat and also in the apiman community (from what I can
> tell) vs. RAML.
>
> -Eric
>
> On 5/17/2016 1:39 PM, Subbarao Denduluri wrote:
>> Thanks for your reply Eric. Actually is there priotity in your timelines to support Swagger or Raml.  Like which particular technology would be available first to import if at all you are planning to support either of these
>>
>> Thanks
>> Subba
>>
>> -----Original Message-----
>> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
>> Sent: Tuesday, May 17, 2016 8:34 AM
>> To: Subbarao Denduluri <sdenduluri at ebsco.com>
>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>
>> Unfortunately we don't yet have support for importing APIs into the manager from swagger.  It's something that we *want* but haven't implemented yet.  There is an "Import APIs" UI already, which is designed to support things like:
>>
>> * swagger
>> * raml
>> * wadl
>> * wsdl
>>
>> However, currently it only supports the internal "API Catalog" concept that apiman has.
>>
>> -Eric
>>
>>
>> On 5/16/2016 4:29 PM, Subbarao Denduluri wrote:
>>> Hello Eric,
>>>
>>>        I have a question on Apiman swagger integration.  I am looking into apiman support for an api import from a swagger file.  Does Apiman have support like that?
>>>
>>> Thanks!
>>>
>>>
>>> -----Original Message-----
>>> From: apiman-user-bounces at lists.jboss.org
>>> [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Eric
>>> Wittmann
>>> Sent: Monday, May 16, 2016 9:43 AM
>>> To: Helio Frota <00hf11 at gmail.com>; apiman-user
>>> <apiman-user at lists.jboss.org>
>>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>>
>>> This endpoint 'http://localhost:8080/apiman/gateways/' [PUT] is used to test whether a particular Gateway configuration would likely work if it were added via the endpoint 'http://localhost:8080/apiman/gateways/' [POST].
>>>
>>> This is used by the UI on both the New Gateway and Edit Gateway pages.
>>> See the attached screenshot for details.  When the user clicks the "Test Gateway" button, the UI sends the gateway configuration details from the form to validate whether the settings are likely correct.  The API Manager (/apiman) will try to make a connection to the API Gateway to see if it can be reached and whether authentication succeeds.  If all goes well, the user can be reasonably certain that she has inputted correct information in the form.
>>>
>>> -Eric
>>>
>>>
>>> On 5/12/2016 12:47 PM, Helio Frota wrote:
>>>> Hi all,
>>>>
>>>>  From REST docs:
>>>>
>>>> 'This endpoint is used to test the Gateway's settings prior to either
>>>> creating or updating it. The information will be used to attempt to
>>>> create a link between the API Manager and the Gateway, by simply
>>>> trying to ping the Gateway's "status" endpoint.'
>>>>
>>>> This part:
>>>> 'The information will be used to attempt to create a link between the
>>>> API Manager and the Gateway'
>>>>
>>>> ( http://www.apiman.io/latest/api-manager-restdocs.html )
>>>>
>>>>
>>>> This means the endpoint 'http://localhost:8080/apiman/gateways/'
>>>> [PUT] is used for/to/only Apiman itself ? This can be used by other
>>>> clients or it no makes much sense ?
>>>>
>>>> Thanks !
>>>>
>>>>
>>>> _______________________________________________
>>>> Apiman-user mailing list
>>>> Apiman-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user


From 00hf11 at gmail.com  Fri May 20 11:51:03 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Fri, 20 May 2016 12:51:03 -0300
Subject: [Apiman-user] PluginNotFoundException when adding a new plugin
Message-ID: <CABv=XZWd1LqJAt3Y6FDXoaiXc4+YPm=5J+RNmTL6PHQdm7aFjQ@mail.gmail.com>

Hi ,

I'm trying to use the endpoint :

http://localhost:8080/apiman/plugins/ [ POST ]

' Use this endpoint to add a plugin to apiman. '

Using this object representation:

let plug = {
    name: 'the-new-plugin',
    description: 'the description',
    type: 'plugs',
    version: '1.0.0.Final',
    groupId: 'org.myplugins',
    artifactId: 'superplugin',
    classifier: '1',
    upgrade: false
};

And I'm getting this error :

 type: 'PluginNotFoundException',
  errorCode: 12002,
  message: 'org.myplugins:superplugin:1.0.0.Final-1:plugs',
  moreInfoUrl: null,
  stacktrace:
'io.apiman.manager.api.rest.contract.exceptions.PluginNotFoundException:
  ...

Maybe I'm populating the object with wrong values ? [ e.g classifier ? ]

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160520/1a4de8b5/attachment.html 

From 00hf11 at gmail.com  Fri May 20 12:56:58 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Fri, 20 May 2016 13:56:58 -0300
Subject: [Apiman-user] Node.js client for the Apiman admin API.
Message-ID: <CABv=XZVwO2khfYfQk1FvZZ8N-iBKDE6G64MG89_kB00aAU48tw@mail.gmail.com>

Hi,

I just released version 0.1.0 of a client for Apiman Admin Rest API.

Still a bit experimental but functional.

Feel free to experiment and contribute.
[ npm install apiman-admin-client -S ]

https://github.com/bucharest-gold/apiman-admin-client

https://www.npmjs.com/package/apiman-admin-client
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160520/885b403b/attachment.html 

From marc.savy at redhat.com  Sun May 22 13:12:46 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Sun, 22 May 2016 18:12:46 +0100
Subject: [Apiman-user] APIMAN MTLS struggles: ssuggestions
In-Reply-To: <0874655a5d12478da1b3b3b8173ecfb6@NJ4PDMSGDAG02.markit.partners>
References: <0874655a5d12478da1b3b3b8173ecfb6@NJ4PDMSGDAG02.markit.partners>
Message-ID: <CAA7j38+enoW+S-NHyFM7-uH4zx+bJNSMnonmefPtareuEo_AkA@mail.gmail.com>

Responses inline

On 17 May 2016 at 16:16, Amit Joshi <amit.joshi at markit.com> wrote:
> Hello,
>
>
>
> I have been following the information in the blog post:
>
http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/2016/01/22/mtls-mutual-auth-redux.html
> but has a tough time. I had a simple Java test program that worked against
> the Api with setting the has a trust store etc. using system properties:
>
>
>
>         System.setProperty("javax.net.ssl.trustStore",
> System.getProperty("truststore.path"));
>
>         System.setProperty("javax.net.ssl.trustStorePassword",
> System.getProperty("keystore.password"));
>
>         System.setProperty("javax.net.ssl.keyStore",
> System.getProperty("keystore.path"));
>
>         System.setProperty("javax.net.ssl.keyStorePassword",
> System.getProperty("keystore.password"));
>
>         System.setProperty("javax.net.ssl.keyStoreType",
> System.getProperty("keystore.type"));
>
>
>
> However, when I try to do the same , but using APIMan (and setting the
> properties in the apiman.properties file) to gateway the API it fails as
> below. I tried setting the ?Djavax.net.debug.all  (as suggested in the
> article) which gives a lot more in the logs but all I could see that
looked
> relevant: ?Warning: no suitable certificate found - continuing without
> client authentication? which made no sense since I have the correct cert
and
> it works with the test program.
>
> I finally figured out the issue ? the MTLS setup does not allow you to
pass
> in the keyStoreType and my keystore was PKCS12 and not JKS.
>
>
>
> Couple of suggestions as a result:
>
> ?         Add the ability to set the keyStoreType so we won?t have to
> convert them

That shouldn't be too hard https://issues.jboss.org/browse/APIMAN-1154

>
> ?         Also the stacktrace gets truncated in the output (see below) and
> its very difficult to diagnose what the problem is ? something I think
would
> have been minutes if I could have seen the message about not being able to
> load the keystore took hours.

I don't think it's truncated, it's just that the formatting might be
difficult to read. I agree, though - we need to do something a bit nicer
for humans in this area.

echo -e "<stacktrace>" can be a workaround for the moment.

>From the docs:

Note the presence of lines containing the characters "...". These lines
> indicate that the remainder of the stack trace for this exception matches
> the indicated number of frames from the bottom of the stack trace of the
> exception that was caused by this exception (the "enclosing" exception).
> This shorthand can greatly reduce the length of the output in the common
> case where a wrapped exception is thrown from same method as the "causative
> exception" is caught. The above example was produced by running the program:



>
> ?         Also I want to be able to automatically use different keystores
> based on the api or logged-in user or url etc. My thought was to extend
the
> HttpConnectorFactory and override the TlsOptions. However the class has
all
> the properties private with no getters/setters and so it is difficult to
do
> so that. This means I have to pretty much make a copy of the class instead
> of just a custom extension . Would be good if the class had public or at
> least protected getters/setters there so I could override the keystore
based
> on some rules..

Unfortunately this isn't possible yet, but if you wouldn't mind, could you
file a JIRA with your requirements (as above, plus any other bits you can
think of). That will help guide us, as we're aware this is an area that
might be of interest to some. It may be possible to do something clever in
combination with Keycloak - but it'll require a bit more integration.

>
>
>
> Results when running against apiman but with a pkcs12 keystore:
>
> Using the Advanced Rest Client app for Chrome. I see the following as a
> response
>
> X-Gateway-Error: Not connected.
>
> 500  Internal Server Error
>
> And the response looks as follows. Note that the message is generic ?Not
> connected? and the stack trace is missing any information about why the
> connection failed.

I've already got a JIRA for this (https://issues.jboss.org/browse/APIMAN-690),
but it can be a pain sometimes because the underlying system tends to
return pretty generic errors - I'll see what I can do to improve the
situation. Thanks for bringing it up, it's certainly valid.

>
>
>
> {
>
>   "responseCode": 500,
>
>   "message": "Not connected.",
>
>   "trace": "io.apiman.gateway.engine.beans.exceptions.ConnectorException:
> Not connected.\n\tat
>
io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:332)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$1(ApiRequestExecutorImpl.java:234)\n\tat
>
io.apiman.gateway.engine.io.AbstractStream.handleBody(AbstractStream.java:107)\n\tat
> io.apiman.gateway.engine.policy.Chain.write(Chain.java:181)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl$1.write(ApiRequestExecutorImpl.java:525)\n\tat
>
io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:169)\n\tat
>
io.apiman.gateway.platforms.servlet.GatewayServlet$2.handle(GatewayServlet.java:161)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.handleStream(ApiRequestExecutorImpl.java:517)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$null$3(ApiRequestExecutorImpl.java:243)\n\tat
> io.apiman.gateway.engine.policy.Chain.handleHead(Chain.java:211)\n\tat
> io.apiman.gateway.engine.policy.Chain.doApply(Chain.java:150)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$4(ApiRequestExecutorImpl.java:246)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.loadPolicies(ApiRequestExecutorImpl.java:419)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.lambda$execute$5(ApiRequestExecutorImpl.java:269)\n\tat
>
io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:123)\n\tat
>
io.apiman.gateway.engine.impl.SecureRegistryWrapper$1.handle(SecureRegistryWrapper.java:112)\n\tat
>
io.apiman.gateway.engine.es.CachingESRegistry.getApi(CachingESRegistry.java:115)\n\tat
>
io.apiman.gateway.engine.impl.SecureRegistryWrapper.getApi(SecureRegistryWrapper.java:112)\n\tat
>
io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:252)\n\tat
>
io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:179)\n\tat
>
io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:79)\n\tat
> javax.servlet.http.HttpServlet.service(HttpServlet.java:790)\n\tat
>
io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)\n\tat
>
io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat
>
io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)\n\tat
>
org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat
>
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
>
io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)\n\tat
>
io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)\n\tat
>
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
>
io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)\n\tat
>
io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)\n\tat
>
io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)\n\tat
>
io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)\n\tat
>
io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)\n\tat
>
io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)\n\tat
>
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
>
org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)\n\tat
>
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
>
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat
>
io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)\n\tat
>
io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)\n\tat
>
io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)\n\tat
>
io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)\n\tat
>
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)\n\tat
>
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)\n\tat
>
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
>
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by: java.io.IOException: Not
> connected.\n\tat
>
io.apiman.gateway.platforms.servlet.connectors.HttpApiConnection.write(HttpApiConnection.java:319)\n\t...
> 48 more\n"
>
> }
>
>
>
> Regards,
>
>
>
> Amit Joshi
>
>
>
>
>
>
> ________________________________
>
> This e-mail, including accompanying communications and attachments, is
> strictly confidential and only for the intended recipient. Any retention,
> use or disclosure not expressly authorised by Markit is prohibited. This
> email is subject to all waivers and other terms at the following link:
> http://www.markit.com/en/about/legal/email-disclaimer.page
>
> Please visit http://www.markit.com/en/about/contact/contact-us.page for
> contact information on our offices worldwide.
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160522/06c2a4e9/attachment-0001.html 

From eric.wittmann at redhat.com  Mon May 23 09:40:57 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 23 May 2016 09:40:57 -0400
Subject: [Apiman-user] PluginNotFoundException when adding a new plugin
In-Reply-To: <CABv=XZWd1LqJAt3Y6FDXoaiXc4+YPm=5J+RNmTL6PHQdm7aFjQ@mail.gmail.com>
References: <CABv=XZWd1LqJAt3Y6FDXoaiXc4+YPm=5J+RNmTL6PHQdm7aFjQ@mail.gmail.com>
Message-ID: <7c7aebd4-3d84-eee2-68af-ecab8758e318@redhat.com>

Have you created a plugin already?  You must use maven to build and 
deploy your plugin so that apiman can find it.  The endpoint you mention 
is for installing a plugin, so you must provide the correct information.

Typically the value of "type" would be "war" and the value of 
"classifier" can simply be omitted.  The following properties are all 
directly related to their identically named maven properties:

	groupId, artifactId, version, type, classifier

What apiman will attempt to do when you invoke this endpoint, is 
download the appropriate plugin file from maven (either by finding it 
locally in your maven .m2 directory or by downloading it from a 
configured remote maven repository).  The above information is needed to 
identify the proper maven artifact and download it.

-Eric

On 5/20/2016 11:51 AM, Helio Frota wrote:
> Hi ,
>
> I'm trying to use the endpoint :
>
> http://localhost:8080/apiman/plugins/ [ POST ]
>
> ' Use this endpoint to add a plugin to apiman. '
>
> Using this object representation:
>
> let plug = {
>     name: 'the-new-plugin',
>     description: 'the description',
>     type: 'plugs',
>     version: '1.0.0.Final',
>     groupId: 'org.myplugins',
>     artifactId: 'superplugin',
>     classifier: '1',
>     upgrade: false
> };
>
> And I'm getting this error :
>
>  type: 'PluginNotFoundException',
>   errorCode: 12002,
>   message: 'org.myplugins:superplugin:1.0.0.Final-1:plugs',
>   moreInfoUrl: null,
>   stacktrace:
> 'io.apiman.manager.api.rest.contract.exceptions.PluginNotFoundException:
>   ...
>
> Maybe I'm populating the object with wrong values ? [ e.g classifier ? ]
>
> Thanks
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From 00hf11 at gmail.com  Mon May 23 09:52:53 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Mon, 23 May 2016 10:52:53 -0300
Subject: [Apiman-user] PluginNotFoundException when adding a new plugin
In-Reply-To: <7c7aebd4-3d84-eee2-68af-ecab8758e318@redhat.com>
References: <CABv=XZWd1LqJAt3Y6FDXoaiXc4+YPm=5J+RNmTL6PHQdm7aFjQ@mail.gmail.com>
	<7c7aebd4-3d84-eee2-68af-ecab8758e318@redhat.com>
Message-ID: <CABv=XZULGunS8DC12d7qEjHWQmnQOYpEbVpOAmvci_uhCsCD+g@mail.gmail.com>

Hi,

 --- No, no plugin created. ---

Now it makes a lot of sense.

Thanks again for the clarification !

Wow - this also means development of nodejs-apiman-admin-client we got >>
Zero << issues from/with Apiman.
Congratulations and thanks to all the Apiman team for this ^ too.




On Mon, May 23, 2016 at 10:40 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Have you created a plugin already?  You must use maven to build and deploy
> your plugin so that apiman can find it.  The endpoint you mention is for
> installing a plugin, so you must provide the correct information.
>
> Typically the value of "type" would be "war" and the value of "classifier"
> can simply be omitted.  The following properties are all directly related
> to their identically named maven properties:
>
>         groupId, artifactId, version, type, classifier
>
> What apiman will attempt to do when you invoke this endpoint, is download
> the appropriate plugin file from maven (either by finding it locally in
> your maven .m2 directory or by downloading it from a configured remote
> maven repository).  The above information is needed to identify the proper
> maven artifact and download it.
>
> -Eric
>
>
> On 5/20/2016 11:51 AM, Helio Frota wrote:
>
>> Hi ,
>>
>> I'm trying to use the endpoint :
>>
>> http://localhost:8080/apiman/plugins/ [ POST ]
>>
>> ' Use this endpoint to add a plugin to apiman. '
>>
>> Using this object representation:
>>
>> let plug = {
>>     name: 'the-new-plugin',
>>     description: 'the description',
>>     type: 'plugs',
>>     version: '1.0.0.Final',
>>     groupId: 'org.myplugins',
>>     artifactId: 'superplugin',
>>     classifier: '1',
>>     upgrade: false
>> };
>>
>> And I'm getting this error :
>>
>>  type: 'PluginNotFoundException',
>>   errorCode: 12002,
>>   message: 'org.myplugins:superplugin:1.0.0.Final-1:plugs',
>>   moreInfoUrl: null,
>>   stacktrace:
>> 'io.apiman.manager.api.rest.contract.exceptions.PluginNotFoundException:
>>   ...
>>
>> Maybe I'm populating the object with wrong values ? [ e.g classifier ? ]
>>
>> Thanks
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160523/9f60d57b/attachment.html 

From eric.wittmann at redhat.com  Mon May 23 09:58:06 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 23 May 2016 09:58:06 -0400
Subject: [Apiman-user] PluginNotFoundException when adding a new plugin
In-Reply-To: <CABv=XZULGunS8DC12d7qEjHWQmnQOYpEbVpOAmvci_uhCsCD+g@mail.gmail.com>
References: <CABv=XZWd1LqJAt3Y6FDXoaiXc4+YPm=5J+RNmTL6PHQdm7aFjQ@mail.gmail.com>
	<7c7aebd4-3d84-eee2-68af-ecab8758e318@redhat.com>
	<CABv=XZULGunS8DC12d7qEjHWQmnQOYpEbVpOAmvci_uhCsCD+g@mail.gmail.com>
Message-ID: <6903b642-13da-fb3c-4552-87ce67e79afd@redhat.com>

If you're just testing the node.js admin client, try this:

          let plug = {
              type: 'war',
              version: '1.2.5.Final',
              groupId: 'io.apiman.plugins',
              artifactId: 'apiman-plugins-log-policy'
          };

The rest of the properties are not required.

That should result in a successful response.

-Eric

On 5/23/2016 9:52 AM, Helio Frota wrote:
> Hi,
>
>  --- No, no plugin created. ---
>
> Now it makes a lot of sense.
>
> Thanks again for the clarification !
>
> Wow - this also means development of nodejs-apiman-admin-client we got
>>> Zero << issues from/with Apiman.
> Congratulations and thanks to all the Apiman team for this ^ too.
>
>
>
>
> On Mon, May 23, 2016 at 10:40 AM, Eric Wittmann
> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>
>     Have you created a plugin already?  You must use maven to build and
>     deploy your plugin so that apiman can find it.  The endpoint you
>     mention is for installing a plugin, so you must provide the correct
>     information.
>
>     Typically the value of "type" would be "war" and the value of
>     "classifier" can simply be omitted.  The following properties are
>     all directly related to their identically named maven properties:
>
>             groupId, artifactId, version, type, classifier
>
>     What apiman will attempt to do when you invoke this endpoint, is
>     download the appropriate plugin file from maven (either by finding
>     it locally in your maven .m2 directory or by downloading it from a
>     configured remote maven repository).  The above information is
>     needed to identify the proper maven artifact and download it.
>
>     -Eric
>
>
>     On 5/20/2016 11:51 AM, Helio Frota wrote:
>
>         Hi ,
>
>         I'm trying to use the endpoint :
>
>         http://localhost:8080/apiman/plugins/ [ POST ]
>
>         ' Use this endpoint to add a plugin to apiman. '
>
>         Using this object representation:
>
>         let plug = {
>             name: 'the-new-plugin',
>             description: 'the description',
>             type: 'plugs',
>             version: '1.0.0.Final',
>             groupId: 'org.myplugins',
>             artifactId: 'superplugin',
>             classifier: '1',
>             upgrade: false
>         };
>
>         And I'm getting this error :
>
>          type: 'PluginNotFoundException',
>           errorCode: 12002,
>           message: 'org.myplugins:superplugin:1.0.0.Final-1:plugs',
>           moreInfoUrl: null,
>           stacktrace:
>         'io.apiman.manager.api.rest.contract.exceptions.PluginNotFoundException:
>           ...
>
>         Maybe I'm populating the object with wrong values ? [ e.g
>         classifier ? ]
>
>         Thanks
>
>
>
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From 00hf11 at gmail.com  Mon May 23 10:19:30 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Mon, 23 May 2016 11:19:30 -0300
Subject: [Apiman-user] PluginNotFoundException when adding a new plugin
In-Reply-To: <6903b642-13da-fb3c-4552-87ce67e79afd@redhat.com>
References: <CABv=XZWd1LqJAt3Y6FDXoaiXc4+YPm=5J+RNmTL6PHQdm7aFjQ@mail.gmail.com>
	<7c7aebd4-3d84-eee2-68af-ecab8758e318@redhat.com>
	<CABv=XZULGunS8DC12d7qEjHWQmnQOYpEbVpOAmvci_uhCsCD+g@mail.gmail.com>
	<6903b642-13da-fb3c-4552-87ce67e79afd@redhat.com>
Message-ID: <CABv=XZUdgXBvY43a10QYR-MFr1tMHeeRN0CA7zO6vkE+DpRr2A@mail.gmail.com>

Working fine thanks a lot !

https://github.com/bucharest-gold/apiman-admin-client/issues/10


On Mon, May 23, 2016 at 10:58 AM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> If you're just testing the node.js admin client, try this:
>
>          let plug = {
>              type: 'war',
>              version: '1.2.5.Final',
>              groupId: 'io.apiman.plugins',
>              artifactId: 'apiman-plugins-log-policy'
>          };
>
> The rest of the properties are not required.
>
> That should result in a successful response.
>
> -Eric
>
> On 5/23/2016 9:52 AM, Helio Frota wrote:
>
>> Hi,
>>
>>  --- No, no plugin created. ---
>>
>> Now it makes a lot of sense.
>>
>> Thanks again for the clarification !
>>
>> Wow - this also means development of nodejs-apiman-admin-client we got
>>
>>> Zero << issues from/with Apiman.
>>>>
>>> Congratulations and thanks to all the Apiman team for this ^ too.
>>
>>
>>
>>
>> On Mon, May 23, 2016 at 10:40 AM, Eric Wittmann
>> <eric.wittmann at redhat.com <mailto:eric.wittmann at redhat.com>> wrote:
>>
>>     Have you created a plugin already?  You must use maven to build and
>>     deploy your plugin so that apiman can find it.  The endpoint you
>>     mention is for installing a plugin, so you must provide the correct
>>     information.
>>
>>     Typically the value of "type" would be "war" and the value of
>>     "classifier" can simply be omitted.  The following properties are
>>     all directly related to their identically named maven properties:
>>
>>             groupId, artifactId, version, type, classifier
>>
>>     What apiman will attempt to do when you invoke this endpoint, is
>>     download the appropriate plugin file from maven (either by finding
>>     it locally in your maven .m2 directory or by downloading it from a
>>     configured remote maven repository).  The above information is
>>     needed to identify the proper maven artifact and download it.
>>
>>     -Eric
>>
>>
>>     On 5/20/2016 11:51 AM, Helio Frota wrote:
>>
>>         Hi ,
>>
>>         I'm trying to use the endpoint :
>>
>>         http://localhost:8080/apiman/plugins/ [ POST ]
>>
>>         ' Use this endpoint to add a plugin to apiman. '
>>
>>         Using this object representation:
>>
>>         let plug = {
>>             name: 'the-new-plugin',
>>             description: 'the description',
>>             type: 'plugs',
>>             version: '1.0.0.Final',
>>             groupId: 'org.myplugins',
>>             artifactId: 'superplugin',
>>             classifier: '1',
>>             upgrade: false
>>         };
>>
>>         And I'm getting this error :
>>
>>          type: 'PluginNotFoundException',
>>           errorCode: 12002,
>>           message: 'org.myplugins:superplugin:1.0.0.Final-1:plugs',
>>           moreInfoUrl: null,
>>           stacktrace:
>>
>> 'io.apiman.manager.api.rest.contract.exceptions.PluginNotFoundException:
>>           ...
>>
>>         Maybe I'm populating the object with wrong values ? [ e.g
>>         classifier ? ]
>>
>>         Thanks
>>
>>
>>
>>
>>         _______________________________________________
>>         Apiman-user mailing list
>>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>         https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160523/1f204e18/attachment-0001.html 

From donovan.muller at gmail.com  Wed May 25 14:48:43 2016
From: donovan.muller at gmail.com (Donovan Muller)
Date: Wed, 25 May 2016 18:48:43 +0000
Subject: [Apiman-user] Disable bundled Elasticsearch when using external
	instance
Message-ID: <CAOtJiHYMdq-1razx8VriVGJfcg8nygvEwPgg6CpSQ47PS_NWqg@mail.gmail.com>

Hi,

If you're using an external Elasticsearch instance, is there a way to
disable the default instance bundled?
Couldn't find anything in the docs...

From
https://github.com/apiman/apiman/blob/master/distro/es/src/main/java/io/apiman/distro/es/Bootstrapper.java#L49
it doesn't seem like it
Unless there is something I'm not aware of, would it be useful to have a
config option to turn off the embedded ES instance?
For instance a apiman.distro-es.enabled=false in
https://github.com/apiman/apiman/blob/master/distro/es/src/main/java/io/apiman/distro/es/DistroESConfig.java
or something.

See https://gitter.im/apiman/apiman?at=573d6c4c64dbdadc7ded7d32 for
reference.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160525/0fbfc126/attachment.html 

From eric.wittmann at redhat.com  Wed May 25 15:50:59 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 25 May 2016 15:50:59 -0400
Subject: [Apiman-user] Disable bundled Elasticsearch when using external
 instance
In-Reply-To: <CAOtJiHYMdq-1razx8VriVGJfcg8nygvEwPgg6CpSQ47PS_NWqg@mail.gmail.com>
References: <CAOtJiHYMdq-1razx8VriVGJfcg8nygvEwPgg6CpSQ47PS_NWqg@mail.gmail.com>
Message-ID: <01f2fba9-236d-ea31-99f6-3a6dc68c0e86@redhat.com>

Sorry, I forgot to answer this question.

There's no way to *disable* it - but you can simply delete the 
deployment.  For example:

rm -f 
~/apiman-1.2.6.Final/wildfly-10.0.0.Final/standalone/deployments/apiman-es.*

Basically there is a simple WAR file that bundles up and deploys the 
embedded ES instance called "apiman-es.war".  Delete it and you're good 
to go.

-Eric

On 5/25/2016 2:48 PM, Donovan Muller wrote:
> Hi,
>
> If you're using an external Elasticsearch instance, is there a way to
> disable the default instance bundled?
> Couldn't find anything in the docs...
>
> From
> https://github.com/apiman/apiman/blob/master/distro/es/src/main/java/io/apiman/distro/es/Bootstrapper.java#L49
> it doesn't seem like it
> Unless there is something I'm not aware of, would it be useful to have a
> config option to turn off the embedded ES instance?
> For instance a apiman.distro-es.enabled=false in
> https://github.com/apiman/apiman/blob/master/distro/es/src/main/java/io/apiman/distro/es/DistroESConfig.java
> or something.
>
> See https://gitter.im/apiman/apiman?at=573d6c4c64dbdadc7ded7d32 for
> reference.
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From donovan.muller at gmail.com  Thu May 26 01:18:06 2016
From: donovan.muller at gmail.com (Donovan Muller)
Date: Thu, 26 May 2016 05:18:06 +0000
Subject: [Apiman-user] Disable bundled Elasticsearch when using external
	instance
In-Reply-To: <01f2fba9-236d-ea31-99f6-3a6dc68c0e86@redhat.com>
References: <CAOtJiHYMdq-1razx8VriVGJfcg8nygvEwPgg6CpSQ47PS_NWqg@mail.gmail.com>
	<01f2fba9-236d-ea31-99f6-3a6dc68c0e86@redhat.com>
Message-ID: <CAOtJiHZxEqKZMtzuv5CsdrMrpWm6WnHDy7h4m=SXJXd2zM7RSw@mail.gmail.com>

Great, thanks

On Wed, 25 May 2016 at 21:51 Eric Wittmann <eric.wittmann at redhat.com> wrote:

> Sorry, I forgot to answer this question.
>
> There's no way to *disable* it - but you can simply delete the
> deployment.  For example:
>
> rm -f
>
> ~/apiman-1.2.6.Final/wildfly-10.0.0.Final/standalone/deployments/apiman-es.*
>
> Basically there is a simple WAR file that bundles up and deploys the
> embedded ES instance called "apiman-es.war".  Delete it and you're good
> to go.
>
> -Eric
>
> On 5/25/2016 2:48 PM, Donovan Muller wrote:
> > Hi,
> >
> > If you're using an external Elasticsearch instance, is there a way to
> > disable the default instance bundled?
> > Couldn't find anything in the docs...
> >
> > From
> >
> https://github.com/apiman/apiman/blob/master/distro/es/src/main/java/io/apiman/distro/es/Bootstrapper.java#L49
> > it doesn't seem like it
> > Unless there is something I'm not aware of, would it be useful to have a
> > config option to turn off the embedded ES instance?
> > For instance a apiman.distro-es.enabled=false in
> >
> https://github.com/apiman/apiman/blob/master/distro/es/src/main/java/io/apiman/distro/es/DistroESConfig.java
> > or something.
> >
> > See https://gitter.im/apiman/apiman?at=573d6c4c64dbdadc7ded7d32 for
> > reference.
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160526/11f2ffd6/attachment.html 

From eric.wittmann at redhat.com  Fri May 27 09:04:27 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 27 May 2016 09:04:27 -0400
Subject: [Apiman-user] APIMAN rate limiting policy granularity
In-Reply-To: <BL2PR01MB38672391E3A887A062D1750C2410@BL2PR01MB386.prod.exchangelabs.com>
References: <BL2PR01MB38672391E3A887A062D1750C2410@BL2PR01MB386.prod.exchangelabs.com>
Message-ID: <a36403d0-ed62-1c8e-4cb4-71d92ce15a1e@redhat.com>

(adding the apiman-user list for posterity)

Thanks for the question.  Here are definitions of these two granularities:

User:  only possible when also using Authentication (basic or oauth), 
the granularity is based off the username of the authenticated user as 
well as the API information.  In other words, the "rate limiting counter 
id" for this would be:

	username+apiOrgId+apiId+apiVersion

Client:  only possible for non-public APIs - this is based off the API 
Key of the client app issuing the rquest.  In other words, the "rate 
limiting counter id" for this would be:

	API Key+apiOrgId+apiId+apiVersion

I hope that helps!

-Eric

On 5/26/2016 3:40 PM, Subbarao Denduluri wrote:
> The granularity shows:  user , api and client.     What is the difference between user and client.  And also thinking of putting the policy at the APIKEY level.  Does that mean  the user level?
>
> thanks
>

From eric.wittmann at redhat.com  Fri May 27 09:07:00 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Fri, 27 May 2016 09:07:00 -0400
Subject: [Apiman-user] Question about Test Gateway endpoint
In-Reply-To: <BL2PR01MB386C20CC6F8463CAEE68DD7C2410@BL2PR01MB386.prod.exchangelabs.com>
References: <CABv=XZUj1+QXHwxvt5+DkJQtnsKc2_HU_GGmMiduzqki2OOX=A@mail.gmail.com>
	<5739CE4A.5080002@redhat.com>
	<BLUPR01MB392205E0AA08F129ECE818FC2770@BLUPR01MB392.prod.exchangelabs.com>
	<8c9485ef-4bcd-af13-9659-d01b9a51a2f1@redhat.com>
	<BLUPR01MB392C6E570C94AAEFED2056BC2480@BLUPR01MB392.prod.exchangelabs.com>
	<05a5641e-7d6d-1b93-52a4-094de2652abe@redhat.com>
	<BLUPR01MB392FF23F6483B310E15686EC2410@BLUPR01MB392.prod.exchangelabs.com>
	<51525780-c56f-feb8-d006-710640789de1@redhat.com>
	<BL2PR01MB386C20CC6F8463CAEE68DD7C2410@BL2PR01MB386.prod.exchangelabs.com>
Message-ID: <9d0f219f-cce7-efc7-7382-74b8b2bc3a7e@redhat.com>

The available time granularity is really the only difference.  Typically 
a Quota is something like "10,000 requests per month" while a Rate Limit 
is more like "100 requests per minute".

Often times you may want BOTH of these added for the same API.

-Eric

On 5/26/2016 3:18 PM, Subbarao Denduluri wrote:
> Eric,
>
>   Is there any difference between rate limiting policy and  Quota policy. Both seem to show number of requests per second
>
> -----Original Message-----
> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
> Sent: Thursday, May 26, 2016 1:37 PM
> To: Subbarao Denduluri <sdenduluri at ebsco.com>
> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>
> The IP whitelist policy is built-in to core - it doesn't require a plugin.
>
> -Eric
>
> On 5/26/2016 12:43 PM, Subbarao Denduluri wrote:
>> Thanks Eric for the response.   Good to know.  One more thing I would like to ask. I want to use the IP whitelisting policy. We are using the 1.2.5 version of apiman. Do I have to add any plugin to accomplish the whitelisting or is it inbuilt?
>>
>> Thanks
>> Subba
>>
>> -----Original Message-----
>> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
>> Sent: Wednesday, May 18, 2016 9:05 AM
>> To: Subbarao Denduluri <sdenduluri at ebsco.com>;
>> apiman-user at lists.jboss.org
>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>
>> I don't have a specific timeline for this, but Swagger would
>> definitely be the first to be implemented.  There is more of a
>> preference for Swagger within Red Hat and also in the apiman community
>> (from what I can
>> tell) vs. RAML.
>>
>> -Eric
>>
>> On 5/17/2016 1:39 PM, Subbarao Denduluri wrote:
>>> Thanks for your reply Eric. Actually is there priotity in your
>>> timelines to support Swagger or Raml.  Like which particular
>>> technology would be available first to import if at all you are
>>> planning to support either of these
>>>
>>> Thanks
>>> Subba
>>>
>>> -----Original Message-----
>>> From: Eric Wittmann [mailto:eric.wittmann at redhat.com]
>>> Sent: Tuesday, May 17, 2016 8:34 AM
>>> To: Subbarao Denduluri <sdenduluri at ebsco.com>
>>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>>
>>> Unfortunately we don't yet have support for importing APIs into the manager from swagger.  It's something that we *want* but haven't implemented yet.  There is an "Import APIs" UI already, which is designed to support things like:
>>>
>>> * swagger
>>> * raml
>>> * wadl
>>> * wsdl
>>>
>>> However, currently it only supports the internal "API Catalog" concept that apiman has.
>>>
>>> -Eric
>>>
>>>
>>> On 5/16/2016 4:29 PM, Subbarao Denduluri wrote:
>>>> Hello Eric,
>>>>
>>>>        I have a question on Apiman swagger integration.  I am looking into apiman support for an api import from a swagger file.  Does Apiman have support like that?
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: apiman-user-bounces at lists.jboss.org
>>>> [mailto:apiman-user-bounces at lists.jboss.org] On Behalf Of Eric
>>>> Wittmann
>>>> Sent: Monday, May 16, 2016 9:43 AM
>>>> To: Helio Frota <00hf11 at gmail.com>; apiman-user
>>>> <apiman-user at lists.jboss.org>
>>>> Subject: Re: [Apiman-user] Question about Test Gateway endpoint
>>>>
>>>> This endpoint 'http://localhost:8080/apiman/gateways/' [PUT] is used to test whether a particular Gateway configuration would likely work if it were added via the endpoint 'http://localhost:8080/apiman/gateways/' [POST].
>>>>
>>>> This is used by the UI on both the New Gateway and Edit Gateway pages.
>>>> See the attached screenshot for details.  When the user clicks the "Test Gateway" button, the UI sends the gateway configuration details from the form to validate whether the settings are likely correct.  The API Manager (/apiman) will try to make a connection to the API Gateway to see if it can be reached and whether authentication succeeds.  If all goes well, the user can be reasonably certain that she has inputted correct information in the form.
>>>>
>>>> -Eric
>>>>
>>>>
>>>> On 5/12/2016 12:47 PM, Helio Frota wrote:
>>>>> Hi all,
>>>>>
>>>>>  From REST docs:
>>>>>
>>>>> 'This endpoint is used to test the Gateway's settings prior to
>>>>> either creating or updating it. The information will be used to
>>>>> attempt to create a link between the API Manager and the Gateway,
>>>>> by simply trying to ping the Gateway's "status" endpoint.'
>>>>>
>>>>> This part:
>>>>> 'The information will be used to attempt to create a link between
>>>>> the API Manager and the Gateway'
>>>>>
>>>>> ( http://www.apiman.io/latest/api-manager-restdocs.html )
>>>>>
>>>>>
>>>>> This means the endpoint 'http://localhost:8080/apiman/gateways/'
>>>>> [PUT] is used for/to/only Apiman itself ? This can be used by other
>>>>> clients or it no makes much sense ?
>>>>>
>>>>> Thanks !
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Apiman-user mailing list
>>>>> Apiman-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>>>

From sdenduluri at ebsco.com  Fri May 27 09:20:54 2016
From: sdenduluri at ebsco.com (Subbarao Denduluri)
Date: Fri, 27 May 2016 13:20:54 +0000
Subject: [Apiman-user] APIMAN rate limiting policy granularity
In-Reply-To: <a36403d0-ed62-1c8e-4cb4-71d92ce15a1e@redhat.com>
References: <BL2PR01MB38672391E3A887A062D1750C2410@BL2PR01MB386.prod.exchangelabs.com>
	<a36403d0-ed62-1c8e-4cb4-71d92ce15a1e@redhat.com>
Message-ID: <BLUPR01MB3929A083152C37534269E0CC2420@BLUPR01MB392.prod.exchangelabs.com>

Thanks for the Clarifications Eric. This is very helpful

-Subba
-----Original Message-----
From: Eric Wittmann [mailto:eric.wittmann at redhat.com] 
Sent: Friday, May 27, 2016 9:04 AM
To: Subbarao Denduluri <sdenduluri at ebsco.com>; apiman-user at lists.jboss.org
Subject: Re: APIMAN rate limiting policy granularity

(adding the apiman-user list for posterity)

Thanks for the question.  Here are definitions of these two granularities:

User:  only possible when also using Authentication (basic or oauth), the granularity is based off the username of the authenticated user as well as the API information.  In other words, the "rate limiting counter id" for this would be:

	username+apiOrgId+apiId+apiVersion

Client:  only possible for non-public APIs - this is based off the API Key of the client app issuing the rquest.  In other words, the "rate limiting counter id" for this would be:

	API Key+apiOrgId+apiId+apiVersion

I hope that helps!

-Eric

On 5/26/2016 3:40 PM, Subbarao Denduluri wrote:
> The granularity shows:  user , api and client.     What is the difference between user and client.  And also thinking of putting the policy at the APIKEY level.  Does that mean  the user level?
>
> thanks
>


From ike.braun at googlemail.com  Tue May 31 07:49:12 2016
From: ike.braun at googlemail.com (Heiko Braun)
Date: Tue, 31 May 2016 13:49:12 +0200
Subject: [Apiman-user] linkerd style routing?
Message-ID: <095A8681-00DC-4CC8-AB48-A0777F133978@googlemail.com>



I was looking linkerd [1] the other day one feature caught my attention: the RPC routing capabilities [2] (i.e. http, or thrift). I was wondering if a similar concept exists in APIMan that allows for redirection of HTTP invocations and dynamic changes to the routing tables?

Regards, Heiko

[1] https://linkerd.io/ <https://linkerd.io/>
[2] https://blog.buoyant.io/2016/05/04/real-world-microservices-when-services-stop-playing-well-and-start-getting-real/ <https://blog.buoyant.io/2016/05/04/real-world-microservices-when-services-stop-playing-well-and-start-getting-real/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160531/23028793/attachment.html 

From Manvendra.Rai at ril.com  Tue May 31 08:01:58 2016
From: Manvendra.Rai at ril.com (Manvendra.Rai at ril.com)
Date: Tue, 31 May 2016 12:01:58 +0000
Subject: [Apiman-user] Question: How to stop path segments & query
 parameters from going on to the back-end API endpoint?
Message-ID: <9c9e63fac22e415184288b6c8588bcbd@SIDC1EXMBX23.in.ril.com>

Hello All,
I left this question on freenode - IRC and though to post the same on the email group.

Question: We are using API Gateway for couple of things and one of the main functionalities we are leveraging is - Managed API.

Our requirement is to create a Plugin which will invoke backend API after fetching fielded from the database based on the object id from the Manage URL.

Say for example -

My manage API is -

http://abc.com/apiman-gateway/testapp/manav/3.0/images/{objectid}<http://abc.com/apiman-gateway/testapp/manav/3.0/images/%7bobjectid%7d>


My Backend API

http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/{fileid}<http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/%7bfileid%7d>

We have implemented almost all this requirement but have one issue. As per the default behaviour, API Gateway proxies all path segments beyond the {version} segment with query parameters back-end API.
This is causing an issue because [objected] is also being sent to Backend API.

So my question is to know - how can we stop {objected} from going to Backend API?

Thanks for your time looking at the issue and advising back.

Thanks,
Manav

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160531/f02ab1e9/attachment.html 

From marc.savy at redhat.com  Tue May 31 09:26:13 2016
From: marc.savy at redhat.com (Marc Savy)
Date: Tue, 31 May 2016 14:26:13 +0100
Subject: [Apiman-user] linkerd style routing?
In-Reply-To: <095A8681-00DC-4CC8-AB48-A0777F133978@googlemail.com>
References: <095A8681-00DC-4CC8-AB48-A0777F133978@googlemail.com>
Message-ID: <CAA7j38JZJX2XwiUb+K2r4Y8WKugeNHdhnm0Q72R4j8dnZhDC1g@mail.gmail.com>

Presently we don't have any such functionality, but I don't see why we
couldn't consider adding something like that. The underlying model may be
flexible enough (hard to say without trying, though).

I'd definitely like to investigate this at some point, though, as it'd
potentially be a valuable thing to support.

On 31 May 2016 at 12:49, Heiko Braun <ike.braun at googlemail.com> wrote:

>
>
> I was looking linkerd [1] the other day one feature caught my attention:
> the RPC routing capabilities [2] (i.e. http, or thrift). I was wondering if
> a similar concept exists in APIMan that allows for redirection of HTTP
> invocations and dynamic changes to the routing tables?
>
> Regards, Heiko
>
> [1] https://linkerd.io/
> [2]
> https://blog.buoyant.io/2016/05/04/real-world-microservices-when-services-stop-playing-well-and-start-getting-real/
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160531/9f10951e/attachment.html 

From ike.braun at googlemail.com  Tue May 31 09:38:41 2016
From: ike.braun at googlemail.com (Heiko Braun)
Date: Tue, 31 May 2016 15:38:41 +0200
Subject: [Apiman-user] linkerd style routing?
In-Reply-To: <CAA7j38JZJX2XwiUb+K2r4Y8WKugeNHdhnm0Q72R4j8dnZhDC1g@mail.gmail.com>
References: <095A8681-00DC-4CC8-AB48-A0777F133978@googlemail.com>
	<CAA7j38JZJX2XwiUb+K2r4Y8WKugeNHdhnm0Q72R4j8dnZhDC1g@mail.gmail.com>
Message-ID: <E7ED9EFC-7EF2-4823-93E6-283E733C69E7@googlemail.com>


Yes, it seems linkerd borrowed much of routing table from finagle:

https://linkerd.io/doc/dtabs/ <https://linkerd.io/doc/dtabs/>

The other component that comes into play is what they call namerd, which provides name resolution through external registries.

But AFAIK, APIMan already has support for registries like consul & zookeeper?

Regards, Heiko



> On 31 May 2016, at 15:26, Marc Savy <marc.savy at redhat.com> wrote:
> 
> Presently we don't have any such functionality, but I don't see why we couldn't consider adding something like that. The underlying model may be flexible enough (hard to say without trying, though).
> 
> I'd definitely like to investigate this at some point, though, as it'd potentially be a valuable thing to support.  
> 
> On 31 May 2016 at 12:49, Heiko Braun <ike.braun at googlemail.com <mailto:ike.braun at googlemail.com>> wrote:
> 
> 
> I was looking linkerd [1] the other day one feature caught my attention: the RPC routing capabilities [2] (i.e. http, or thrift). I was wondering if a similar concept exists in APIMan that allows for redirection of HTTP invocations and dynamic changes to the routing tables?
> 
> Regards, Heiko
> 
> [1] https://linkerd.io/ <https://linkerd.io/>
> [2] https://blog.buoyant.io/2016/05/04/real-world-microservices-when-services-stop-playing-well-and-start-getting-real/ <https://blog.buoyant.io/2016/05/04/real-world-microservices-when-services-stop-playing-well-and-start-getting-real/>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/apiman-user <https://lists.jboss.org/mailman/listinfo/apiman-user>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160531/b255fb0e/attachment.html 

From eric.wittmann at redhat.com  Tue May 31 11:10:53 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 31 May 2016 11:10:53 -0400
Subject: [Apiman-user] Question: How to stop path segments & query
 parameters from going on to the back-end API endpoint?
In-Reply-To: <9c9e63fac22e415184288b6c8588bcbd@SIDC1EXMBX23.in.ril.com>
References: <9c9e63fac22e415184288b6c8588bcbd@SIDC1EXMBX23.in.ril.com>
Message-ID: <6faccc66-f9f1-e6ee-1dc5-45e44d71285b@redhat.com>

Hi Manav,

This would require a custom policy to be implemented (this is pretty 
easy if you have access to a java developer!).  Unfortunately we don't 
have any policies out of the box that will let you manipulate the path.

But here is how you could do it in a custom plugin:

   https://gist.github.com/EricWittmann/aa0073b47f1f4d159c6a75e60ab22faf

This is just pseudo-code, mind you.  But basically you can manipulate 
the path, headers, and query params in whatever way you wish.

-Eric

On 5/31/2016 8:01 AM, Manvendra.Rai at ril.com wrote:
> Hello All,
>
> I left this question on freenode ? IRC and though to post the same on
> the email group.
>
>
>
> *Question*: We are using API Gateway for couple of things and one of the
> main functionalities we are leveraging is - Managed API.
>
>
>
> Our requirement is to create a Plugin which will invoke backend API
> after fetching _fielded from the database_ based on the object id from
> the Manage URL.
>
>
>
> Say for example -
>
>
>
> My manage API is -
>
>
>
> http://abc.com/apiman-gateway/testapp/manav/3.0/images/{objectid}
> <http://abc.com/apiman-gateway/testapp/manav/3.0/images/%7bobjectid%7d>
>
>
>
>
>
> My Backend API
>
>
>
> http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/{fileid}
> <http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/%7bfileid%7d>
>
>
>
> We have implemented almost all this requirement but have one issue. As
> per the default behaviour, API Gateway proxies all path segments beyond
> the {version} segment with query parameters back-end API.
>
> This is causing an issue because [objected] is also being sent to
> Backend API.
>
>
>
> So my question is to know ? how can we stop {objected} from going to
> Backend API?
>
>
>
> Thanks for your time looking at the issue and advising back.
>
>
>
> Thanks,
>
> Manav
>
>
>
>
> "*Confidentiality Warning*: This message and any attachments are
> intended only for the use of the intended recipient(s), are confidential
> and may be privileged. If you are not the intended recipient, you are
> hereby notified that any review, re-transmission, conversion to hard
> copy, copying, circulation or other use of this message and any
> attachments is strictly prohibited. If you are not the intended
> recipient, please notify the sender immediately by return email and
> delete this message and any attachments from your system.
>
> *Virus Warning:* Although the company has taken reasonable precautions
> to ensure no viruses are present in this email. The company cannot
> accept responsibility for any loss or damage arising from the use of
> this email or attachment."
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From Nidhish.Agrawal at ril.com  Tue May 31 13:24:36 2016
From: Nidhish.Agrawal at ril.com (Nidhish.Agrawal at ril.com)
Date: Tue, 31 May 2016 17:24:36 +0000
Subject: [Apiman-user] Question: How to stop path segments & query
 parameters from going on to the back-end API endpoint?
In-Reply-To: <6faccc66-f9f1-e6ee-1dc5-45e44d71285b@redhat.com>
References: <9c9e63fac22e415184288b6c8588bcbd@SIDC1EXMBX23.in.ril.com>
	<6faccc66-f9f1-e6ee-1dc5-45e44d71285b@redhat.com>
Message-ID: <D373C581.A34B%nidhish.agrawal@ril.com>

Hi Eric, 

Thanks for the very quick response, I am working on the policies part with
manav

I am manipulating with request.setUrl(request.getUrl().subString(0,15)) ,
but it not stoping the path param to pass with endpoint.

Can you please give difference between destination & url.

Regards
Nidhish Agrawal

Direct      : +91-22-4475 0085
Mobile    : +91-8828002901
E- mail    : nidhish <nidhish.agrawal at ril.com>




On 5/31/16, 8:40 PM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:

>Hi Manav,
>
>This would require a custom policy to be implemented (this is pretty
>easy if you have access to a java developer!).  Unfortunately we don't
>have any policies out of the box that will let you manipulate the path.
>
>But here is how you could do it in a custom plugin:
>
>   https://gist.github.com/EricWittmann/aa0073b47f1f4d159c6a75e60ab22faf
>
>This is just pseudo-code, mind you.  But basically you can manipulate
>the path, headers, and query params in whatever way you wish.
>
>-Eric
>
>On 5/31/2016 8:01 AM, Manvendra.Rai at ril.com wrote:
>> Hello All,
>>
>> I left this question on freenode ? IRC and though to post the same on
>> the email group.
>>
>>
>>
>> *Question*: We are using API Gateway for couple of things and one of the
>> main functionalities we are leveraging is - Managed API.
>>
>>
>>
>> Our requirement is to create a Plugin which will invoke backend API
>> after fetching _fielded from the database_ based on the object id from
>> the Manage URL.
>>
>>
>>
>> Say for example -
>>
>>
>>
>> My manage API is -
>>
>>
>>
>> http://abc.com/apiman-gateway/testapp/manav/3.0/images/{objectid}
>> <http://abc.com/apiman-gateway/testapp/manav/3.0/images/%7bobjectid%7d>
>>
>>
>>
>>
>>
>> My Backend API
>>
>>
>>
>> http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/{fileid}
>> 
>><http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/%7bfilei
>>d%7d>
>>
>>
>>
>> We have implemented almost all this requirement but have one issue. As
>> per the default behaviour, API Gateway proxies all path segments beyond
>> the {version} segment with query parameters back-end API.
>>
>> This is causing an issue because [objected] is also being sent to
>> Backend API.
>>
>>
>>
>> So my question is to know ? how can we stop {objected} from going to
>> Backend API?
>>
>>
>>
>> Thanks for your time looking at the issue and advising back.
>>
>>
>>
>> Thanks,
>>
>> Manav
>>
>>
>>
>>
>> "*Confidentiality Warning*: This message and any attachments are
>> intended only for the use of the intended recipient(s), are confidential
>> and may be privileged. If you are not the intended recipient, you are
>> hereby notified that any review, re-transmission, conversion to hard
>> copy, copying, circulation or other use of this message and any
>> attachments is strictly prohibited. If you are not the intended
>> recipient, please notify the sender immediately by return email and
>> delete this message and any attachments from your system.
>>
>> *Virus Warning:* Although the company has taken reasonable precautions
>> to ensure no viruses are present in this email. The company cannot
>> accept responsibility for any loss or damage arising from the use of
>> this email or attachment."
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>

"Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s). 
are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any 
review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is 
strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email. 
and delete this message and any attachments from your system.

Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email. 
The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."



From eric.wittmann at redhat.com  Tue May 31 13:29:00 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 31 May 2016 13:29:00 -0400
Subject: [Apiman-user] Question: How to stop path segments & query
 parameters from going on to the back-end API endpoint?
In-Reply-To: <D373C581.A34B%nidhish.agrawal@ril.com>
References: <9c9e63fac22e415184288b6c8588bcbd@SIDC1EXMBX23.in.ril.com>
	<6faccc66-f9f1-e6ee-1dc5-45e44d71285b@redhat.com>
	<D373C581.A34B%nidhish.agrawal@ril.com>
Message-ID: <cae7f78f-729c-a347-bd23-d60c70b4c5cc@redhat.com>

The URL field holds the absolute URL sent by the client.  The 
'destination' field is just the extra path segments beyond the managed 
endpoint.  So for example:

https://localhost:8443/apiman-gateway/MyOrg/MyApi/1.7/path/to/dest

In this case, the 'url' field will hold the entire value from above, 
while the 'destination' will hold just this:

/path/to/dest

The full URL exists only for auditing and reference purposes, while 
'destination' is used downstream from the policies when proxying to the 
back end API.

-Eric

On 5/31/2016 1:24 PM, Nidhish.Agrawal at ril.com wrote:
> Hi Eric,
>
> Thanks for the very quick response, I am working on the policies part with
> manav
>
> I am manipulating with request.setUrl(request.getUrl().subString(0,15)) ,
> but it not stoping the path param to pass with endpoint.
>
> Can you please give difference between destination & url.
>
> Regards
> Nidhish Agrawal
>
> Direct      : +91-22-4475 0085
> Mobile    : +91-8828002901
> E- mail    : nidhish <nidhish.agrawal at ril.com>
>
>
>
>
> On 5/31/16, 8:40 PM, "Eric Wittmann" <eric.wittmann at redhat.com> wrote:
>
>> Hi Manav,
>>
>> This would require a custom policy to be implemented (this is pretty
>> easy if you have access to a java developer!).  Unfortunately we don't
>> have any policies out of the box that will let you manipulate the path.
>>
>> But here is how you could do it in a custom plugin:
>>
>>   https://gist.github.com/EricWittmann/aa0073b47f1f4d159c6a75e60ab22faf
>>
>> This is just pseudo-code, mind you.  But basically you can manipulate
>> the path, headers, and query params in whatever way you wish.
>>
>> -Eric
>>
>> On 5/31/2016 8:01 AM, Manvendra.Rai at ril.com wrote:
>>> Hello All,
>>>
>>> I left this question on freenode ? IRC and though to post the same on
>>> the email group.
>>>
>>>
>>>
>>> *Question*: We are using API Gateway for couple of things and one of the
>>> main functionalities we are leveraging is - Managed API.
>>>
>>>
>>>
>>> Our requirement is to create a Plugin which will invoke backend API
>>> after fetching _fielded from the database_ based on the object id from
>>> the Manage URL.
>>>
>>>
>>>
>>> Say for example -
>>>
>>>
>>>
>>> My manage API is -
>>>
>>>
>>>
>>> http://abc.com/apiman-gateway/testapp/manav/3.0/images/{objectid}
>>> <http://abc.com/apiman-gateway/testapp/manav/3.0/images/%7bobjectid%7d>
>>>
>>>
>>>
>>>
>>>
>>> My Backend API
>>>
>>>
>>>
>>> http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/{fileid}
>>>
>>> <http://abc.com/apiman-gateway/testapp/manav/3.0/download/images/%7bfilei
>>> d%7d>
>>>
>>>
>>>
>>> We have implemented almost all this requirement but have one issue. As
>>> per the default behaviour, API Gateway proxies all path segments beyond
>>> the {version} segment with query parameters back-end API.
>>>
>>> This is causing an issue because [objected] is also being sent to
>>> Backend API.
>>>
>>>
>>>
>>> So my question is to know ? how can we stop {objected} from going to
>>> Backend API?
>>>
>>>
>>>
>>> Thanks for your time looking at the issue and advising back.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Manav
>>>
>>>
>>>
>>>
>>> "*Confidentiality Warning*: This message and any attachments are
>>> intended only for the use of the intended recipient(s), are confidential
>>> and may be privileged. If you are not the intended recipient, you are
>>> hereby notified that any review, re-transmission, conversion to hard
>>> copy, copying, circulation or other use of this message and any
>>> attachments is strictly prohibited. If you are not the intended
>>> recipient, please notify the sender immediately by return email and
>>> delete this message and any attachments from your system.
>>>
>>> *Virus Warning:* Although the company has taken reasonable precautions
>>> to ensure no viruses are present in this email. The company cannot
>>> accept responsibility for any loss or damage arising from the use of
>>> this email or attachment."
>>>
>>>
>>>
>>> _______________________________________________
>>> Apiman-user mailing list
>>> Apiman-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>
> "Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s).
> are confidential and may be privileged. If you are not the intended recipient. you are hereby notified that any
> review. re-transmission. conversion to hard copy. copying. circulation or other use of this message and any attachments is
> strictly prohibited. If you are not the intended recipient. please notify the sender immediately by return email.
> and delete this message and any attachments from your system.
>
> Virus Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email.
> The company cannot accept responsibility for any loss or damage arising from the use of this email or attachment."
>

From mohanjoyappa at gmail.com  Tue May 31 16:13:35 2016
From: mohanjoyappa at gmail.com (Mohan)
Date: Tue, 31 May 2016 16:13:35 -0400
Subject: [Apiman-user] APIMAN Analytics
Message-ID: <CAGUEYgQJ5UdsYVbDJUUYtaYv7aET-dzoLmtQXzMLsgKPmkRP6A@mail.gmail.com>

Hi APIMAN Team,

While going through APIMAN?s Analytics functionality, I have found out that
you need to open individual APIs to see following stats

1 ) Usage of a given API per client and per plan

2) # of Successful/Failed/erroneous responses





I would like to know is there any way for us to get following reports in
APIMAN

1.       Is there any way to see above statistics for *ALL published API*s
at *ONE* place without having to go through each APIs?

2.       And, For a given time period

a.       Among all the published APIs, show me the APIs for which we had
issues/(# faulty API calls per API) so that I know the problematic APIs and
can take corrective action.

b.      Among the published APIs, show me the number of subscriptions
(Example : API-1 has 1 subscriber/ClientApp, API-2 has 3
subscriber/clientApp) to measure the adoption rate for a given API

c.       Among the published APIs, show me the number of APIs call made per
API and their response time (so that I know which APIs are slow and I can
take corrective action to improve the performance)

d.      Number of API calls per user/clientApp (This will help developer to
see whether to reduce their usage of API calls or not and also helps the
service provider to know which developer are exceeding their quota).



Appreciate your feedback/response



Best

Mohan Joyappa (@ ebsco)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160531/28ad78bb/attachment.html 

From eric.wittmann at redhat.com  Tue May 31 16:46:58 2016
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 31 May 2016 16:46:58 -0400
Subject: [Apiman-user] APIMAN Analytics
In-Reply-To: <CAGUEYgQJ5UdsYVbDJUUYtaYv7aET-dzoLmtQXzMLsgKPmkRP6A@mail.gmail.com>
References: <CAGUEYgQJ5UdsYVbDJUUYtaYv7aET-dzoLmtQXzMLsgKPmkRP6A@mail.gmail.com>
Message-ID: <8c48f03f-2f34-3d2d-8bd4-5727d4d58d2c@redhat.com>

Hello, Mohan Joyappa (@ ebsco)!  :)

All of the information you listed below is available in the metrics 
storage, if you are using Elasticsearch for metrics (apiman supports 
multiple metrics storage back-ends).  Only a small subset of the data 
collected is surfaced in the apiman UI.

However, you could install and use Kibana to give yourself a way to 
create arbitrary visualizations/graphs of the metrics data. 
Alternatively you could access the data directly by issuing 
Elasticsearch aggregation queries.  Unless you are an Elasticsearch 
expert, I expect the former will be easier.

In the future we may have more extensive support for querying the 
metrics data, but for now this is what we have.

Regards,

Eric



On 5/31/2016 4:13 PM, Mohan wrote:
>
> Hi APIMAN Team,
>
> While going through APIMAN?s Analytics functionality, I have found out
> that you need to open individual APIs to see following stats
>
> 1 ) Usage of a given API per client and per plan
>
> 2) # of Successful/Failed/erroneous responses
>
>
>
>
>
> I would like to know is there any way for us to get following reports in
> APIMAN
>
> 1.       Is there any way to see above statistics for *ALL published
> API*s at *ONE* place without having to go through each APIs?
>
> 2.       And, For a given time period
>
> a.       Among all the published APIs, show me the APIs for which we had
> issues/(# faulty API calls per API) so that I know the problematic APIs
> and can take corrective action.
>
> b.      Among the published APIs, show me the number of subscriptions
> (Example : API-1 has 1 subscriber/ClientApp, API-2 has 3
> subscriber/clientApp) to measure the adoption rate for a given API
>
> c.       Among the published APIs, show me the number of APIs call made
> per API and their response time (so that I know which APIs are slow and
> I can take corrective action to improve the performance)
>
> d.      Number of API calls per user/clientApp (This will help developer
> to see whether to reduce their usage of API calls or not and also helps
> the service provider to know which developer are exceeding their quota).
>
>
>
> Appreciate your feedback/response
>
>
>
> Best
>
> Mohan Joyappa (@ ebsco)
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From 00hf11 at gmail.com  Tue May 31 16:51:43 2016
From: 00hf11 at gmail.com (Helio Frota)
Date: Tue, 31 May 2016 17:51:43 -0300
Subject: [Apiman-user] APIMAN Analytics
In-Reply-To: <8c48f03f-2f34-3d2d-8bd4-5727d4d58d2c@redhat.com>
References: <CAGUEYgQJ5UdsYVbDJUUYtaYv7aET-dzoLmtQXzMLsgKPmkRP6A@mail.gmail.com>
	<8c48f03f-2f34-3d2d-8bd4-5727d4d58d2c@redhat.com>
Message-ID: <CABv=XZWZHM07ZbMBcCK8J6P=r_oxw=brgXJD2cLeSNpC1kTqvg@mail.gmail.com>

Great !

[interesting topic]

Also thanks for this information !
Looking forward for future endpoints on reports in case implemented.



On Tue, May 31, 2016 at 5:46 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Hello, Mohan Joyappa (@ ebsco)!  :)
>
> All of the information you listed below is available in the metrics
> storage, if you are using Elasticsearch for metrics (apiman supports
> multiple metrics storage back-ends).  Only a small subset of the data
> collected is surfaced in the apiman UI.
>
> However, you could install and use Kibana to give yourself a way to
> create arbitrary visualizations/graphs of the metrics data.
> Alternatively you could access the data directly by issuing
> Elasticsearch aggregation queries.  Unless you are an Elasticsearch
> expert, I expect the former will be easier.
>
> In the future we may have more extensive support for querying the
> metrics data, but for now this is what we have.
>
> Regards,
>
> Eric
>
>
>
> On 5/31/2016 4:13 PM, Mohan wrote:
> >
> > Hi APIMAN Team,
> >
> > While going through APIMAN?s Analytics functionality, I have found out
> > that you need to open individual APIs to see following stats
> >
> > 1 ) Usage of a given API per client and per plan
> >
> > 2) # of Successful/Failed/erroneous responses
> >
> >
> >
> >
> >
> > I would like to know is there any way for us to get following reports in
> > APIMAN
> >
> > 1.       Is there any way to see above statistics for *ALL published
> > API*s at *ONE* place without having to go through each APIs?
> >
> > 2.       And, For a given time period
> >
> > a.       Among all the published APIs, show me the APIs for which we had
> > issues/(# faulty API calls per API) so that I know the problematic APIs
> > and can take corrective action.
> >
> > b.      Among the published APIs, show me the number of subscriptions
> > (Example : API-1 has 1 subscriber/ClientApp, API-2 has 3
> > subscriber/clientApp) to measure the adoption rate for a given API
> >
> > c.       Among the published APIs, show me the number of APIs call made
> > per API and their response time (so that I know which APIs are slow and
> > I can take corrective action to improve the performance)
> >
> > d.      Number of API calls per user/clientApp (This will help developer
> > to see whether to reduce their usage of API calls or not and also helps
> > the service provider to know which developer are exceeding their quota).
> >
> >
> >
> > Appreciate your feedback/response
> >
> >
> >
> > Best
> >
> > Mohan Joyappa (@ ebsco)
> >
> >
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160531/55166ae5/attachment-0001.html 

From mohanjoyappa at gmail.com  Tue May 31 16:59:43 2016
From: mohanjoyappa at gmail.com (Mohan)
Date: Tue, 31 May 2016 16:59:43 -0400
Subject: [Apiman-user] APIMAN Analytics
In-Reply-To: <8c48f03f-2f34-3d2d-8bd4-5727d4d58d2c@redhat.com>
References: <CAGUEYgQJ5UdsYVbDJUUYtaYv7aET-dzoLmtQXzMLsgKPmkRP6A@mail.gmail.com>
	<8c48f03f-2f34-3d2d-8bd4-5727d4d58d2c@redhat.com>
Message-ID: <CAGUEYgS0VJr_w2aW7OfTi8eiKAmWSELXEJ4Kfb2Y=JJi4D8=6Q@mail.gmail.com>

Hi Eric :),

I very much appreciate your quick feedback. Glad to know that these data
can be extracted from underlying data storage.

I may have some additional reporting need which I believe could be
extracted from back end data. Will give a try.... If not, I will surely
seek your guidance

Thanks again,

Best
Mohan Joyappa

On Tue, May 31, 2016 at 4:46 PM, Eric Wittmann <eric.wittmann at redhat.com>
wrote:

> Hello, Mohan Joyappa (@ ebsco)!  :)
>
> All of the information you listed below is available in the metrics
> storage, if you are using Elasticsearch for metrics (apiman supports
> multiple metrics storage back-ends).  Only a small subset of the data
> collected is surfaced in the apiman UI.
>
> However, you could install and use Kibana to give yourself a way to create
> arbitrary visualizations/graphs of the metrics data. Alternatively you
> could access the data directly by issuing Elasticsearch aggregation
> queries.  Unless you are an Elasticsearch expert, I expect the former will
> be easier.
>
> In the future we may have more extensive support for querying the metrics
> data, but for now this is what we have.
>
> Regards,
>
> Eric
>
>
>
> On 5/31/2016 4:13 PM, Mohan wrote:
>
>>
>> Hi APIMAN Team,
>>
>> While going through APIMAN?s Analytics functionality, I have found out
>> that you need to open individual APIs to see following stats
>>
>> 1 ) Usage of a given API per client and per plan
>>
>> 2) # of Successful/Failed/erroneous responses
>>
>>
>>
>>
>>
>> I would like to know is there any way for us to get following reports in
>> APIMAN
>>
>> 1.       Is there any way to see above statistics for *ALL published
>> API*s at *ONE* place without having to go through each APIs?
>>
>> 2.       And, For a given time period
>>
>> a.       Among all the published APIs, show me the APIs for which we had
>> issues/(# faulty API calls per API) so that I know the problematic APIs
>> and can take corrective action.
>>
>> b.      Among the published APIs, show me the number of subscriptions
>> (Example : API-1 has 1 subscriber/ClientApp, API-2 has 3
>> subscriber/clientApp) to measure the adoption rate for a given API
>>
>> c.       Among the published APIs, show me the number of APIs call made
>> per API and their response time (so that I know which APIs are slow and
>> I can take corrective action to improve the performance)
>>
>> d.      Number of API calls per user/clientApp (This will help developer
>> to see whether to reduce their usage of API calls or not and also helps
>> the service provider to know which developer are exceeding their quota).
>>
>>
>>
>> Appreciate your feedback/response
>>
>>
>>
>> Best
>>
>> Mohan Joyappa (@ ebsco)
>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>


-- 
Thanks
Mohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20160531/ec77f510/attachment.html