apiman: Vert.X Gateway - Error 500 "Policy not found" with custom pluginRepositories

On our deployment we pull Apiman plugins from our Nexus, as a Maven repository.

We ares already using this parameter in apiman.properties file for WildFly gateways :

apiman.plugins.repositories=https://<hostname>/nexus/repository/public/

=> It works. When an api whose using a plugin policy is call, plugin is downloaded and call successful.

We are tying to replace Wildfly gateways by Vert.X gateways. So, we are settings the same parameters in conf-es.json :

"plugin-registry": {
    "class": "io.apiman.gateway.platforms.vertx3.engine.VertxPluginRegistry",
    "config": {
      "pluginRepositories": ["https://<hostname>/nexus/repository/public/" ],
      "pluginsDir" : "/home/gwvertx/tmp/plugins"
    }
  },

=> Butin this case, each api call finish with the following error :

{"responseCode":500,"message":"Policy not found: plugin:io.apiman.plugins:apiman-plugins-jwt-policy:1.5.1.Final:war/io.apiman.plugins.jwt.JWTPolicy","trace":null}

How to reproduce :

  • Deploy a Vert.X gateway 1.3.1 Final.
  • Customise “pluginRepositories” parameter in json config, with a Nexus repository.
  • Publish an api using a policy provided by a plugin (ex: jwt).
  • Send a request to the api.
  • See the “Policy not found” error.

Possible origin :

  • VertxPluginRegistry class seem to not consider “pluginRepositories” parameter in his constructor.
  • The code hasn’t change since version 1.3.1. So, I think is always present.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 16 (16 by maintainers)

Commits related to this issue

Most upvoted comments

@EricWittmann,

The issue is fixed by PR #788.

It is deploy on our api management staging platform. It works !

+2
jhauray on Jan 27, 2020

@msavy ,

I find my mistake : The right class is “VertxConfigDrivenEngineFactory” and not “ConfigDrivenEngineFactory”.

Sorry for this.

Have a good weekend!

+1
jhauray on Dec 6, 2019

It was a long time ago I wrote this stuff, I can’t quite remember. I’ll have a look over the weekend if I can.

On Fri, 6 Dec 2019, 16:58 Jérémy HAURAY, notifications@github.com wrote:

@msavy https://github.com/msavy

To be able to easily test PluginRegistry instanciation with original class, but without loading a full engine, I write a short extend class :

public class TestConfigDrivenEngineFactory extends ConfigDrivenEngineFactory {

public TestConfigDrivenEngineFactory(IEngineConfig engineConfig) {
    super(engineConfig);
}

public IPluginRegistry createPluginRegistry(){ return super.createPluginRegistry(); }

}

The unit test :

@Testpublic void CustomizedPluginRegistry(){

    String jsonStr = "{\"plugin-registry\": {\n" +
    "    \"class\": \"io.apiman.gateway.platforms.vertx3.engine.VertxPluginRegistry\",\n" +
    "            \"config\": {\n" +
    "                 \"pluginRepositories\": [\"https://repo1.maven.org/maven2/\" ],\n" +
    "                 \"pluginsDir\" : \"/tmp/plugins\"\n" +
    "            }\n" +
    "    }\n" +
    "}";

    JsonObject jsonObject = new JsonObject(jsonStr);

    IEngineConfig config = new VertxEngineConfig(jsonObject);

    TestConfigDrivenEngineFactory ef = new TestConfigDrivenEngineFactory(config);

    IPluginRegistry pluginRegistry = ef.createPluginRegistry();

}

The error stack :

java.lang.RuntimeException: java.lang.InstantiationException: io.apiman.gateway.platforms.vertx3.engine.VertxPluginRegistry

at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:242) at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.doInstantiate(ConfigDrivenEngineFactory.java:221) at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.create(ConfigDrivenEngineFactory.java:181) at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.createPluginRegistry(ConfigDrivenEngineFactory.java:69) at io.apiman.gateway.platforms.vertx3.engine.TestConfigDrivenEngineFactory.createPluginRegistry(TestConfigDrivenEngineFactory.java:13) at io.apiman.gateway.platforms.vertx3.engine.VertxPluginRegistryTest.CustomizedPluginRegistry(VertxPluginRegistryTest.java:68) 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.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.junit.runner.JUnitCore.run(JUnitCore.java:160) at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68) at com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70) Caused by: java.lang.InstantiationException: io.apiman.gateway.platforms.vertx3.engine.VertxPluginRegistry at java.lang.Class.newInstance(Class.java:427) at io.apiman.gateway.engine.impl.ConfigDrivenEngineFactory.instantiate(ConfigDrivenEngineFactory.java:240) … 27 more Caused by: java.lang.NoSuchMethodException: io.apiman.gateway.platforms.vertx3.engine.VertxPluginRegistry.<init>() at java.lang.Class.getConstructor0(Class.java:3082) at java.lang.Class.newInstance(Class.java:412) … 28 more

And about adding a constructor, it’s not possible. In this context, we need Vertx object used by createHttpClient() : VertxPluginRegistry.java(L64) https://github.com/apiman/apiman/blob/f29772a1a2bd67f88a10eb724853c3dd6b996466/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/engine/VertxPluginRegistry.java#L64

I see two possible explanations : I didn’t find the right loading path or VertxPluginRegistry is not used.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/apiman/apiman/issues/732?email_source=notifications&email_token=AADHMWOLLLYAQQ5TJMBKRNLQXKAEDA5CNFSM4HNWMJBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGEWS3A#issuecomment-562653548, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADHMWLSUSVV6VAR4WSGRLDQXKAEDANCNFSM4HNWMJBA .

+1
msavy on Dec 6, 2019

Hi @EricWittmann !!

If you agree, I’m up to suggest a merge request.

Just one question : Do you know if it already exist some unit test for VertX plugins loading ?

+1
jhauray on Dec 2, 2019

@EricWittmann , I’ve find the problem in code.

VertxPluginRegistry constructor instanciate super class DefaultPluginRegistry, with this constructor :

DefaultPluginRegistry(File pluginsDir, Set<URI> pluginRepositories)

And set pluginRepositories with PluginUtils.getDefaultMavenRepositories(). But not with values from Map<> config (json conf file).

That’s why pluginRepositories parameter is not taked in account.

I see two ways to fix the problem :

  • limited impact : Calling DefaultPluginRegistry.getConfiguredPluginRepositories() in VertxPluginRegistry constructor, before calling DefaultPluginRegistry constructor DefaultPluginRegistry(File pluginsDir, Set<URI> pluginRepositories).
  • Larger impact : Directly calling DefaultPluginRegistry(Map<String, String> configMap) constructor in VertxPluginRegistry constructor. This solution fixe a other problem : conf-es.json PluginsDir parameter is not taken into account by Vert.X gateway.

Last point : The problem is still present in master branch.

+1
jhauray on Jun 17, 2019
Read more comments on GitHub
← apiman: Problems with keycloak oauth plugin and postgres database
fusio: Unable to get to /developer/documentation/api using nginx →