db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Question about using URLClassLoader and Derby
Date Thu, 10 Nov 2005 12:05:37 GMT
Oyvind.Bakksjo@Sun.COM writes:

> David W. Van Couvering wrote:
>> Hi, Kathey.  At first glance it looks good to me.  I'm assuming
>> *all* classes your app needs are available to the from the URL you
>> specify, because you are not specifying a parent classloader when
>> you create it.
>
> Not specifying a parent classloader does not mean that there will not
> be one. When using this constructor, the parent classloader will be
> the default classloader at the invocation point, e.g. the same
> classloader that would be used if you wrote Class.forName() at that
> spot.
>
>>  Also, you'll need to make sure you give the class that runs this
>> code the permission to load classes (I'm not sure exactly how this
>> is done, I just know it's an issue).
>> But I am no classloader guru.  I am forwarding this to folks I know
>> within Sun who have done a *lot* of work within classloaders as part
>> of the app server effort.  I'll get back to you with any information
>> I get.
>> David
>> Kathey Marsden wrote:
>>
>>> My goal is:
>>> I want to use a specific version of Derby which I ship with my app and I
>>> don't  want to interfere with any other derby versions loaded  in the
>>> same JVM or have them interfere with me.   I am creating a new
>>> datasource in a separate URLClassLoader and using that for creating all
>>> my connections.  Are there other things I need to do to meet my
>>> goal?
>
> Your URLClassLoader will delegate loading to its parent before it
> tries to load anything itself. You need to be sure that your
> URLClassLoader's parents have no Derby system to load - if they do,
> the result is not what you want.
>
> If you cannot assume anything about what's in the parent classloaders'
> search path, you will need to create your own custom classloader which
> "cuts off" the delegation for classes whose names follow a certain
> pattern - for instance, start with "org.apache.derby." I have done
> this successfully in other projects.

Overloading the loadClass method like this is enough, isn't it?

// untested code follows
protected Class loadClass(String name, boolean resolve)
                   throws ClassNotFoundException {
    Class cl = findLoadedClass(name);
    // uncomment the next line to use parent classloader
    //if (cl == null) cl = getParent().loadClass(name);
    if (cl == null) cl = findClass(name);
    if (cl == null) throw new ClassNotFoundException();
    if (resolve) resolveClass(cl);
    return cl;
}

>>> I have a feeling it all must be more complex than it looks to me
>>> right now.
>
> Just a little. :)

-- 
Knut Anders


Mime
View raw message