[
https://issues.apache.org/jira/browse/DERBY-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847516#comment-13847516
]
Richard Huddleston commented on DERBY-6430:
-------------------------------------------
Rick,
I'll investigate, but all these solutions feel too hackish for our cloud
deployment model to work.
In response to #1 and #3, we COULD run the network server in the classloader of
a specific ear, but that would only let us run 1 Derby network server in one
ear on our JBoss server, (on 1 port). What we need is to have n different ears
on our jboss instance be exposed through one network server. Thus, we need
derby to run at a "lower" classloader level in the j2ee stack than the ears.
the only place is in the jboss root libs.
In regards to #2,
part A) you are correct, I can't argue that point
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.
This just popped into my head,
Perhaps we could work around the SQL standard to allow "transient" functions to
only be declared on an in memory only schema / or i'm lacking on the term, but
a boot of derby to an in memory database. Any functions declared / registered
in an in memory database / schema can record their classloaders by just
maintaining a reference to the Thread context classloader, that way you don't
need to deviate the the SQL grammer, only your 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.
Our issue is, that we can boot up 1 network server with a memory only schema /
db, then multiple ears can register functions, they just don't resolve when
invoked. But perhaps it would be as simple as derby just grabbing the current
thread's context classloader when a function is declared and maintaining a
reference to that.
> 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)
