We know that plugin developers often make use of the third-party libraries that we ship with Confluence -- things like the Apache Commons libraries, or joda-time. However, given the effort involved in upgrading, we don't always ship the most-recent versions of those 3rd party libraries. In fact, we usually take an "if it ain't broke" approach to upgrading, and only really upgrade it when we need the new functionality or fixes.
However, sometimes you, our hearty plugin developers, do need the latest version of some library to realize your insanely great plugin ideas. So, to that end, we've whipped up this little page for you to request our attention. Just tell know what libraries you'd like to see upgraded (and preferably why) and we'll do our best to work it in.
Thanks for your feedback.
4 Comment(s)
Why not load the plugins in their own classloaders so they have nothing but the essentials in their classpath? Then they can each load their own versions of 3rd party libraries.
By Bob Lee at January 3, 2007 10:32 AM
Bob: We already load plugins in their own classloader, and many plugins ship bundled with their own dependencies. However, it's slightly more convenient for plugin developers if we ship with at least reasonably up-to-date versions of common dependencies.
By Charles Miller at January 7, 2007 3:24 PM
Bob: As far as I know, this would also be hell on the permgen space used by the instance? If each classloader was completely 'parentless' then it would have to load everything (ie log4j) again because it's coming from a different JAR (from within your plugin, not WEB-INF/lib). Ergo, more permgen space used.
40-some plugins in Confluence, 64MB default permgen in the VM. Bad voodoo :)
By Mike Cannon-Brookes at January 7, 2007 3:48 PM
Good points. Logging definitely qualifies as an "essential." Otherwise, it would be pretty difficult for plugins to coordinate log output.
Just brainstorming here, but as for the memory usage, you could forgo hierarchical classloaders and share third party libraries when the versions match identically. Unfortunately, this means plugins would sometimes share static scopes and sometimes not.
Ideally, you could load up multiple instances of the same class meanwhile sharing as much as possible. For example, if two plugins depend on the same version of a non-shared library, you could load the bytecode once and then allocate two different instances of the classes, one set for each plugin. i.e., each plugin would have its own static scope. I wonder if the new modules JSR addresses this (it does address loading different versions of the same library).
By Bob Lee at January 7, 2007 5:11 PM