Le 14/09/2010 11:02, Thomas Mortagne a écrit :
Hi Roman,
Glad someone is looking at it :)
On Mon, Sep 13, 2010 at 21:41, Roman Muntyanu<[email protected]> wrote:
Hello Thomas,
The Extension thing sounds ambitious!
Sure but we really need that and anyway it's fun ;)
Several comments regarding class loading/unloading. As far as I know, there's no other way to lose a jar/class from the class loader then to lose the class-loader itself. In one of my projects, we had to provide ability to Upload/Re-upload different class implementations without the need to restart the server. We have developed a small plug-in manager based on java ability to load jars storing a hash-table [pluginName->classLoaderContext], if plug-in implementation needs to be updated, old record is thrown away and new one is placed instead. This might be potential cause of memory leaks, unless you do not reload classes too often and plug-in implementation is carefully checked (which is our case).
I hope this helps. Would gladly hear any news in case if my knowledge in this area is somewhat outdated :)
No I don't know a better solution than destroying the classloader and recreate it to unload a jar yet. I did not searched much for it very recently but i doubt this changed much technically. AFAIK OSGI "solution" is to have one classloader per package and if any package needs something from another package it has to do it through OSGI plumbing (at some point we will probably go to OSGI anyway but it was too much work to make everything work properly with it for a first thing). Now even when you are able to do perfect unload of a jar it's not always easy to make sure no component is using it anymore, everything has to be written very dynamically.
Not exactly true, OSGi provides 1 ClassLoader per bundle. A bundle being a special jar file (that can contains other jars) with OSGi metadata. In theses metadatas, you'll find (among other things) a list of imported packages (packages that will be used by classes in this bundle). As bundles can be loaded/unloaded at runtime, you have a dynamic environment. So "client" components have to be notified that a "resource" they've been using has disappeared. --Guillaume
At worst for a first version you will need to restart XWiki to fully unload a jar from classloader. It's not too critical for now since removing components from ComponentManager is very easy and that we usually access most of the features using components so it will be possible to uninstall something from user POV in most of the cases. At least there is no such issue with others extension types like xars.
Regards, Roman
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Mortagne Sent: Monday, September 13, 2010 8:51 PM To: XWiki Developers; XWiki Users Subject: [xwiki-devs] Extension Manager first working POC !
Hi xwikiers,
Since May and actively since end of August I'm working on a POC for the future (long awaited) Extension Manager. It's now in a state where you can play with it a bit !
So here is a quick advertisement.
You can find it on http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-extension/
What it does already: - display remote extension and its dependencies as a tree - install remote extension and its dependencies from repositories - framework support any kind of extension using ExtensionInstaller component interface but only jar installer is implemented right now - framework support any kind of repository using RepositoryFactory component interface but only maven is implemented right now - load installed application when XWiki starts
Critical features not yet supported: - miscellaneous rights protections in extension manager script service - uninstall/upgrade support: need to find a way to remove a jar from classloader. Note that you can remove an extension from local repository and restart. - xar installer: just need to provide a ExtensionInstaller implementation with role hint "xar" since this needs access to the whole model the first version will probably be implemented with old APIs (XWikiDocument, etc.) on xwiki-core side - install extension not coming from a repository: the current API is very repository centric but you can do it "by hand" by putting directly the extension jar file in the local repository. - real descriptors in local repository for installed extensions (to store in a repository independent way extension information as well as some local only metadas like the fact that an extension as been installed as a dependency of another etc.) - others on http://svn.xwiki.org/svnroot/xwiki/contrib/sandbox/xwiki-extension/README.tx...
I'm preparing some design documentation that will go on http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerProposal but i don't have much time right now so it will probably be tomorrow (GMT).
The current state is not final at all but it still introduce a lot of APIs and design, lets call it an over designed POC. It needs to be discussed in all it's aspects before having its experimental tag removed. The plan is to distribute it with XE coming with 2.5 whatever it's state (when it does not represent a risk for XE obviously) as an experimental playground with all the required warnings in the UI and promote it when we are happy with a first version.
Thanks, -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs