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