db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Question about using URLClassLoader and Derby
Date Wed, 09 Nov 2005 21:03:48 GMT
Hi Kathey,

The approach looks good. More comments below.

On Nov 9, 2005, at 9:14 AM, 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.

As I understand it, the only classes that need to be available via  
the special classloader are the Derby implementation classes and its  
dependencies. JDBC is a pretty good abstraction layer that uses pass- 
by-value semantics not pass-by-reference semantics, so as long as  
you're not using user classes inside your database you should be ok.

> 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).

You might consider providing a helper class as part of the Derby  
suite that does have the permission. I think it's RuntimePermission 
("createClassLoader") permission.

But you might need other permissions as well since you're playing  
with URLs; e.g., there are file permissions required to read the jar  
files referenced by the classpath string.

And you should of course call the privileged methods in a  
doPrivileged block to avoid the entire call stack from having to have  
the privilege.

Craig
> 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?  I have a feeling it all must be more complex than it looks  
>> to me right now.
>> Thanks
>> Kathey
>>    Below is some code showing what I have done in playing with  
>> this  so far.
>> Method to load derby in separate loader and create datasource:
>>             private static DataSource newDataSource(ClassLoader  
>> loader, String
>> databaseName) throws Exception
>>     {
>>         DataSource ds = (DataSource)
>> loader.loadClass 
>> ("org.apache.derby.jdbc.EmbeddedDataSource").newInstance();
>>         // setDatabaseName with reflection
>>         Class[] argType = {String.class};
>>         String[] args = new String[] {databaseName};
>>         Method sh = ds.getClass().getMethod("setDatabaseName",  
>> argType);
>>         sh.invoke(ds, args);
>>         return ds;
>>            }
>>     // Calling program ....
>>     .....
>>         URL[] urls =
>>                   new URL[]{new URL(derbyJarURLString)};
>>             System.out.println(urls[0].getFile());
>>             ClassLoader loader1 =new URLClassLoader(urls);
>>             DataSource ds = newDataSource 
>> (loader1,"mydb;create=true");
>>             ds.getConnection();
>>    ...
>>
>> <david.vancouvering.vcf>
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message