14 Sep
2010
14 Sep
'10
11:38 a.m.
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<rmuntyan(a)softserveinc.com> wrote:
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
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.
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: devs-bounces(a)xwiki.org [mailto:devs-bounces@xwiki.org] 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.t…
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs