I will try to construct a test case. Although I don't know how easy
that will be...
Further I noticed that the following first few lines in
ClassFactoryClassLoader.findClass() could be dropped:
try
{
return super.findClass(name);
}
catch (ClassNotFoundException ex)
{
cnfex = ex;
}
ClassFactoryClassLoader directly extends java.lang.ClassLoader which,
as documented, always throws a ClassNotFoundException in its
findClass() implementation.
--knut
On 7/21/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
That seems like it would work, since the CFCL and HiveMindClassPool
work together to add and search ClassLoaders as needed.
On 7/21/06, Knut Wannheden <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I've noticed that users on multiple occasions now have reported
> problems with the class loading in HiveMind. Usually I think the
> problem is that the thread context class loader isn't set up properly.
> And that's what HiveMind uses both to find hivemodule.xml descriptors
> (when the registry is constructed in the default manner) and also as
> the class loader for Javassist when creating and instrumenting classes
> (using the HiveMindClassPool).
>
> The class loader used for the module descriptor loading is fairly easy
> to change to something different, but the class loader used by
> Javassist is hard wired to the thread context class loader. Of course
> the user can manually set the thread context class loader to something
> different.
>
> One problem with the Javassist class loading in HiveMind that's come
> up a few times now is during the registry startup phase when the
> Startup service is instrumented with the writeReplace() method. An
> exception like the following will be thrown:
>
> org.apache.hivemind.ApplicationRuntimeException: Unable to add method
> java.lang.Object writeReplace() to class $Runnable_10b95a29c5e:
> [source error] no such class:
> org.apache.hivemind.internal.ser.ServiceSerializationHelper
>
> Javassist can't find the ServiceSerializationHelper class.
>
> I was wondering if we could solve this w/o having the user to set the
> thread context class loader. Right now Javassist will use a
> ClassFactoryClassLoader class loader which has the system class loader
> as it's parent and the thread context class loader as a class loader
> it will delegate to (a child class loader). Would it make sense to
> setup the ClassFactoryClassLoader with the class loader which loaded
> the HiveMind classes as its parent? I.e. add the following default
> constructor:
>
> public ClassFactoryClassLoader()
> {
> super(ClassFactoryClassLoader.class.getClassLoader());
> }
>
> Then at least Javassist shouldn't have problems with loading
> ServiceSerializationHelper.
>
> --knut
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
