Daniel John Debrunner wrote:
Jeremy, I'm having trouble understanding this. The embedded engine requires classes for Java procedures to either be available through the thread context classloader, the class loader for Derby code, or through the database classpath using jars stored in the database.
Yes, it is the case where they are loaded through the TCCL that is an issue here.
I'm not sure what the network server would set the thread context classloader to that would change anything, and I'm not sure what you mean by 'this differs from embedded mode where classes may be located in the application'. What does 'located in the application' mean?
The network server does not set the TCCL so classes must be located in the same classloader as the engine code (or the database classpath but I have not tested that).
Is there some concrete example you have that is broken?
In Geronimo we use Derby as the system database, use a J2CA RAR file to define Resource that can be used to access; that RAR file binds the embedded driver to a DataSource and also starts a NetworkServer to allow access to database from clients.
To allow users to define other J2CA RARs that access the same engine, we needed to place the engine code in the appserver's classloader; if we don't, then the second RAR fails to open the database as access is being attempted from two different classloaders.
Unfortunately we do have a second RAR which includes some stored procedures and which defines a NetworkServer. This works fine for in-VM applications as they connect through the embedded driver which so the procedure classes are found using the TCCL. However, clients that access the server via this NetworkServer cannot see the procedure classes because they are not in the appserver's classloader. If the NetworkServer copied the TCCL from the RAR that started it onto its worker threads then the engine would be able to load those procedure classes.
I am thinking of addressing this by allowing a ClassLoader to be passed to the NetworkServer when it is created. This would then set as the TCCL for any worker threads it creates.
-- Jeremy
