Costin Manolache wrote:
Remy Maucherat wrote:
Costin Manolache wrote:
Both difference and similarity :-).
Eclipse ( osgi actually ) has a similar flat loader implementation, but with finer control over what is exported/imported and pretty strong versioning. In addition osgi supports permissions on importing packages.
The reloading of modules is a bit more complicated than in jboss ( where you just change the jar ).
>From tomcat point of view - the implementation should be very similar with jboss.
What I like is the standardized and simpler behavior of class loaders, with ability to reload and upgrade any module ( like jboss ).
This classloader looks like it does stuff :)
I recommend plugging it in as usual, with the Loader interface. Is that ok ?
It should be, plugging tomcat into anything is usually simple.
The current tomcat loading mechanism - with 2 hierarchies of class loaders and the delegation hacks, plus the very rigid isolation between webapps - is far from perfect.
Again, it's a matter of interpreting the servlet spec - they do have some clear requirements on class loading, but I can't find any place where they forbid using other standards. I know adding an optional OSGI manifest could be controversial - but the benefits will be quite big. It would mean you can finally have arbitrary multiple versions of the same package, or have fine control ( using java permissions ) over what packages can be imported in a webapp or plugin. And it would mean an unified model for both webapps and plugins ( connectors, etc ).
The other very interesting aspects of eclipse are the extension point and the ( extreme ) laziness in loading plugins.
I imagined something a bit like that (with plenty of "CLs" each containing a particular version of a JAR), but:
- I got a big headache, and I don't think I'm capable of not screwing it up :D (so I decided to keep the current CL, which kinda works)
- I would take me a lot of time, and it wouldn't be useful to my employer, so they wouldn't be too happy in the end
I'd be really curious to see how you implemented all that stuff :)
Rémy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
