db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6430) ClassNotFoundException when invoking a table function declared in another classloader
Date Fri, 13 Dec 2013 16:07:07 GMT

    [ https://issues.apache.org/jira/browse/DERBY-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847602#comment-13847602

Rick Hillegas commented on DERBY-6430:

Thanks for that additional information about your cloud-based app, Richard. That helps me
understand your problem better. What is the lifetime of a Derby database for your app? For
the length of a user session? For some period of time determined by the end-user? Do you expect
Derby databases to survive over network outages and JBoss crashes?

>> part B) I'm a little confused about your use of the term "persistent facts" . Are
you talking about state of Derby
>> across reboots ? If this is the case, I totally agree these functions would not be
"persistent" across reboots. That's
>> why I would call them "transient" functions, or something like that.

Yes, that's what I mean. Everything declared by the CREATE FUNCTION statement becomes part
of the persistent metadata for the function and Derby expects all of that information to survive

>> interpretation of how functions are resolved in classloaders. I'd be surprised if
how Classes were resolved from a
>> function definition was defined in the SQL standard. 

Yes, that's correct. The Standard is silent on the topic of class loading.

Can you help me understand why option (3) won't work for you? It seems to me that some layer
in your application understands what ProtectionDomains need to be wired into the class loader
which resolves function references. That is the layer which is responsible for cooking up
the CREATE FUNCTION statement in your proposal. Why can't that layer be responsible for creating
the connection URL used to connect to the Derby database?



> ClassNotFoundException when invoking a table function declared in another classloader
> -------------------------------------------------------------------------------------
>                 Key: DERBY-6430
>                 URL: https://issues.apache.org/jira/browse/DERBY-6430
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions:
>         Environment: jboss
>            Reporter: Richard Huddleston
>            Priority: Blocker
>              Labels: features
> we run a derby network server in jboss, and want to be able to allow deployed ears to
expose their functionality through derby VTI.  ears run in their own classloader seperate
from the common derby network server started in jboss. unfortunately there is no way to register
a function in derby and have it record the classloader which registered the function, and
which should be used resolve the function class.  the problem is that when we use ij to connect
to the jboss instance, or even another ear in the same jboss, to call the declared function,
derby says it can't resolve the function class.  that is because derby does not remember which
ear the function was declared in, and is only searching the "root" jboss class libs for the
function.  obviously, the only way to work around this is to NOT deploy our functions in ears,
but that breaks the "cloud" like system we have for deployment.  
> obviously, the classloaders would be wrong after a "reboot" of derby, the classloader
would no longer existing.  so to solve our bug with our current deployment model, i think
we need to be able to have a new sql call for derby to create a "transient function", a function
which does not last across reboots
> something like a modification to this call
> instead of
> CREATE FUNCTION externalEmployees
> ()
> ...
> we need something like this
> ()
> ...
> or
> ()
> ...

This message was sent by Atlassian JIRA

View raw message