[
https://issues.apache.org/jira/browse/DERBY-6430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13847072#comment-13847072
]
Richard Huddleston commented on DERBY-6430:
-------------------------------------------
just storing the class files in the DB does not help. we need to have a way for
derby to reference an already loaded class in a given EAR / j2ee running
webapp. there's no way to do that in a j2ee way that references EJBs in a
local "no-interface" view without having a thread do an initialcontext lookup
in the classloader of an existing EAR / j2ee app.
if we tried to do a lookup outside an EAR of a remote EJB, any objects that
cross the jboss EAR boundary between applications would pay the cost of
serialization. we're dealing with big data, and are not willing to pay that
price.
again, we need a way for derby to "lookup" already loaded classes in another
classloader.
> 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)
