#1592 closed task (fixed)
Unified installation procedure for plug-ins, extensions and more...
| Reported by: | Nicklas Nordborg | Owned by: | Nicklas Nordborg |
|---|---|---|---|
| Priority: | major | Milestone: | BASE 3.0 |
| Component: | core | Version: | |
| Keywords: | Cc: |
Description (last modified by )
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:
Change History (28)
comment:1 by , 14 years ago
| Description: | modified (diff) |
|---|
comment:2 by , 14 years ago
| Description: | modified (diff) |
|---|
comment:3 by , 14 years ago
comment:4 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
comment:5 by , 14 years ago
(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.).
comment:6 by , 14 years ago
(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);
comment:7 by , 14 years ago
| Description: | modified (diff) |
|---|
comment:8 by , 14 years ago
(In [5601]) References #1592: Unified installation procedure for plug-ins, extensions and more... References #1593: Extension system for the core API
Started to move the web client extensions into the core registry. So far the extensions are loaded at startup, but there is no support for adding more at runtime. The administrative interface is a bit of a mess right now, since a lot of the metadata that we used to get from the registration process is not yet available.
comment:9 by , 14 years ago
(In [5602]) References #1592: Unified installation procedure for plug-ins, extensions and more... References #1593: Extension system for the core API
Added fuctionality for metadata handling and status/error reporting. Everything is still only loaded at startup but now we can see most of the information in the admin interface.
comment:10 by , 14 years ago
(In [5603]) References #1592: Unified installation procedure for plug-ins, extensions and more... References #1593: Extension system for the core API
Added support for adding and removing extensions at runtime. There are still some minor issues to fix since it seems difficult to get the various processors to do exactly what is needed. There are also some issues when an updated version of an extension is installed over an old one.
Added a lot more statistics to both the manager and processors. It is now possible to get almost as much information as before.
comment:11 by , 14 years ago
comment:12 by , 14 years ago
(In [5610]) References #1592: Unified installation procedure for plug-ins, extensions and more...
Moved plug-in definitions into the extension definitions file. This means that we can get rid of the Plugin.getAbout() method since that information is now provided in the XML file instead. I have started to move the core plug-in definitions into the core-plugins.xml file (only a few so far).
The base-plugins.dtd was removed since it is no longer used. External plug-in packages that use base-plugins.xml must be updated to use the new format.
comment:13 by , 14 years ago
comment:14 by , 14 years ago
comment:15 by , 14 years ago
(In [5615]) References #1592: Unified installation procedure for plug-ins, extensions and more...
Added file processor for installing plug-ins as part of a scan for extensions. Trying to link information about plug-in into the tree with extensions information.
Added "disabled" property to plug-ins to make them behave more similar to extensions. There may still be synchronization issues with the in-memory information and the database information.
Changed the installation procedure somewhat to allow re-using the same code for installing plug-ins (eg. from initdb/updatedb, and scanning extensions). There are some bumps to fix yet.
comment:16 by , 14 years ago
(In [5616]) References #1592: Unified installation procedure for plug-ins, extensions and more...
Re-organized the installation procedure. The first step will now show scan for new/updated/deleted files and present a list of options for each one (eg. install/uninstall).
We keep track of each installed extension in the settings file which should be safer since no automatic installation is done any longer.
There may still be some error handling issues, and plug-in configuration are still not installed.
Re-organized the Administrate and Extensions menus in the web client. All plug-in/extensions installation is now done from Administrate -> Plug-ins & extensions -> Overview.
comment:17 by , 14 years ago
(In [5617]) References #1592: Unified installation procedure for plug-ins, extensions and more...
Added support for installing plug-in configurations. The file we are looking for has changed to META-INF/plugin-configurations.xml
Moved duplicates of the installation code to the PluginConfiguration class (from the Install class and PluginConfigurationImporter).
comment:18 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
All functions from the old extension system should now be working. I'll close this ticket for now and hope that no more major issues should appear.
comment:19 by , 14 years ago
(In [5637]) References #1592: Unified installation procedure for plug-ins, extensions and more...
Added missing 'PrintMapFlatFileImporter'.
comment:20 by , 13 years ago
comment:21 by , 13 years ago
comment:22 by , 13 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
I found an issue with the XJspCompiler when testing the example plug-ins and extensions. The compiler is still looking for extension JAR:s in the WEB-INF/extensions directory. It must be updated to use the plugins.dir folder as configured in BASE. It is not trivial since the Application class is not on the class path, but I think we can use reflection just as we do when getting the JarClassLoader instances.
comment:23 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
My current idea is to make things a bit more restrictive:
plugins.dirsetting must be specified inbase.config.WEB-INF/lib).WEB-INF/classesto allow class-path lookup.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_pathcolumn (maybe we should create a new column,jar_file, instead and remove the old column?).