[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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