Unified installation procedure for plug-ins, extensions and more...

[Nicklas Nordborg]

The installation procedure is quite different for plug-ins, extensions and other external code. For example:

• Plug-ins can be installed anywhere, but it is recommended to place them in the folder specified by the 'plugins.dir' setting in the base.config file.
• Extensions must be installed in the WEB-INF/extensions folder.
• Some types of "plug-ins" eg. authentication and logging plug-ins are specified in the 'base.config' file but must be located in the WEB-INF/lib folder.
• File validator plug-ins (eg. cdf/cel files) are configured in the database and can be located anywhere but the recommended location is the 'plugins.dir' folder.

Needless to say, this is a headache for packages that need to utilize several types of plug-ins+extensions. For example, the Illumina package (​http://baseplugins.thep.lu.se/wiki/net.sf.basedb.illumina).

I think we need a different approach that is simpler for administrators. Eg. a single directory should be used for all types of plug-ins/extensions. BASE should be able to scan this directory and, using metadata inside the JAR, it should be possible to determine what it is. A single JAR file should of course be able to hold multiple types of plug-ins+extensions. Installation should be triggered from a single place in the web gui. It would also be nice if an initialization script could be executed directly. Using the Illumina package as an example I think steps 7-14 could be reduced to just one or two steps.

One big issue is to not break an existing BASE installation... I guess we'll have to think about that.

Related tickets:

• #1593: Extension system for the core API
• #1594: JarClassLoader support for JARs within JARs
• #1598: Use the extensions system for data file validators and metadata readers
• #1582: Extended support for external files

[Nicklas Nordborg]

My current idea is to make things a bit more restrictive:

• The plugins.dir setting must be specified in base.config.
• All plug-ins/extensions must be installed in this folder (except core plug-ins which are installed in WEB-INF/lib).
• With #1594 in place a single JAR file should be enough for most plug-ins/extensions.
• Configuration files are placed in WEB-INF/classes to allow class-path lookup.
• Metadata+installation information about the plug-in/extension is kept in XML files in the META-INF directory inside the JAR file. This can already be done, but the XML format is different for plug-ins vs. extensions and information has to be repeated if a package contains both. This should be fixed.
• Installation of plug-ins/extensions should be made from a single place in the web interface. The manual registration of a single plug-in should be removed and the plug-in installation wizard should be merged with the extensions installation wizard.

As far as I can tell this should not be too difficult to fix. When upgrading an existing server the admin must ensure that all plug-ins and extensions are located in the specified directory and move them if not. The upgrade script (#1591) should remove path information from from the PluginDefinitions.jar_path column (maybe we should create a new column, jar_file, instead and remove the old column?).

[Nicklas Nordborg]

(In [5595]) References #1592: Unified installation procedure for plug-ins, extensions and more...

Application will check that plugins.dir is set and exists at startup and exists with an error message otherwise.

Removed PluginDefinition.jarPath property and replaced with PluginDefinition.jarFile. No path information is allowed in this property. Update script must copy the filename only from jar_path column in PluginDefinitions to jar_file and then remove the jar_path column.

Removed JobAgentSettings.jarPath property since it no longer makes sense to override this property. The update script should remove the jar_path column from the JobAgentSettings table.

Removed/replaced several methods from the PluginDefinition class that allows overriding the JAR path to a plug-in. External applications or plug-ins no longer has to worry about the path, but they may need to be recompiled to use the new methods.

The DataFileType has not yet been fully fixed and may not work as expected. The idea is to replace the classname+jarpath properties with some kind of extension system (#1593) similar to external file support (#1582).

In the web gui, places that are handling JAR path information has been fixed. For job agents it has been removed completely since it is no longer needed. The auto-installation wizard is probably not working at the moment. The update script should remove references to the jarPath property in context information (list filters, sort order, etc.).

[Nicklas Nordborg]

(In [5596]) References #1592: Unified installation procedure for plug-ins, extensions and more...

When a new instance of a plug-in is created through the BASE core API using the PluginDefinition.newInstance(Class) and the given class wasn't loaded by the default classloader, we'll try to use the classloader of the given class first to try to avoid ClassCastExceptions later.

This means that the second statement below now has a chance to succeed even if the first fails.

• X x = (X)plugin.newInstance();
• X x = plugin.newInstance(X.class);