[clazz] Clazz Loader Factories

[Dmitri Plotnikov <dm...@apache.org>]

The new construct in [clazz], ClazzLoaderFactory is not necessarily an
intuitive addition.  For some people it may be an indication that [clazz] is
becoming too complex. I think I need to explain its purpose.

The considerations are as follows:

    1. Some ClazzLoaders are based on reflection, some are not.  This is why
ClazzLoader APIs are based on the class name.  We cannot use Class instead,
because some Clazzes are not associated with a Class.

    2. If we don't have a Class, we cannot perform reflection.  Therefore,
we need to obtain a Class by name.  Every time this happens we run into
problems.  We need a ClassLoader, but there is no easy way to find one.

    3. When the developers of the JDK encountered a similar problem, they
added a method that would give them the caller's class loader.  They made
the method native and private.  With that mechanism Sun's engineers make
methods like "Class.forName()" work properly.  I personally think we need to
lobby to get this mechanism opened to the general public, but for now we are
out of luck.

    4. Since we cannot make the determination automatically, we'll have to
create custom solutions for individual situations.

    5. It would be nice to build some generic class loader lookup, but I
personally do not believe that it is possible.  In some environments (app
servers, plug-ins to IDEs etc) there are many class loaders, they are
created dynamically, even for individual threads, and linked up into
intricate networks.  These different environments do it differently and will
have different caching needs.


So, in order to allow for such custom solutions, I have introduced a new
delegation mechanism.  It is based on a new interface, ClazzLoaderFactory.
It declares one method: createClazzLoader(classLoader).  The SPI provider
implements this interface and registers the implementation with Clazz using
a "model key".  The implementation may construct networks of ClazzLoaders,
some unique to the supplied class loader, some shared, e.g. for any shared
parent class loaders.  The client does not know anything about the
complexity of the clazz loader created by the SPI provider.  It obtains a
ClazzLoaderFactory by the model key, calls createClazzLoader, caches the
created ClazzLoader and uses it to acquire meta data as needed.  As "simple"
as that.

I could not come up with a simpler solution.  Does anybody have an better
idea?  Please let me know, I would love to reduce complexity in this area.

- Dmitri


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>