Re: [equinox-dev] Changes to DefaultClassLoader and EclipseClassLoader

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Thanks for the great input Martin.  I've
updated the ClasspathEntry class to added accessor methods for the BundleFile
and ProtectionDomain fields.  This should prevent you from having
to subclass the EclipseClasspathEntry class.

Thomas Watson

Martin Lippert <lippert@xxxxxxx> Sent by: equinox-dev-admin@xxxxxxxxxxx 04/14/2004 04:45 AM Please respond to equinox-dev

To:        equinox-dev@xxxxxxxxxxx         cc:                 Subject:        Re: [equinox-dev] Changes to DefaultClassLoader and EclipseClassLoader

Hi,

Sorry for the late reply to this thread...

> To allow for more flexiblity to FrameworkAdaptor
developers the
> DefaultClassLoader and EclipseClassLoader have been change.
>
> The changes allow for a FrameworkAdaptor to have more control over
the
> construction and use of ClasspathEntry objects.  A new protected
method
> was added to DefaultClassLoader:
>
> protected ClasspathEntry createClassPathEntry(BundleFile,
> ProtectionDomain)
>
> This allows Framework adaptors to extend DefaultClassLoader and to
provide
> their own implementation of ClasspathEntry class.  The defineClass
and
> findClassImpl have been changed to accept a ClasspathEntry instead
of a
> separate ProtectionDomain and BundleFile arguments.

This implementation works for my specialized adaptor
implementation. But
it also means some extra work for people subclassing EclipseClassLoader
to implement their own class loading.

The reason is that the bundlefile field of
DefaultClassLoader.ClasspathEntry is protected so that my subclass of
EclipseClassLoader cannot read the field from the bundlefile parameter
of the findClassImpl method. I have to create my own subclass of
EclipseClassLoader.EclipseClasspathEntry, override the
createClassPathEntry method and use an additioal accessor method of my
classpath entry innerclass to get access to the bundlefile to load the
bytecode.

This is of course possible, but makes things more
complicated. A pure
bundlefile object seems to be useless for subclasses. They need to
define their own subclass of ClasspathEntry to make use of it. What do
you think of that?

Best regards,
Martin





#### smime.p7s has been removed from
this note on April 14, 2004 by Thomas Watson

Attachment: smime.p7s
Description: Binary data