Remy Maucherat wrote:
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 :)
Well, I don't have a lot of free time, so reimplementing all this stuff is not a choice, and I don't want the headaches :-).
Eclipse, oscar, knopflerfish ( last 2 with BSD licence ) already implement the class loaders - and there osgi standard is available in many other implementations ( sun embedded web server, etc ).
Jboss and eclipse use the same class loading mechanism - and the same model for "plugins". It would be really nice if jboss will make one extra step and add the missing features from osgi ( fine control of export/import and use the version information to match the loader ), and
even better if they would do this using the standard osgi manifest.
I think the granularity of jboss integration is a bit high - what I'm trying is to have each "plugin"( connector, auth, etc) as well as each webapp in a separate bundle - so you can add/remove/upgrade plugins just like eclipse does, without restart and with on-demand loading. ( I haven't checked the last jboss tough - maybe it alreay does that :-)
Anyway - it's work in progress, I don't know all details - the basic stuff obviouslty works ( since it works in jobss as well ), I can load/unload tomcat and individual connectors from eclipse console without problems.
Costin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
