Oh, right. That would explain why we don't see line numbers. Without
line numbers it's hard to speculate about what's gone wrong. I don't
have any theory about why a one line change to the engine jar file would
raise an NPE on the client-side. Can you attach derby.log to DERBY-6981?
Maybe there are some clues there.
On 4/29/19 12:37 PM, Oskar Z wrote:
Hi Rick,
I’m not running 10.15 actually. I’m running 10.14 with only 1 line
code change from defect:
DERBY-6981
<https://issues.apache.org/jira/browse/DERBY-6981>
"SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerException
XJ001.U"
Thanks,
Oskar
On Apr 29, 2019, at 3:14 PM, Rick Hillegas <rick.hille...@gmail.com
<mailto:rick.hille...@gmail.com>> wrote:
I don't see derbyshared.jar on the classpath. That new jar is
required for all 10.15 configurations.
On 4/29/19 11:29 AM, Oskar Z wrote:
Hi Rick,
I’m running a back ported fix from 10.15 in 10.14:
DERBY-6981
<https://issues.apache.org/jira/browse/DERBY-6981>
"SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerException
XJ001.U"
Classptah includes all the jars, derby.jar, derbynet.jar,
derbyclient.jar, derbyrun.jar, derbytools.jar
Thanks,
Oskar
On Apr 29, 2019, at 2:11 PM, Rick Hillegas <rick.hille...@gmail.com
<mailto:rick.hille...@gmail.com>> wrote:
That looks odd. I thought that line numbers would be included in
10.15 stack traces. It's dying while trying to open a connection.
What does your classpath look like?
On 4/29/19 9:05 AM, Oskar Z wrote:
Hi Rick,
As follow-up so we started running the ported fix for the
NullPointerException…. ("SQLSTATE: XJ001, SQLERRMC:
java.lang.NullPointerException XJ001.U”)/
And now seeing a similar but different NullPointerException;
Caused by:
ERROR XJ001: DERBY SQL error: ERRORCODE: 0, SQLSTATE: XJ001,
SQLERRMC: java.lang.NullPointerExceptionXJ001.U
at
org.apache.derby.client.am.ClientConnection.completeSqlca(Unknown
Source)
at
org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(Unknown
Source)
at
org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(Unknown
Source)
at
org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(Unknown
Source)
at
org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown
Source)
at
org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source)
at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
at
org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(Unknown
Source)
... 11 more
Any ideas here?
Thanks,
Oskar
On Apr 11, 2019, at 7:02 PM, Rick Hillegas
<rick.hille...@gmail.com <mailto:rick.hille...@gmail.com>> wrote:
On 4/11/19 7:36 AM, Oskar Z wrote:
By engine jar, you mean “derby.jar” itself, correct?
Yes, that's right.
On Apr 11, 2019, at 10:22 AM, Rick Hillegas
<rick.hille...@gmail.com <mailto:rick.hille...@gmail.com>> wrote:
Hi Oskar,
Glad to hear that. If you applied the fix, then it should be in
the engine jar. Have you taken it for a test-drive? That's the
real proof.
Cheers,
-Rick
On 4/11/19 7:04 AM, Oskar Z wrote:
Hi Rick,
Thanks for the information!
I was able to download and build, and add the fix. I was able
to generate the jars.
So this fix is part of derby.jar, correct?
Thanks,
Oskar
On Apr 5, 2019, at 9:43 AM, Rick Hillegas
<rick.hille...@gmail.com <mailto:rick.hille...@gmail.com>> wrote:
Hi Oskar,
Some responses inline...
On 4/4/19 4:47 PM, Oskar Zinger wrote:
Hi Rick,
Thanks for a quick reply. So I could potentially port the
fix to 10.14.2.0 release without any issues?
It's easy to do. See the instructions below.
I actually never compiled the sources of Derby, so not sure
how complicated it is.
What would happen if I simply recompiled 10.15.3.1 in Java 8?
It will fail immediately because the 10.15.1.3 build script
requires a compiler at level Java 9 or higher. The 10.15 code
makes use of features which are only available from Java 9
onward.
Your other option is to upgrade your installation to the
latest Open JDK version (https://jdk.java.net/11/) and then
upgrade to Derby 10.15.1.3.
Here are instructions for patching and building your own
10.14 release:
* Unpack the source code from the db-derby-10.14.2.0-src.zip
at http://db.apache.org/derby/releases/release-10.14.2.0.cgi
* Then follow the instructions at
https://svn.apache.org/repos/asf/db/derby/code/branches/10.14/BUILDING.html
Once you're confident that you can build the source, you
should apply the patch and re-build. The patch is patch1.diff
at https://issues.apache.org/jira/browse/DERBY-6981.
Excluding the regression test, it's a 1 line patch. You can
use the svn code-management tool to do this or you can do it
by hand. You will be updating the following file:
java/engine/org/apache/derby/impl/sql/execute/TableScanResultSet.java
You will add one line to the following stanza at line 625...
if (past2FutureTbl != null)
{
past2FutureTbl.close();
}
...so that it ends up looking like this:
if (past2FutureTbl != null)
{
past2FutureTbl.close();
past2FutureTbl = null;
}
Hope this helps,
-Rick
Thanks,
Oskar
Sent from my iPhone
On Apr 4, 2019, at 7:39 PM, Rick Hillegas
<rick.hille...@gmail.com <mailto:rick.hille...@gmail.com>>
wrote:
Hi Oskar,
The fix has not been ported to any earlier branches and
no-one has volunteered to manage a new release on those
older branches. You are correct that 10.15.1.3 requires
Java 9 or higher. The fix does not look complicated--it's
only one line, excluding the regression test. You could
patch your own workspace for your preferred older branch
and build your own jars with little risk.
Hope this helps,
-Rick
On 4/4/19 9:56 AM, Oskar Z wrote:
I’m looking to get the following Defect for Derby which is
available in 10.15.3.1
DERBY-6981
<https://issues.apache.org/jira/browse/DERBY-6981>
"SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerException
XJ001.U"
But it is available only in 10.15.3.1 and only run in Java 9.
Is it possible to get the same fix for Java 8? Is it a
hard requirement to run in Java 9?
We could also try and get the source, and re-compile with
Java 8, but not sure if there would be any issues.
Thanks,
Oskar
