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 13:42:07 GMT

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

Rick Hillegas commented on DERBY-6430:
--------------------------------------

Hi Richard,

Right now Derby supports two approaches for faulting in class definitions for user-defined
routines, datatypes, and aggregates:

1) Via the class loader of the Derby engine (which in your situation would be the network
server's class loader)

2) Via a custom class loader built out of jar files stored in the database.

You are proposing another approach which involves class loaders specific to each routine,
datatype, and aggregate. I am skeptical about your proposal in its current form for the following
reasons:

A) The proposed language falls outside the SQL Standard. Compliance with the Standard is part
of Derby's charter.

B) The proposed language suggests that the binding to an alternative class loader is one of
the persistent facts about the routine, datatype, or aggregate. I would expect all of the
persistent facts to be honored after the database reboots.

Another approach might be

3) Via a class loader which is specific to the database. Maybe the database-specific ProtectionDomains
could be specified on the connection URL used to boot the database.

However, my gut feeling is that the root of your problem is that the network server is being
booted from the wrong class loader. The quickest solution would be to figure out how to get
the right class loader for the network server.

Hope this helps,
-Rick

> 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: 10.10.1.1
>         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
> CREATE FUNCTION USING_THIS_CLASSLOADER externalEmployees
> ()
> ...
> or
> CREATE TRANSIENT_FUNCTION externalEmployees
> ()
> ...



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

Mime
View raw message