From eric.wittmann at redhat.com Thu Jun 1 08:03:05 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 1 Jun 2017 08:03:05 -0400 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: I do not believe that there were any database changes between 1.2.8 and 1.30. So I *think* you should be OK if you just upgrade the application and skip the export/import process (just point the new version to your existing database). However, I would advise you to clone your database and give it a try first (on a test system), before doing anything in production. -Eric On Wed, May 31, 2017 at 4:45 PM, Celso Agra wrote: > Hi all, > > Sorry about that, but I'm concern to upgrade my apiman to a newest. > I read about upgrating the application: http://www.apiman.io/latest/ > installation-guide.html#_upgrading_to_a_new_apiman_version > But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed to > export and reimport all data from different versions. > > Could I just change server and application without change anything in my > database? just put the new wildfly running the apiman instance. Would be > possible to do that? > > PS.: My APIMan is running with a remote database and remote Keycloak. > > Best Regards, > > -- > --- > *Celso Agra* > > _______________________________________________ > 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/20170601/3ec75b88/attachment.html From marc.savy at redhat.com Thu Jun 1 08:46:09 2017 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 1 Jun 2017 13:46:09 +0100 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: +1. That's my expectation, also. On 1 June 2017 at 13:03, Eric Wittmann wrote: > I do not believe that there were any database changes between 1.2.8 and > 1.30. So I *think* you should be OK if you just upgrade the application > and skip the export/import process (just point the new version to your > existing database). However, I would advise you to clone your database and > give it a try first (on a test system), before doing anything in production. > > -Eric > > > On Wed, May 31, 2017 at 4:45 PM, Celso Agra wrote: > >> Hi all, >> >> Sorry about that, but I'm concern to upgrade my apiman to a newest. >> I read about upgrating the application: http://www.apiman.io/latest/in >> stallation-guide.html#_upgrading_to_a_new_apiman_version >> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed to >> export and reimport all data from different versions. >> >> Could I just change server and application without change anything in my >> database? just put the new wildfly running the apiman instance. Would be >> possible to do that? >> >> PS.: My APIMan is running with a remote database and remote Keycloak. >> >> Best Regards, >> >> -- >> --- >> *Celso Agra* >> >> _______________________________________________ >> 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/20170601/3cdcb851/attachment.html From andyyar66 at gmail.com Fri Jun 2 03:05:06 2017 From: andyyar66 at gmail.com (Andy Yar) Date: Fri, 2 Jun 2017 09:05:06 +0200 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug Message-ID: Hello, Keycloak OAuth plugin's presence generates a certain amount of records to pd_templates table on each action of Apiman Manager related to a Keycloak OAuth policy (even read-only ones like listing a plan's policies, etc.). Over time the number of records in pd_templates table can grow to milions resulting in Apiman Manager OoM exceptions. Given these records are basically just text hints it is really funny. A workaround is to periodically dedup the records. I guess this issue should be an easy fix. Affected version is: Apiman 1.2.9.Final + corresponding Keycloak OAuth plugin. From marc.savy at redhat.com Fri Jun 2 06:26:44 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 2 Jun 2017 11:26:44 +0100 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: Hi Andy, I spent time yesterday evening trying to replicate this after our chat on IRC, but I haven't been able to trigger it. Perhaps with more information we can narrow this down. Which version of Postgres are you using? Which driver version? I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final (should be same as 1.2.9.Final for this). Have you done any export-import? Have you observed the precise action that corresponds with the extraneous pd_templates entries being inserted? Regards, Marc On 2 June 2017 at 08:05, Andy Yar wrote: > > Hello, > Keycloak OAuth plugin's presence generates a certain amount of records > to pd_templates table on each action of Apiman Manager related to a > Keycloak OAuth policy (even read-only ones like listing a plan's > policies, etc.). > > Over time the number of records in pd_templates table can grow to > milions resulting in Apiman Manager OoM exceptions. Given these > records are basically just text hints it is really funny. > > A workaround is to periodically dedup the records. > > I guess this issue should be an easy fix. > > Affected version is: Apiman 1.2.9.Final + corresponding Keycloak OAuth plugin. > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user From marc.savy at redhat.com Fri Jun 2 07:49:28 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 2 Jun 2017 12:49:28 +0100 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: Hi Andy, Can you describe how your API, ClientApp & Plan is set up? e.g. API = [Keycloak OAuth2 Policy] Plan = [] ClientApp = [Header Policy] Regards, Marc On 2 June 2017 at 12:20, Andy Yar wrote: > Oh, sorry I missed version info. > > psql (PostgreSQL) 9.4.12 > JDBC connector - PostgreSQL 9.4.1212 > Apiman 1.2.9.Final > CentOS7 > Oracle Java 1.8.0_111 > > No export/import was done prior this issue. > > I can say I've been observed slower and slower responses during > operation with the Manager OAuth related pages. > > The trigger action seems to be a GET on a URL pattern like this: > apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/policies/1155 > > Resulting screen loads a policy config scheme from Keycloak OAuth > Plugin and displays it. It also generates N^2 new rows in > pd_templates. I've observed 16, 32, 64, 128 and then 256 added new > rows... > > Thanks > > > On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy wrote: >> Hi Andy, >> >> I spent time yesterday evening trying to replicate this after our chat >> on IRC, but I haven't been able to trigger it. Perhaps with more >> information we can narrow this down. >> >> Which version of Postgres are you using? Which driver version? >> >> I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final >> (should be same as 1.2.9.Final for this). >> >> Have you done any export-import? >> >> Have you observed the precise action that corresponds with the >> extraneous pd_templates entries being inserted? >> >> Regards, >> Marc >> >> On 2 June 2017 at 08:05, Andy Yar wrote: >>> >>> Hello, >>> Keycloak OAuth plugin's presence generates a certain amount of records >>> to pd_templates table on each action of Apiman Manager related to a >>> Keycloak OAuth policy (even read-only ones like listing a plan's >>> policies, etc.). >>> >>> Over time the number of records in pd_templates table can grow to >>> milions resulting in Apiman Manager OoM exceptions. Given these >>> records are basically just text hints it is really funny. >>> >>> A workaround is to periodically dedup the records. >>> >>> I guess this issue should be an easy fix. >>> >>> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak OAuth plugin. >>> _______________________________________________ >>> Apiman-user mailing list >>> Apiman-user at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/apiman-user From andyyar66 at gmail.com Fri Jun 2 07:20:38 2017 From: andyyar66 at gmail.com (Andy Yar) Date: Fri, 2 Jun 2017 13:20:38 +0200 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: Oh, sorry I missed version info. psql (PostgreSQL) 9.4.12 JDBC connector - PostgreSQL 9.4.1212 Apiman 1.2.9.Final CentOS7 Oracle Java 1.8.0_111 No export/import was done prior this issue. I can say I've been observed slower and slower responses during operation with the Manager OAuth related pages. The trigger action seems to be a GET on a URL pattern like this: apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/policies/1155 Resulting screen loads a policy config scheme from Keycloak OAuth Plugin and displays it. It also generates N^2 new rows in pd_templates. I've observed 16, 32, 64, 128 and then 256 added new rows... Thanks On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy wrote: > Hi Andy, > > I spent time yesterday evening trying to replicate this after our chat > on IRC, but I haven't been able to trigger it. Perhaps with more > information we can narrow this down. > > Which version of Postgres are you using? Which driver version? > > I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final > (should be same as 1.2.9.Final for this). > > Have you done any export-import? > > Have you observed the precise action that corresponds with the > extraneous pd_templates entries being inserted? > > Regards, > Marc > > On 2 June 2017 at 08:05, Andy Yar wrote: >> >> Hello, >> Keycloak OAuth plugin's presence generates a certain amount of records >> to pd_templates table on each action of Apiman Manager related to a >> Keycloak OAuth policy (even read-only ones like listing a plan's >> policies, etc.). >> >> Over time the number of records in pd_templates table can grow to >> milions resulting in Apiman Manager OoM exceptions. Given these >> records are basically just text hints it is really funny. >> >> A workaround is to periodically dedup the records. >> >> I guess this issue should be an easy fix. >> >> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak OAuth plugin. >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user From marc.savy at redhat.com Fri Jun 2 08:11:59 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 2 Jun 2017 13:11:59 +0100 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: Also, which platform are you running the Apiman Manager on. WildFly, EAP, Tomcat, Jetty, etc? Would be interested to see you try the newest Postgres driver. e.g. https://jdbc.postgresql.org/download/postgresql-42.1.1.jar On 2 June 2017 at 12:49, Marc Savy wrote: > Hi Andy, > > Can you describe how your API, ClientApp & Plan is set up? > > e.g. > > API = [Keycloak OAuth2 Policy] > Plan = [] > ClientApp = [Header Policy] > > > Regards, > Marc > > On 2 June 2017 at 12:20, Andy Yar wrote: >> Oh, sorry I missed version info. >> >> psql (PostgreSQL) 9.4.12 >> JDBC connector - PostgreSQL 9.4.1212 >> Apiman 1.2.9.Final >> CentOS7 >> Oracle Java 1.8.0_111 >> >> No export/import was done prior this issue. >> >> I can say I've been observed slower and slower responses during >> operation with the Manager OAuth related pages. >> >> The trigger action seems to be a GET on a URL pattern like this: >> apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/policies/1155 >> >> Resulting screen loads a policy config scheme from Keycloak OAuth >> Plugin and displays it. It also generates N^2 new rows in >> pd_templates. I've observed 16, 32, 64, 128 and then 256 added new >> rows... >> >> Thanks >> >> >> On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy wrote: >>> Hi Andy, >>> >>> I spent time yesterday evening trying to replicate this after our chat >>> on IRC, but I haven't been able to trigger it. Perhaps with more >>> information we can narrow this down. >>> >>> Which version of Postgres are you using? Which driver version? >>> >>> I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final >>> (should be same as 1.2.9.Final for this). >>> >>> Have you done any export-import? >>> >>> Have you observed the precise action that corresponds with the >>> extraneous pd_templates entries being inserted? >>> >>> Regards, >>> Marc >>> >>> On 2 June 2017 at 08:05, Andy Yar wrote: >>>> >>>> Hello, >>>> Keycloak OAuth plugin's presence generates a certain amount of records >>>> to pd_templates table on each action of Apiman Manager related to a >>>> Keycloak OAuth policy (even read-only ones like listing a plan's >>>> policies, etc.). >>>> >>>> Over time the number of records in pd_templates table can grow to >>>> milions resulting in Apiman Manager OoM exceptions. Given these >>>> records are basically just text hints it is really funny. >>>> >>>> A workaround is to periodically dedup the records. >>>> >>>> I guess this issue should be an easy fix. >>>> >>>> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak OAuth plugin. >>>> _______________________________________________ >>>> Apiman-user mailing list >>>> Apiman-user at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/apiman-user From eric.wittmann at redhat.com Fri Jun 2 08:50:46 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 2 Jun 2017 08:50:46 -0400 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: This is a very strange problem. I'll add some technical info to this discussion in case it helps. The "pd_templates" table stores potentially multiple html templates for displaying the *summary* of a configured instance of a policy. It can store multiple templates by language - this is basically an i18n feature. In practice, we only really have English language versions, so there should only be one row in that table for each row in the "policydefs" table. The "policydefs" table should have one row per policy definition (basically one row for each item in the Policy Type drop-down when adding a new policy to an API). The ORM class for the pd_templates table is here: https://github.com/apiman/apiman/blob/master/manager/api/beans/src/main/java/io/apiman/manager/api/beans/policies/PolicyDefinitionTemplateBean.java And the policy definition ORM bean is here: https://github.com/apiman/apiman/blob/master/manager/api/beans/src/main/java/io/apiman/manager/api/beans/policies/PolicyDefinitionBean.java This sounds like hibernate making a mess of things (or more likely my mis-understanding of something hibernate is doing). It's one of the reasons I'm on the fence about ORM technologies in general. They can be so helpful, but if you wrote your own SQL statements you'd never have a weird issue like this. In any case, at this point I have no theory about how this could be happening. I assume your "policydefs" table is sensible. So the question is why hibernate would be duplicating the data in "pd_templates", especially when doing a simple GET of the information (shouldn't be mutating anything!). Could try enabling SQL logging in hibernate to see what's going on. But of course trying to replicate the problem locally is always the best approach. :) -Eric On Fri, Jun 2, 2017 at 7:49 AM, Marc Savy wrote: > Hi Andy, > > Can you describe how your API, ClientApp & Plan is set up? > > e.g. > > API = [Keycloak OAuth2 Policy] > Plan = [] > ClientApp = [Header Policy] > > > Regards, > Marc > > On 2 June 2017 at 12:20, Andy Yar wrote: > > Oh, sorry I missed version info. > > > > psql (PostgreSQL) 9.4.12 > > JDBC connector - PostgreSQL 9.4.1212 > > Apiman 1.2.9.Final > > CentOS7 > > Oracle Java 1.8.0_111 > > > > No export/import was done prior this issue. > > > > I can say I've been observed slower and slower responses during > > operation with the Manager OAuth related pages. > > > > The trigger action seems to be a GET on a URL pattern like this: > > apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/policies/1155 > > > > Resulting screen loads a policy config scheme from Keycloak OAuth > > Plugin and displays it. It also generates N^2 new rows in > > pd_templates. I've observed 16, 32, 64, 128 and then 256 added new > > rows... > > > > Thanks > > > > > > On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy wrote: > >> Hi Andy, > >> > >> I spent time yesterday evening trying to replicate this after our chat > >> on IRC, but I haven't been able to trigger it. Perhaps with more > >> information we can narrow this down. > >> > >> Which version of Postgres are you using? Which driver version? > >> > >> I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final > >> (should be same as 1.2.9.Final for this). > >> > >> Have you done any export-import? > >> > >> Have you observed the precise action that corresponds with the > >> extraneous pd_templates entries being inserted? > >> > >> Regards, > >> Marc > >> > >> On 2 June 2017 at 08:05, Andy Yar wrote: > >>> > >>> Hello, > >>> Keycloak OAuth plugin's presence generates a certain amount of records > >>> to pd_templates table on each action of Apiman Manager related to a > >>> Keycloak OAuth policy (even read-only ones like listing a plan's > >>> policies, etc.). > >>> > >>> Over time the number of records in pd_templates table can grow to > >>> milions resulting in Apiman Manager OoM exceptions. Given these > >>> records are basically just text hints it is really funny. > >>> > >>> A workaround is to periodically dedup the records. > >>> > >>> I guess this issue should be an easy fix. > >>> > >>> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak OAuth > plugin. > >>> _______________________________________________ > >>> 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/20170602/61334fe0/attachment.html From celso.agra at gmail.com Fri Jun 2 10:30:28 2017 From: celso.agra at gmail.com (Celso Agra) Date: Fri, 2 Jun 2017 11:30:28 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: Thanks Marc and Eric! The application works fine, but for some reason, I can't delete any API. Looks like there is no reference for them. Is there some elasticsearch node in the Apiman? 2017-06-01 9:46 GMT-03:00 Marc Savy : > +1. That's my expectation, also. > > On 1 June 2017 at 13:03, Eric Wittmann wrote: > >> I do not believe that there were any database changes between 1.2.8 and >> 1.30. So I *think* you should be OK if you just upgrade the application >> and skip the export/import process (just point the new version to your >> existing database). However, I would advise you to clone your database and >> give it a try first (on a test system), before doing anything in production. >> >> -Eric >> >> >> On Wed, May 31, 2017 at 4:45 PM, Celso Agra wrote: >> >>> Hi all, >>> >>> Sorry about that, but I'm concern to upgrade my apiman to a newest. >>> I read about upgrating the application: http://www.apiman.io/latest/in >>> stallation-guide.html#_upgrading_to_a_new_apiman_version >>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed to >>> export and reimport all data from different versions. >>> >>> Could I just change server and application without change anything in my >>> database? just put the new wildfly running the apiman instance. Would be >>> possible to do that? >>> >>> PS.: My APIMan is running with a remote database and remote Keycloak. >>> >>> Best Regards, >>> >>> -- >>> --- >>> *Celso Agra* >>> >>> _______________________________________________ >>> 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 >> >> > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/734e33f5/attachment-0001.html From celso.agra at gmail.com Fri Jun 2 10:32:53 2017 From: celso.agra at gmail.com (Celso Agra) Date: Fri, 2 Jun 2017 11:32:53 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: Here is the error when I try to register some changes in my ClientApp io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed to register client. at io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException(ExceptionFactory.java:331) at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerClient(ActionResourceImpl.java:427) at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction(ActionResourceImpl.java:111) at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$_WeldClientProxy.performAction(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ... Caused by: io.apiman.gateway.engine.beans.exceptions.RegistrationException: API api-servico-dev not found in Organization homolog. at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRegistry.java:159) at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegistry.java:139) at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegistry.java:108) at io.apiman.gateway.engine.es.PollCachingESRegistry.registerClient(PollCachingESRegistry.java:114) at io.apiman.gateway.engine.impl.SecureRegistryWrapper.registerClient(SecureRegistryWrapper.java:81) at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register(ClientResourceImpl.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) ... 2017-06-02 11:30 GMT-03:00 Celso Agra : > Thanks Marc and Eric! > > The application works fine, but for some reason, I can't delete any API. > Looks like there is no reference for them. > > Is there some elasticsearch node in the Apiman? > > 2017-06-01 9:46 GMT-03:00 Marc Savy : > >> +1. That's my expectation, also. >> >> On 1 June 2017 at 13:03, Eric Wittmann wrote: >> >>> I do not believe that there were any database changes between 1.2.8 and >>> 1.30. So I *think* you should be OK if you just upgrade the application >>> and skip the export/import process (just point the new version to your >>> existing database). However, I would advise you to clone your database and >>> give it a try first (on a test system), before doing anything in production. >>> >>> -Eric >>> >>> >>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>> wrote: >>> >>>> Hi all, >>>> >>>> Sorry about that, but I'm concern to upgrade my apiman to a newest. >>>> I read about upgrating the application: http://www.apiman.io/latest/in >>>> stallation-guide.html#_upgrading_to_a_new_apiman_version >>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed to >>>> export and reimport all data from different versions. >>>> >>>> Could I just change server and application without change anything in >>>> my database? just put the new wildfly running the apiman instance. Would be >>>> possible to do that? >>>> >>>> PS.: My APIMan is running with a remote database and remote Keycloak. >>>> >>>> Best Regards, >>>> >>>> -- >>>> --- >>>> *Celso Agra* >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> > > > -- > --- > *Celso Agra* > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/2df7e466/attachment.html From celso.agra at gmail.com Fri Jun 2 10:40:37 2017 From: celso.agra at gmail.com (Celso Agra) Date: Fri, 2 Jun 2017 11:40:37 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: Also, when I try to access some API with an APIKey, i got this error {"responseCode":500,"message":"No client found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman.gateway.engine.beans.exceptions.InvalidContractException: No client found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:361)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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 2017-06-02 11:32 GMT-03:00 Celso Agra : > Here is the error when I try to register some changes in my ClientApp > > > io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed to > register client. > at io.apiman.manager.api.rest.impl.util.ExceptionFactory.actionException( > ExceptionFactory.java:331) > at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerClient( > ActionResourceImpl.java:427) > at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAction( > ActionResourceImpl.java:111) > at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$ > _$$_WeldClientProxy.performAction(Unknown Source) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke( > MethodInjectorImpl.java:139) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget( > ResourceMethodInvoker.java:295) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( > ResourceMethodInvoker.java:249) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( > ResourceMethodInvoker.java:236) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke( > SynchronousDispatcher.java:402) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke( > SynchronousDispatcher.java:209) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher. > service(ServletContainerDispatcher.java:221) > at org.jboss.resteasy.plugins.server.servlet. > HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet. > HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > ... > Caused by: io.apiman.gateway.engine.beans.exceptions.RegistrationException: > API api-servico-dev not found in Organization homolog. > at io.apiman.gateway.engine.es.ESRegistry.validateContract( > ESRegistry.java:159) > at io.apiman.gateway.engine.es.ESRegistry.validateClient( > ESRegistry.java:139) > at io.apiman.gateway.engine.es.ESRegistry.registerClient( > ESRegistry.java:108) > at io.apiman.gateway.engine.es.PollCachingESRegistry.registerClient( > PollCachingESRegistry.java:114) > at io.apiman.gateway.engine.impl.SecureRegistryWrapper.registerClient( > SecureRegistryWrapper.java:81) > at io.apiman.gateway.api.rest.impl.ClientResourceImpl. > register(ClientResourceImpl.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke( > NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke( > DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.jboss.resteasy.core.MethodInjectorImpl.invoke( > MethodInjectorImpl.java:139) > at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget( > ResourceMethodInvoker.java:295) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( > ResourceMethodInvoker.java:249) > at org.jboss.resteasy.core.ResourceMethodInvoker.invoke( > ResourceMethodInvoker.java:236) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke( > SynchronousDispatcher.java:402) > at org.jboss.resteasy.core.SynchronousDispatcher.invoke( > SynchronousDispatcher.java:209) > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher. > service(ServletContainerDispatcher.java:221) > at org.jboss.resteasy.plugins.server.servlet. > HttpServletDispatcher.service(HttpServletDispatcher.java:56) > at org.jboss.resteasy.plugins.server.servlet. > HttpServletDispatcher.service(HttpServletDispatcher.java:51) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > ... > > 2017-06-02 11:30 GMT-03:00 Celso Agra : > >> Thanks Marc and Eric! >> >> The application works fine, but for some reason, I can't delete any API. >> Looks like there is no reference for them. >> >> Is there some elasticsearch node in the Apiman? >> >> 2017-06-01 9:46 GMT-03:00 Marc Savy : >> >>> +1. That's my expectation, also. >>> >>> On 1 June 2017 at 13:03, Eric Wittmann wrote: >>> >>>> I do not believe that there were any database changes between 1.2.8 and >>>> 1.30. So I *think* you should be OK if you just upgrade the application >>>> and skip the export/import process (just point the new version to your >>>> existing database). However, I would advise you to clone your database and >>>> give it a try first (on a test system), before doing anything in production. >>>> >>>> -Eric >>>> >>>> >>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> Sorry about that, but I'm concern to upgrade my apiman to a newest. >>>>> I read about upgrating the application: http://www.apiman.io/latest/in >>>>> stallation-guide.html#_upgrading_to_a_new_apiman_version >>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed >>>>> to export and reimport all data from different versions. >>>>> >>>>> Could I just change server and application without change anything in >>>>> my database? just put the new wildfly running the apiman instance. Would be >>>>> possible to do that? >>>>> >>>>> PS.: My APIMan is running with a remote database and remote Keycloak. >>>>> >>>>> Best Regards, >>>>> >>>>> -- >>>>> --- >>>>> *Celso Agra* >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >> >> >> -- >> --- >> *Celso Agra* >> > > > > -- > --- > *Celso Agra* > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/98370dd8/attachment-0001.html From eric.wittmann at redhat.com Fri Jun 2 15:53:19 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 2 Jun 2017 15:53:19 -0400 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: It sounds like your configuration is different between 1.2.8 and 1.3.0. Can you post the apiman.properties files from each? On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra wrote: > Also, when I try to access some API with an APIKey, i got this error > > {"responseCode":500,"message":"No client found for API Key > xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io. > apiman.gateway.engine.beans.exceptions.InvalidContractException: No > client found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat > io.apiman.gateway.engine.es.CachingESRegistry.getContract( > CachingESRegistry.java:78)\n\tat io.apiman.gateway.engine.impl. > SecureRegistryWrapper.getContract(SecureRegistryWrapper.java:154)\n\tat > io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute( > ApiRequestExecutorImpl.java:361)\n\tat io.apiman.gateway.platforms. > servlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat > io.apiman.gateway.platforms.servlet.GatewayServlet. > service(GatewayServlet.java:78)\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 > > 2017-06-02 11:32 GMT-03:00 Celso Agra : > >> Here is the error when I try to register some changes in my ClientApp >> >> >> io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed >> to register client. >> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >> Exception(ExceptionFactory.java:331) >> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >> lient(ActionResourceImpl.java:427) >> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >> tion(ActionResourceImpl.java:111) >> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >> _WeldClientProxy.performAction(Unknown Source) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >> ssorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >> thodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >> ctorImpl.java:139) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >> (ResourceMethodInvoker.java:295) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >> eMethodInvoker.java:249) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >> eMethodInvoker.java:236) >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >> nousDispatcher.java:402) >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >> nousDispatcher.java:209) >> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >> spatcher.service(ServletContainerDispatcher.java:221) >> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >> her.service(HttpServletDispatcher.java:56) >> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >> her.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> ... >> Caused by: io.apiman.gateway.engine.beans.exceptions.RegistrationException: >> API api-servico-dev not found in Organization homolog. >> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >> gistry.java:159) >> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >> stry.java:139) >> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >> stry.java:108) >> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >> ient(PollCachingESRegistry.java:114) >> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >> Client(SecureRegistryWrapper.java:81) >> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >> ClientResourceImpl.java:54) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >> ssorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >> thodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:498) >> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >> ctorImpl.java:139) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >> (ResourceMethodInvoker.java:295) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >> eMethodInvoker.java:249) >> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >> eMethodInvoker.java:236) >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >> nousDispatcher.java:402) >> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >> nousDispatcher.java:209) >> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >> spatcher.service(ServletContainerDispatcher.java:221) >> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >> her.service(HttpServletDispatcher.java:56) >> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >> her.service(HttpServletDispatcher.java:51) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >> ... >> >> 2017-06-02 11:30 GMT-03:00 Celso Agra : >> >>> Thanks Marc and Eric! >>> >>> The application works fine, but for some reason, I can't delete any API. >>> Looks like there is no reference for them. >>> >>> Is there some elasticsearch node in the Apiman? >>> >>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>> >>>> +1. That's my expectation, also. >>>> >>>> On 1 June 2017 at 13:03, Eric Wittmann >>>> wrote: >>>> >>>>> I do not believe that there were any database changes between 1.2.8 >>>>> and 1.30. So I *think* you should be OK if you just upgrade the >>>>> application and skip the export/import process (just point the new version >>>>> to your existing database). However, I would advise you to clone your >>>>> database and give it a try first (on a test system), before doing anything >>>>> in production. >>>>> >>>>> -Eric >>>>> >>>>> >>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>>>> wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Sorry about that, but I'm concern to upgrade my apiman to a newest. >>>>>> I read about upgrating the application: >>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>> ng_to_a_new_apiman_version >>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed >>>>>> to export and reimport all data from different versions. >>>>>> >>>>>> Could I just change server and application without change anything in >>>>>> my database? just put the new wildfly running the apiman instance. Would be >>>>>> possible to do that? >>>>>> >>>>>> PS.: My APIMan is running with a remote database and remote Keycloak. >>>>>> >>>>>> Best Regards, >>>>>> >>>>>> -- >>>>>> --- >>>>>> *Celso Agra* >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> >> >> -- >> --- >> *Celso Agra* >> > > > > -- > --- > *Celso Agra* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/fb72f3f9/attachment.html From celso.agra at gmail.com Fri Jun 2 16:06:08 2017 From: celso.agra at gmail.com (Celso Agra) Date: Fri, 2 Jun 2017 17:06:08 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: Here is both files! Actually, I believe I did something wrong. I just create a new instance of APIMan just pointing to my keycloak and database. So, it was a new instance of whole system, such as Wildfly, Apiman-es, Apiman, etc... 2017-06-02 16:53 GMT-03:00 Eric Wittmann : > It sounds like your configuration is different between 1.2.8 and 1.3.0. > Can you post the apiman.properties files from each? > > On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra wrote: > >> Also, when I try to access some API with an APIKey, i got this error >> >> {"responseCode":500,"message":"No client found for API Key >> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman. >> gateway.engine.beans.exceptions.InvalidContractException: No client >> found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat >> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat >> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContr >> act(SecureRegistryWrapper.java:154)\n\tat io.apiman.gateway.engine.impl. >> ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:361)\n\tat >> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat >> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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.ServletSecurityRoleHan >> dler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >> eRequest(ServletDispatchingHandler.java:36)\n\tat >> org.wildfly.extension.undertow.security.SecurityContextAssoc >> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >> io.undertow.servlet.handlers.security.SSLInformationAssociat >> ionHandler.handleRequest(SSLInformationAssociationHandler. >> java:131)\n\tat >> >> 2017-06-02 11:32 GMT-03:00 Celso Agra : >> >>> Here is the error when I try to register some changes in my ClientApp >>> >>> >>> io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed >>> to register client. >>> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >>> Exception(ExceptionFactory.java:331) >>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >>> lient(ActionResourceImpl.java:427) >>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >>> tion(ActionResourceImpl.java:111) >>> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >>> _WeldClientProxy.performAction(Unknown Source) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>> ssorImpl.java:62) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>> thodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>> ctorImpl.java:139) >>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>> (ResourceMethodInvoker.java:295) >>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>> eMethodInvoker.java:249) >>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>> eMethodInvoker.java:236) >>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>> nousDispatcher.java:402) >>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>> nousDispatcher.java:209) >>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>> spatcher.service(ServletContainerDispatcher.java:221) >>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>> her.service(HttpServletDispatcher.java:56) >>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>> her.service(HttpServletDispatcher.java:51) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> ... >>> Caused by: io.apiman.gateway.engine.beans.exceptions.RegistrationException: >>> API api-servico-dev not found in Organization homolog. >>> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >>> gistry.java:159) >>> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >>> stry.java:139) >>> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >>> stry.java:108) >>> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >>> ient(PollCachingESRegistry.java:114) >>> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >>> Client(SecureRegistryWrapper.java:81) >>> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >>> ClientResourceImpl.java:54) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>> ssorImpl.java:62) >>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>> thodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:498) >>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>> ctorImpl.java:139) >>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>> (ResourceMethodInvoker.java:295) >>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>> eMethodInvoker.java:249) >>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>> eMethodInvoker.java:236) >>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>> nousDispatcher.java:402) >>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>> nousDispatcher.java:209) >>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>> spatcher.service(ServletContainerDispatcher.java:221) >>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>> her.service(HttpServletDispatcher.java:56) >>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>> her.service(HttpServletDispatcher.java:51) >>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>> ... >>> >>> 2017-06-02 11:30 GMT-03:00 Celso Agra : >>> >>>> Thanks Marc and Eric! >>>> >>>> The application works fine, but for some reason, I can't delete any >>>> API. Looks like there is no reference for them. >>>> >>>> Is there some elasticsearch node in the Apiman? >>>> >>>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>>> >>>>> +1. That's my expectation, also. >>>>> >>>>> On 1 June 2017 at 13:03, Eric Wittmann >>>>> wrote: >>>>> >>>>>> I do not believe that there were any database changes between 1.2.8 >>>>>> and 1.30. So I *think* you should be OK if you just upgrade the >>>>>> application and skip the export/import process (just point the new version >>>>>> to your existing database). However, I would advise you to clone your >>>>>> database and give it a try first (on a test system), before doing anything >>>>>> in production. >>>>>> >>>>>> -Eric >>>>>> >>>>>> >>>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Sorry about that, but I'm concern to upgrade my apiman to a newest. >>>>>>> I read about upgrating the application: >>>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>>> ng_to_a_new_apiman_version >>>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must needed >>>>>>> to export and reimport all data from different versions. >>>>>>> >>>>>>> Could I just change server and application without change anything >>>>>>> in my database? just put the new wildfly running the apiman instance. Would >>>>>>> be possible to do that? >>>>>>> >>>>>>> PS.: My APIMan is running with a remote database and remote Keycloak. >>>>>>> >>>>>>> Best Regards, >>>>>>> >>>>>>> -- >>>>>>> --- >>>>>>> *Celso Agra* >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> --- >>>> *Celso Agra* >>>> >>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> >> >> -- >> --- >> *Celso Agra* >> > > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/65deb0d2/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: apiman.properties.1.2.8 Type: application/octet-stream Size: 11364 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/65deb0d2/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: apiman.properties.1.3.0 Type: application/octet-stream Size: 11699 bytes Desc: not available Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/65deb0d2/attachment-0003.obj From eric.wittmann at redhat.com Fri Jun 2 16:48:34 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 2 Jun 2017 16:48:34 -0400 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: You *almost* did the right thing. :) You were correct to create a new instance of the whole system, just pointing it to your KC and database. However you must *also* point it to your Gateway storage, which by default is Elasticsearch (embedded in the quickstart). Note that you really shouldn't use the embedded Elasticsearch instance for production (there is more info in the Production guide on the apiman site). It's really intended as a quick Getting Started approach. Anyway, the Gateway has its own separate persistence store which you'll need to copy to your 1.3.0 setup. You should be able to find the data files in Wildfly somewhere (standalone/data/apiman iirc). -Eric On Fri, Jun 2, 2017 at 4:06 PM, Celso Agra wrote: > Here is both files! > > Actually, I believe I did something wrong. I just create a new instance of > APIMan just pointing to my keycloak and database. > So, it was a new instance of whole system, such as Wildfly, Apiman-es, > Apiman, etc... > > > 2017-06-02 16:53 GMT-03:00 Eric Wittmann : > >> It sounds like your configuration is different between 1.2.8 and 1.3.0. >> Can you post the apiman.properties files from each? >> >> On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra wrote: >> >>> Also, when I try to access some API with an APIKey, i got this error >>> >>> {"responseCode":500,"message":"No client found for API Key >>> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman.gat >>> eway.engine.beans.exceptions.InvalidContractException: No client found >>> for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat >>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat >>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContr >>> act(SecureRegistryWrapper.java:154)\n\tat io.apiman.gateway.engine.impl. >>> ApiRequestExecutorImpl.execute(ApiRequestExecutorImpl.java:361)\n\tat >>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat >>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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.ServletSecurityRoleHan >>> dler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >>> eRequest(ServletDispatchingHandler.java:36)\n\tat >>> org.wildfly.extension.undertow.security.SecurityContextAssoc >>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>> io.undertow.servlet.handlers.security.SSLInformationAssociat >>> ionHandler.handleRequest(SSLInformationAssociationHandler.ja >>> va:131)\n\tat >>> >>> 2017-06-02 11:32 GMT-03:00 Celso Agra : >>> >>>> Here is the error when I try to register some changes in my ClientApp >>>> >>>> >>>> io.apiman.manager.api.rest.contract.exceptions.ActionException: Failed >>>> to register client. >>>> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >>>> Exception(ExceptionFactory.java:331) >>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >>>> lient(ActionResourceImpl.java:427) >>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >>>> tion(ActionResourceImpl.java:111) >>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >>>> _WeldClientProxy.performAction(Unknown Source) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>> ssorImpl.java:62) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>> thodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>> ctorImpl.java:139) >>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>> (ResourceMethodInvoker.java:295) >>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>> eMethodInvoker.java:249) >>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>> eMethodInvoker.java:236) >>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>> nousDispatcher.java:402) >>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>> nousDispatcher.java:209) >>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>> spatcher.service(ServletContainerDispatcher.java:221) >>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>> her.service(HttpServletDispatcher.java:56) >>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>> her.service(HttpServletDispatcher.java:51) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>> ... >>>> Caused by: io.apiman.gateway.engine.beans.exceptions.RegistrationException: >>>> API api-servico-dev not found in Organization homolog. >>>> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >>>> gistry.java:159) >>>> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >>>> stry.java:139) >>>> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >>>> stry.java:108) >>>> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >>>> ient(PollCachingESRegistry.java:114) >>>> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >>>> Client(SecureRegistryWrapper.java:81) >>>> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >>>> ClientResourceImpl.java:54) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>> ssorImpl.java:62) >>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>> thodAccessorImpl.java:43) >>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>> ctorImpl.java:139) >>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>> (ResourceMethodInvoker.java:295) >>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>> eMethodInvoker.java:249) >>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>> eMethodInvoker.java:236) >>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>> nousDispatcher.java:402) >>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>> nousDispatcher.java:209) >>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>> spatcher.service(ServletContainerDispatcher.java:221) >>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>> her.service(HttpServletDispatcher.java:56) >>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>> her.service(HttpServletDispatcher.java:51) >>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>> ... >>>> >>>> 2017-06-02 11:30 GMT-03:00 Celso Agra : >>>> >>>>> Thanks Marc and Eric! >>>>> >>>>> The application works fine, but for some reason, I can't delete any >>>>> API. Looks like there is no reference for them. >>>>> >>>>> Is there some elasticsearch node in the Apiman? >>>>> >>>>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>>>> >>>>>> +1. That's my expectation, also. >>>>>> >>>>>> On 1 June 2017 at 13:03, Eric Wittmann >>>>>> wrote: >>>>>> >>>>>>> I do not believe that there were any database changes between 1.2.8 >>>>>>> and 1.30. So I *think* you should be OK if you just upgrade the >>>>>>> application and skip the export/import process (just point the new version >>>>>>> to your existing database). However, I would advise you to clone your >>>>>>> database and give it a try first (on a test system), before doing anything >>>>>>> in production. >>>>>>> >>>>>>> -Eric >>>>>>> >>>>>>> >>>>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>>>>>> wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> Sorry about that, but I'm concern to upgrade my apiman to a newest. >>>>>>>> I read about upgrating the application: >>>>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>>>> ng_to_a_new_apiman_version >>>>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must >>>>>>>> needed to export and reimport all data from different versions. >>>>>>>> >>>>>>>> Could I just change server and application without change anything >>>>>>>> in my database? just put the new wildfly running the apiman instance. Would >>>>>>>> be possible to do that? >>>>>>>> >>>>>>>> PS.: My APIMan is running with a remote database and remote >>>>>>>> Keycloak. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> >>>>>>>> -- >>>>>>>> --- >>>>>>>> *Celso Agra* >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> *Celso Agra* >>>>> >>>> >>>> >>>> >>>> -- >>>> --- >>>> *Celso Agra* >>>> >>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> > > > -- > --- > *Celso Agra* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/b0dfd8e5/attachment-0001.html From celso.agra at gmail.com Fri Jun 2 16:59:31 2017 From: celso.agra at gmail.com (Celso Agra) Date: Fri, 2 Jun 2017 17:59:31 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: I knew it! hehehe I'll try again later. Thanks!! 2017-06-02 17:48 GMT-03:00 Eric Wittmann : > You *almost* did the right thing. :) You were correct to create a new > instance of the whole system, just pointing it to your KC and database. > However you must *also* point it to your Gateway storage, which by default > is Elasticsearch (embedded in the quickstart). > > Note that you really shouldn't use the embedded Elasticsearch instance for > production (there is more info in the Production guide on the apiman > site). It's really intended as a quick Getting Started approach. > > Anyway, the Gateway has its own separate persistence store which you'll > need to copy to your 1.3.0 setup. You should be able to find the data > files in Wildfly somewhere (standalone/data/apiman iirc). > > -Eric > > > On Fri, Jun 2, 2017 at 4:06 PM, Celso Agra wrote: > >> Here is both files! >> >> Actually, I believe I did something wrong. I just create a new instance >> of APIMan just pointing to my keycloak and database. >> So, it was a new instance of whole system, such as Wildfly, Apiman-es, >> Apiman, etc... >> >> >> 2017-06-02 16:53 GMT-03:00 Eric Wittmann : >> >>> It sounds like your configuration is different between 1.2.8 and 1.3.0. >>> Can you post the apiman.properties files from each? >>> >>> On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra >>> wrote: >>> >>>> Also, when I try to access some API with an APIKey, i got this error >>>> >>>> {"responseCode":500,"message":"No client found for API Key >>>> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman.gat >>>> eway.engine.beans.exceptions.InvalidContractException: No client found >>>> for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat >>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat >>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContr >>>> act(SecureRegistryWrapper.java:154)\n\tat >>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute >>>> (ApiRequestExecutorImpl.java:361)\n\tat io.apiman.gateway.platforms.se >>>> rvlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat >>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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.ServletSecurityRoleHan >>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >>>> eRequest(ServletDispatchingHandler.java:36)\n\tat >>>> org.wildfly.extension.undertow.security.SecurityContextAssoc >>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>>> io.undertow.servlet.handlers.security.SSLInformationAssociat >>>> ionHandler.handleRequest(SSLInformationAssociationHandler.ja >>>> va:131)\n\tat >>>> >>>> 2017-06-02 11:32 GMT-03:00 Celso Agra : >>>> >>>>> Here is the error when I try to register some changes in my ClientApp >>>>> >>>>> >>>>> io.apiman.manager.api.rest.contract.exceptions.ActionException: >>>>> Failed to register client. >>>>> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >>>>> Exception(ExceptionFactory.java:331) >>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >>>>> lient(ActionResourceImpl.java:427) >>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >>>>> tion(ActionResourceImpl.java:111) >>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >>>>> _WeldClientProxy.performAction(Unknown Source) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>> ssorImpl.java:62) >>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>> thodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>> ctorImpl.java:139) >>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>> (ResourceMethodInvoker.java:295) >>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>> eMethodInvoker.java:249) >>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>> eMethodInvoker.java:236) >>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>> nousDispatcher.java:402) >>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>> nousDispatcher.java:209) >>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>> her.service(HttpServletDispatcher.java:56) >>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>> her.service(HttpServletDispatcher.java:51) >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> ... >>>>> Caused by: io.apiman.gateway.engine.beans >>>>> .exceptions.RegistrationException: API api-servico-dev not found in >>>>> Organization homolog. >>>>> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >>>>> gistry.java:159) >>>>> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >>>>> stry.java:139) >>>>> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >>>>> stry.java:108) >>>>> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >>>>> ient(PollCachingESRegistry.java:114) >>>>> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >>>>> Client(SecureRegistryWrapper.java:81) >>>>> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >>>>> ClientResourceImpl.java:54) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>> ssorImpl.java:62) >>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>> thodAccessorImpl.java:43) >>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>> ctorImpl.java:139) >>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>> (ResourceMethodInvoker.java:295) >>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>> eMethodInvoker.java:249) >>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>> eMethodInvoker.java:236) >>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>> nousDispatcher.java:402) >>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>> nousDispatcher.java:209) >>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>> her.service(HttpServletDispatcher.java:56) >>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>> her.service(HttpServletDispatcher.java:51) >>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>> ... >>>>> >>>>> 2017-06-02 11:30 GMT-03:00 Celso Agra : >>>>> >>>>>> Thanks Marc and Eric! >>>>>> >>>>>> The application works fine, but for some reason, I can't delete any >>>>>> API. Looks like there is no reference for them. >>>>>> >>>>>> Is there some elasticsearch node in the Apiman? >>>>>> >>>>>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>>>>> >>>>>>> +1. That's my expectation, also. >>>>>>> >>>>>>> On 1 June 2017 at 13:03, Eric Wittmann >>>>>>> wrote: >>>>>>> >>>>>>>> I do not believe that there were any database changes between 1.2.8 >>>>>>>> and 1.30. So I *think* you should be OK if you just upgrade the >>>>>>>> application and skip the export/import process (just point the new version >>>>>>>> to your existing database). However, I would advise you to clone your >>>>>>>> database and give it a try first (on a test system), before doing anything >>>>>>>> in production. >>>>>>>> >>>>>>>> -Eric >>>>>>>> >>>>>>>> >>>>>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Sorry about that, but I'm concern to upgrade my apiman to a newest. >>>>>>>>> I read about upgrating the application: >>>>>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>>>>> ng_to_a_new_apiman_version >>>>>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must >>>>>>>>> needed to export and reimport all data from different versions. >>>>>>>>> >>>>>>>>> Could I just change server and application without change anything >>>>>>>>> in my database? just put the new wildfly running the apiman instance. Would >>>>>>>>> be possible to do that? >>>>>>>>> >>>>>>>>> PS.: My APIMan is running with a remote database and remote >>>>>>>>> Keycloak. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> >>>>>>>>> -- >>>>>>>>> --- >>>>>>>>> *Celso Agra* >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --- >>>>>> *Celso Agra* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> *Celso Agra* >>>>> >>>> >>>> >>>> >>>> -- >>>> --- >>>> *Celso Agra* >>>> >>> >>> >> >> >> -- >> --- >> *Celso Agra* >> > > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/024ff610/attachment-0001.html From celso.agra at gmail.com Fri Jun 2 17:06:40 2017 From: celso.agra at gmail.com (Celso Agra) Date: Fri, 2 Jun 2017 18:06:40 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: I think I found it! ./standalone/data# ls -l > apiman bootstrap content es kernel keycloak.h2.db keycloak.lock.db keycloak.trace.db keycloak.trace.db.old timer-service-data tx-object-store Could I just copy the whole "data" folder? I'll take a look in the production guide. Thanks again! 2017-06-02 17:59 GMT-03:00 Celso Agra : > I knew it! hehehe > > I'll try again later. > > Thanks!! > > 2017-06-02 17:48 GMT-03:00 Eric Wittmann : > >> You *almost* did the right thing. :) You were correct to create a new >> instance of the whole system, just pointing it to your KC and database. >> However you must *also* point it to your Gateway storage, which by default >> is Elasticsearch (embedded in the quickstart). >> >> Note that you really shouldn't use the embedded Elasticsearch instance >> for production (there is more info in the Production guide on the apiman >> site). It's really intended as a quick Getting Started approach. >> >> Anyway, the Gateway has its own separate persistence store which you'll >> need to copy to your 1.3.0 setup. You should be able to find the data >> files in Wildfly somewhere (standalone/data/apiman iirc). >> >> -Eric >> >> >> On Fri, Jun 2, 2017 at 4:06 PM, Celso Agra wrote: >> >>> Here is both files! >>> >>> Actually, I believe I did something wrong. I just create a new instance >>> of APIMan just pointing to my keycloak and database. >>> So, it was a new instance of whole system, such as Wildfly, Apiman-es, >>> Apiman, etc... >>> >>> >>> 2017-06-02 16:53 GMT-03:00 Eric Wittmann : >>> >>>> It sounds like your configuration is different between 1.2.8 and >>>> 1.3.0. Can you post the apiman.properties files from each? >>>> >>>> On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra >>>> wrote: >>>> >>>>> Also, when I try to access some API with an APIKey, i got this error >>>>> >>>>> {"responseCode":500,"message":"No client found for API Key >>>>> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman.gat >>>>> eway.engine.beans.exceptions.InvalidContractException: No client >>>>> found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat >>>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat >>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContr >>>>> act(SecureRegistryWrapper.java:154)\n\tat >>>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute >>>>> (ApiRequestExecutorImpl.java:361)\n\tat io.apiman.gateway.platforms.se >>>>> rvlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat >>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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.ServletSecurityRoleHan >>>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >>>>> eRequest(ServletDispatchingHandler.java:36)\n\tat >>>>> org.wildfly.extension.undertow.security.SecurityContextAssoc >>>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>>>> io.undertow.servlet.handlers.security.SSLInformationAssociat >>>>> ionHandler.handleRequest(SSLInformationAssociationHandler.ja >>>>> va:131)\n\tat >>>>> >>>>> 2017-06-02 11:32 GMT-03:00 Celso Agra : >>>>> >>>>>> Here is the error when I try to register some changes in my ClientApp >>>>>> >>>>>> >>>>>> io.apiman.manager.api.rest.contract.exceptions.ActionException: >>>>>> Failed to register client. >>>>>> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >>>>>> Exception(ExceptionFactory.java:331) >>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >>>>>> lient(ActionResourceImpl.java:427) >>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >>>>>> tion(ActionResourceImpl.java:111) >>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >>>>>> _WeldClientProxy.performAction(Unknown Source) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>> ssorImpl.java:62) >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>> thodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>> ctorImpl.java:139) >>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>> (ResourceMethodInvoker.java:295) >>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>> eMethodInvoker.java:249) >>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>> eMethodInvoker.java:236) >>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>> nousDispatcher.java:402) >>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>> nousDispatcher.java:209) >>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>> her.service(HttpServletDispatcher.java:56) >>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>> her.service(HttpServletDispatcher.java:51) >>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>> ... >>>>>> Caused by: io.apiman.gateway.engine.beans >>>>>> .exceptions.RegistrationException: API api-servico-dev not found in >>>>>> Organization homolog. >>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >>>>>> gistry.java:159) >>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >>>>>> stry.java:139) >>>>>> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >>>>>> stry.java:108) >>>>>> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >>>>>> ient(PollCachingESRegistry.java:114) >>>>>> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >>>>>> Client(SecureRegistryWrapper.java:81) >>>>>> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >>>>>> ClientResourceImpl.java:54) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>> ssorImpl.java:62) >>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>> thodAccessorImpl.java:43) >>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>> ctorImpl.java:139) >>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>> (ResourceMethodInvoker.java:295) >>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>> eMethodInvoker.java:249) >>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>> eMethodInvoker.java:236) >>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>> nousDispatcher.java:402) >>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>> nousDispatcher.java:209) >>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>> her.service(HttpServletDispatcher.java:56) >>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>> her.service(HttpServletDispatcher.java:51) >>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>> ... >>>>>> >>>>>> 2017-06-02 11:30 GMT-03:00 Celso Agra : >>>>>> >>>>>>> Thanks Marc and Eric! >>>>>>> >>>>>>> The application works fine, but for some reason, I can't delete any >>>>>>> API. Looks like there is no reference for them. >>>>>>> >>>>>>> Is there some elasticsearch node in the Apiman? >>>>>>> >>>>>>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>>>>>> >>>>>>>> +1. That's my expectation, also. >>>>>>>> >>>>>>>> On 1 June 2017 at 13:03, Eric Wittmann >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I do not believe that there were any database changes between >>>>>>>>> 1.2.8 and 1.30. So I *think* you should be OK if you just upgrade the >>>>>>>>> application and skip the export/import process (just point the new version >>>>>>>>> to your existing database). However, I would advise you to clone your >>>>>>>>> database and give it a try first (on a test system), before doing anything >>>>>>>>> in production. >>>>>>>>> >>>>>>>>> -Eric >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Hi all, >>>>>>>>>> >>>>>>>>>> Sorry about that, but I'm concern to upgrade my apiman to a >>>>>>>>>> newest. >>>>>>>>>> I read about upgrating the application: >>>>>>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>>>>>> ng_to_a_new_apiman_version >>>>>>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must >>>>>>>>>> needed to export and reimport all data from different versions. >>>>>>>>>> >>>>>>>>>> Could I just change server and application without change >>>>>>>>>> anything in my database? just put the new wildfly running the apiman >>>>>>>>>> instance. Would be possible to do that? >>>>>>>>>> >>>>>>>>>> PS.: My APIMan is running with a remote database and remote >>>>>>>>>> Keycloak. >>>>>>>>>> >>>>>>>>>> Best Regards, >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> --- >>>>>>>>>> *Celso Agra* >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --- >>>>>>> *Celso Agra* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --- >>>>>> *Celso Agra* >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> *Celso Agra* >>>>> >>>> >>>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> > > > -- > --- > *Celso Agra* > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170602/59602143/attachment-0001.html From eric.wittmann at redhat.com Sat Jun 3 09:22:28 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Sat, 3 Jun 2017 09:22:28 -0400 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: You should probably be safe copying the entire data directory...I think. :) On Fri, Jun 2, 2017 at 5:06 PM, Celso Agra wrote: > I think I found it! > > ./standalone/data# ls -l >> > apiman > > bootstrap > > content > > es > > kernel > > keycloak.h2.db > > keycloak.lock.db > > keycloak.trace.db > > keycloak.trace.db.old > > timer-service-data > > tx-object-store > > > Could I just copy the whole "data" folder? > > I'll take a look in the production guide. > > Thanks again! > > > 2017-06-02 17:59 GMT-03:00 Celso Agra : > >> I knew it! hehehe >> >> I'll try again later. >> >> Thanks!! >> >> 2017-06-02 17:48 GMT-03:00 Eric Wittmann : >> >>> You *almost* did the right thing. :) You were correct to create a new >>> instance of the whole system, just pointing it to your KC and database. >>> However you must *also* point it to your Gateway storage, which by default >>> is Elasticsearch (embedded in the quickstart). >>> >>> Note that you really shouldn't use the embedded Elasticsearch instance >>> for production (there is more info in the Production guide on the apiman >>> site). It's really intended as a quick Getting Started approach. >>> >>> Anyway, the Gateway has its own separate persistence store which you'll >>> need to copy to your 1.3.0 setup. You should be able to find the data >>> files in Wildfly somewhere (standalone/data/apiman iirc). >>> >>> -Eric >>> >>> >>> On Fri, Jun 2, 2017 at 4:06 PM, Celso Agra wrote: >>> >>>> Here is both files! >>>> >>>> Actually, I believe I did something wrong. I just create a new instance >>>> of APIMan just pointing to my keycloak and database. >>>> So, it was a new instance of whole system, such as Wildfly, Apiman-es, >>>> Apiman, etc... >>>> >>>> >>>> 2017-06-02 16:53 GMT-03:00 Eric Wittmann : >>>> >>>>> It sounds like your configuration is different between 1.2.8 and >>>>> 1.3.0. Can you post the apiman.properties files from each? >>>>> >>>>> On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra >>>>> wrote: >>>>> >>>>>> Also, when I try to access some API with an APIKey, i got this error >>>>>> >>>>>> {"responseCode":500,"message":"No client found for API Key >>>>>> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman.gat >>>>>> eway.engine.beans.exceptions.InvalidContractException: No client >>>>>> found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat >>>>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat >>>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContr >>>>>> act(SecureRegistryWrapper.java:154)\n\tat >>>>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute >>>>>> (ApiRequestExecutorImpl.java:361)\n\tat >>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat >>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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.ServletSecurityRoleHan >>>>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >>>>>> eRequest(ServletDispatchingHandler.java:36)\n\tat >>>>>> org.wildfly.extension.undertow.security.SecurityContextAssoc >>>>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociat >>>>>> ionHandler.handleRequest(SSLInformationAssociationHandler.ja >>>>>> va:131)\n\tat >>>>>> >>>>>> 2017-06-02 11:32 GMT-03:00 Celso Agra : >>>>>> >>>>>>> Here is the error when I try to register some changes in my ClientApp >>>>>>> >>>>>>> >>>>>>> io.apiman.manager.api.rest.contract.exceptions.ActionException: >>>>>>> Failed to register client. >>>>>>> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >>>>>>> Exception(ExceptionFactory.java:331) >>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >>>>>>> lient(ActionResourceImpl.java:427) >>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >>>>>>> tion(ActionResourceImpl.java:111) >>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >>>>>>> _WeldClientProxy.performAction(Unknown Source) >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>>> ssorImpl.java:62) >>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>>> thodAccessorImpl.java:43) >>>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>>> ctorImpl.java:139) >>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>>> (ResourceMethodInvoker.java:295) >>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>> eMethodInvoker.java:249) >>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>> eMethodInvoker.java:236) >>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>> nousDispatcher.java:402) >>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>> nousDispatcher.java:209) >>>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>> her.service(HttpServletDispatcher.java:56) >>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>> her.service(HttpServletDispatcher.java:51) >>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>> ... >>>>>>> Caused by: io.apiman.gateway.engine.beans >>>>>>> .exceptions.RegistrationException: API api-servico-dev not found in >>>>>>> Organization homolog. >>>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >>>>>>> gistry.java:159) >>>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >>>>>>> stry.java:139) >>>>>>> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >>>>>>> stry.java:108) >>>>>>> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >>>>>>> ient(PollCachingESRegistry.java:114) >>>>>>> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >>>>>>> Client(SecureRegistryWrapper.java:81) >>>>>>> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >>>>>>> ClientResourceImpl.java:54) >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>>> ssorImpl.java:62) >>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>>> thodAccessorImpl.java:43) >>>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>>> ctorImpl.java:139) >>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>>> (ResourceMethodInvoker.java:295) >>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>> eMethodInvoker.java:249) >>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>> eMethodInvoker.java:236) >>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>> nousDispatcher.java:402) >>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>> nousDispatcher.java:209) >>>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>> her.service(HttpServletDispatcher.java:56) >>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>> her.service(HttpServletDispatcher.java:51) >>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>> ... >>>>>>> >>>>>>> 2017-06-02 11:30 GMT-03:00 Celso Agra : >>>>>>> >>>>>>>> Thanks Marc and Eric! >>>>>>>> >>>>>>>> The application works fine, but for some reason, I can't delete any >>>>>>>> API. Looks like there is no reference for them. >>>>>>>> >>>>>>>> Is there some elasticsearch node in the Apiman? >>>>>>>> >>>>>>>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>>>>>>> >>>>>>>>> +1. That's my expectation, also. >>>>>>>>> >>>>>>>>> On 1 June 2017 at 13:03, Eric Wittmann >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I do not believe that there were any database changes between >>>>>>>>>> 1.2.8 and 1.30. So I *think* you should be OK if you just upgrade the >>>>>>>>>> application and skip the export/import process (just point the new version >>>>>>>>>> to your existing database). However, I would advise you to clone your >>>>>>>>>> database and give it a try first (on a test system), before doing anything >>>>>>>>>> in production. >>>>>>>>>> >>>>>>>>>> -Eric >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Sorry about that, but I'm concern to upgrade my apiman to a >>>>>>>>>>> newest. >>>>>>>>>>> I read about upgrating the application: >>>>>>>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>>>>>>> ng_to_a_new_apiman_version >>>>>>>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must >>>>>>>>>>> needed to export and reimport all data from different versions. >>>>>>>>>>> >>>>>>>>>>> Could I just change server and application without change >>>>>>>>>>> anything in my database? just put the new wildfly running the apiman >>>>>>>>>>> instance. Would be possible to do that? >>>>>>>>>>> >>>>>>>>>>> PS.: My APIMan is running with a remote database and remote >>>>>>>>>>> Keycloak. >>>>>>>>>>> >>>>>>>>>>> Best Regards, >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> --- >>>>>>>>>>> *Celso Agra* >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> --- >>>>>>>> *Celso Agra* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --- >>>>>>> *Celso Agra* >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --- >>>>>> *Celso Agra* >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> --- >>>> *Celso Agra* >>>> >>> >>> >> >> >> -- >> --- >> *Celso Agra* >> > > > > -- > --- > *Celso Agra* > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170603/2e845abd/attachment-0001.html From celso.agra at gmail.com Sat Jun 3 09:47:15 2017 From: celso.agra at gmail.com (Celso Agra) Date: Sat, 3 Jun 2017 10:47:15 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: Thanks Eric! I'll try do to that. Best regards, Celso Agra 2017-06-03 10:22 GMT-03:00 Eric Wittmann : > You should probably be safe copying the entire data directory...I think. :) > > On Fri, Jun 2, 2017 at 5:06 PM, Celso Agra wrote: > >> I think I found it! >> >> ./standalone/data# ls -l >>> >> apiman >> >> bootstrap >> >> content >> >> es >> >> kernel >> >> keycloak.h2.db >> >> keycloak.lock.db >> >> keycloak.trace.db >> >> keycloak.trace.db.old >> >> timer-service-data >> >> tx-object-store >> >> >> Could I just copy the whole "data" folder? >> >> I'll take a look in the production guide. >> >> Thanks again! >> >> >> 2017-06-02 17:59 GMT-03:00 Celso Agra : >> >>> I knew it! hehehe >>> >>> I'll try again later. >>> >>> Thanks!! >>> >>> 2017-06-02 17:48 GMT-03:00 Eric Wittmann : >>> >>>> You *almost* did the right thing. :) You were correct to create a new >>>> instance of the whole system, just pointing it to your KC and database. >>>> However you must *also* point it to your Gateway storage, which by default >>>> is Elasticsearch (embedded in the quickstart). >>>> >>>> Note that you really shouldn't use the embedded Elasticsearch instance >>>> for production (there is more info in the Production guide on the apiman >>>> site). It's really intended as a quick Getting Started approach. >>>> >>>> Anyway, the Gateway has its own separate persistence store which you'll >>>> need to copy to your 1.3.0 setup. You should be able to find the data >>>> files in Wildfly somewhere (standalone/data/apiman iirc). >>>> >>>> -Eric >>>> >>>> >>>> On Fri, Jun 2, 2017 at 4:06 PM, Celso Agra >>>> wrote: >>>> >>>>> Here is both files! >>>>> >>>>> Actually, I believe I did something wrong. I just create a new >>>>> instance of APIMan just pointing to my keycloak and database. >>>>> So, it was a new instance of whole system, such as Wildfly, Apiman-es, >>>>> Apiman, etc... >>>>> >>>>> >>>>> 2017-06-02 16:53 GMT-03:00 Eric Wittmann : >>>>> >>>>>> It sounds like your configuration is different between 1.2.8 and >>>>>> 1.3.0. Can you post the apiman.properties files from each? >>>>>> >>>>>> On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra >>>>>> wrote: >>>>>> >>>>>>> Also, when I try to access some API with an APIKey, i got this error >>>>>>> >>>>>>> {"responseCode":500,"message":"No client found for API Key >>>>>>> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman.gat >>>>>>> eway.engine.beans.exceptions.InvalidContractException: No client >>>>>>> found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat >>>>>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat >>>>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContr >>>>>>> act(SecureRegistryWrapper.java:154)\n\tat >>>>>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute >>>>>>> (ApiRequestExecutorImpl.java:361)\n\tat >>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat >>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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.ServletSecurityRoleHan >>>>>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >>>>>>> eRequest(ServletDispatchingHandler.java:36)\n\tat >>>>>>> org.wildfly.extension.undertow.security.SecurityContextAssoc >>>>>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociat >>>>>>> ionHandler.handleRequest(SSLInformationAssociationHandler.ja >>>>>>> va:131)\n\tat >>>>>>> >>>>>>> 2017-06-02 11:32 GMT-03:00 Celso Agra : >>>>>>> >>>>>>>> Here is the error when I try to register some changes in my >>>>>>>> ClientApp >>>>>>>> >>>>>>>> >>>>>>>> io.apiman.manager.api.rest.contract.exceptions.ActionException: >>>>>>>> Failed to register client. >>>>>>>> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >>>>>>>> Exception(ExceptionFactory.java:331) >>>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >>>>>>>> lient(ActionResourceImpl.java:427) >>>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >>>>>>>> tion(ActionResourceImpl.java:111) >>>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >>>>>>>> _WeldClientProxy.performAction(Unknown Source) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>>>> ssorImpl.java:62) >>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>>>> thodAccessorImpl.java:43) >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>>>> ctorImpl.java:139) >>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>>>> (ResourceMethodInvoker.java:295) >>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>> eMethodInvoker.java:249) >>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>> eMethodInvoker.java:236) >>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>> nousDispatcher.java:402) >>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>> nousDispatcher.java:209) >>>>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>> her.service(HttpServletDispatcher.java:56) >>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>> her.service(HttpServletDispatcher.java:51) >>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>> ... >>>>>>>> Caused by: io.apiman.gateway.engine.beans >>>>>>>> .exceptions.RegistrationException: API api-servico-dev not found >>>>>>>> in Organization homolog. >>>>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >>>>>>>> gistry.java:159) >>>>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >>>>>>>> stry.java:139) >>>>>>>> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >>>>>>>> stry.java:108) >>>>>>>> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >>>>>>>> ient(PollCachingESRegistry.java:114) >>>>>>>> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >>>>>>>> Client(SecureRegistryWrapper.java:81) >>>>>>>> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >>>>>>>> ClientResourceImpl.java:54) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>>>> ssorImpl.java:62) >>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>>>> thodAccessorImpl.java:43) >>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>>>> ctorImpl.java:139) >>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>>>> (ResourceMethodInvoker.java:295) >>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>> eMethodInvoker.java:249) >>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>> eMethodInvoker.java:236) >>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>> nousDispatcher.java:402) >>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>> nousDispatcher.java:209) >>>>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>> her.service(HttpServletDispatcher.java:56) >>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>> her.service(HttpServletDispatcher.java:51) >>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>> ... >>>>>>>> >>>>>>>> 2017-06-02 11:30 GMT-03:00 Celso Agra : >>>>>>>> >>>>>>>>> Thanks Marc and Eric! >>>>>>>>> >>>>>>>>> The application works fine, but for some reason, I can't delete >>>>>>>>> any API. Looks like there is no reference for them. >>>>>>>>> >>>>>>>>> Is there some elasticsearch node in the Apiman? >>>>>>>>> >>>>>>>>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>>>>>>>> >>>>>>>>>> +1. That's my expectation, also. >>>>>>>>>> >>>>>>>>>> On 1 June 2017 at 13:03, Eric Wittmann >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> I do not believe that there were any database changes between >>>>>>>>>>> 1.2.8 and 1.30. So I *think* you should be OK if you just upgrade the >>>>>>>>>>> application and skip the export/import process (just point the new version >>>>>>>>>>> to your existing database). However, I would advise you to clone your >>>>>>>>>>> database and give it a try first (on a test system), before doing anything >>>>>>>>>>> in production. >>>>>>>>>>> >>>>>>>>>>> -Eric >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra < >>>>>>>>>>> celso.agra at gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi all, >>>>>>>>>>>> >>>>>>>>>>>> Sorry about that, but I'm concern to upgrade my apiman to a >>>>>>>>>>>> newest. >>>>>>>>>>>> I read about upgrating the application: >>>>>>>>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>>>>>>>> ng_to_a_new_apiman_version >>>>>>>>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must >>>>>>>>>>>> needed to export and reimport all data from different versions. >>>>>>>>>>>> >>>>>>>>>>>> Could I just change server and application without change >>>>>>>>>>>> anything in my database? just put the new wildfly running the apiman >>>>>>>>>>>> instance. Would be possible to do that? >>>>>>>>>>>> >>>>>>>>>>>> PS.: My APIMan is running with a remote database and remote >>>>>>>>>>>> Keycloak. >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> --- >>>>>>>>>>>> *Celso Agra* >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> --- >>>>>>>>> *Celso Agra* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> --- >>>>>>>> *Celso Agra* >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> --- >>>>>>> *Celso Agra* >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> *Celso Agra* >>>>> >>>> >>>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> >> >> -- >> --- >> *Celso Agra* >> > > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170603/b2e88ca1/attachment-0001.html From celso.agra at gmail.com Mon Jun 5 08:18:51 2017 From: celso.agra at gmail.com (Celso Agra) Date: Mon, 5 Jun 2017 09:18:51 -0300 Subject: [Apiman-user] Would be possible to upgrade APIMan from 1.2.8 to 1.3.0? In-Reply-To: References: Message-ID: Looks like everything works perfect! This is awesome. I just copy the whole ./standalone/data folder to another version. Before to do that, I just compare the both folders to avoid overwrite something relevant. Thanks all!! 2017-06-03 10:47 GMT-03:00 Celso Agra : > Thanks Eric! I'll try do to that. > > Best regards, > > Celso Agra > > 2017-06-03 10:22 GMT-03:00 Eric Wittmann : > >> You should probably be safe copying the entire data directory...I think. >> :) >> >> On Fri, Jun 2, 2017 at 5:06 PM, Celso Agra wrote: >> >>> I think I found it! >>> >>> ./standalone/data# ls -l >>>> >>> apiman >>> >>> bootstrap >>> >>> content >>> >>> es >>> >>> kernel >>> >>> keycloak.h2.db >>> >>> keycloak.lock.db >>> >>> keycloak.trace.db >>> >>> keycloak.trace.db.old >>> >>> timer-service-data >>> >>> tx-object-store >>> >>> >>> Could I just copy the whole "data" folder? >>> >>> I'll take a look in the production guide. >>> >>> Thanks again! >>> >>> >>> 2017-06-02 17:59 GMT-03:00 Celso Agra : >>> >>>> I knew it! hehehe >>>> >>>> I'll try again later. >>>> >>>> Thanks!! >>>> >>>> 2017-06-02 17:48 GMT-03:00 Eric Wittmann : >>>> >>>>> You *almost* did the right thing. :) You were correct to create a >>>>> new instance of the whole system, just pointing it to your KC and >>>>> database. However you must *also* point it to your Gateway storage, which >>>>> by default is Elasticsearch (embedded in the quickstart). >>>>> >>>>> Note that you really shouldn't use the embedded Elasticsearch instance >>>>> for production (there is more info in the Production guide on the apiman >>>>> site). It's really intended as a quick Getting Started approach. >>>>> >>>>> Anyway, the Gateway has its own separate persistence store which >>>>> you'll need to copy to your 1.3.0 setup. You should be able to find the >>>>> data files in Wildfly somewhere (standalone/data/apiman iirc). >>>>> >>>>> -Eric >>>>> >>>>> >>>>> On Fri, Jun 2, 2017 at 4:06 PM, Celso Agra >>>>> wrote: >>>>> >>>>>> Here is both files! >>>>>> >>>>>> Actually, I believe I did something wrong. I just create a new >>>>>> instance of APIMan just pointing to my keycloak and database. >>>>>> So, it was a new instance of whole system, such as Wildfly, >>>>>> Apiman-es, Apiman, etc... >>>>>> >>>>>> >>>>>> 2017-06-02 16:53 GMT-03:00 Eric Wittmann : >>>>>> >>>>>>> It sounds like your configuration is different between 1.2.8 and >>>>>>> 1.3.0. Can you post the apiman.properties files from each? >>>>>>> >>>>>>> On Fri, Jun 2, 2017 at 10:40 AM, Celso Agra >>>>>>> wrote: >>>>>>> >>>>>>>> Also, when I try to access some API with an APIKey, i got this error >>>>>>>> >>>>>>>> {"responseCode":500,"message":"No client found for API Key >>>>>>>> xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","trace":"io.apiman.gat >>>>>>>> eway.engine.beans.exceptions.InvalidContractException: No client >>>>>>>> found for API Key xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\n\tat >>>>>>>> io.apiman.gateway.engine.es.CachingESRegistry.getContract(CachingESRegistry.java:78)\n\tat >>>>>>>> io.apiman.gateway.engine.impl.SecureRegistryWrapper.getContr >>>>>>>> act(SecureRegistryWrapper.java:154)\n\tat >>>>>>>> io.apiman.gateway.engine.impl.ApiRequestExecutorImpl.execute >>>>>>>> (ApiRequestExecutorImpl.java:361)\n\tat >>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.doAction(GatewayServlet.java:177)\n\tat >>>>>>>> io.apiman.gateway.platforms.servlet.GatewayServlet.service(GatewayServlet.java:78)\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.ServletSecurityRoleHan >>>>>>>> dler.handleRequest(ServletSecurityRoleHandler.java:62)\n\tat >>>>>>>> io.undertow.servlet.handlers.ServletDispatchingHandler.handl >>>>>>>> eRequest(ServletDispatchingHandler.java:36)\n\tat >>>>>>>> org.wildfly.extension.undertow.security.SecurityContextAssoc >>>>>>>> iationHandler.handleRequest(SecurityContextAssociationHandler.java:78)\n\tat >>>>>>>> io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)\n\tat >>>>>>>> io.undertow.servlet.handlers.security.SSLInformationAssociat >>>>>>>> ionHandler.handleRequest(SSLInformationAssociationHandler.ja >>>>>>>> va:131)\n\tat >>>>>>>> >>>>>>>> 2017-06-02 11:32 GMT-03:00 Celso Agra : >>>>>>>> >>>>>>>>> Here is the error when I try to register some changes in my >>>>>>>>> ClientApp >>>>>>>>> >>>>>>>>> >>>>>>>>> io.apiman.manager.api.rest.contract.exceptions.ActionException: >>>>>>>>> Failed to register client. >>>>>>>>> at io.apiman.manager.api.rest.impl.util.ExceptionFactory.action >>>>>>>>> Exception(ExceptionFactory.java:331) >>>>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.registerC >>>>>>>>> lient(ActionResourceImpl.java:427) >>>>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl.performAc >>>>>>>>> tion(ActionResourceImpl.java:111) >>>>>>>>> at io.apiman.manager.api.rest.impl.ActionResourceImpl$Proxy$_$$ >>>>>>>>> _WeldClientProxy.performAction(Unknown Source) >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>>>>> ssorImpl.java:62) >>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>>>>> thodAccessorImpl.java:43) >>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>>>>> ctorImpl.java:139) >>>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>>>>> (ResourceMethodInvoker.java:295) >>>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>>> eMethodInvoker.java:249) >>>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>>> eMethodInvoker.java:236) >>>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>>> nousDispatcher.java:402) >>>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>>> nousDispatcher.java:209) >>>>>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>>> her.service(HttpServletDispatcher.java:56) >>>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>>> her.service(HttpServletDispatcher.java:51) >>>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>>> ... >>>>>>>>> Caused by: io.apiman.gateway.engine.beans >>>>>>>>> .exceptions.RegistrationException: API api-servico-dev not found >>>>>>>>> in Organization homolog. >>>>>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateContract(ESRe >>>>>>>>> gistry.java:159) >>>>>>>>> at io.apiman.gateway.engine.es.ESRegistry.validateClient(ESRegi >>>>>>>>> stry.java:139) >>>>>>>>> at io.apiman.gateway.engine.es.ESRegistry.registerClient(ESRegi >>>>>>>>> stry.java:108) >>>>>>>>> at io.apiman.gateway.engine.es.PollCachingESRegistry.registerCl >>>>>>>>> ient(PollCachingESRegistry.java:114) >>>>>>>>> at io.apiman.gateway.engine.impl.SecureRegistryWrapper.register >>>>>>>>> Client(SecureRegistryWrapper.java:81) >>>>>>>>> at io.apiman.gateway.api.rest.impl.ClientResourceImpl.register( >>>>>>>>> ClientResourceImpl.java:54) >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce >>>>>>>>> ssorImpl.java:62) >>>>>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe >>>>>>>>> thodAccessorImpl.java:43) >>>>>>>>> at java.lang.reflect.Method.invoke(Method.java:498) >>>>>>>>> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInje >>>>>>>>> ctorImpl.java:139) >>>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget >>>>>>>>> (ResourceMethodInvoker.java:295) >>>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>>> eMethodInvoker.java:249) >>>>>>>>> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(Resourc >>>>>>>>> eMethodInvoker.java:236) >>>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>>> nousDispatcher.java:402) >>>>>>>>> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(Synchro >>>>>>>>> nousDispatcher.java:209) >>>>>>>>> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDi >>>>>>>>> spatcher.service(ServletContainerDispatcher.java:221) >>>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>>> her.service(HttpServletDispatcher.java:56) >>>>>>>>> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatc >>>>>>>>> her.service(HttpServletDispatcher.java:51) >>>>>>>>> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) >>>>>>>>> ... >>>>>>>>> >>>>>>>>> 2017-06-02 11:30 GMT-03:00 Celso Agra : >>>>>>>>> >>>>>>>>>> Thanks Marc and Eric! >>>>>>>>>> >>>>>>>>>> The application works fine, but for some reason, I can't delete >>>>>>>>>> any API. Looks like there is no reference for them. >>>>>>>>>> >>>>>>>>>> Is there some elasticsearch node in the Apiman? >>>>>>>>>> >>>>>>>>>> 2017-06-01 9:46 GMT-03:00 Marc Savy : >>>>>>>>>> >>>>>>>>>>> +1. That's my expectation, also. >>>>>>>>>>> >>>>>>>>>>> On 1 June 2017 at 13:03, Eric Wittmann >>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> I do not believe that there were any database changes between >>>>>>>>>>>> 1.2.8 and 1.30. So I *think* you should be OK if you just upgrade the >>>>>>>>>>>> application and skip the export/import process (just point the new version >>>>>>>>>>>> to your existing database). However, I would advise you to clone your >>>>>>>>>>>> database and give it a try first (on a test system), before doing anything >>>>>>>>>>>> in production. >>>>>>>>>>>> >>>>>>>>>>>> -Eric >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, May 31, 2017 at 4:45 PM, Celso Agra < >>>>>>>>>>>> celso.agra at gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi all, >>>>>>>>>>>>> >>>>>>>>>>>>> Sorry about that, but I'm concern to upgrade my apiman to a >>>>>>>>>>>>> newest. >>>>>>>>>>>>> I read about upgrating the application: >>>>>>>>>>>>> http://www.apiman.io/latest/installation-guide.html#_upgradi >>>>>>>>>>>>> ng_to_a_new_apiman_version >>>>>>>>>>>>> But I'd like to know if I upgrade from 1.2.8 to 1.3.0 is must >>>>>>>>>>>>> needed to export and reimport all data from different versions. >>>>>>>>>>>>> >>>>>>>>>>>>> Could I just change server and application without change >>>>>>>>>>>>> anything in my database? just put the new wildfly running the apiman >>>>>>>>>>>>> instance. Would be possible to do that? >>>>>>>>>>>>> >>>>>>>>>>>>> PS.: My APIMan is running with a remote database and remote >>>>>>>>>>>>> Keycloak. >>>>>>>>>>>>> >>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> --- >>>>>>>>>>>>> *Celso Agra* >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> --- >>>>>>>>>> *Celso Agra* >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> --- >>>>>>>>> *Celso Agra* >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> --- >>>>>>>> *Celso Agra* >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> --- >>>>>> *Celso Agra* >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> --- >>>> *Celso Agra* >>>> >>> >>> >>> >>> -- >>> --- >>> *Celso Agra* >>> >> >> > > > -- > --- > *Celso Agra* > -- --- *Celso Agra* -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170605/f676071e/attachment-0001.html From andyyar66 at gmail.com Tue Jun 6 02:37:52 2017 From: andyyar66 at gmail.com (Andy Yar) Date: Tue, 6 Jun 2017 08:37:52 +0200 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: I've enabled logging of org.hibernate.SQL. Now I can see inserts to the "pd_templates" in my server.log: https://hastebin.com/zovefusoyo.sql. These are triggered when browsing an OAuth policy. The "policydefs" table seems to be OK - only a single record for the Keycloak OAuth. On Fri, Jun 2, 2017 at 2:50 PM, Eric Wittmann wrote: > This is a very strange problem. I'll add some technical info to this > discussion in case it helps. > > The "pd_templates" table stores potentially multiple html templates for > displaying the *summary* of a configured instance of a policy. It can store > multiple templates by language - this is basically an i18n feature. In > practice, we only really have English language versions, so there should > only be one row in that table for each row in the "policydefs" table. The > "policydefs" table should have one row per policy definition (basically one > row for each item in the Policy Type drop-down when adding a new policy to > an API). > > The ORM class for the pd_templates table is here: > > https://github.com/apiman/apiman/blob/master/manager/api/beans/src/main/java/io/apiman/manager/api/beans/policies/PolicyDefinitionTemplateBean.java > > And the policy definition ORM bean is here: > > https://github.com/apiman/apiman/blob/master/manager/api/beans/src/main/java/io/apiman/manager/api/beans/policies/PolicyDefinitionBean.java > > This sounds like hibernate making a mess of things (or more likely my > mis-understanding of something hibernate is doing). It's one of the reasons > I'm on the fence about ORM technologies in general. They can be so helpful, > but if you wrote your own SQL statements you'd never have a weird issue like > this. > > In any case, at this point I have no theory about how this could be > happening. > > I assume your "policydefs" table is sensible. So the question is why > hibernate would be duplicating the data in "pd_templates", especially when > doing a simple GET of the information (shouldn't be mutating anything!). > > Could try enabling SQL logging in hibernate to see what's going on. > > But of course trying to replicate the problem locally is always the best > approach. :) > > -Eric > > > On Fri, Jun 2, 2017 at 7:49 AM, Marc Savy wrote: >> >> Hi Andy, >> >> Can you describe how your API, ClientApp & Plan is set up? >> >> e.g. >> >> API = [Keycloak OAuth2 Policy] >> Plan = [] >> ClientApp = [Header Policy] >> >> >> Regards, >> Marc >> >> On 2 June 2017 at 12:20, Andy Yar wrote: >> > Oh, sorry I missed version info. >> > >> > psql (PostgreSQL) 9.4.12 >> > JDBC connector - PostgreSQL 9.4.1212 >> > Apiman 1.2.9.Final >> > CentOS7 >> > Oracle Java 1.8.0_111 >> > >> > No export/import was done prior this issue. >> > >> > I can say I've been observed slower and slower responses during >> > operation with the Manager OAuth related pages. >> > >> > The trigger action seems to be a GET on a URL pattern like this: >> > apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/policies/1155 >> > >> > Resulting screen loads a policy config scheme from Keycloak OAuth >> > Plugin and displays it. It also generates N^2 new rows in >> > pd_templates. I've observed 16, 32, 64, 128 and then 256 added new >> > rows... >> > >> > Thanks >> > >> > >> > On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy wrote: >> >> Hi Andy, >> >> >> >> I spent time yesterday evening trying to replicate this after our chat >> >> on IRC, but I haven't been able to trigger it. Perhaps with more >> >> information we can narrow this down. >> >> >> >> Which version of Postgres are you using? Which driver version? >> >> >> >> I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final >> >> (should be same as 1.2.9.Final for this). >> >> >> >> Have you done any export-import? >> >> >> >> Have you observed the precise action that corresponds with the >> >> extraneous pd_templates entries being inserted? >> >> >> >> Regards, >> >> Marc >> >> >> >> On 2 June 2017 at 08:05, Andy Yar wrote: >> >>> >> >>> Hello, >> >>> Keycloak OAuth plugin's presence generates a certain amount of records >> >>> to pd_templates table on each action of Apiman Manager related to a >> >>> Keycloak OAuth policy (even read-only ones like listing a plan's >> >>> policies, etc.). >> >>> >> >>> Over time the number of records in pd_templates table can grow to >> >>> milions resulting in Apiman Manager OoM exceptions. Given these >> >>> records are basically just text hints it is really funny. >> >>> >> >>> A workaround is to periodically dedup the records. >> >>> >> >>> I guess this issue should be an easy fix. >> >>> >> >>> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak OAuth >> >>> plugin. >> >>> _______________________________________________ >> >>> 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 eric.wittmann at redhat.com Tue Jun 6 08:05:03 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 6 Jun 2017 08:05:03 -0400 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: Great thanks! Now we just need to figure out why the heck that would happen... Perhaps the ORM gods are angry. An offering will be required. Note: I wonder what would happen if we put a unique constraint on pd_templates (combination of id and lang columns). That could be a workaround until we found the root cause. -Eric On Tue, Jun 6, 2017 at 2:37 AM, Andy Yar wrote: > I've enabled logging of org.hibernate.SQL. Now I can see inserts to > the "pd_templates" in my server.log: > https://hastebin.com/zovefusoyo.sql. These are triggered when browsing > an OAuth policy. > > The "policydefs" table seems to be OK - only a single record for the > Keycloak OAuth. > > On Fri, Jun 2, 2017 at 2:50 PM, Eric Wittmann > wrote: > > This is a very strange problem. I'll add some technical info to this > > discussion in case it helps. > > > > The "pd_templates" table stores potentially multiple html templates for > > displaying the *summary* of a configured instance of a policy. It can > store > > multiple templates by language - this is basically an i18n feature. In > > practice, we only really have English language versions, so there should > > only be one row in that table for each row in the "policydefs" table. > The > > "policydefs" table should have one row per policy definition (basically > one > > row for each item in the Policy Type drop-down when adding a new policy > to > > an API). > > > > The ORM class for the pd_templates table is here: > > > > https://github.com/apiman/apiman/blob/master/manager/ > api/beans/src/main/java/io/apiman/manager/api/beans/policies/ > PolicyDefinitionTemplateBean.java > > > > And the policy definition ORM bean is here: > > > > https://github.com/apiman/apiman/blob/master/manager/ > api/beans/src/main/java/io/apiman/manager/api/beans/ > policies/PolicyDefinitionBean.java > > > > This sounds like hibernate making a mess of things (or more likely my > > mis-understanding of something hibernate is doing). It's one of the > reasons > > I'm on the fence about ORM technologies in general. They can be so > helpful, > > but if you wrote your own SQL statements you'd never have a weird issue > like > > this. > > > > In any case, at this point I have no theory about how this could be > > happening. > > > > I assume your "policydefs" table is sensible. So the question is why > > hibernate would be duplicating the data in "pd_templates", especially > when > > doing a simple GET of the information (shouldn't be mutating anything!). > > > > Could try enabling SQL logging in hibernate to see what's going on. > > > > But of course trying to replicate the problem locally is always the best > > approach. :) > > > > -Eric > > > > > > On Fri, Jun 2, 2017 at 7:49 AM, Marc Savy wrote: > >> > >> Hi Andy, > >> > >> Can you describe how your API, ClientApp & Plan is set up? > >> > >> e.g. > >> > >> API = [Keycloak OAuth2 Policy] > >> Plan = [] > >> ClientApp = [Header Policy] > >> > >> > >> Regards, > >> Marc > >> > >> On 2 June 2017 at 12:20, Andy Yar wrote: > >> > Oh, sorry I missed version info. > >> > > >> > psql (PostgreSQL) 9.4.12 > >> > JDBC connector - PostgreSQL 9.4.1212 > >> > Apiman 1.2.9.Final > >> > CentOS7 > >> > Oracle Java 1.8.0_111 > >> > > >> > No export/import was done prior this issue. > >> > > >> > I can say I've been observed slower and slower responses during > >> > operation with the Manager OAuth related pages. > >> > > >> > The trigger action seems to be a GET on a URL pattern like this: > >> > apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/policies/ > 1155 > >> > > >> > Resulting screen loads a policy config scheme from Keycloak OAuth > >> > Plugin and displays it. It also generates N^2 new rows in > >> > pd_templates. I've observed 16, 32, 64, 128 and then 256 added new > >> > rows... > >> > > >> > Thanks > >> > > >> > > >> > On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy > wrote: > >> >> Hi Andy, > >> >> > >> >> I spent time yesterday evening trying to replicate this after our > chat > >> >> on IRC, but I haven't been able to trigger it. Perhaps with more > >> >> information we can narrow this down. > >> >> > >> >> Which version of Postgres are you using? Which driver version? > >> >> > >> >> I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final > >> >> (should be same as 1.2.9.Final for this). > >> >> > >> >> Have you done any export-import? > >> >> > >> >> Have you observed the precise action that corresponds with the > >> >> extraneous pd_templates entries being inserted? > >> >> > >> >> Regards, > >> >> Marc > >> >> > >> >> On 2 June 2017 at 08:05, Andy Yar wrote: > >> >>> > >> >>> Hello, > >> >>> Keycloak OAuth plugin's presence generates a certain amount of > records > >> >>> to pd_templates table on each action of Apiman Manager related to a > >> >>> Keycloak OAuth policy (even read-only ones like listing a plan's > >> >>> policies, etc.). > >> >>> > >> >>> Over time the number of records in pd_templates table can grow to > >> >>> milions resulting in Apiman Manager OoM exceptions. Given these > >> >>> records are basically just text hints it is really funny. > >> >>> > >> >>> A workaround is to periodically dedup the records. > >> >>> > >> >>> I guess this issue should be an easy fix. > >> >>> > >> >>> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak > OAuth > >> >>> plugin. > >> >>> _______________________________________________ > >> >>> 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/20170606/c5c4fdd2/attachment.html From andyyar66 at gmail.com Tue Jun 6 08:18:33 2017 From: andyyar66 at gmail.com (Andy Yar) Date: Tue, 6 Jun 2017 14:18:33 +0200 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: To be honest, I was surprised there was no effective unique constraint. Thus allowing multiple lines being present. But yea, I'm no Hibernate/ORM expert by any means. On Tue, Jun 6, 2017 at 2:05 PM, Eric Wittmann wrote: > Great thanks! Now we just need to figure out why the heck that would > happen... > > Perhaps the ORM gods are angry. An offering will be required. > > Note: I wonder what would happen if we put a unique constraint on > pd_templates (combination of id and lang columns). That could be a > workaround until we found the root cause. > > -Eric > > On Tue, Jun 6, 2017 at 2:37 AM, Andy Yar wrote: >> >> I've enabled logging of org.hibernate.SQL. Now I can see inserts to >> the "pd_templates" in my server.log: >> https://hastebin.com/zovefusoyo.sql. These are triggered when browsing >> an OAuth policy. >> >> The "policydefs" table seems to be OK - only a single record for the >> Keycloak OAuth. >> >> On Fri, Jun 2, 2017 at 2:50 PM, Eric Wittmann >> wrote: >> > This is a very strange problem. I'll add some technical info to this >> > discussion in case it helps. >> > >> > The "pd_templates" table stores potentially multiple html templates for >> > displaying the *summary* of a configured instance of a policy. It can >> > store >> > multiple templates by language - this is basically an i18n feature. In >> > practice, we only really have English language versions, so there should >> > only be one row in that table for each row in the "policydefs" table. >> > The >> > "policydefs" table should have one row per policy definition (basically >> > one >> > row for each item in the Policy Type drop-down when adding a new policy >> > to >> > an API). >> > >> > The ORM class for the pd_templates table is here: >> > >> > >> > https://github.com/apiman/apiman/blob/master/manager/api/beans/src/main/java/io/apiman/manager/api/beans/policies/PolicyDefinitionTemplateBean.java >> > >> > And the policy definition ORM bean is here: >> > >> > >> > https://github.com/apiman/apiman/blob/master/manager/api/beans/src/main/java/io/apiman/manager/api/beans/policies/PolicyDefinitionBean.java >> > >> > This sounds like hibernate making a mess of things (or more likely my >> > mis-understanding of something hibernate is doing). It's one of the >> > reasons >> > I'm on the fence about ORM technologies in general. They can be so >> > helpful, >> > but if you wrote your own SQL statements you'd never have a weird issue >> > like >> > this. >> > >> > In any case, at this point I have no theory about how this could be >> > happening. >> > >> > I assume your "policydefs" table is sensible. So the question is why >> > hibernate would be duplicating the data in "pd_templates", especially >> > when >> > doing a simple GET of the information (shouldn't be mutating anything!). >> > >> > Could try enabling SQL logging in hibernate to see what's going on. >> > >> > But of course trying to replicate the problem locally is always the best >> > approach. :) >> > >> > -Eric >> > >> > >> > On Fri, Jun 2, 2017 at 7:49 AM, Marc Savy wrote: >> >> >> >> Hi Andy, >> >> >> >> Can you describe how your API, ClientApp & Plan is set up? >> >> >> >> e.g. >> >> >> >> API = [Keycloak OAuth2 Policy] >> >> Plan = [] >> >> ClientApp = [Header Policy] >> >> >> >> >> >> Regards, >> >> Marc >> >> >> >> On 2 June 2017 at 12:20, Andy Yar wrote: >> >> > Oh, sorry I missed version info. >> >> > >> >> > psql (PostgreSQL) 9.4.12 >> >> > JDBC connector - PostgreSQL 9.4.1212 >> >> > Apiman 1.2.9.Final >> >> > CentOS7 >> >> > Oracle Java 1.8.0_111 >> >> > >> >> > No export/import was done prior this issue. >> >> > >> >> > I can say I've been observed slower and slower responses during >> >> > operation with the Manager OAuth related pages. >> >> > >> >> > The trigger action seems to be a GET on a URL pattern like this: >> >> > >> >> > apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/policies/1155 >> >> > >> >> > Resulting screen loads a policy config scheme from Keycloak OAuth >> >> > Plugin and displays it. It also generates N^2 new rows in >> >> > pd_templates. I've observed 16, 32, 64, 128 and then 256 added new >> >> > rows... >> >> > >> >> > Thanks >> >> > >> >> > >> >> > On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy >> >> > wrote: >> >> >> Hi Andy, >> >> >> >> >> >> I spent time yesterday evening trying to replicate this after our >> >> >> chat >> >> >> on IRC, but I haven't been able to trigger it. Perhaps with more >> >> >> information we can narrow this down. >> >> >> >> >> >> Which version of Postgres are you using? Which driver version? >> >> >> >> >> >> I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final >> >> >> (should be same as 1.2.9.Final for this). >> >> >> >> >> >> Have you done any export-import? >> >> >> >> >> >> Have you observed the precise action that corresponds with the >> >> >> extraneous pd_templates entries being inserted? >> >> >> >> >> >> Regards, >> >> >> Marc >> >> >> >> >> >> On 2 June 2017 at 08:05, Andy Yar wrote: >> >> >>> >> >> >>> Hello, >> >> >>> Keycloak OAuth plugin's presence generates a certain amount of >> >> >>> records >> >> >>> to pd_templates table on each action of Apiman Manager related to a >> >> >>> Keycloak OAuth policy (even read-only ones like listing a plan's >> >> >>> policies, etc.). >> >> >>> >> >> >>> Over time the number of records in pd_templates table can grow to >> >> >>> milions resulting in Apiman Manager OoM exceptions. Given these >> >> >>> records are basically just text hints it is really funny. >> >> >>> >> >> >>> A workaround is to periodically dedup the records. >> >> >>> >> >> >>> I guess this issue should be an easy fix. >> >> >>> >> >> >>> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak >> >> >>> OAuth >> >> >>> plugin. >> >> >>> _______________________________________________ >> >> >>> 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 eric.wittmann at redhat.com Tue Jun 6 08:31:03 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 6 Jun 2017 08:31:03 -0400 Subject: [Apiman-user] Keycloak OAuth plugin persistence bug In-Reply-To: References: Message-ID: @msavy - After looking at the code a bit I have no idea why hibernate is doing this. :( I can't see anything in there that would be problematic based on my current level of understanding of hibernate. That said, the root of the issue is here: https://github.com/apiman/apiman/blob/master/manager/api/rest-impl/src/main/java/io/apiman/manager/api/rest/impl/OrganizationResourceImpl.java#L3446-L3451 Clearly no Tx is required to simply read data, so I presume the .beginTx() and .commitTx() calls are not required. Without that, no data would ever get written back to the DB (which in this case is what we want). Of course, that's only true of JPA and not necessarily every storage layer. I think perhaps we have two choices: 1) Remove the .beginTx() and .commitTx() calls for ALL read-only operations. This should work for both existing storage mechanisms now (JPA and ES[1]). 2) Add a flag to IStorage::beginTx() to indicate whether it should be read-only or not: public void beginTx(boolean readOnly) throws StorageException; For #2, the JPA implementation would simply *not* create a transaction if the readOnly flag was true. Lastly, we should probably *also* add a unique constraint to the pd_templates table. :) -Eric [1] - the Elasticsearch implementation ignores the Tx related calls because it does not support transactions On Tue, Jun 6, 2017 at 8:05 AM, Eric Wittmann wrote: > Great thanks! Now we just need to figure out why the heck that would > happen... > > Perhaps the ORM gods are angry. An offering will be required. > > Note: I wonder what would happen if we put a unique constraint on > pd_templates (combination of id and lang columns). That could be a > workaround until we found the root cause. > > -Eric > > On Tue, Jun 6, 2017 at 2:37 AM, Andy Yar wrote: > >> I've enabled logging of org.hibernate.SQL. Now I can see inserts to >> the "pd_templates" in my server.log: >> https://hastebin.com/zovefusoyo.sql. These are triggered when browsing >> an OAuth policy. >> >> The "policydefs" table seems to be OK - only a single record for the >> Keycloak OAuth. >> >> On Fri, Jun 2, 2017 at 2:50 PM, Eric Wittmann >> wrote: >> > This is a very strange problem. I'll add some technical info to this >> > discussion in case it helps. >> > >> > The "pd_templates" table stores potentially multiple html templates for >> > displaying the *summary* of a configured instance of a policy. It can >> store >> > multiple templates by language - this is basically an i18n feature. In >> > practice, we only really have English language versions, so there should >> > only be one row in that table for each row in the "policydefs" table. >> The >> > "policydefs" table should have one row per policy definition (basically >> one >> > row for each item in the Policy Type drop-down when adding a new policy >> to >> > an API). >> > >> > The ORM class for the pd_templates table is here: >> > >> > https://github.com/apiman/apiman/blob/master/manager/api/ >> beans/src/main/java/io/apiman/manager/api/beans/policies/Pol >> icyDefinitionTemplateBean.java >> > >> > And the policy definition ORM bean is here: >> > >> > https://github.com/apiman/apiman/blob/master/manager/api/ >> beans/src/main/java/io/apiman/manager/api/beans/policies/ >> PolicyDefinitionBean.java >> > >> > This sounds like hibernate making a mess of things (or more likely my >> > mis-understanding of something hibernate is doing). It's one of the >> reasons >> > I'm on the fence about ORM technologies in general. They can be so >> helpful, >> > but if you wrote your own SQL statements you'd never have a weird issue >> like >> > this. >> > >> > In any case, at this point I have no theory about how this could be >> > happening. >> > >> > I assume your "policydefs" table is sensible. So the question is why >> > hibernate would be duplicating the data in "pd_templates", especially >> when >> > doing a simple GET of the information (shouldn't be mutating anything!). >> > >> > Could try enabling SQL logging in hibernate to see what's going on. >> > >> > But of course trying to replicate the problem locally is always the best >> > approach. :) >> > >> > -Eric >> > >> > >> > On Fri, Jun 2, 2017 at 7:49 AM, Marc Savy wrote: >> >> >> >> Hi Andy, >> >> >> >> Can you describe how your API, ClientApp & Plan is set up? >> >> >> >> e.g. >> >> >> >> API = [Keycloak OAuth2 Policy] >> >> Plan = [] >> >> ClientApp = [Header Policy] >> >> >> >> >> >> Regards, >> >> Marc >> >> >> >> On 2 June 2017 at 12:20, Andy Yar wrote: >> >> > Oh, sorry I missed version info. >> >> > >> >> > psql (PostgreSQL) 9.4.12 >> >> > JDBC connector - PostgreSQL 9.4.1212 >> >> > Apiman 1.2.9.Final >> >> > CentOS7 >> >> > Oracle Java 1.8.0_111 >> >> > >> >> > No export/import was done prior this issue. >> >> > >> >> > I can say I've been observed slower and slower responses during >> >> > operation with the Manager OAuth related pages. >> >> > >> >> > The trigger action seems to be a GET on a URL pattern like this: >> >> > apimanui/api-manager/orgs/MyOrg/plans/MyOrgKeycloakOAuth/1/ >> policies/1155 >> >> > >> >> > Resulting screen loads a policy config scheme from Keycloak OAuth >> >> > Plugin and displays it. It also generates N^2 new rows in >> >> > pd_templates. I've observed 16, 32, 64, 128 and then 256 added new >> >> > rows... >> >> > >> >> > Thanks >> >> > >> >> > >> >> > On Fri, Jun 2, 2017 at 12:26 PM, Marc Savy >> wrote: >> >> >> Hi Andy, >> >> >> >> >> >> I spent time yesterday evening trying to replicate this after our >> chat >> >> >> on IRC, but I haven't been able to trigger it. Perhaps with more >> >> >> information we can narrow this down. >> >> >> >> >> >> Which version of Postgres are you using? Which driver version? >> >> >> >> >> >> I've been using: Postgres 9.6.2, Driver 42.1.1, apiman 1.3.0.Final >> >> >> (should be same as 1.2.9.Final for this). >> >> >> >> >> >> Have you done any export-import? >> >> >> >> >> >> Have you observed the precise action that corresponds with the >> >> >> extraneous pd_templates entries being inserted? >> >> >> >> >> >> Regards, >> >> >> Marc >> >> >> >> >> >> On 2 June 2017 at 08:05, Andy Yar wrote: >> >> >>> >> >> >>> Hello, >> >> >>> Keycloak OAuth plugin's presence generates a certain amount of >> records >> >> >>> to pd_templates table on each action of Apiman Manager related to a >> >> >>> Keycloak OAuth policy (even read-only ones like listing a plan's >> >> >>> policies, etc.). >> >> >>> >> >> >>> Over time the number of records in pd_templates table can grow to >> >> >>> milions resulting in Apiman Manager OoM exceptions. Given these >> >> >>> records are basically just text hints it is really funny. >> >> >>> >> >> >>> A workaround is to periodically dedup the records. >> >> >>> >> >> >>> I guess this issue should be an easy fix. >> >> >>> >> >> >>> Affected version is: Apiman 1.2.9.Final + corresponding Keycloak >> OAuth >> >> >>> plugin. >> >> >>> _______________________________________________ >> >> >>> 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/20170606/dd2f2726/attachment.html From scottpelliott at gmail.com Mon Jun 12 10:10:21 2017 From: scottpelliott at gmail.com (Scott Elliott) Date: Mon, 12 Jun 2017 14:10:21 +0000 Subject: [Apiman-user] Is there a distribution of apiman-plugins for each release? Message-ID: Is there a downloadable distribution of the apiman-plugins, or does it have to be compiled? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170612/86e04dc5/attachment.html From marc.savy at redhat.com Mon Jun 12 11:17:50 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 12 Jun 2017 16:17:50 +0100 Subject: [Apiman-user] Is there a distribution of apiman-plugins for each release? In-Reply-To: References: Message-ID: Hi, All of the plugins we make (or were contributed by the community) are on Maven Central. https://search.maven.org/#search%7Cga%7C1%7Cg%3A%22io.apiman.plugins%22 Regards, Marc On 12 June 2017 at 15:10, Scott Elliott wrote: > Is there a downloadable distribution of the apiman-plugins, or does it have > to be compiled? > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From eric.wittmann at redhat.com Mon Jun 12 11:27:16 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 12 Jun 2017 11:27:16 -0400 Subject: [Apiman-user] Is there a distribution of apiman-plugins for each release? In-Reply-To: References: Message-ID: All apiman plugins are built and deployed to maven central where they are downloaded (by apiman) when installed in the UI. If your production server cannot access the internet, you can download the full maven repository of apiman plugins here: https://repo.maven.apache.org/maven2/io/apiman/plugins/apiman-plugins-repository/ I think there is documentation about this somewhere... @msavy do you recall where documentation exists about setting up a custom local maven repository? -Eric On Mon, Jun 12, 2017 at 10:10 AM, Scott Elliott wrote: > Is there a downloadable distribution of the apiman-plugins, or does it > have to be compiled? > > _______________________________________________ > 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/20170612/fe9272a7/attachment-0001.html From marc.savy at redhat.com Mon Jun 12 12:42:19 2017 From: marc.savy at redhat.com (Marc Savy) Date: Mon, 12 Jun 2017 17:42:19 +0100 Subject: [Apiman-user] Is there a distribution of apiman-plugins for each release? In-Reply-To: References: Message-ID: > @msavy do you recall where documentation exists about setting up a custom local maven repository? http://www.apiman.io/blog/configuration/production/offline/2016/04/05/locked-down-network.html On 12 June 2017 at 16:27, Eric Wittmann wrote: > All apiman plugins are built and deployed to maven central where they are > downloaded (by apiman) when installed in the UI. If your production server > cannot access the internet, you can download the full maven repository of > apiman plugins here: > > https://repo.maven.apache.org/maven2/io/apiman/plugins/apiman-plugins-repository/ > > I think there is documentation about this somewhere... > > @msavy do you recall where documentation exists about setting up a custom > local maven repository? > > -Eric > > > > On Mon, Jun 12, 2017 at 10:10 AM, Scott Elliott > wrote: >> >> Is there a downloadable distribution of the apiman-plugins, or does it >> have to be compiled? >> >> _______________________________________________ >> 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 marc.savy at redhat.com Fri Jun 23 12:24:05 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 23 Jun 2017 17:24:05 +0100 Subject: [Apiman-user] Proposal to provide relevant HTTP codes for exceptions (not 500 for everything!) Message-ID: Hi, Up until now there has been an issue with certain exceptions being indistinguishable by HTTP code. For example: timeouts and connection issues; API not found, API not public; invalid accesses, etc, all return 500. A community member requested us to remedy that, and I'm proposing to do the following in this release: Not found-related (like API not found): 404 Invalid access (like trying to access an API directly that isn't public): 401 Unable to connect to backend API: 502 Connector timeouts: 504 Is this likely to be an issue to anyone such that I should delay its inclusion? Any other thoughts? Regards, Marc From marc.savy at redhat.com Sat Jun 24 05:47:18 2017 From: marc.savy at redhat.com (Marc Savy) Date: Sat, 24 Jun 2017 10:47:18 +0100 Subject: [Apiman-user] Proposal to provide relevant HTTP codes for exceptions (not 500 for everything!) In-Reply-To: References: Message-ID: Off-list feedback for this seems to have been positive, so I've merged the changes. It's not set in stone, though, so continue to send any concerns. On 23 June 2017 at 17:24, Marc Savy wrote: > Hi, > > Up until now there has been an issue with certain exceptions being > indistinguishable by HTTP code. > > For example: timeouts and connection issues; API not found, API not > public; invalid accesses, etc, all return 500. > > A community member requested us to remedy that, and I'm proposing to > do the following in this release: > > Not found-related (like API not found): 404 > Invalid access (like trying to access an API directly that isn't public): 401 > Unable to connect to backend API: 502 > Connector timeouts: 504 > > Is this likely to be an issue to anyone such that I should delay its > inclusion? Any other thoughts? > > Regards, > Marc From marc.savy at redhat.com Tue Jun 27 15:03:46 2017 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 27 Jun 2017 20:03:46 +0100 Subject: [Apiman-user] 1.3.1.Final released! Message-ID: Hi All, I'm delighted to announce Apiman 1.3.1.Final is out, with a few notable new features and improvements [1]. ## 3scale-related functionality You can now use the Apiman Gateway with the 3scale Manager/UI as an alternative to the Apiman Manager/UI![2] Using an overlay file you can augment your 3scale APIs with apiman policies. There will hopefully be an opportunity for a more cohesive and deeper integration with 3scale in the near future. Your feedback and demand will drive this; I hope as many people try it out this functionality as possible! The new 3scale registry and plugin can perform all of the usual 3scale functions, such as auth, reporting, metrics, and rate-limiting; with the addition breadth of apiman's policies and pluggable functionality. The one exception is that 3scale OAuth is currently not implemented (apiman's OAuth plugins work as normal). I'll be providing some blogposts over the coming days to demonstrate the new features in a more digestible form, but the documentation is available already. Just download the Vert.x distro and follow the instructions: https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_headless_elasticsearch https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/registries-and-components/3scale_immutable.html Expect some tooling soon to make generating JSON configurations for headless and 3scale registries easier! ## Bug-fixes & Improvements A good number of bugs were squashed in this release. Please try it out and let us know if your issues persist (if you had any!). The HTTP codes returned in error cases have been improved, including connection issues (e.g. DNS, timeouts, etc). You should no longer get HTTP 500 for these, and the error messages should be more meaningful. Let us know if there still seem to be issues in this area. There were a few issues with TLS on the Vert.x gateway that have been improved (e.g. devmode was not working properly). In the near future we'll look to provide some sort of self-signed certificate generation so that TLS can be configured OOTB. As an added bonus, if you provide ALPN Boot, then HTTP/2 should just work[3]. ## You can help! Please try the new functionality and let us know how you find it. Your demand and feedback is extremely important to the future direction of this project. ## Next Expect another release very soon with more functionality, configurability and tooling. Some users have reported issues with the new GitBook documentation, so I'll be looking to improve this. Regards, Marc [1] The more eagle-eyed amongst you will no doubt have noticed that most of this was actually released a few days ago. [2] You will need 3scale SaaS or on-prem for this to work. [3] More in a blog soon. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170627/35a7ed40/attachment.html From kstam at redhat.com Tue Jun 27 19:11:16 2017 From: kstam at redhat.com (Kurt Stam) Date: Tue, 27 Jun 2017 19:11:16 -0400 Subject: [Apiman-user] [Apiman-dev] 1.3.1.Final released! In-Reply-To: References: Message-ID: Congrats! Sounds like a huge step forward. Is it time to upgrade apiman on fabric8? --Kurt On Tue, Jun 27, 2017 at 3:03 PM, Marc Savy wrote: > Hi All, > > I'm delighted to announce Apiman 1.3.1.Final is out, with a few notable > new features and improvements [1]. > > ## 3scale-related functionality > > You can now use the Apiman Gateway with the 3scale Manager/UI as an > alternative to the Apiman Manager/UI![2] > > Using an overlay file you can augment your 3scale APIs with apiman > policies. There will hopefully be an opportunity for a more cohesive and > deeper integration with 3scale in the near future. Your feedback and demand > will drive this; I hope as many people try it out this functionality as > possible! > > The new 3scale registry and plugin can perform all of the usual 3scale > functions, such as auth, reporting, metrics, and rate-limiting; with the > addition breadth of apiman's policies and pluggable functionality. The one > exception is that 3scale OAuth is currently not implemented (apiman's OAuth > plugins work as normal). > > I'll be providing some blogposts over the coming days to demonstrate the > new features in a more digestible form, but the documentation is available > already. Just download the Vert.x distro and follow the instructions: > > https://apiman.gitbooks.io/apiman-installation-guide/ > installation-guide/vertx/download.html#_headless_elasticsearch > > https://apiman.gitbooks.io/apiman-installation-guide/ > installation-guide/registries-and-components/3scale_immutable.html > > Expect some tooling soon to make generating JSON configurations for > headless and 3scale registries easier! > > ## Bug-fixes & Improvements > > A good number of bugs were squashed in this release. Please try it out and > let us know if your issues persist (if you had any!). > > The HTTP codes returned in error cases have been improved, including > connection issues (e.g. DNS, timeouts, etc). You should no longer get HTTP > 500 for these, and the error messages should be more meaningful. Let us > know if there still seem to be issues in this area. > > There were a few issues with TLS on the Vert.x gateway that have been > improved (e.g. devmode was not working properly). In the near future we'll > look to provide some sort of self-signed certificate generation so that TLS > can be configured OOTB. As an added bonus, if you provide ALPN Boot, then > HTTP/2 should just work[3]. > > ## You can help! > > Please try the new functionality and let us know how you find it. Your > demand and feedback is extremely important to the future direction of this > project. > > ## Next > > Expect another release very soon with more functionality, configurability > and tooling. > > Some users have reported issues with the new GitBook documentation, so > I'll be looking to improve this. > > Regards, > Marc > > [1] The more eagle-eyed amongst you will no doubt have noticed that most > of this was actually released a few days ago. > [2] You will need 3scale SaaS or on-prem for this to work. > [3] More in a blog soon. > > _______________________________________________ > Apiman-dev mailing list > Apiman-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-dev > > -- Kurt T. Stam twitter: @KurtStam google+: kurt.stam at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170627/dd5c6ed0/attachment.html From eric.wittmann at redhat.com Wed Jun 28 07:20:44 2017 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 28 Jun 2017 07:20:44 -0400 Subject: [Apiman-user] [Apiman-dev] 1.3.1.Final released! In-Reply-To: References: Message-ID: Great job on the release, Marc! On Tue, Jun 27, 2017 at 3:03 PM, Marc Savy wrote: > Hi All, > > I'm delighted to announce Apiman 1.3.1.Final is out, with a few notable > new features and improvements [1]. > > ## 3scale-related functionality > > You can now use the Apiman Gateway with the 3scale Manager/UI as an > alternative to the Apiman Manager/UI![2] > > Using an overlay file you can augment your 3scale APIs with apiman > policies. There will hopefully be an opportunity for a more cohesive and > deeper integration with 3scale in the near future. Your feedback and demand > will drive this; I hope as many people try it out this functionality as > possible! > > The new 3scale registry and plugin can perform all of the usual 3scale > functions, such as auth, reporting, metrics, and rate-limiting; with the > addition breadth of apiman's policies and pluggable functionality. The one > exception is that 3scale OAuth is currently not implemented (apiman's OAuth > plugins work as normal). > > I'll be providing some blogposts over the coming days to demonstrate the > new features in a more digestible form, but the documentation is available > already. Just download the Vert.x distro and follow the instructions: > > https://apiman.gitbooks.io/apiman-installation-guide/ > installation-guide/vertx/download.html#_headless_elasticsearch > > https://apiman.gitbooks.io/apiman-installation-guide/ > installation-guide/registries-and-components/3scale_immutable.html > > Expect some tooling soon to make generating JSON configurations for > headless and 3scale registries easier! > > ## Bug-fixes & Improvements > > A good number of bugs were squashed in this release. Please try it out and > let us know if your issues persist (if you had any!). > > The HTTP codes returned in error cases have been improved, including > connection issues (e.g. DNS, timeouts, etc). You should no longer get HTTP > 500 for these, and the error messages should be more meaningful. Let us > know if there still seem to be issues in this area. > > There were a few issues with TLS on the Vert.x gateway that have been > improved (e.g. devmode was not working properly). In the near future we'll > look to provide some sort of self-signed certificate generation so that TLS > can be configured OOTB. As an added bonus, if you provide ALPN Boot, then > HTTP/2 should just work[3]. > > ## You can help! > > Please try the new functionality and let us know how you find it. Your > demand and feedback is extremely important to the future direction of this > project. > > ## Next > > Expect another release very soon with more functionality, configurability > and tooling. > > Some users have reported issues with the new GitBook documentation, so > I'll be looking to improve this. > > Regards, > Marc > > [1] The more eagle-eyed amongst you will no doubt have noticed that most > of this was actually released a few days ago. > [2] You will need 3scale SaaS or on-prem for this to work. > [3] More in a blog soon. > > _______________________________________________ > Apiman-dev mailing list > Apiman-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170628/a091f69f/attachment-0001.html From ryordan at redhat.com Wed Jun 28 07:35:06 2017 From: ryordan at redhat.com (Rachel Yordan) Date: Wed, 28 Jun 2017 11:35:06 +0000 Subject: [Apiman-user] [Apiman-dev] 1.3.1.Final released! In-Reply-To: References: Message-ID: Congrats Marc! On Wed, Jun 28, 2017 at 7:26 AM Eric Wittmann wrote: > Great job on the release, Marc! > > On Tue, Jun 27, 2017 at 3:03 PM, Marc Savy wrote: > >> Hi All, >> >> I'm delighted to announce Apiman 1.3.1.Final is out, with a few notable >> new features and improvements [1]. >> >> ## 3scale-related functionality >> >> You can now use the Apiman Gateway with the 3scale Manager/UI as an >> alternative to the Apiman Manager/UI![2] >> >> Using an overlay file you can augment your 3scale APIs with apiman >> policies. There will hopefully be an opportunity for a more cohesive and >> deeper integration with 3scale in the near future. Your feedback and demand >> will drive this; I hope as many people try it out this functionality as >> possible! >> >> The new 3scale registry and plugin can perform all of the usual 3scale >> functions, such as auth, reporting, metrics, and rate-limiting; with the >> addition breadth of apiman's policies and pluggable functionality. The one >> exception is that 3scale OAuth is currently not implemented (apiman's OAuth >> plugins work as normal). >> >> I'll be providing some blogposts over the coming days to demonstrate the >> new features in a more digestible form, but the documentation is available >> already. Just download the Vert.x distro and follow the instructions: >> >> >> https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_headless_elasticsearch >> >> >> https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/registries-and-components/3scale_immutable.html >> >> Expect some tooling soon to make generating JSON configurations for >> headless and 3scale registries easier! >> >> ## Bug-fixes & Improvements >> >> A good number of bugs were squashed in this release. Please try it out >> and let us know if your issues persist (if you had any!). >> >> The HTTP codes returned in error cases have been improved, including >> connection issues (e.g. DNS, timeouts, etc). You should no longer get HTTP >> 500 for these, and the error messages should be more meaningful. Let us >> know if there still seem to be issues in this area. >> >> There were a few issues with TLS on the Vert.x gateway that have been >> improved (e.g. devmode was not working properly). In the near future we'll >> look to provide some sort of self-signed certificate generation so that TLS >> can be configured OOTB. As an added bonus, if you provide ALPN Boot, then >> HTTP/2 should just work[3]. >> >> ## You can help! >> >> Please try the new functionality and let us know how you find it. Your >> demand and feedback is extremely important to the future direction of this >> project. >> >> ## Next >> >> Expect another release very soon with more functionality, configurability >> and tooling. >> >> Some users have reported issues with the new GitBook documentation, so >> I'll be looking to improve this. >> >> Regards, >> Marc >> >> [1] The more eagle-eyed amongst you will no doubt have noticed that most >> of this was actually released a few days ago. >> [2] You will need 3scale SaaS or on-prem for this to work. >> [3] More in a blog soon. >> >> _______________________________________________ >> Apiman-dev mailing list >> Apiman-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-dev >> >> _______________________________________________ > Apiman-dev mailing list > Apiman-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-dev > -- Regards, *Rachel Yord?n* Senior Software Engineer Red Hat, Inc. | Middleware ryordan at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20170628/d8b1cff7/attachment.html From marc.savy at redhat.com Wed Jun 28 10:45:22 2017 From: marc.savy at redhat.com (Marc Savy) Date: Wed, 28 Jun 2017 15:45:22 +0100 Subject: [Apiman-user] 1.3.1.Final released! In-Reply-To: References: Message-ID: First link should have been: https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_3scale_immutable On 27 June 2017 at 20:03, Marc Savy wrote: > Hi All, > > I'm delighted to announce Apiman 1.3.1.Final is out, with a few notable new > features and improvements [1]. > > ## 3scale-related functionality > > You can now use the Apiman Gateway with the 3scale Manager/UI as an > alternative to the Apiman Manager/UI![2] > > Using an overlay file you can augment your 3scale APIs with apiman policies. > There will hopefully be an opportunity for a more cohesive and deeper > integration with 3scale in the near future. Your feedback and demand will > drive this; I hope as many people try it out this functionality as possible! > > The new 3scale registry and plugin can perform all of the usual 3scale > functions, such as auth, reporting, metrics, and rate-limiting; with the > addition breadth of apiman's policies and pluggable functionality. The one > exception is that 3scale OAuth is currently not implemented (apiman's OAuth > plugins work as normal). > > I'll be providing some blogposts over the coming days to demonstrate the new > features in a more digestible form, but the documentation is available > already. Just download the Vert.x distro and follow the instructions: > > https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_headless_elasticsearch > > https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/registries-and-components/3scale_immutable.html > > Expect some tooling soon to make generating JSON configurations for headless > and 3scale registries easier! > > ## Bug-fixes & Improvements > > A good number of bugs were squashed in this release. Please try it out and > let us know if your issues persist (if you had any!). > > The HTTP codes returned in error cases have been improved, including > connection issues (e.g. DNS, timeouts, etc). You should no longer get HTTP > 500 for these, and the error messages should be more meaningful. Let us know > if there still seem to be issues in this area. > > There were a few issues with TLS on the Vert.x gateway that have been > improved (e.g. devmode was not working properly). In the near future we'll > look to provide some sort of self-signed certificate generation so that TLS > can be configured OOTB. As an added bonus, if you provide ALPN Boot, then > HTTP/2 should just work[3]. > > ## You can help! > > Please try the new functionality and let us know how you find it. Your > demand and feedback is extremely important to the future direction of this > project. > > ## Next > > Expect another release very soon with more functionality, configurability > and tooling. > > Some users have reported issues with the new GitBook documentation, so I'll > be looking to improve this. > > Regards, > Marc > > [1] The more eagle-eyed amongst you will no doubt have noticed that most of > this was actually released a few days ago. > [2] You will need 3scale SaaS or on-prem for this to work. > [3] More in a blog soon. From marc.savy at redhat.com Thu Jun 29 06:58:17 2017 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 29 Jun 2017 11:58:17 +0100 Subject: [Apiman-user] [Apiman-dev] 1.3.1.Final released! In-Reply-To: References: Message-ID: No reason not to! I'd think the headless functionality introduced last version might be interesting for K8/F8? Either way, it should not present any compatibility issues that I can think of off the top of my head, so be sure to give it a go :-). On 28 June 2017 at 00:11, Kurt Stam wrote: > Congrats! Sounds like a huge step forward. Is it time to upgrade apiman on > fabric8? > --Kurt > > On Tue, Jun 27, 2017 at 3:03 PM, Marc Savy wrote: >> >> Hi All, >> >> I'm delighted to announce Apiman 1.3.1.Final is out, with a few notable >> new features and improvements [1]. >> >> ## 3scale-related functionality >> >> You can now use the Apiman Gateway with the 3scale Manager/UI as an >> alternative to the Apiman Manager/UI![2] >> >> Using an overlay file you can augment your 3scale APIs with apiman >> policies. There will hopefully be an opportunity for a more cohesive and >> deeper integration with 3scale in the near future. Your feedback and demand >> will drive this; I hope as many people try it out this functionality as >> possible! >> >> The new 3scale registry and plugin can perform all of the usual 3scale >> functions, such as auth, reporting, metrics, and rate-limiting; with the >> addition breadth of apiman's policies and pluggable functionality. The one >> exception is that 3scale OAuth is currently not implemented (apiman's OAuth >> plugins work as normal). >> >> I'll be providing some blogposts over the coming days to demonstrate the >> new features in a more digestible form, but the documentation is available >> already. Just download the Vert.x distro and follow the instructions: >> >> >> https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/vertx/download.html#_headless_elasticsearch >> >> >> https://apiman.gitbooks.io/apiman-installation-guide/installation-guide/registries-and-components/3scale_immutable.html >> >> Expect some tooling soon to make generating JSON configurations for >> headless and 3scale registries easier! >> >> ## Bug-fixes & Improvements >> >> A good number of bugs were squashed in this release. Please try it out and >> let us know if your issues persist (if you had any!). >> >> The HTTP codes returned in error cases have been improved, including >> connection issues (e.g. DNS, timeouts, etc). You should no longer get HTTP >> 500 for these, and the error messages should be more meaningful. Let us know >> if there still seem to be issues in this area. >> >> There were a few issues with TLS on the Vert.x gateway that have been >> improved (e.g. devmode was not working properly). In the near future we'll >> look to provide some sort of self-signed certificate generation so that TLS >> can be configured OOTB. As an added bonus, if you provide ALPN Boot, then >> HTTP/2 should just work[3]. >> >> ## You can help! >> >> Please try the new functionality and let us know how you find it. Your >> demand and feedback is extremely important to the future direction of this >> project. >> >> ## Next >> >> Expect another release very soon with more functionality, configurability >> and tooling. >> >> Some users have reported issues with the new GitBook documentation, so >> I'll be looking to improve this. >> >> Regards, >> Marc >> >> [1] The more eagle-eyed amongst you will no doubt have noticed that most >> of this was actually released a few days ago. >> [2] You will need 3scale SaaS or on-prem for this to work. >> [3] More in a blog soon. >> >> _______________________________________________ >> Apiman-dev mailing list >> Apiman-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-dev >> > > > > -- > Kurt T. Stam > > twitter: @KurtStam > google+: kurt.stam at gmail.com From marc.savy at redhat.com Thu Jun 29 10:57:57 2017 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 29 Jun 2017 15:57:57 +0100 Subject: [Apiman-user] Thinking of moving to SemVer Message-ID: I've been thinking of moving Apiman to the SemVer 2.x versioning scheme (http://semver.org/) to provide a more meaningful and consistent release number scheme. Does anyone foresee that being a problem or have any thoughts? Regards, Marc From kstam at redhat.com Thu Jun 29 13:41:59 2017 From: kstam at redhat.com (Kurt Stam) Date: Thu, 29 Jun 2017 13:41:59 -0400 Subject: [Apiman-user] [Apiman-dev] Thinking of moving to SemVer In-Reply-To: References: Message-ID: <9E98BA4B-1BE7-4061-AB5C-1FE24049C2FF@redhat.com> +1, I thought you already were.. > On Jun 29, 2017, at 10:57 AM, Marc Savy wrote: > > I've been thinking of moving Apiman to the SemVer 2.x versioning > scheme (http://semver.org/) to provide a more meaningful and > consistent release number scheme. > > Does anyone foresee that being a problem or have any thoughts? > > Regards, > Marc > _______________________________________________ > Apiman-dev mailing list > Apiman-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-dev From marc.savy at redhat.com Fri Jun 30 05:44:32 2017 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 30 Jun 2017 10:44:32 +0100 Subject: [Apiman-user] [Apiman-dev] Thinking of moving to SemVer In-Reply-To: <9E98BA4B-1BE7-4061-AB5C-1FE24049C2FF@redhat.com> References: <9E98BA4B-1BE7-4061-AB5C-1FE24049C2FF@redhat.com> Message-ID: Up until now our scheme had been to put (external/visible) breaking API changes as minor releases and new features as patch. In many ways we'd just be shifting to the left! On 29 June 2017 at 18:41, Kurt Stam wrote: > +1, I thought you already were.. > >> On Jun 29, 2017, at 10:57 AM, Marc Savy wrote: >> >> I've been thinking of moving Apiman to the SemVer 2.x versioning >> scheme (http://semver.org/) to provide a more meaningful and >> consistent release number scheme. >> >> Does anyone foresee that being a problem or have any thoughts? >> >> Regards, >> Marc >> _______________________________________________ >> Apiman-dev mailing list >> Apiman-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-dev >