[xmlblaster-devel] XML-CORBA mix - Classloader approach

[Marcel Ruff <ruff at swand.lake.de>]

Hi,

on the tomcat page
  http://jakarta.apache.org/tomcat/tomcat-4.0-doc/class-loader-howto.html

there is a nice overview about classloader issues.


Probably xmlBlaster should use a customized classloader hierarchy
as well to avoid jar conflicts.

Currently i know of following conflicts in xmlBlaster:

 - xml parser incompatibility
 - multiple CORBA implementations
 - java_cup conflict for JDBC-tinySQL and JacORB-idl


What about this classloader hierarchy:
======================================

      Bootstrap

          |

       System

          |

       Common

      /          \

 xmlBlasterCore   Shared

                /     \  \

          PluginX  PluginY PluginZ ...

Where "Plugin*" are all xmlBlaster plugins, like
security plugins, protocol plugins, persistence plugins
and other future plugin interfaces.

The xmlBlaster plugin loader diverges from the default Java 2 delegation 
model. When a request to load a plugin is processed, this class loader 
will look in the local repositories first, instead of delegating before 
looking. All other class loaders follow the usual delegation pattern
(looking for the class in the parent classloader first).
(Possibly xmlBlasterCore should look local first as well).

Specialized jar files (if needed) will reside in subdirectories of
   xmlBlaster/lib
representing the package part below org.xmlBlaster.
Example:

   xmlBlaster/lib/protocol/corba
                          /xmlrpc
                 /authentication/plugins/ldap
                                        /htpasswd
                 /persistence/xmldb/xindice/
   ...


Now we need:

- Comments on this.
- A volunteer having the time to code it.

best regards,

Marcel


--
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org