Plugin constructor args via Jersey annotations disallowed by PluginValidator?

[jeremyjyang]

Jersey allows support of plugin constructor args which will be automatically supplied, such as:

public MyBardPlugin( @Context ServletConfig servletConfig, @Context ServletContext servletContext, @Context HttpServletRequest httpServletRequest, @Context HttpHeaders headers)

This provides an important functionality, so runtime configuration parameters (e.g. db access credentials) can be specified and modified via web.xml without recompiling and reinstalling the plugin.

However, this appears to be disallowed by gov.nih.ncgc.bard.tools.PluginValidator, as it tries to instantiate a new object with no args:

    IPlugin plugin = (IPlugin) klass.newInstance();

[jeremyjyang]

Another thing I should note: Despite not validating, the plugin can be deployed, and function, which I have tested today on a local plugin container webapp.

[rajarshi]

I've updated the plugin spec to require that an empty constructor be available - given that the validtor is not going to check for functional correctness, the fact that the plugin will not be properly initialized via the http context etc is probably not an issue.

If you're OK with this, please close this issue

[jeremyjyang]

It seems that requirement for an empty constructor was and is precisely the problem, because use of annotations means the constructor will be non-empty. So I did a fresh pull today and rebuild and test, and still get an InstantiationException. A separate issue, but related, is that the constructor-arg annotations didn't seem to work on the NCGC servlet container. Recall the new schema "badapple2" had to be hard coded, I think.

[rajarshi]

Can you provide a simple example for me to test

On a separate note, I've refactored the plugin package such that it is no longer in the main BARD API. There is a new repository at https://github.com/ncatsdpiprobedev/bardplugins. The key things to note are

1. Plugins are now WAR files and the source directories are laid out as such
2. Plugins will depend on bardplugin.jar which can be made from the main API. I've also included this dependency in each example plugin in the new repository
3. Plugin wars should be named as bardplugin_ROOTRESOURCENAME.war - this is currently necessary due to how I plan to get nginx to route requests to plugins appropriately. So in your case, the war file should be bardplugin_badapple.war since your root resource is badapple

I've updated the wiki page on plugins to take note of the new design. I'll be updating the validation tool to take into account these changes.

Let me know if you have any questions.

[rajarshi]

I just did a check on the example plugin and you can add an extra constructor that takes no arguments. This will allow the validator to instantiate the class. Take a look at https://github.com/ncatsdpiprobedev/bardplugins/blob/master/csls/src/gov/nih/ncgc/bardplugin/CSLS.java