[jira] Created: (DERBY-502) Browser title for manuals in HTML format is a non-sense default value

[Kristian Waagan (JIRA)]

Browser title for manuals in HTML format is a non-sense default value
-

 Key: DERBY-502
 URL: http://issues.apache.org/jira/browse/DERBY-502
 Project: Derby
Type: Bug
  Components: Documentation  
Reporter: Kristian Waagan
Priority: Minor


The browser title for manuals in HTML format is not set to reflect the title of 
the manual itself. All manuals in HTML book format has title "XSL FO Document", 
while the HTML single manuals have title "Web Sample". Since the Derby 
documentation is separated into several manuals, this makes it hard to navigate 
when you have several/all manuals open in your browser.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-534) Support use of the WHEN clause in CREATE TRIGGER statements

[Kristian Waagan (JIRA)]

Support use of the WHEN clause in CREATE TRIGGER statements
---

 Key: DERBY-534
 URL: http://issues.apache.org/jira/browse/DERBY-534
 Project: Derby
Type: New Feature
  Components: SQL  
Reporter: Kristian Waagan
Priority: Minor


Support use of the WHEN clause in CREATE TRIGGER statements. The clause is 
described in the SQL standard (2003) in chapter "11.39 " 
under "".

There are traces in the code that suggests some work has been done on this 
earlier. If anyone knows something about this, please add a comment to this 
issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-746) NullPointerException when 'encryptionKey' length is an odd number, or it contains invalid chars

[Kristian Waagan (JIRA)]

NullPointerException when 'encryptionKey' length is an odd number, or it 
contains invalid chars
---

 Key: DERBY-746
 URL: http://issues.apache.org/jira/browse/DERBY-746
 Project: Derby
Type: Bug
  Components: Security  
Versions: 10.2.0.0, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2
 Environment: All environments.
Reporter: Kristian Waagan
Priority: Minor


When booting/creating an encrypted database, a NullPointerException is thrown 
if the length of the connection string attribute 'encryptionKey' is an odd 
number, or the encryption key contains invalid characters for hexadecimal 
numbers (char not in the set [0-9a-fA-F]).

The reason for the exception being thrown, is that the method 
'iapi.util.StringUtil.fromHexString(String, int, int)' returns null for the 
cases described above. The code calling the method in 
'JCECipherFactory.boot(boolean, Properties)' does not check that the return 
value is not null.

A related trivial issue is that 'fromHexString' does not allow the caller to 
see the distinction between a string with invalid length and a string 
containing invalid characters (both cases return null).

[To reproduce]
(connection string copied from test 'store/encryptionKey.sql' and then modified)
Supply the following connection string, for instance in ij:
connect 
'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656';
(deleted the last digit in the encryption key)
'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656X';
(replaced last digit with an X)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-746) NullPointerException when 'encryptionKey' length is an odd number, or it contains invalid chars

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-746?page=all ]

Kristian Waagan reassigned DERBY-746:
-

Assign To: Kristian Waagan

> NullPointerException when 'encryptionKey' length is an odd number, or it 
> contains invalid chars
> ---
>
>  Key: DERBY-746
>  URL: http://issues.apache.org/jira/browse/DERBY-746
>  Project: Derby
> Type: Bug
>   Components: Security
> Versions: 10.2.0.0, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2
>  Environment: All environments.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor

>
> When booting/creating an encrypted database, a NullPointerException is thrown 
> if the length of the connection string attribute 'encryptionKey' is an odd 
> number, or the encryption key contains invalid characters for hexadecimal 
> numbers (char not in the set [0-9a-fA-F]).
> The reason for the exception being thrown, is that the method 
> 'iapi.util.StringUtil.fromHexString(String, int, int)' returns null for the 
> cases described above. The code calling the method in 
> 'JCECipherFactory.boot(boolean, Properties)' does not check that the return 
> value is not null.
> A related trivial issue is that 'fromHexString' does not allow the caller to 
> see the distinction between a string with invalid length and a string 
> containing invalid characters (both cases return null).
> [To reproduce]
> (connection string copied from test 'store/encryptionKey.sql' and then 
> modified)
> Supply the following connection string, for instance in ij:
> connect 
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656';
> (deleted the last digit in the encryption key)
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656X';
> (replaced last digit with an X)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-753) References from table of contents in the HTML book manuals are invalid

[Kristian Waagan (JIRA)]

References from table of contents in the HTML book manuals are invalid
--

 Key: DERBY-753
 URL: http://issues.apache.org/jira/browse/DERBY-753
 Project: Derby
Type: Bug
  Components: Documentation  
Versions: 10.1.1.2, 10.1.2.1
 Environment: Tested in several different browsers and on different computers.
Reporter: Kristian Waagan


The references from the table of contents are invalid. They do not work because 
the wrong anchor/name is used, or that the tags defining the anchors are not 
included. 
Is something going wrong in the documentation build process?

To illustrate the point, try this:
> http://db.apache.org/derby/docs/dev/ref/ref-single.html#crefsqlj95081
The manual is shown, but you are not directed to the 'CREATE statements' 
chapter.
Then try this:
> http://db.apache.org/derby/docs/dev/ref/ref-single.html#N1223F
This works and direct you to the 'CREATE statements' chapter.




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

'store/encryptionKey.sql' fails on Solaris 10
-

 Key: DERBY-788
 URL: http://issues.apache.org/jira/browse/DERBY-788
 Project: Derby
Type: Bug
  Components: Services, Test  
Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
 Environment: Solaris 10 (generic hardware)
Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
Reporter: Kristian Waagan
 Assigned to: Kristian Waagan 
Priority: Minor
 Fix For: 10.2.0.0


The 'store/encryptionKey.sql' test fails on Solaris 10.
Investigation revealed that the failure is caused by a difference in behavior 
between the 'SunPCKS11-Solaris' provider and other providers (tested with 
'SunJCE' and 'IBMJCE').

The initialization of the DES cipher fails because the 16 byte key (specified 
in the test) is not translated to a 8 byte DES key by 
SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
know the spec). Enquiries are being made.

The exception is being thrown from the constructor of 
'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-746) NullPointerException when 'encryptionKey' length is an odd number, or it contains invalid chars

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-746?page=all ]

Kristian Waagan updated DERBY-746:
--

Attachment: derby-746.diff
derby-746.stat

Stat and diff for the patch (against revision 365637).
No new files added.

Derbyall ran without errors 32 bit (chroot) Gentoo Linux (6 suites skipped - no 
db2jcc).
The test will fail on Solaris 10 with J2SE 5.0 due to another problem, see 
DERBY-788.

Patch description:
* JCECipherFactory.boot() now checks the output from the fromHexString-method 
and throws an exception if it is invalid, instead of failing with NPE.
* Added 2 new SQLStates and messages (only English)
* Added 2 new test cases (invalid char in encryption key and encryption key of 
with odd length).
* Updated master file.


> NullPointerException when 'encryptionKey' length is an odd number, or it 
> contains invalid chars
> ---
>
>  Key: DERBY-746
>  URL: http://issues.apache.org/jira/browse/DERBY-746
>  Project: Derby
> Type: Bug
>   Components: Security
> Versions: 10.1.1.2, 10.1.2.1, 10.2.0.0, 10.1.3.0, 10.1.2.2
>  Environment: All environments.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: derby-746.diff, derby-746.stat
>
> When booting/creating an encrypted database, a NullPointerException is thrown 
> if the length of the connection string attribute 'encryptionKey' is an odd 
> number, or the encryption key contains invalid characters for hexadecimal 
> numbers (char not in the set [0-9a-fA-F]).
> The reason for the exception being thrown, is that the method 
> 'iapi.util.StringUtil.fromHexString(String, int, int)' returns null for the 
> cases described above. The code calling the method in 
> 'JCECipherFactory.boot(boolean, Properties)' does not check that the return 
> value is not null.
> A related trivial issue is that 'fromHexString' does not allow the caller to 
> see the distinction between a string with invalid length and a string 
> containing invalid characters (both cases return null).
> [To reproduce]
> (connection string copied from test 'store/encryptionKey.sql' and then 
> modified)
> Supply the following connection string, for instance in ij:
> connect 
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656';
> (deleted the last digit in the encryption key)
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656X';
> (replaced last digit with an X)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-149) Server hang when invalid string is bound to datetime columns.

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-149?page=all ]
 
Kristian Waagan closed DERBY-149:
-


Verified the fix on 10.1.2.1 and trunk, and closed the issue.
Also tested that the test program indeed did hang on 10.0.2.1 and 10.1.1.0.

Output from test program on 10.1.2.1:
]$ java -classpath 
./db2jcc.jar:./db2jcc_license_c.jar:../db-derby-10.1.2.1-lib/lib/derbyclient.jar:./
 go
Got 22007: DB2 SQL error: SQLCODE: -1, SQLSTATE: 22007, SQLERRMC: 22007.S.181

> Server hang when invalid string is bound to datetime columns.
> -
>
>  Key: DERBY-149
>  URL: http://issues.apache.org/jira/browse/DERBY-149
>  Project: Derby
> Type: Bug
>   Components: Network Server
>  Environment: Derby running with Network Server via JDBC universal driver.
> Reporter: A B
> Assignee: Kathey Marsden
>  Fix For: 10.2.0.0, 10.1.2.0, 10.1.1.2

>
> When running against Derby Network Server with the JCC driver, attempts to 
> bind an invalid date/time string to a date/time/timestamp parameter lead to a 
> hang in either the JCC client or in the Network Server (not sure which).
> The problem does NOT occur if the same thing is run against a DB2 server, 
> which suggests the bug is in Network Server, not in the JCC driver.  That 
> said, though, the problem also does NOT happen if one uses an ODBC client to 
> connect to Network Server, instead of a JDBC client--so perhaps it's a 
> problem with JCC, after all...hard to say one way or the other...
> Here's a simple program to reproduce the problem:
> import java.sql.*;
> public class go {
>   public static void main (String[] args) throws Exception {
>   Class.forName("com.ibm.db2.jcc.DB2Driver");
>   Connection c = DriverManager.getConnection(
>   "jdbc:derby:net://localhost:1527/ugh;create=true", 
> "bah", "humbug");
>   Statement s = c.createStatement();
>   try {
>   s.execute("drop table dt");
>   } catch (SQLException se) {}
>   s.execute("create table dt (d date)");
>   PreparedStatement pSt = c.prepareStatement("insert into dt 
> values (?)");
>   try {
>   pSt.setString(1, "oops"); // invalid date value.
>   pSt.execute();
>   } catch (SQLException se) {
>   System.out.println("Got " + se.getSQLState() + ": " + 
> se.getMessage());
>   }
>   }
> }
> Of course, in order for the program to run, one must start the Network Server 
> on port 1527 first.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-487) Getting Started Guide has reference to incubator URL

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-487?page=all ]
 
Kristian Waagan closed DERBY-487:
-


Verified URL in DITA source file. Closed.

> Getting Started Guide has reference to incubator URL
> 
>
>  Key: DERBY-487
>  URL: http://issues.apache.org/jira/browse/DERBY-487
>  Project: Derby
> Type: Task
>   Components: Documentation
> Versions: 10.1.1.0
>  Environment: all
> Reporter: Jeff Levitt
> Priority: Trivial
>  Fix For: 10.2.0.0
>  Attachments: derbyinc.diff
>
> On http://db.apache.org/derby/docs/getstart/cgsinstallingderby.html
> we have a reference to an incubator URL.  Even though it will redirect, it 
> should probably be changed to the new URL format.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-652) Documentation and demos have incubator references

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-652?page=all ]
 
Kristian Waagan closed DERBY-652:
-


Searched for incubator references in doc trunk. None found; issue closed.

> Documentation and demos have incubator references
> -
>
>  Key: DERBY-652
>  URL: http://issues.apache.org/jira/browse/DERBY-652
>  Project: Derby
> Type: Bug
>   Components: Documentation
> Versions: 10.1.2.1, 10.1.3.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Andrew McIntyre
>  Fix For: 10.1.2.1, 10.1.3.0, 10.2.0.0

>
> Just a quick scan of the html files  in demo and docs directories of the 
> 10.1.2.0 release candidate show incubator references in the following files.
> ./demo/demo.html
> ./demo/navbar.html
> ./docs/html/getstart/cgsinstallingderby.html
> ./docs/html/getstart/getstart-single.html
> ./docs/html/getstart/gsconrefs.html
> Thanks to Naka for pointing this out.
> I did not check the trunk and only checked the html files.  A more 
> comprehensive check by someone used to working in this area would be good.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-650) Hyperlinks in demo/demo.html are broken

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-650?page=all ]
 
Kristian Waagan closed DERBY-650:
-


Closed as "parent issue" is also closed.

> Hyperlinks in demo/demo.html are broken
> ---
>
>  Key: DERBY-650
>  URL: http://issues.apache.org/jira/browse/DERBY-650
>  Project: Derby
> Type: Bug
>   Components: Documentation
> Versions: 10.1.2.0, 10.1.2.1
> Reporter: Tomohito Nakayama
>  Fix For: 10.1.2.1, 10.1.3.0, 10.2.0.0

>
> I found hyperlinks in demo\demo.html was broken.
> Broken hyperlinks were found in next sentence :
> This directory contains example programs. For a complete description, see 
> Getting Started with Apache Derby 
>  and the Apache Derby 
> Server and Administration Guide 
> .
> Getting Started with Apache Derby 
>  and
> Apache Derby Server and Administration Guide 
>  seem to be expired link .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-793) 'trunk/README' should be rewritten to reflect graduation from incubation

[Kristian Waagan (JIRA)]

'trunk/README' should be rewritten to reflect graduation from incubation


 Key: DERBY-793
 URL: http://issues.apache.org/jira/browse/DERBY-793
 Project: Derby
Type: Task
  Components: Documentation  
Versions: 10.2.0.0
Reporter: Kristian Waagan
Priority: Minor


The content of 'trunk/README' is outdated, with references to the incubator. It 
should be rewritten to reflect the current situation for Derby.

Thanks to Bryan Pendleton for pointing this out (on derby-dev).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-746) NullPointerException when 'encryptionKey' length is an odd number, or it contains invalid chars

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-746?page=all ]

Kristian Waagan updated DERBY-746:
--

Attachment: derby-746a.stat
derby-746a.diff

Original patch (derby-746.diff) applied to trunk revision 365785.
Sunhita Kambhampati pointed out a spelling error in the patch (thanks).
An *additional* patch fixing the error in the message file and the test master 
file is attached as derby-746a.diff.
I reran 'store/encryptionKey.sql' - no errors (Gentoo Linux, 64 bit, Sun JDK 
1.4.2_10 Blackdown JDK 1.4.2-02 & IBM J9SE 2.2 (1.4.2)).

> NullPointerException when 'encryptionKey' length is an odd number, or it 
> contains invalid chars
> ---
>
>  Key: DERBY-746
>  URL: http://issues.apache.org/jira/browse/DERBY-746
>  Project: Derby
> Type: Bug
>   Components: Security
> Versions: 10.1.1.2, 10.1.2.1, 10.2.0.0, 10.1.3.0, 10.1.2.2
>  Environment: All environments.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: derby-746.diff, derby-746.stat, derby-746a.diff, derby-746a.stat
>
> When booting/creating an encrypted database, a NullPointerException is thrown 
> if the length of the connection string attribute 'encryptionKey' is an odd 
> number, or the encryption key contains invalid characters for hexadecimal 
> numbers (char not in the set [0-9a-fA-F]).
> The reason for the exception being thrown, is that the method 
> 'iapi.util.StringUtil.fromHexString(String, int, int)' returns null for the 
> cases described above. The code calling the method in 
> 'JCECipherFactory.boot(boolean, Properties)' does not check that the return 
> value is not null.
> A related trivial issue is that 'fromHexString' does not allow the caller to 
> see the distinction between a string with invalid length and a string 
> containing invalid characters (both cases return null).
> [To reproduce]
> (connection string copied from test 'store/encryptionKey.sql' and then 
> modified)
> Supply the following connection string, for instance in ij:
> connect 
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656';
> (deleted the last digit in the encryption key)
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656X';
> (replaced last digit with an X)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-744) Problem setting sanity state to false by using 'ant -Dsane=false'

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-744?page=comments#action_12361842 ] 

Kristian Waagan commented on DERBY-744:
---

I also have problems with this, but don't know if it is caused by build.xml or 
my build environment 
Sometimes my insane build is placed into the 'jars/sane' directory. I have also 
seen the Derby jars go to one directory, and the testing jar to the other.
'ant clobber' was run before the build: 'ant buildsource buildjars', followed 
by 'ant testing derbytesting jar'.
~/ant.properties contained 'sane=false' and 'debug=false'.

Apache Ant version 1.6.2
Sun jdk1.4.2_05

> Problem setting sanity state to false by using 'ant -Dsane=false'
> -
>
>  Key: DERBY-744
>  URL: http://issues.apache.org/jira/browse/DERBY-744
>  Project: Derby
> Type: Bug
>   Components: Build tools
> Versions: 10.2.0.0, 10.1.2.1, 10.1.3.0, 10.1.2.2
> Reporter: Andrew McIntyre
> Assignee: Andrew McIntyre
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.2

>
> Problem report from Kathey Marsden:
> There seems to be some sort of problem with the sanity state.
> After ant clobber, rm -rf jars, rm -rf snapshot  no apparent problematic
> files, ant -Dsane=false snapshot  seemed to sometimes build the jars to
> the sane jar directory and yield the following error.
> 
>   [delete] Deleting directory D:\svn\opensource\10.1\javadoc\sourcedir
>[mkdir] Created dir: D:\svn\opensource\10.1\snapshot
> BUILD FAILED
> D:\svn\opensource\10.1\build.xml:1287:
> D:\svn\opensource\10.1\jars\insane not found.
> A reliable  workaround was to run
> ant insane
> before ant -Dsane=false snapshot.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-641) Remove need for db2jcc.jar for executing ij or upload it on ibiblio

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-641?page=comments#action_12361844 ] 

Kristian Waagan commented on DERBY-641:
---

>From 10.1 Derby includes its own JDBC driver, called the Derby Network Client 
>according to the FAQ (http://db.apache.org/derby/faq.html). Although the DB2 
>JCC can still be used with Derby, it is no longer required. As the DB2 JCC 
>driver is not available without registration, the required files cannot be 
>uploaded to another download site.

In my mind this fulfills the improvement request, and I suggest we close this 
issue.

> Remove need for db2jcc.jar for executing ij or upload it on ibiblio
> ---
>
>  Key: DERBY-641
>  URL: http://issues.apache.org/jira/browse/DERBY-641
>  Project: Derby
> Type: Improvement
>   Components: Tools
> Versions: 10.1.1.0
> Reporter: Vincent Massol

>
> I'm trying to automate loading DDL files with Maven/Maven2 and all the derby 
> are available on ibiblio except db2jcc.jar...
> Thanks!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-641) Remove need for db2jcc.jar for executing ij or upload it on ibiblio

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-641?page=all ]
 
Kristian Waagan closed DERBY-641:
-

Fix Version: 10.1.1.0
 Resolution: Invalid

Closed and marked as 'Invalid', although it is kind of 'Fixed'  as well :)

> Remove need for db2jcc.jar for executing ij or upload it on ibiblio
> ---
>
>  Key: DERBY-641
>  URL: http://issues.apache.org/jira/browse/DERBY-641
>  Project: Derby
> Type: Improvement
>   Components: Tools
> Versions: 10.1.1.0
> Reporter: Vincent Massol
>  Fix For: 10.1.1.0

>
> I'm trying to automate loading DDL files with Maven/Maven2 and all the derby 
> are available on ibiblio except db2jcc.jar...
> Thanks!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-746) NullPointerException when 'encryptionKey' length is an odd number, or it contains invalid chars

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-746?page=all ]
 
Kristian Waagan closed DERBY-746:
-

Fix Version: 10.2.0.0
 Resolution: Fixed

Spelling error fixed in revision 367712, thanks to Daniel John Debrunner.

Verified changes by inspection, closing the issue.

> NullPointerException when 'encryptionKey' length is an odd number, or it 
> contains invalid chars
> ---
>
>  Key: DERBY-746
>  URL: http://issues.apache.org/jira/browse/DERBY-746
>  Project: Derby
> Type: Bug
>   Components: Security
> Versions: 10.2.0.0, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2
>  Environment: All environments.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: derby-746.diff, derby-746.stat, derby-746a.diff, derby-746a.stat
>
> When booting/creating an encrypted database, a NullPointerException is thrown 
> if the length of the connection string attribute 'encryptionKey' is an odd 
> number, or the encryption key contains invalid characters for hexadecimal 
> numbers (char not in the set [0-9a-fA-F]).
> The reason for the exception being thrown, is that the method 
> 'iapi.util.StringUtil.fromHexString(String, int, int)' returns null for the 
> cases described above. The code calling the method in 
> 'JCECipherFactory.boot(boolean, Properties)' does not check that the return 
> value is not null.
> A related trivial issue is that 'fromHexString' does not allow the caller to 
> see the distinction between a string with invalid length and a string 
> containing invalid characters (both cases return null).
> [To reproduce]
> (connection string copied from test 'store/encryptionKey.sql' and then 
> modified)
> Supply the following connection string, for instance in ij:
> connect 
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656';
> (deleted the last digit in the encryption key)
> 'jdbc:derby:encdbcbc_key;create=true;dataEncryption=true;encryptionAlgorithm=DES/CBC/NoPadding;encryptionKey=6162636465666768696162636465656X';
> (replaced last digit with an X)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
--

 Key: DERBY-809
 URL: http://issues.apache.org/jira/browse/DERBY-809
 Project: Derby
Type: Bug
  Components: Documentation, Javadoc  
Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
Reporter: Kristian Waagan
Priority: Minor
 Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.2


The documentation for 'NetworkServerControl.logConnections(boolean)' states 
that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
earlier releases, this is not true. The documentation should be corrected to 
avoid confusing users.

The thought of adding logging of disconnections has also been posted on 
derby-dev.

Byran Pendleton identified the following documentation with the incorrect 
description:
http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html

Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12362838 ] 

Kristian Waagan commented on DERBY-788:
---

I got a response to my inquiry about this issue:

"...it is not clearly defined how SecretKeyFactories and Ciphers behave when 
passed a key that is "too long". In most cases I would expect the two to behave 
the same. That means that even though your technique worked for DES and the 
providers you have tried, it may not work for other algorithms or providers."

This raises a few questions:
1) Is the approach used by Derby valid? (wrt. what we can expect from crypto 
providers)
Why allow the user to believe, say, a  512 byte key is used, when in fact only 
the first 8 bytes are used for encrypting/decrypting the database? Are we able 
to enforce a valid key length for a given algorithm? (without hardcoding limits 
in Derby code)

2) Why does the test use a 16 byte key for the DES algorithm?
Should it be changed to 8 byte, or is the test written to test the behavior of 
Derby when the key is not according to the specifications for the given 
algorithm?

I will take no further action until I get some feedback. Until a) the 
'SunPCKS11-Solaris' is changed, b) the test is changed or c) another default 
provider is set for Solaris10, the test will continue to fail on Solaris10 (and 
probably higher versions).

> 'store/encryptionKey.sql' fails on Solaris 10
> -
>
>  Key: DERBY-788
>  URL: http://issues.apache.org/jira/browse/DERBY-788
>  Project: Derby
> Type: Bug
>   Components: Services, Test
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>  Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0

>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior 
> between the 'SunPCKS11-Solaris' provider and other providers (tested with 
> 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified 
> in the test) is not translated to a 8 byte DES key by 
> SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
> know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 
> 'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-3) Identity column not filled consecutively with "insert ... select distinct"

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-3?page=all ]

Kristian Waagan updated DERBY-3:


   type: Improvement  (was: Bug)
Description: 
When an "insert ... select distinct" is used to fill a table with an identity 
column, gaps occur in the identity column. The caps correspond to the rows of 
the source table that have been suppressed with "distinct".

Example:

create table temp1 (
   s varchar(10));
insert into temp1 values 'a','a','a','b','c','c','c','d';

create table temp2 (
   i integer not null
  generated always as identity
  primary key,
   s varchar(10));

insert into temp2 (s)
   select distinct s from temp1;
select * from temp2;

output:
 1   a
 4   b
 5   c
 8   d


  was:
When an "insert ... select distinct" is used to fill a table with an identity 
column, gaps occur in the identity column. The caps correspond to the rows of 
the source table that have been suppressed with "distinct".

Example:

create table temp1 (
   s varchar(10));
insert into temp1 values 'a','a','a','b','c','c','c','d';

create table temp2 (
   i integer not null
  generated always as identity
  primary key,
   s varchar(10));

insert into temp2 (s)
   select distinct s from temp1;
select * from temp2;

output:
 1   a
 4   b
 5   c
 8   d


Version: 10.2.0.0
Environment: 
Derby Snapshot svnversion 46005
or Cloudscape 10.0 GA
Derby 10.2beta

  was:
Derby Snapshot svnversion 46005
or Cloudscape 10.0 GA

   Priority: Minor  (was: Major)

Ran test script on Derby 10.2beta. The behavior is still the same, you do not 
get consequtive ids for the given query (with "insert ... select distinct").
Recategorized issue, as the current behavior is not a bug.

> Identity column not filled consecutively with "insert ... select distinct"
> --
>
>  Key: DERBY-3
>  URL: http://issues.apache.org/jira/browse/DERBY-3
>  Project: Derby
> Type: Improvement
>   Components: SQL
> Versions: 10.2.0.0
>  Environment: Derby Snapshot svnversion 46005
> or Cloudscape 10.0 GA
> Derby 10.2beta
> Reporter: Christian d'Heureuse
> Priority: Minor

>
> When an "insert ... select distinct" is used to fill a table with an identity 
> column, gaps occur in the identity column. The caps correspond to the rows of 
> the source table that have been suppressed with "distinct".
> Example:
> create table temp1 (
>s varchar(10));
> insert into temp1 values 'a','a','a','b','c','c','c','d';
> create table temp2 (
>i integer not null
>   generated always as identity
>   primary key,
>s varchar(10));
> insert into temp2 (s)
>select distinct s from temp1;
> select * from temp2;
> output:
>  1   a
>  4   b
>  5   c
>  8   d

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Reopened: (DERBY-3) Identity column not filled consecutively with "insert ... select distinct"

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-3?page=all ]
 
Kristian Waagan reopened DERBY-3:
-


> Identity column not filled consecutively with "insert ... select distinct"
> --
>
>  Key: DERBY-3
>  URL: http://issues.apache.org/jira/browse/DERBY-3
>  Project: Derby
> Type: Improvement
>   Components: SQL
> Versions: 10.2.0.0
>  Environment: Derby Snapshot svnversion 46005
> or Cloudscape 10.0 GA
> Derby 10.2beta
> Reporter: Christian d'Heureuse
> Priority: Minor

>
> When an "insert ... select distinct" is used to fill a table with an identity 
> column, gaps occur in the identity column. The caps correspond to the rows of 
> the source table that have been suppressed with "distinct".
> Example:
> create table temp1 (
>s varchar(10));
> insert into temp1 values 'a','a','a','b','c','c','c','d';
> create table temp2 (
>i integer not null
>   generated always as identity
>   primary key,
>s varchar(10));
> insert into temp2 (s)
>select distinct s from temp1;
> select * from temp2;
> output:
>  1   a
>  4   b
>  5   c
>  8   d

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-7) Bug in NULLIF Function

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-7?page=comments#action_12363673 ] 

Kristian Waagan commented on DERBY-7:
-

I verified that the initial reported error no longer occurs, but the discussion 
for this issue is somewhat volumnious and several other (potential) problems 
are mentioned.
Could someone with more knowledge about this field confirm that this issue is 
fixed and that no more work is to be done on it?
If true, please close the issue.

> Bug in NULLIF Function
> --
>
>  Key: DERBY-7
>  URL: http://issues.apache.org/jira/browse/DERBY-7
>  Project: Derby
> Type: Bug
>   Components: SQL
> Versions: 10.0.2.0
> Reporter: Tulika Agrawal
> Assignee: Mamta A. Satoor
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: Derby-7.txt, Derby7NullIf061005svndiff.txt, derby-nullif.patch, 
> derby7Nullif080205svndiff.txt
>
> Reporting for Christian d'Heureuse, filed on derby-dev list.
> The NULLIF built-in function of Cloudscape 10.0.1.0 beta seems to accept
> only string values.
> Examples:
>  values nullif('a','b');
>  --> OK
>  values nullif(1,2);
>  --> Error message: "ERROR 42X89: Types 'CHAR' and
>  'INTEGER' are not type compatible. (Neither type
>  is assignable to the other type.)"

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-33) Connection.setTypeMap throws unimplemented exception with empty map

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-33?page=all ]
 
Kristian Waagan closed DERBY-33:



Verified fix by quick code inspection and minimalistic JDBC testing.
Closing the issue.

> Connection.setTypeMap throws unimplemented exception with empty map
> ---
>
>  Key: DERBY-33
>  URL: http://issues.apache.org/jira/browse/DERBY-33
>  Project: Derby
> Type: Bug
>   Components: JDBC
> Versions: 10.0.2.0
> Reporter: Daniel John Debrunner
> Priority: Minor

>
> With some other unimplemented methods Derby accepts a default value or value 
> that is in effect a no-op. In this case an empty map should be accepted. May 
> want to apply the same logi to other JDBC methods that take a type map.
> Original bug discovered by Edward Rayl
> http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=43

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-918) introduce a new test type to run junit tests from the current harness

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-918?page=comments#action_12365723 ] 

Kristian Waagan commented on DERBY-918:
---

I have one question related to the patch, or actually a comment in the patch:


> introduce a new test type to run junit tests from the current harness
> -
>
>  Key: DERBY-918
>  URL: http://issues.apache.org/jira/browse/DERBY-918
>  Project: Derby
> Type: Improvement
>   Components: Test
>  Environment: All
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
>  Attachments: DERBY-918.diff, DERBY-918.stat
>
> It seems to me that for including a new JUnit test into i.e derby-all we need 
> to make a new java class with a main() method, which parses a command line 
> and set up the testsuite and run it, just like any java program. Basically we 
> are running the junit tests as test type "java".
> Instead of having to do this for every junit test going into a derby test 
> suite, I would propose a different strategy.
> I propose to introduce a new test type called "junit" (current test types 
> are: sql,sql2,unit,java,multi,demo - unit is not junit)
> Then you can use:
> java org.apache.derbyTesting.functionTests.harness.RunTest 
> .junit
> to run a Junit test - instead of:
> java org.apache.derbyTesting.functionTests.harness.RunTest 
> .java
> When starting a test of type junit, the RunTest class may simply use the
> junit.textui.TestRunner class, which has a main method which takes a TestCase 
> class name as parameter.  The junit.textui.TestRunner  runs the tests defined 
> by the suite() method of the TestCase class.
> I think this strategy will make it easier to integrate new JUnit tests into 
> the current test suites, since it save you the trouble of creating a java 
> class with a main method for every test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-918) introduce a new test type to run junit tests from the current harness

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-918?page=all ]

Kristian Waagan updated DERBY-918:
--

Comment: was deleted

> introduce a new test type to run junit tests from the current harness
> -
>
>  Key: DERBY-918
>  URL: http://issues.apache.org/jira/browse/DERBY-918
>  Project: Derby
> Type: Improvement
>   Components: Test
>  Environment: All
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
>  Attachments: DERBY-918.diff, DERBY-918.stat
>
> It seems to me that for including a new JUnit test into i.e derby-all we need 
> to make a new java class with a main() method, which parses a command line 
> and set up the testsuite and run it, just like any java program. Basically we 
> are running the junit tests as test type "java".
> Instead of having to do this for every junit test going into a derby test 
> suite, I would propose a different strategy.
> I propose to introduce a new test type called "junit" (current test types 
> are: sql,sql2,unit,java,multi,demo - unit is not junit)
> Then you can use:
> java org.apache.derbyTesting.functionTests.harness.RunTest 
> .junit
> to run a Junit test - instead of:
> java org.apache.derbyTesting.functionTests.harness.RunTest 
> .java
> When starting a test of type junit, the RunTest class may simply use the
> junit.textui.TestRunner class, which has a main method which takes a TestCase 
> class name as parameter.  The junit.textui.TestRunner  runs the tests defined 
> by the suite() method of the TestCase class.
> I think this strategy will make it easier to integrate new JUnit tests into 
> the current test suites, since it save you the trouble of creating a java 
> class with a main method for every test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-918) introduce a new test type to run junit tests from the current harness

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-918?page=comments#action_12365729 ] 

Kristian Waagan commented on DERBY-918:
---

(Sorry for accidentally finding a keyboard shortcut that submitted the comment 
before I was finished...)
 I have one comment related to the patch, or actually a comment in the patch:

else if (testType.equals("junit"))
{
System.out.println("JUnit tests not implemented yet with 
useprocess=false");
System.exit(1);

// This does not compile since JUnit is not in the CLASSPATH
//junit.textui.TestRunner.run
//(new junit.framework.TestSuite(Class.forName(javaPath + "." + 
testBase)));
} 

If we use the way described in the comment to start the test, it will differ 
from how we do it when useprocess=true. When we start the testrunner from the 
command line, it will use the method 'BaseTestRunner.getTest', which uses 
reflection to call the test class' 'suite' method. The way described by the 
comment will also use reflection, but it will get a list of all methods in the 
test class and find those that starts with 'test'.

The latter case would cause any test setup done/initiated from 'suite' to be 
skipped. I have observed on the developer list that we have talked about using 
a test decorator, like 'TestSetup', to create a common test setup/environment 
for the tests in the suite (or test class). 'suite' could also possibly skip 
one or more test methods that is known to fail, but these would be included in 
the latter case.

I know this is a little ahead of time, but I would rather see the comment 
deleted, to make sure we don't simply uncomment it later and expect things to 
work as before.

> introduce a new test type to run junit tests from the current harness
> -
>
>  Key: DERBY-918
>  URL: http://issues.apache.org/jira/browse/DERBY-918
>  Project: Derby
> Type: Improvement
>   Components: Test
>  Environment: All
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
>  Attachments: DERBY-918.diff, DERBY-918.stat
>
> It seems to me that for including a new JUnit test into i.e derby-all we need 
> to make a new java class with a main() method, which parses a command line 
> and set up the testsuite and run it, just like any java program. Basically we 
> are running the junit tests as test type "java".
> Instead of having to do this for every junit test going into a derby test 
> suite, I would propose a different strategy.
> I propose to introduce a new test type called "junit" (current test types 
> are: sql,sql2,unit,java,multi,demo - unit is not junit)
> Then you can use:
> java org.apache.derbyTesting.functionTests.harness.RunTest 
> .junit
> to run a Junit test - instead of:
> java org.apache.derbyTesting.functionTests.harness.RunTest 
> .java
> When starting a test of type junit, the RunTest class may simply use the
> junit.textui.TestRunner class, which has a main method which takes a TestCase 
> class name as parameter.  The junit.textui.TestRunner  runs the tests defined 
> by the suite() method of the TestCase class.
> I think this strategy will make it easier to integrate new JUnit tests into 
> the current test suites, since it save you the trouble of creating a java 
> class with a main method for every test.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-788?page=all ]

Kristian Waagan updated DERBY-788:
--

Component: Regression Test Failure

Added component 'Regression Test Failure', as this test fails on Solaris10 with 
the 'SunPCKS11-Solaris' Java Security provider (which is the default provider). 
Will fail until the test is changed or the provider is changed/fixed. See 
earlier comment for more details.

> 'store/encryptionKey.sql' fails on Solaris 10
> -
>
>  Key: DERBY-788
>  URL: http://issues.apache.org/jira/browse/DERBY-788
>  Project: Derby
> Type: Bug
>   Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>  Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0

>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior 
> between the 'SunPCKS11-Solaris' provider and other providers (tested with 
> 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified 
> in the test) is not translated to a 8 byte DES key by 
> SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
> know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 
> 'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-788?page=all ]

Kristian Waagan reassigned DERBY-788:
-

Assign To: (was: Kristian Waagan)

According to the comment, Sunitha is having a look at the code/test. Awaiting 
feedback before we decide what to do with the test.

> 'store/encryptionKey.sql' fails on Solaris 10
> -
>
>  Key: DERBY-788
>  URL: http://issues.apache.org/jira/browse/DERBY-788
>  Project: Derby
> Type: Bug
>   Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>  Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0

>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior 
> between the 'SunPCKS11-Solaris' provider and other providers (tested with 
> 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified 
> in the test) is not translated to a 8 byte DES key by 
> SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
> know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 
> 'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-788?page=comments#action_12366473 ] 

Kristian Waagan commented on DERBY-788:
---

For the cases I have tested, the exception comes from the Cipher.init method. 
The skf.translateKey seems to simply return what is passed in when it does not 
know what to do with the key. Note that the capabilities of the method depends 
on the implementation/provider.

I tried using AES instead of DES, but got a few errors. I suspect they are only 
minor changes in the error message that are reported, but I have not 
investigated.

I plan on rewriting this test to a JUnit test, but I am awaiting some JUnit 
framework commits. Then we could have the test run with both DES and AES with 
minimal changes and code duplication in the test.

My suggestion is that we create a new Jira issue to track the general problem 
regarding use of the skf.translageKey method (as Sunitha suggested), and that 
the 16 byte key is replaced with a 8 byte key to stop the test from failing in 
the regression test on Solaris10. I will start/do the rewrite during a few days 
if I don't get pushback.

> 'store/encryptionKey.sql' fails on Solaris 10
> -
>
>  Key: DERBY-788
>  URL: http://issues.apache.org/jira/browse/DERBY-788
>  Project: Derby
> Type: Bug
>   Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>  Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0

>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior 
> between the 'SunPCKS11-Solaris' provider and other providers (tested with 
> 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified 
> in the test) is not translated to a 8 byte DES key by 
> SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
> know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 
> 'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1001) Rewrite 'store/encryptionKey.sql' to a JUnit test

[Kristian Waagan (JIRA)]

Rewrite 'store/encryptionKey.sql' to a JUnit test
-

 Key: DERBY-1001
 URL: http://issues.apache.org/jira/browse/DERBY-1001
 Project: Derby
Type: Test
  Components: Test  
Versions: 10.2.0.0
Reporter: Kristian Waagan
 Assigned to: Kristian Waagan 
Priority: Minor


This test has failed on Solaris10 for a long time, due to issues with the 
default security provider on this OS. See DERBY-788 for details.

I consider rewriting this test as interresting because it allows us to see how 
things can be done in "the JUnit way". 

1) Run test with multiple encryption algorithms with minimal test code 
duplication.
2) Special handling of exceptions for specific providers (PCKS11-Solaris).

The rewritten test might cause some discussion on how we want to handle the 
issues mentioned above.



-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-809?page=comments#action_12367010 ] 

Kristian Waagan commented on DERBY-809:
---

Sorry for the incomplete issue description.

Unless the behavior has changed recently, disconnections are not being logged. 
This posting seem to agree also: 
http://www.nabble.com/forum/ViewPost.jtp?post=2334961&framed=y

> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0

>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-809?page=all ]

Kristian Waagan updated DERBY-809:
--

Attachment: DERBY-809-1a-javadoc.diff
DERBY-809-1a-javadoc.stat

'DERBY-809-1a-javadoc.diff' is a small patch (4 lines changed) for the javadoc 
of NetworkServerControl, removing the false statement that disconnections are 
logged to derby.log. Patch can be applied when someone has reviewed and 
approved it :)

Note that this is only a partial fix for the issue; the user documentation must 
also be corrected.

> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-809-1a-javadoc.diff, DERBY-809-1a-javadoc.stat
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-809?page=all ]

Kristian Waagan updated DERBY-809:
--

Other Info: [Patch available]

> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-809-1a-javadoc.diff, DERBY-809-1a-javadoc.stat
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-788?page=all ]

Kristian Waagan updated DERBY-788:
--

Attachment: DERBY-788-1a.diff
DERBY-788-1a.stat

'DERBY-788-1a.diff' is a patch that replaces the 16 byte key with a 8 byte key 
for the DES encryption algorithm used in the test 'store/encryptionKey.sql'. 
The test still exercises the intended parts of the Derby code (according to my 
own analysis and that of Sunitha). The patch makes the test stop failing on 
Solaris10 (with security provider 'SunPCKS11-Solaris') .

One test case is changed; where it previously tested a key that was of 
incorrect length (longer than 8 bytes, shorter than 16), it now tests an 
incorrect key of the correct length. It is not possible to make the test pass 
on Solaris10 with a key of incorrect length, because keys of length less than 8 
bytes are caught by a check in the code, and keys longer than 8 bytes cause the 
underlying security provider to fail ('SunPCKS11-Solaris'). This issue will be 
addressed in DERBY-1001 (rewrite of test to a JUnit-test).

Ran derbyall on Solaris10, which resulted in 6 known errors (some are already 
fixed according to the tinderbox test). 'store/encryptionKey.sql' passed.

> 'store/encryptionKey.sql' fails on Solaris 10
> -
>
>  Key: DERBY-788
>  URL: http://issues.apache.org/jira/browse/DERBY-788
>  Project: Derby
> Type: Bug
>   Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>  Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior 
> between the 'SunPCKS11-Solaris' provider and other providers (tested with 
> 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified 
> in the test) is not translated to a 8 byte DES key by 
> SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
> know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 
> 'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-788?page=all ]

Kristian Waagan updated DERBY-788:
--

Other Info: [Patch available]

> 'store/encryptionKey.sql' fails on Solaris 10
> -
>
>  Key: DERBY-788
>  URL: http://issues.apache.org/jira/browse/DERBY-788
>  Project: Derby
> Type: Bug
>   Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>  Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior 
> between the 'SunPCKS11-Solaris' provider and other providers (tested with 
> 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified 
> in the test) is not translated to a 8 byte DES key by 
> SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
> know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 
> 'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-809?page=all ]

Kristian Waagan updated DERBY-809:
--

Attachment: DERBY-809-1b-javadoc.stat
DERBY-809-1b-javadoc.diff

Yes, we need to remove references to disconnections here as well. Thanks for 
catching this Bryan :)

I have uploaded the updated patch 'DERBY-809-1b-javadoc.diff' which addesses 
the previous sections *and* the additional JavaDoc section. Patch 
'DERBY-809-1a-javadoc.diff' is now deprecated, and will be deleted since it 
does not have any value (all contents of 1a are found in 1b).

> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-809-1b-javadoc.diff, DERBY-809-1b-javadoc.stat, 
> derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-809?page=all ]

Kristian Waagan updated DERBY-809:
--

Attachment: (was: DERBY-809-1a-javadoc.diff)

> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-809-1b-javadoc.diff, DERBY-809-1b-javadoc.stat, 
> derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-809?page=all ]

Kristian Waagan updated DERBY-809:
--

Attachment: (was: DERBY-809-1a-javadoc.stat)

> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-809-1b-javadoc.diff, DERBY-809-1b-javadoc.stat, 
> derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-953) Add miscellaneous Statement methods introduced by JDBC 4

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-953?page=all ]

Kristian Waagan reassigned DERBY-953:
-

Assign To: Kristian Waagan

> Add miscellaneous Statement methods introduced by JDBC 4
> 
>
>  Key: DERBY-953
>  URL: http://issues.apache.org/jira/browse/DERBY-953
>  Project: Derby
> Type: New Feature
>   Components: JDBC
> Reporter: Rick Hillegas
> Assignee: Kristian Waagan
>  Fix For: 10.2.0.0

>
> As described in the JDBC 4 spec, sections 13.1 and 3.1.
> This adds support for new Statement methods added by JDBC4 and not addressed 
> by other JIRAs: isClosed() and getResultSetHoldability().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-809?page=comments#action_12367995 ] 

Kristian Waagan commented on DERBY-809:
---

I reviewed Jeff's patch (derby809.diff), and it looks good. I do have two 
comments:

1) The DOCTYPE tags have been changed, but I don't know what they should be 
like. Since Jeff has built the HTML files, I take they are good.

2) The capitalization of "connection number" should be consistent. Both 
"..connection number..." and "...Connection Number..." are used.

These are not blockers, and I leave it up to the committers whether it is a go 
or not. 
Thank you for updating the manuals Jeff!


> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-809-1b-javadoc.diff, DERBY-809-1b-javadoc.stat, 
> derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-809?page=comments#action_12368306 ] 

Kristian Waagan commented on DERBY-809:
---

I have checked that the documentation change happens in the latest alpha 
manuals. They do not in the 10.1 manuals (or 10.0 manuals).

Should we port the manual fixes to these branches as well, or is 10.2 enough?
The Javadoc fix can also be ported, but I consider this less important.

The fix version should be updated as appropriate.



> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-809-1b-javadoc.diff, DERBY-809-1b-javadoc.stat, 
> derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Assigned: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan reassigned DERBY-623:
-

Assign To: Kristian Waagan

> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor

>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan updated DERBY-623:
--

Attachment: DERBY-623-2a-javadoc.stat
DERBY-623-2a-javadoc.diff

A separate patch ('DERBY-623-2a-javadoc.diff') for a few Javadoc fixes. First, 
a spelling error is corrected several places ('privledged' -> 'priviledged') 
and the prefix for properties have been changed from 'db2j' to 'derby.' (only 
documentation is changed in this patch, implementation is untouched). 

A committer should be able to both review and commit this small patch (8 lines 
changed).

DERBY-623-2a-javadoc.diff does not resolve this issue, it is only an additional 
documentation fix.

> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-2a-javadoc.diff, DERBY-623-2a-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan updated DERBY-623:
--

Attachment: DERBY-623-2b-javadoc.diff
DERBY-623-2b-javadoc.stat

'DERBY-623-2b-javadoc.diff' is a patch fixing spelling errors for a patch 
fixing spelling errors :)
See description for rev 2a for patch description.

Must have had a blackout or something. Sorry for the noise... 

> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-2b-javadoc.diff, DERBY-623-2b-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan updated DERBY-623:
--

Attachment: (was: DERBY-623-2a-javadoc.diff)

> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-2b-javadoc.diff, DERBY-623-2b-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan updated DERBY-623:
--

Attachment: (was: DERBY-623-2a-javadoc.stat)

> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-2b-javadoc.diff, DERBY-623-2b-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan updated DERBY-623:
--

Attachment: DERBY-623-1a.diff
DERBY-623-1a.stat

'DERBY-623-1a.diff' is a patch changing BaseMonitor to use privileged blocks 
for reading system properties and also removing the workaround permissions 
granted in 'derby_tests.policy'. 

Reading of specific properties are done with 'PropertyUtil.getSystemProperty()'.
Besides general feedback, I would like feedback on the following issues:

1) I have not separated reading all system properties (System.getProperties) 
into its own method, because this is done only here (and one place in testing 
code). It is also something we should in general not do. Further, keeping it 
inside the sanity block removes it in insane builds.

2) Should the swallowed exception be logged somewhere?

3) Is the order of the 'startServices' calls important? If not, I would move 
the call inside the sanity block to the end. I also removed the call for insane 
builds, since the variable passed in is only set for sane builds.

The patch is a mix of my own work and the patch I got by Rick Hillegas on 
derby-dev (subject 'Security manager problems with Class.forName()').


> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-1a.diff, DERBY-623-1a.stat, 
> DERBY-623-2b-javadoc.diff, DERBY-623-2b-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan updated DERBY-623:
--

Other Info: [Patch available]

Patch ready for review :)

> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-1a.diff, DERBY-623-1a.stat, 
> DERBY-623-2b-javadoc.diff, DERBY-623-2b-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1088) Verify handling of invalid encryption keys

[Kristian Waagan (JIRA)]

Verify handling of invalid encryption keys 
---

 Key: DERBY-1088
 URL: http://issues.apache.org/jira/browse/DERBY-1088
 Project: Derby
Type: Task
  Components: Services  
Versions: 10.2.0.0
Reporter: Kristian Waagan
Priority: Minor


The handling and checking/verification of external encryption keys passed in to 
Derby is possibly not good enough. Some information was obtained while 
investigating bug DERBY-788. The most important information is copied here, see 
the issue for more background information.

--
"...it is not clearly defined how SecretKeyFactories and Ciphers behave when 
passed a key that is "too long". In most cases I would expect the two to behave 
the same. That means that even though your technique worked for DES and the 
providers you have tried, it may not work for other algorithms or providers." 

--
That said, I think it is interesting that we cant expect the translateKey to 
always translate the key for us.

I found this in the java api for SecretKeySpec.
public SecretKeySpec(byte[] key,
 String algorithm)Constructs a secret key from the given 
byte array.
This constructor does not check if the given bytes indeed specify a secret key 
of the specified algorithm. For example, if the algorithm is DES, this 
constructor does not check if key is 8 bytes long, and also does not check for 
weak or semi-weak keys. In order for those checks to be performed, an 
algorithm-specific key specification class (in this case: DESKeySpec) should be 
used.

In derby code, there is
// Since the key may be a series of bytes generated by an arbitary means
// we need to translate it into a key suitable for the algorithm.
secretKey = skf.translateKey(new SecretKeySpec(secretKey.getEncoded(), 
secretKey.getAlgorithm()));

I think you are right about - that we cannot assume that invalid key checks 
would not happen with the call. I looked at the Java api for 1.4.2 but I didnt 
find any AES specific KeySpec but found for others like DES and DESede.

I think we should open another jira so we can record what we learnt here so we 
can improve this. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-788) 'store/encryptionKey.sql' fails on Solaris 10

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-788?page=all ]
 
Kristian Waagan closed DERBY-788:
-


Fix verified. Created DERBY-1088 to track general issues/weaknesses in the way 
external encryption keys are handled.

> 'store/encryptionKey.sql' fails on Solaris 10
> -
>
>  Key: DERBY-788
>  URL: http://issues.apache.org/jira/browse/DERBY-788
>  Project: Derby
> Type: Bug
>   Components: Services, Test, Regression Test Failure
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
>  Environment: Solaris 10 (generic hardware)
> Sun JDK 5.0 with the 'SunPCKS11-Solaris' Java Security provider
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: DERBY-788-1a.diff, DERBY-788-1a.stat
>
> The 'store/encryptionKey.sql' test fails on Solaris 10.
> Investigation revealed that the failure is caused by a difference in behavior 
> between the 'SunPCKS11-Solaris' provider and other providers (tested with 
> 'SunJCE' and 'IBMJCE').
> The initialization of the DES cipher fails because the 16 byte key (specified 
> in the test) is not translated to a 8 byte DES key by 
> SecretKeyFactory.translateKey(). This might be a bug in the provider (I don't 
> know the spec). Enquiries are being made.
> The exception is being thrown from the constructor of 
> 'impl.services.jce.JCECipherProvider'.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-623?page=comments#action_12369559 ] 

Kristian Waagan commented on DERBY-623:
---

By looking at the description of the bug, I really can't see that the changes I 
implemented are outside the scope of the bug:
"The engine contains code to read system properties using privileged blocks, 
this should be used by the monitor."

About the only thing changed by patch 'DERBY-623-1a.diff' is that the 
properties (including 'System.getProperties()') that was previously read 
outside a privileged block is now read inside one.
I take your previous comment was related to the parts of the code that use the 
result of 'System.getProperties()', and removing this should be easy enough for 
someone that knows the code a little. Based on the comments in the method 
'runWithState', I think I'll step down since I don't know the story of the unit 
tests and the overall function of BaseMonitor.

In my opinion, your previous comment points in the direction of a new Jira 
issue.
That said, discarding the current patch and implementing the changes you talk 
about as part of this issue is fine with me - but for the reason mentioned 
above this is not my itch.

> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-1a.diff, DERBY-623-1a.stat, 
> DERBY-623-2b-javadoc.diff, DERBY-623-2b-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-623) Derby monitor accesses two system properties without using a privileged block when built sane=true

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-623?page=all ]

Kristian Waagan updated DERBY-623:
--

Attachment: DERBY-623-1b.diff
DERBY-623-1b.stat

Dan, I see your point now! I do still mean we need another Jira though, to 
track cleaning up BaseMonitor (primarily method 'runWithState').

'DERBY-623-1b.diff' is a reduced patch, only addressing reading two specific 
system properties in privileged blocks and updating the test policy file 
accordingly.
Patch 'DERBY-623-1a.diff' is now deprecated.
Tests run on Solaris10, Sun 1.5:
derbyall - insane - jars:  derbynet/runtimeinfo.java, jdbcapi/Stream.java and 
jdbcapi/SURTest.junit failed.
derbyall - sane - jars: OK! (stress.multi failed)
derbyall - sane - classes: NSinSameJVM failed.

I don't think the errors are caused by the changes, but if anyone else thinks 
so, speak up!


> Derby monitor accesses two system properties without using a privileged block 
> when built sane=true
> --
>
>  Key: DERBY-623
>  URL: http://issues.apache.org/jira/browse/DERBY-623
>  Project: Derby
> Type: Bug
>   Components: Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Kristian Waagan
> Priority: Minor
>  Attachments: DERBY-623-1a.diff, DERBY-623-1a.stat, DERBY-623-1b.diff, 
> DERBY-623-1b.stat, DERBY-623-2b-javadoc.diff, DERBY-623-2b-javadoc.stat
>
> When built with sane=true and testing with the jars these permissions are 
> required to be granted all the way up the stack, currently this means for the 
> tests granting them to the network server jar.
>   permission java.util.PropertyPermission "derby.monitor.verbose", "read";
>   permission java.util.PropertyPermission "derby.debug.*", "read";
> The engine contains code to read system properties using privileged blocks, 
> this should be used by the monitor.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1061) SqlException while fetching message results in recursive calls between SqlException.getSQLException and Sqlca.getJDBCMessage

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1061?page=all ]

Kristian Waagan updated DERBY-1061:
---

Attachment: JDBC4StackOverflowErrorReproduction.java
derby-1061_2-unix.diff

Had some problems applying diff on Linux, seems to be related to newline style. 
Changed it and posted a updated file 'derby-1061_2-unix.diff'.

Tried out the patch, but it does not seem to fix my problem. I attach the repro 
'JDBC4StackOverflowErrorReproduction.java' that demonstrate the error. Might be 
a different problem than this issue is fixing, if so I hope the patch 
contributer can inform about that.

To run, start a JDBC4 enabled network server (run with JDK 1.6), then run the 
script with JDK 1.6.

> SqlException while fetching message results in recursive calls between 
> SqlException.getSQLException and Sqlca.getJDBCMessage
> 
>
>  Key: DERBY-1061
>  URL: http://issues.apache.org/jira/browse/DERBY-1061
>  Project: Derby
> Type: Sub-task
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>  Attachments: JDBC4StackOverflowErrorReproduction.java, derby-1061.diff, 
> derby-1061_2-unix.diff, derby-1061_2.diff, derbyall_report.txt
>
> stored procedure is used to fetch localised message in net work client
> because of issue 1059 the call to the stored prcedures fails resulting in 
> SqlException. When  SqlException.getSQLException, to set 
> exceptionThrownOnStoredProcInvocation_, is called it again results in a call 
> to SqlException.getMessage which call Sqlca.getJDBCMessage. 
> The cycle repeats and finally ends up with StackOverfilowError
> fixing 1059 will solve this problem temporarily but some other situaltion may 
> cause it again.
> Isuggest seting SqlException itself to exceptionThrownOnStoredProcInvocation_ 
> to break this loop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1095) Closing an embedded connection does not seem to close associated EmbedStatements

[Kristian Waagan (JIRA)]

Closing an embedded connection does not seem to close associated EmbedStatements


 Key: DERBY-1095
 URL: http://issues.apache.org/jira/browse/DERBY-1095
 Project: Derby
Type: Bug
  Components: JDBC  
Versions: 10.2.0.0
Reporter: Kristian Waagan
Priority: Minor


Closing an embedded connection (calling EmbedConnection.close()) does not seem 
to close associated EmbedStatements. 
The severity of the bug is not determined. The least severe case is that the 
internal EmbedStatement variable 'active' is not updated accordingly, the most 
severe case is that the the resources bound to EmbedStatement will not be 
viable for garbage collection until the EmbedStatement itself is (if user keeps 
references to it).
If methods on the statement are called, Derby will correctly throw an 
NoCurrentConnection exception, but the close() method is still never called 
automatically.
The problem also seem to extend down to ResultSet.isClosed(), but this is 
probably due to the bug in EmbedStatement.

Problem detected while fixing DERBY-953; implement Statement.isClosed().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1095) Closing an embedded connection does not seem to close associated EmbedStatements

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1095?page=all ]

Kristian Waagan updated DERBY-1095:
---

Attachment: Derby1095Repro.java

Simple repro for demonstrating the issue. Compile and run with JDK 1.6. Derby 
must also be built with JDK 1.6.
The repro will fail with a "java.sql.SQLTransientConnectionException: No 
current connection" as long as the issue exist.
When the issue is fixed, it should simply print two lines saying both the 
connection and the resultset is closed.

> Closing an embedded connection does not seem to close associated 
> EmbedStatements
> 
>
>  Key: DERBY-1095
>  URL: http://issues.apache.org/jira/browse/DERBY-1095
>  Project: Derby
> Type: Bug
>   Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kristian Waagan
> Priority: Minor
>  Attachments: Derby1095Repro.java
>
> Closing an embedded connection (calling EmbedConnection.close()) does not 
> seem to close associated EmbedStatements. 
> The severity of the bug is not determined. The least severe case is that the 
> internal EmbedStatement variable 'active' is not updated accordingly, the 
> most severe case is that the the resources bound to EmbedStatement will not 
> be viable for garbage collection until the EmbedStatement itself is (if user 
> keeps references to it).
> If methods on the statement are called, Derby will correctly throw an 
> NoCurrentConnection exception, but the close() method is still never called 
> automatically.
> The problem also seem to extend down to ResultSet.isClosed(), but this is 
> probably due to the bug in EmbedStatement.
> Problem detected while fixing DERBY-953; implement Statement.isClosed().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-953) Add miscellaneous Statement methods introduced by JDBC 4

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-953?page=all ]

Kristian Waagan updated DERBY-953:
--

Attachment: DERBY-953-1a.diff
DERBY-953-1a.stat

Uploaded patch 'DERBY-953-1a.diff' for implementing Statement.isClosed() on 
both client and embedded side.
There seems to be a bug in Derby, where Statements are not closed when the 
parent connection is. The problem is not seem when testing the client side, but 
it might still be the case that the problem do occur "under the hood" on the 
server/embedded side. Created issue DERBY-1095 for the bug.

No tests are uploaded yet, as they are dependent on some JUnit changes. Will be 
handled as a separate Jira issue.
Derbyall has not been run for this patch, as it is only created two new methods 
that return variables.
All tests will be run as part of the testing issue. The new tests will 
basically test the existing implementation.

I leave it up to a committer if the patch is delayed until the testing is in 
place or not, as the patch is rather simple.

As a side note, it is possible to implement isClosed() to return the intended 
values despite the bug described. However, in my opinion, this will only mask 
the bug, thus it is better to implement it as it is done in the current patch 
and wait for the bug to be fixed.
If we want to have correct results despite the bug, we only need to have 
isClosed() check the status of the parent connection before checking it's own 
state, but the Statement would actually not be closed even though isClosed() 
says it is...

BTW: getResultSetHoldability() is already implemented (JDBC3?).

> Add miscellaneous Statement methods introduced by JDBC 4
> 
>
>  Key: DERBY-953
>  URL: http://issues.apache.org/jira/browse/DERBY-953
>  Project: Derby
> Type: New Feature
>   Components: JDBC
> Reporter: Rick Hillegas
> Assignee: Kristian Waagan
>  Fix For: 10.2.0.0
>  Attachments: DERBY-953-1a.diff, DERBY-953-1a.stat
>
> As described in the JDBC 4 spec, sections 13.1 and 3.1.
> This adds support for new Statement methods added by JDBC4 and not addressed 
> by other JIRAs: isClosed() and getResultSetHoldability().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1096) Add JUnit tests for Statement.isClosed()

[Kristian Waagan (JIRA)]

Add JUnit tests for Statement.isClosed()


 Key: DERBY-1096
 URL: http://issues.apache.org/jira/browse/DERBY-1096
 Project: Derby
Type: Test
  Components: Test  
Versions: 10.2.0.0
Reporter: Kristian Waagan
 Assigned to: Kristian Waagan 


Add tests for Statement.isClosed() (implemented as part of DERBY-953).
The tests are already written, but because of some "confusion" and diverging 
paths regarding how to get connections when running JUnit tests, they are held 
back.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Deleted: (DERBY-1096) Add JUnit tests for Statement.isClosed()

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1096?page=all ]
 
Kristian Waagan deleted DERBY-1096:
---


> Add JUnit tests for Statement.isClosed()
> 
>
>  Key: DERBY-1096
>  URL: http://issues.apache.org/jira/browse/DERBY-1096
>  Project: Derby
> Type: Test
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan

>
> Add tests for Statement.isClosed() (implemented as part of DERBY-953).
> The tests are already written, but because of some "confusion" and diverging 
> paths regarding how to get connections when running JUnit tests, they are 
> held back.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1097) Add tests for Statement.isClosed()

[Kristian Waagan (JIRA)]

Add tests for Statement.isClosed()
--

 Key: DERBY-1097
 URL: http://issues.apache.org/jira/browse/DERBY-1097
 Project: Derby
Type: Sub-task
  Components: Test  
Versions: 10.2.0.0
 Environment: JDBC4 / JDK 1.6
Reporter: Kristian Waagan
 Assigned to: Kristian Waagan 


Add tests for Statement.isClosed() (implemented as part of DERBY-953).
The tests are already written, but because of some "confusion" and diverging 
paths regarding how to get connections when running JUnit tests, they are held 
back.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1061) SqlException while fetching message results in recursive calls between SqlException.getSQLException and Sqlca.getJDBCMessage

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1061?page=comments#action_12370067 ] 

Kristian Waagan commented on DERBY-1061:


I tried the repro script with unpatched trunk, 'derby-1061_v2' diff and 
'derby-1061-david.diff'. For me, running on Gentoo 2.6.15-gentoo-r7 64bit, only 
'derby-1061-david.diff' solved the problem. I have heard reports that also the 
v2 diff fixed it for others, but it did not for my environment. I would 
therefore recommend we commit patch 'derby-1061-david.diff', assuming that this 
patch also fixes the problem for others seeing this problem.

> SqlException while fetching message results in recursive calls between 
> SqlException.getSQLException and Sqlca.getJDBCMessage
> 
>
>  Key: DERBY-1061
>  URL: http://issues.apache.org/jira/browse/DERBY-1061
>  Project: Derby
> Type: Sub-task
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>  Attachments: JDBC4StackOverflowErrorReproduction.java, 
> derby-1061-david.diff, derby-1061-david.stat, derby-1061.diff, 
> derby-1061_2-unix.diff, derby-1061_2.diff, derbyall_report.txt
>
> stored procedure is used to fetch localised message in net work client
> because of issue 1059 the call to the stored prcedures fails resulting in 
> SqlException. When  SqlException.getSQLException, to set 
> exceptionThrownOnStoredProcInvocation_, is called it again results in a call 
> to SqlException.getMessage which call Sqlca.getJDBCMessage. 
> The cycle repeats and finally ends up with StackOverfilowError
> fixing 1059 will solve this problem temporarily but some other situaltion may 
> cause it again.
> Isuggest seting SqlException itself to exceptionThrownOnStoredProcInvocation_ 
> to break this loop.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1095) Closing an embedded connection does not seem to close associated EmbedStatements

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1095?page=comments#action_12370077 ] 

Kristian Waagan commented on DERBY-1095:


I see your point, but I still think Derby is buggy. The repro script executes a 
statement, closes the connection then asks the resultset if it is closed. The 
resultset says it is not, and based on this the repro then executes an 
operation that causes an exception to be thrown. A correct answer from 
ResultSet.isClosed() would not have caused an exception in the repro.

According to the JDBC4 spec: "A ResultSet is closed if the method close has 
been called on it, or if it is automatically closed."
I thought closing the underlying connection should close all associated 
resources, including the resultset(s). Am I mistaken?

I notice that ResultSet.isClosed() simply returns a variable ('isClosed'), and 
to me it seems that the state of this variable is not maintained correctly 
(have not looked at the code), thus the ResultSet.isClosed() method suffers the 
same problem as Statement.isClosed(). We must either ensure the internal state 
is kept correct, or we must add extra checks to the isClosed methods.
Although the latter solution is very simple (at least for Statement), I 
personally think it would be better if the close methods were executed also 
when the resources are automatically "closed".

Dan, since you have assigned yourself to this issue, can you tell me how your 
(planned) solution would affect the internal state variables in ResultSet and 
Statment, so that I can fix Statement.isClosed accordingly?

> Closing an embedded connection does not seem to close associated 
> EmbedStatements
> 
>
>  Key: DERBY-1095
>  URL: http://issues.apache.org/jira/browse/DERBY-1095
>  Project: Derby
> Type: Bug
>   Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kristian Waagan
> Assignee: Daniel John Debrunner
> Priority: Minor
>  Attachments: Derby1095Repro.java
>
> Closing an embedded connection (calling EmbedConnection.close()) does not 
> seem to close associated EmbedStatements. 
> The severity of the bug is not determined. The least severe case is that the 
> internal EmbedStatement variable 'active' is not updated accordingly, the 
> most severe case is that the the resources bound to EmbedStatement will not 
> be viable for garbage collection until the EmbedStatement itself is (if user 
> keeps references to it).
> If methods on the statement are called, Derby will correctly throw an 
> NoCurrentConnection exception, but the close() method is still never called 
> automatically.
> The problem also seem to extend down to ResultSet.isClosed(), but this is 
> probably due to the bug in EmbedStatement.
> Problem detected while fixing DERBY-953; implement Statement.isClosed().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-919) improve pattern for setting up junit tests

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-919?page=all ]

Kristian Waagan updated DERBY-919:
--

Attachment: BasicDerbyJUnitTest.java
BasicDerbyJUnitTestTest.java
BasicDerbyJUnitTest.html

In my opinion DerbyJUnitTest does not provide the most basic feature a JUnit 
test needs in a proper way - to obtain a connection to some database. The 
critical point is the need to call methods in a specific order for 
getConnection to work (not to get NullPointerExceptions).

Therefore I tried to write my own version of it, mostly to capture 
requirements. I have commented the file pretty well, but I'm sure there are 
still areas where it does not explain enough. Also, there will be lacking 
functionality regarding obtaining a connection, I would appreciate people 
telling if they miss something (see also the questions further down). I also 
wrote a simple test, which I hope demonstrate how BasicDerbyJUnitTest is 
intended to be used. Most notably, it adapts to the settings set by our 
existing test harness.

DerbyJUnitTest has a lot more functionality than BasicDerbyJunitTest, and I 
propose to somehow separate most/all the utility methods from the content of 
BasicDerbyJUnitTest to avoid cluttering the class with a lot of unrelated 
functionality. This can be done either by inserting a new class in the 
inheritance chain, or by creating a(nother) utility class. I do mean that the 
utility methods existing today in DerbyJUnitTest is useful.

Questions regarding BasicDerbyJUnitTest:
a) Do we need to be able to get specific DataSource implementations, like 
EmbeddedSimple-, *ConnectionPool*- and *XADataSource?
(functionality for specifying properties for DataSource connections is not yet 
implemented)
b) Should environment/version information (JVM, OS, maybe hardware) be 
available in/through BasicDerbyJUniTest?

Questions regarding actions for JUnit infrastructure:
1) Is it okay to add yet another way to get connections?
2) I might be able to hack DerbyJUnitTest to work in a similar way as 
BasicDerbyJUnitTest, but it is complicated by dependencies to existing tests. 
Also, it will not be a very clean solution. Is this still something we want to 
do?
3) TestUtil is also used to get connections. It might also be possible to make 
this work as BasicDerbyJunitTest, but then there is no reason to use 
(Basic)DerbyJUnitTest to get connections for JUnit tests. Note that some 
methods, for instance TestUtil.getConnection(), is broken.

Feedback appreciated!

> improve pattern for setting up junit tests
> --
>
>  Key: DERBY-919
>  URL: http://issues.apache.org/jira/browse/DERBY-919
>  Project: Derby
> Type: Sub-task
>   Components: Test
>  Environment: All
> Reporter: Andreas Korneliussen
>  Attachments: BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, 
> BasicDerbyJUnitTestTest.java
>
> The current junit tests cannot be run directly from the java.ui.textrunner by 
> i.e using:
> java junit.textui.TestRunner 
> org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest
> .E
> Time: 0.008
> There was 1 error:
> 1) 
> testBoolean(org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest)java.lang.NullPointerException
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.faultInDriver(DerbyJUnitTest.java:317)
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:345)
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:335)
> at 
> org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest.testBoolean(BooleanTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> FAILURES!!!
> Tests run: 1,  Failures: 0,  Errors: 1
> The reason is that the tests needs to have some fixture being set up before 
> the test can run, and that this is currently supported by calling a bunch of 
> static methods in the correct order to initialize some static members of 
> DerbyJUnitTest.
> The proposed alternative is that the added fixture is set up in the suite() 
> method, which is used by JUnit to get the Test object to be run.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1097) Add tests for Statement.isClosed()

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1097?page=all ]

Kristian Waagan updated DERBY-1097:
---

Attachment: StatementTest.java
StatementTestSetup.java

Updated preliminary tests for Statement.isClosed(). Feedback is appreciated, 
but the files are *not* ready for commit (awaiting review and need to see where 
the JUnit infrastructure discussion lands).

> Add tests for Statement.isClosed()
> --
>
>  Key: DERBY-1097
>  URL: http://issues.apache.org/jira/browse/DERBY-1097
>  Project: Derby
> Type: Sub-task
>   Components: Test
> Versions: 10.2.0.0
>  Environment: JDBC4 / JDK 1.6
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
>  Attachments: StatementTest.java, StatementTestSetup.java
>
> Add tests for Statement.isClosed() (implemented as part of DERBY-953).
> The tests are already written, but because of some "confusion" and diverging 
> paths regarding how to get connections when running JUnit tests, they are 
> held back.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1095) Closing an embedded connection does not seem to close associated EmbedStatements

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1095?page=comments#action_12370138 ] 

Kristian Waagan commented on DERBY-1095:


No Jiras have been opened. First patch for Statement.isClosed() is not even 
committed yet (DERBY-953). Code for ResultSet.isClosed() is committed under 
DERBY-948. 
I was planning to  change the patch for Statement.isClosed() based on 
information about your planned fix, but if you want to do it just unassign me 
from the issue and assign yourself.

> Closing an embedded connection does not seem to close associated 
> EmbedStatements
> 
>
>  Key: DERBY-1095
>  URL: http://issues.apache.org/jira/browse/DERBY-1095
>  Project: Derby
> Type: Bug
>   Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kristian Waagan
> Assignee: Daniel John Debrunner
> Priority: Minor
>  Attachments: Derby1095Repro.java
>
> Closing an embedded connection (calling EmbedConnection.close()) does not 
> seem to close associated EmbedStatements. 
> The severity of the bug is not determined. The least severe case is that the 
> internal EmbedStatement variable 'active' is not updated accordingly, the 
> most severe case is that the the resources bound to EmbedStatement will not 
> be viable for garbage collection until the EmbedStatement itself is (if user 
> keeps references to it).
> If methods on the statement are called, Derby will correctly throw an 
> NoCurrentConnection exception, but the close() method is still never called 
> automatically.
> The problem also seem to extend down to ResultSet.isClosed(), but this is 
> probably due to the bug in EmbedStatement.
> Problem detected while fixing DERBY-953; implement Statement.isClosed().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370182 ] 

Kristian Waagan commented on DERBY-919:
---

I agree that the naming of the class can be changed.

I am not so sure if I fully agree with the proposed change regarding setUp().  
I am more comfortable with having test specific setups performed either in the 
test class' setUp method (called before every test method) or in an associated 
TestSetup.setUp method (executed once before a suite is run). Although I want 
the number of ways to get a connection to be as low as possible, there must be 
ways to perform some specific things - like adding connection attributes when 
testing database encryption or database restore. 
However, having a default setUp that creates a default connection is a good 
idea. The default tearDown must then call either commit or rollback (most 
viable?), then close the connection.

Why do you want to create a data model and then tear it down for every test? I 
see this as useful in some cases, but far from for all.
Also, why introduces abstract methods for something you already have a well 
defined location for - setUp and tearDown?
If you need to add more complex logic to your setUp and tearDown methods, 
getting a default connection is the least of your concerns - "con = 
getConnection();".

The reason why BasicDerbyJUnitTest does not use TestUtil to get connections are 
twofold; some of the methods have limitations, and I thought it would be good 
to separate the mean of obtaining a connection for new JUnit tests and old 
tests. 
For the former, there are no "getConnection()" method. Why specify arguments 
when you don't need to? Also, "getConnection(String, String)" only returns 
embedded connections when using DriverManager.
For the latter, starting from scratch is good for seeing if we  can get rid of 
some unneded things that have piled up as time has passed. I do know that it 
involves some code duplication, but I find this acceptable in this case.

> improve pattern for setting up junit tests
> --
>
>  Key: DERBY-919
>  URL: http://issues.apache.org/jira/browse/DERBY-919
>  Project: Derby
> Type: Sub-task
>   Components: Test
>  Environment: All
> Reporter: Andreas Korneliussen
>  Attachments: BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, 
> BasicDerbyJUnitTestTest.java
>
> The current junit tests cannot be run directly from the java.ui.textrunner by 
> i.e using:
> java junit.textui.TestRunner 
> org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest
> .E
> Time: 0.008
> There was 1 error:
> 1) 
> testBoolean(org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest)java.lang.NullPointerException
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.faultInDriver(DerbyJUnitTest.java:317)
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:345)
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:335)
> at 
> org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest.testBoolean(BooleanTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> FAILURES!!!
> Tests run: 1,  Failures: 0,  Errors: 1
> The reason is that the tests needs to have some fixture being set up before 
> the test can run, and that this is currently supported by calling a bunch of 
> static methods in the correct order to initialize some static members of 
> DerbyJUnitTest.
> The proposed alternative is that the added fixture is set up in the suite() 
> method, which is used by JUnit to get the Test object to be run.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Resolved: (DERBY-809) Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-809?page=all ]
 
Kristian Waagan resolved DERBY-809:
---

Fix Version: (was: 10.1.3.0)
 Resolution: Fixed

Documentation has been fixed. I will close this issue in a few days, unless 
someone signals they want to port this to earlier branches.

> Incorrect documentation for 'NetworkServerControl.logConnections(boolean)'
> --
>
>  Key: DERBY-809
>  URL: http://issues.apache.org/jira/browse/DERBY-809
>  Project: Derby
> Type: Bug
>   Components: Documentation, Javadoc
> Versions: 10.0.2.1, 10.1.1.2, 10.1.2.1
> Reporter: Kristian Waagan
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: DERBY-809-1b-javadoc.diff, DERBY-809-1b-javadoc.stat, 
> derby809.diff, radminconfigdb2jdrdalogconnections.html, tadminlogfile.html
>
> The documentation for 'NetworkServerControl.logConnections(boolean)' states 
> that Derby logs both connections and disconnections. As of 10.1.2.1 and (all) 
> earlier releases, this is not true. The documentation should be corrected to 
> avoid confusing users.
> The thought of adding logging of disconnections has also been posted on 
> derby-dev.
> Byran Pendleton identified the following documentation with the incorrect 
> description:
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/drda/NetworkServerControl.html
> http://db.apache.org/derby/docs/10.1/adminguide/radminconfigdb2jdrdalogconnections.html
> http://db.apache.org/derby/docs/10.0/manuals/admin/hubprnt23.html
> http://db.apache.org/derby/docs/10.1/adminguide/tadminlogfile.html
> Should we fix this in 10.0? If yes, please update fix versions for this issue.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1095) Closing an embedded connection does not seem to close associated EmbedStatements

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1095?page=comments#action_12370338 ] 

Kristian Waagan commented on DERBY-1095:


I do not disagree that it is easy to implement isClosed to return the intended 
results (I commented this when uploading the patch for DERBY-953).

However, by looking briefly at EmbedConnection, I cannot immediatly see how 
assoicated resources are closed when EmbedConnection.close() is called. Can 
someone familiar with the code take a few minutes to briefly explain how it is 
done? (I'm referring to reason 1 in the previous comment by Dan)
With regard to statements and resultsets, are these being closed explicitly or 
are we only nulling out the references to them?

> Closing an embedded connection does not seem to close associated 
> EmbedStatements
> 
>
>  Key: DERBY-1095
>  URL: http://issues.apache.org/jira/browse/DERBY-1095
>  Project: Derby
> Type: Bug
>   Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kristian Waagan
> Assignee: Daniel John Debrunner
> Priority: Minor
>  Attachments: Derby1095Repro.java
>
> Closing an embedded connection (calling EmbedConnection.close()) does not 
> seem to close associated EmbedStatements. 
> The severity of the bug is not determined. The least severe case is that the 
> internal EmbedStatement variable 'active' is not updated accordingly, the 
> most severe case is that the the resources bound to EmbedStatement will not 
> be viable for garbage collection until the EmbedStatement itself is (if user 
> keeps references to it).
> If methods on the statement are called, Derby will correctly throw an 
> NoCurrentConnection exception, but the close() method is still never called 
> automatically.
> The problem also seem to extend down to ResultSet.isClosed(), but this is 
> probably due to the bug in EmbedStatement.
> Problem detected while fixing DERBY-953; implement Statement.isClosed().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1095) Closing an embedded connection does not seem to close associated EmbedStatements

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1095?page=comments#action_12370518 ] 

Kristian Waagan commented on DERBY-1095:


Thanks Dan.

The slides are nice :) Assuming they are still up-to-date, I would recommend 
people who haven't looked at them do so!

> Closing an embedded connection does not seem to close associated 
> EmbedStatements
> 
>
>  Key: DERBY-1095
>  URL: http://issues.apache.org/jira/browse/DERBY-1095
>  Project: Derby
> Type: Bug
>   Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kristian Waagan
> Assignee: Daniel John Debrunner
> Priority: Minor
>  Attachments: Derby1095Repro.java, derby-1095-ResultSet.isClosed-v1.diff, 
> derby-1095-ResultSet.isClosed-v1.stat
>
> Closing an embedded connection (calling EmbedConnection.close()) does not 
> seem to close associated EmbedStatements. 
> The severity of the bug is not determined. The least severe case is that the 
> internal EmbedStatement variable 'active' is not updated accordingly, the 
> most severe case is that the the resources bound to EmbedStatement will not 
> be viable for garbage collection until the EmbedStatement itself is (if user 
> keeps references to it).
> If methods on the statement are called, Derby will correctly throw an 
> NoCurrentConnection exception, but the close() method is still never called 
> automatically.
> The problem also seem to extend down to ResultSet.isClosed(), but this is 
> probably due to the bug in EmbedStatement.
> Problem detected while fixing DERBY-953; implement Statement.isClosed().

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-919) improve pattern for setting up junit tests

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-919?page=comments#action_12370620 ] 

Kristian Waagan commented on DERBY-919:
---

Do we still need to have clients for both DB2 JCC and the "old net" framework?
Based on contents of various classes, there seem to be some confusion (ie. that 
DB2JCC has JDBC prefix "jdbc:derby:net", others use "jdbc:db2:").
Am I correct when saying we only need the "jdbc:derby:net" framework in the 
JDBCClient class, and that this client should be named either "DERBYNET" or 
"JCC"? 
(but not "DB2JCC", as this imply we are connecting to DB2, not Derby)

Is the EmbeddedSimpleDataSource the only mean to create a connection in JSR 169?

> improve pattern for setting up junit tests
> --
>
>  Key: DERBY-919
>  URL: http://issues.apache.org/jira/browse/DERBY-919
>  Project: Derby
> Type: Sub-task
>   Components: Test
>  Environment: All
> Reporter: Andreas Korneliussen
>  Attachments: BasicDerbyJUnitTest.html, BasicDerbyJUnitTest.java, 
> BasicDerbyJUnitTestTest.java, JDBCClient.java, TestConfiguration.java
>
> The current junit tests cannot be run directly from the java.ui.textrunner by 
> i.e using:
> java junit.textui.TestRunner 
> org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest
> .E
> Time: 0.008
> There was 1 error:
> 1) 
> testBoolean(org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest)java.lang.NullPointerException
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.faultInDriver(DerbyJUnitTest.java:317)
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:345)
> at 
> org.apache.derbyTesting.functionTests.util.DerbyJUnitTest.getConnection(DerbyJUnitTest.java:335)
> at 
> org.apache.derbyTesting.functionTests.tests.junitTests.lang.BooleanTest.testBoolean(BooleanTest.java:136)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> FAILURES!!!
> Tests run: 1,  Failures: 0,  Errors: 1
> The reason is that the tests needs to have some fixture being set up before 
> the test can run, and that this is currently supported by calling a bunch of 
> static methods in the correct order to initialize some static members of 
> DerbyJUnitTest.
> The proposed alternative is that the added fixture is set up in the suite() 
> method, which is used by JUnit to get the Test object to be run.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-982) sysinfo api does not provide genus name for client

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-982?page=comments#action_12421542 ] 

Kristian Waagan commented on DERBY-982:
---

Hi Andrew,

I reviewed the version 4 patch. Looks good to me, but I have one minor comment 
on the JUnit test.
Although not too important for this test, it would be nice to have the 
constructor that takes a String argument. This makes it possible to select/run 
specific test methods from the/a suite method.

Also, according to the JUnit documentation, the noarg constructor is there only 
to support serialization (which we don't require).


Thanks,

> sysinfo api does not provide genus name for client
> --
>
> Key: DERBY-982
> URL: http://issues.apache.org/jira/browse/DERBY-982
> Project: Derby
>  Issue Type: Bug
>  Components: Tools
>Affects Versions: 10.1.2.1
>Reporter: Kathey Marsden
> Assigned To: Andrew McIntyre
> Fix For: 10.2.0.0
>
> Attachments: derby-982-v4.diff, derby-982.diff, derby-982_v2.diff, 
> derby-982_v3.diff
>
>
> The sysinfo api does not provide access to the genus name for client to allow 
> applications to retrieve information from sysinfo about the client 
> information.
> http://db.apache.org/derby/javadoc/publishedapi/org/apache/derby/tools/sysinfo.html
> Note: Currently ProductGenusNames has a genus name for network server but 
> network server is closely tied to  the engine so should always have the same 
> version.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-609) Returning ByteArrayInputStream from ResultSet is not appropriate

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-609?page=all ]

Kristian Waagan closed DERBY-609.
-

Fix Version/s: 10.1.2.1
   Resolution: Fixed

Closing this, seems completed. No activity since October 2005.

> Returning ByteArrayInputStream from ResultSet is not appropriate
> 
>
> Key: DERBY-609
> URL: http://issues.apache.org/jira/browse/DERBY-609
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.1.2.1
>
> Attachments: DERBY-609.patch
>
>
> Point where it is not appropriate :
> 1: Compatibility
> The InputStream returned from result set is closed when other get method 
> was called .
> http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html
> However closing ByteArrayInputStream have no effect at all .
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/ByteArrayInputStream.html#close()
> It seems intended that closable InputStream was returned from result set .
> If ByteArrayInputStream was returned from result set , the stream cannot be 
> closed, 
> and compatibility would be lost .
> 2: Performance of program 
> Information inputted from ByteArrayInputStream needs to be expanded to memory 
> as byte[] object .
> If large byte[] object was created for each ByteArrayInputStream object , 
> program will run in bad performance .
> // I think problem is when information typed as LOB was retrieved from 
> ResultSet .
> // Because such informations typed as LOB tend to be large amount .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-609) Returning ByteArrayInputStream from ResultSet is not appropriate

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-609?page=all ]

Kristian Waagan closed DERBY-609.
-

Fix Version/s: 10.2.0.0
   (was: 10.1.2.1)
   Resolution: Fixed

> Returning ByteArrayInputStream from ResultSet is not appropriate
> 
>
> Key: DERBY-609
> URL: http://issues.apache.org/jira/browse/DERBY-609
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.2.0.0
>
> Attachments: DERBY-609.patch
>
>
> Point where it is not appropriate :
> 1: Compatibility
> The InputStream returned from result set is closed when other get method 
> was called .
> http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html
> However closing ByteArrayInputStream have no effect at all .
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/ByteArrayInputStream.html#close()
> It seems intended that closable InputStream was returned from result set .
> If ByteArrayInputStream was returned from result set , the stream cannot be 
> closed, 
> and compatibility would be lost .
> 2: Performance of program 
> Information inputted from ByteArrayInputStream needs to be expanded to memory 
> as byte[] object .
> If large byte[] object was created for each ByteArrayInputStream object , 
> program will run in bad performance .
> // I think problem is when information typed as LOB was retrieved from 
> ResultSet .
> // Because such informations typed as LOB tend to be large amount .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (DERBY-609) Returning ByteArrayInputStream from ResultSet is not appropriate

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-609?page=all ]

Kristian Waagan reopened DERBY-609:
---

 
Reopened issue to correct fix version.

> Returning ByteArrayInputStream from ResultSet is not appropriate
> 
>
> Key: DERBY-609
> URL: http://issues.apache.org/jira/browse/DERBY-609
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.2.0.0
>
> Attachments: DERBY-609.patch
>
>
> Point where it is not appropriate :
> 1: Compatibility
> The InputStream returned from result set is closed when other get method 
> was called .
> http://java.sun.com/j2se/1.5.0/docs/api/java/sql/ResultSet.html
> However closing ByteArrayInputStream have no effect at all .
> http://java.sun.com/j2se/1.5.0/docs/api/java/io/ByteArrayInputStream.html#close()
> It seems intended that closable InputStream was returned from result set .
> If ByteArrayInputStream was returned from result set , the stream cannot be 
> closed, 
> and compatibility would be lost .
> 2: Performance of program 
> Information inputted from ByteArrayInputStream needs to be expanded to memory 
> as byte[] object .
> If large byte[] object was created for each ByteArrayInputStream object , 
> program will run in bad performance .
> // I think problem is when information typed as LOB was retrieved from 
> ResultSet .
> // Because such informations typed as LOB tend to be large amount .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-596) jdbcapi/resultsetStream.java fails in DerbyNetClient Framework

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-596?page=all ]

Kristian Waagan closed DERBY-596.
-


Verified that the failure no longer occurs when running 
jdbcapi/resultsetStream.java under DerbyNetClient with Sun JDK 1.3, 1.4, 1.5 
and Mustang.

>  jdbcapi/resultsetStream.java fails in DerbyNetClient Framework
> ---
>
> Key: DERBY-596
> URL: http://issues.apache.org/jira/browse/DERBY-596
> Project: Derby
>  Issue Type: Bug
>  Components: Network Client, Network Server, Test
>Affects Versions: 10.2.0.0
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.2.0.0
>
>
> Working in DERBY-525, I found that  jdbcapi/resultsetStream.java , which was 
> originally excluded from DerbyNetClient Framework, fails, if added to.
> Next is resultsetStream.diff :
> -- Java Information --
> Java Version:1.4.2_08
> Java Vendor: Sun Microsystems Inc.
> Java home:   /usr/local/j2sdk1.4.2_08/jre
> Java classpath:  /home/naka/ProgramDev/derby/trunk/jars/sane/derby.jar
> :/home/naka/ProgramDev/derby/trunk/jars/sane/derbyclient.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbytools.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbynet.jar:
> /usr/local/share/java/db2jcc/lib/db2jcc.jar:
> /usr/local/share/java/db2jcc/lib/db2jcc_license_c.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyTesting.jar:
> /home/naka/ProgramDev/derby/trunk/tools/java/jakarta-oro-2.0.8.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_de_DE.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_es.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_fr.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_it.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_ja_JP.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_ko_KR.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_pt_BR.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_zh_CN.jar:
> /home/naka/ProgramDev/derby/trunk/jars/sane/derbyLocale_zh_TW.jar
> OS name: Linux
> OS architecture: i386
> OS version:  2.4.27-2-386
> Java user name:  naka
> Java user home:  /home/naka
> Java user dir:   /home/naka/ProgramDev/testDerby/20051001
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.4
> - Derby Information 
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derby.jar] 10.2.0.0 alpha - 
> (292740M)
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbyclient.jar] 10.2.0.0 alpha 
> - (292740M)
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbytools.jar] 10.2.0.0 alpha - 
> (292740M)
> [/home/naka/ProgramDev/derby/trunk/jars/sane/derbynet.jar] 10.2.0.0 alpha - 
> (292740M)
> --
> - Locale Information -
> Current Locale :  [English/United States [en_US]]
> Found support for locale: [de_DE]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [es]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [fr]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [it]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [ja_JP]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [ko_KR]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [pt_BR]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [zh_CN]
>version: 10.2.0.0 alpha - (292740M)
> Found support for locale: [zh_TW]
>version: 10.2.0.0 alpha - (292740M)
> --
> Framework: DerbyNetClient
> *** Start: resultsetStream jdk1.4.2_08 DerbyNetClient 2005-10-02 13:56:27 ***
> 8a9
> > FAIL - stream was not closed after a get*() call. class 
> > java.io.ByteArrayInputStream
> 12 del
> < EXPECTED SQLSTATE(XSDA4): An unexpected exception was thrown
> 13 del
> < EXPECTED SQLSTATE(XJ001): Java exception: 'Input stream held less data than 
> requested length.: java.io.IOException'.
> 14 del
> < EXPECTED SQLSTATE(XSDA4): An unexpected exception was thrown
> 15 del
> < EXPECTED SQLSTATE(XJ001): Java exception: 'Input stream held less data than 
> requested length.: java.io.IOException'.
> 15a13,14
> > EXPECTED SQLSTATE(null): End of Stream prematurely reached while reading 
> > InputStream, parameter #2.  Remaining data has been padded with 0x0.
> > EXPECTED SQLSTATE(null): The specified size of the InputStream, parameter 
> > #2, is less than the actual InputStream length
> Test Failed.
> *** End:   resultsetStream jdk1.4.2_08 DerbyNetClient 2005-10-02 13:56:49 ***

-- 
This message is automatically generated by JIRA.
-
If you

[jira] Created: (DERBY-1519) 'setAsciiStream' uses different encodings for embedded and client

[Kristian Waagan (JIRA)]

'setAsciiStream' uses different encodings for embedded and client
-

 Key: DERBY-1519
 URL: http://issues.apache.org/jira/browse/DERBY-1519
 Project: Derby
  Issue Type: Bug
  Components: JDBC, Network Client
Affects Versions: 10.1.3.1, 10.2.0.0
Reporter: Kristian Waagan


The JDBC method 'setAsciiStream' uses different encodings for embedded and 
client. In the embedded driver, "ISO-8859-1" is used, in the client driver 
"US-ASCII" is used. The former is 8-bit, the latter is 7-bit. According to 
JDBC, the 8-bit encoding should be used for ASCII (see 
http://db.apache.org/derby/papers/JDBCImplementation.html#GetAsciiStream%28%29 
).

The method 'getAsciiStream' should also be made to match in the two drivers.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1524) Add assertEquals overloads for InputStream and Reader

[Kristian Waagan (JIRA)]

Add assertEquals overloads for InputStream and Reader
-

 Key: DERBY-1524
 URL: http://issues.apache.org/jira/browse/DERBY-1524
 Project: Derby
  Issue Type: Sub-task
Reporter: Kristian Waagan




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1524) Add assertEquals overloads for InputStream and Reader

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1524?page=all ]

Kristian Waagan updated DERBY-1524:
---

  Component/s: Test
  Description: 
Add assertEquals overloads for java.io.InputStream and java.io.Reader to 
BaseTestCase.

Implementations of these can be found in test jdbc4/ResultSetTest.java and can 
be moved or used as reference.
Affects Version/s: 10.2.0.0
 Priority: Minor  (was: Major)

> Add assertEquals overloads for InputStream and Reader
> -
>
> Key: DERBY-1524
> URL: http://issues.apache.org/jira/browse/DERBY-1524
> Project: Derby
>  Issue Type: Sub-task
>  Components: Test
>Affects Versions: 10.2.0.0
>Reporter: Kristian Waagan
>Priority: Minor
>
> Add assertEquals overloads for java.io.InputStream and java.io.Reader to 
> BaseTestCase.
> Implementations of these can be found in test jdbc4/ResultSetTest.java and 
> can be moved or used as reference.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-3b-embimpl-and-tests.diff
derby-1417-3b-embimpl-and-tests.stat

Thanks for the review Knut Anders!
My replies follow the order of the questions in your comment.

 - I forgot to duplicate the methods from PreparedStatement40 in
   EmbedCallableStatement40 (no inheritance here). I have added them in the
   new patch. I followed the "policy" of keeping unimplemented methods in the
   JDBC40 specific classes. I still get 21 failures in VerifySignatures, but
   all are in the Brokered* classes.

 - Brokered* methods will be added in a follow-up patch (I feel this patch is
   already too big). Since no JDBC4 tests are picking up these missing methods
   except for the dynamic ones (VerifySignatures, UnsupportedVetter,
   ClosedObjects), I think maybe we should run more of our tests with
   XA/pooled connections. Does anyone else feel the same?

 - I have fixed the JavaDoc errors.

EmbedResultSet.java:
 - Removed "@throws SQLFeatureNotSupported" in JavaDoc.
 
 - Shortened long line.

 - Yes, the switch can be factored out. I decided to put this on hold, as I'm
   not sure what is the best approach. It makes sense to factor out the
   occurences where only the type is checked, and no other action is taken
   based on the type. This is typical for the ResultSet.updateX methods, but
   not for ResultSet.getXStream methods. Not sure if
   DataTypeDescriptor.isJDBCTypeEquivalent() can be used as it is, for
   instance it does not know anything about Types.BLOB.
   The common mechanism should/could also be used across different classes,
   for instance in both EmbedResultSet and EmbedPreparedStatement. So, where
   should it be placed?
   Feel free to add a Jira to track this.

EmbedPreparedStatement.java:
 - Ok. Names changed.

 - Removed "@throws SQLFeatureNotSupported" in JavaDoc.

 - Shortened long line.

 - I removed the comments about DB2 compliance (these were already present
   before my patch).

ReaderToUTF8Stream.java:
 - Was not sure how to handle this. I guess only getting this with debug/sane
   builds is good enough. I replaced the exception with a
   SanityManager.DEBUG block.

Tests:
 - I added DERBY-1524 for the assertEquals-overloads (a sub-task of 1122).

 - This will be added as part of DERBY-1473. Might have to do something on the
   client side also.

In addition to the comments from the review, I changed the following (not
related to my patch):
 - Modified EmbedResultSet.updateAsciiStream(int,InputStream,long) to use
   updateCharacterStreamInternal instead of updateCharacterStream to avoid
   duplicate checks.

 - Removed blank line at the end of EmbedResultSet.java.

 - Corrected spelling error in PreparedStatementTest: Inerted -> Inserted


I reran suite jdbc4. Only saw 3 expected failures: ClosedObjectTest,
UnsupportedVetter and VerifySignatures.
'derby-1417-3b-embimpl-and-tests.diff' is ready for more review and/or commit.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String p

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-4a-disable-psTestsDnc.diff

'derby-1417-4a-disable-psTestsDnc.diff' disables 5 tests in 
jdbc4/PreparedStatementTest for DerbyNetClient.
This error must have slipped off the table and crawled under the carpet... 
Sorry for the noise. The tests will be enabled again when the client-side 
implementation is done.

Please commit this as soon as possible, to stop the test from failing in the 
nightly runs. Thanks.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-5a-brokered.diff
derby-1417-5a-brokered.stat

'derby-1417-5a-brokered.diff' adds the new overloads to the 
iapi/jdbc/Brokered*-classes.
The jdbc4 suite now runs without failure under embedded. Note that there will 
still be failures when running under DerbyNetClient.
Comments:
 - Note the method duplication in BrokeredCallableStatement40. 
 - I have not added JavaDoc for methods that are not implemented. 
 - I updated the UnsupportedVetter-test with the new methods we don't support; 
  * methods with named parameters in CallableStatement
  * methods for unsupported datatypes in Prepared-/CallableStatement and 
ResultSet.

Patch is ready for review.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Derby Info: [Patch Available]

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1527) Factor out type checks in EmbedResultSet and EmbedPreparedStatement

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1527?page=comments#action_12422375 ] 

Kristian Waagan commented on DERBY-1527:


I reviewed the patch, and it looks ready for commit.

The patch applies, no build failures, and I ran the jdbc40 suite as a sanity 
check (no failures for embedded).

Do we have any tests for checking which set/update-methods can be used on the 
various datatypes?
If not, we ought to create a Jira for making one.


Thank you for doing this clean-up.

> Factor out type checks in EmbedResultSet and EmbedPreparedStatement
> ---
>
> Key: DERBY-1527
> URL: http://issues.apache.org/jira/browse/DERBY-1527
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Knut Anders Hatlen
> Assigned To: Knut Anders Hatlen
>Priority: Minor
> Attachments: derby-1527-v1.diff, derby-1527-v1.stat
>
>
> EmbedPreparedStatement and EmbedResultSet have many occurrences of
> switch (...) {
> case Types.CHAR:
> case Types.VARCHAR:
> case Types.LONGVARCHAR:
> case Types.CLOB:
> break;
> default:
> throw dataTypeConversion(...);
> }
> and
> switch (...) {
> case Types.BINARY:
> case Types.VARBINARY:
> case Types.LONGVARBINARY:
> case Types.BLOB:
> break;
> default:
> throw dataTypeConversion(...);
> }
> Instead of having many copies of this code, it would be good to factor
> it out into methods that can be shared. For instance, one could add
> these methods to DataTypeDescriptor:
>   public static boolean isAsciiStreamCompatible(int jdbcType)
>   public static boolean isBinaryStreamCompatible(int jdbcType)
>   public static boolean isCharacterStreamCompatible(int jdbcType)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Derby Info: [Patch Available]

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-6a-clientimpl.diff
derby-1417-6a-clientimpl.stat

'derby-1417-6a-clientimpl.diff' adds the client side implementations of the 
length less overloads.
I had to make some changes "here and there" to get this working, and I remind 
people that this is a somewhat temporarily implementation due to the fact that 
we do not (yet) support streaming of data with unknown length.
Therefore, streams used for input are exhausted and materialized in memory 
before they are sent from the client to the server.

This is the last patch adding new JDBC 4 methods, but there will be at least 
one more follow-up patch for the embedded driver (to fix OutOfMemoryError), and 
DERBY-1473 should be completed as well.

Comments to the patch:
* LOBs are materialized when execute* is called (in [BC]lob.length()).
* I renamed and generalized the existing class UTF32BEEncodedInputStream to 
reuse code. It now delivers InputStreams with UTF8 or UTF16 encoding and is 
used to create a stream from a reader.
* I continued to use the encoding "US-ASCII" over "ISO-8859-1" to be 
consistent. This will be handled by DERBY-1519.
* I added ByteArrayCombinerStream (and a test) to reduce memory usage on the 
client.
* I enabled tests temporarily disabled for DerbyNetClient.

I ran suite jdbc4 without failures. Because I'm running a bit short of time, I 
post the patch before my derbyalls are finished. I will add the results 
tomorrow.
Patch is ready for review.

For the committer: I did a 'svn rename' on UTF32BEEncodedInputStream. I think 
it should be handled by the diff, but keep an extra eye on it :)

Thanks,

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String col

[jira] Commented: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1417?page=comments#action_12423610 ] 

Kristian Waagan commented on DERBY-1417:


Hi Tomohito,

Are you talking about the buffer for the PublicBufferOutputStream (which is a 
subclass of ByteArrayOutputStream)?
I agree it might not be optimal, but ByteArrayOutputStream grows the buffer as 
needed. If we are reading chars outside ISO-8859-1, the ByteArrayOutputStream 
would have to double its internal buffer once for every 1024 characters we read 
(from 2048 bytes to 4096 bytes).
My take on this, is that a separate Jira should be logged for this issue if it 
is worth optimizing/analyzing.

Also, I was very confused by the naming of the file UTF32BEEncodedInputStream 
and its comments. I found that it actually used the encoding 
UnicodeBigUnmarked, which is the Java name for UTF-16BE. But the name and the 
comments claimed UTF-32BE was used.

As for the subclasses, I thought about this, but decided not to do it, since 
the class is completely internal. If we do it, however, we can make the one for 
UnicodeBigUnmarked package private, and the UTF8 one public, since the latter 
one is the only one used outside the client/net package. I also thought about 
ways to restrict the available encodings, but again, this is an internal class 
and we should be able to choose only standard encodings (always available in 
Java). I mentioned this in the class comment. If you feel strongly about this, 
I can make 3 classes (please let me know).


Thanks for looking at the patch :)

BTW: My derbyalls showed a lot of unrelated errors (I got 18 total with 1.6), 
so I need time to study the results before I post anything. However,  with 1.4 
I only got a few known issues.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String c

[jira] Commented: (DERBY-1578) A number of tests fail due to rework on toString() method of SQLException

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1578?page=comments#action_12423631 ] 

Kristian Waagan commented on DERBY-1578:


Here's a list of candidates :)

lang/compressTable.sql
lang/nestedCommit.sql
lang/outparams.java
lang/procedure.java
lang/procedureInTrigger.sql
tools/importExportThruIJ.sql
tools/ieptests.sql
tools/iepnegativetests.sql
jdbcapi/statementJdbc20.java
jdbcapi/statementJdbc30.java
jdbcapi/parameterMapping.java
i18n/iepnegativetests_ES.sql
store/TransactionTable.sql
store/streamingColumn.java

> A number of tests fail due to rework on toString() method of SQLException
> -
>
> Key: DERBY-1578
> URL: http://issues.apache.org/jira/browse/DERBY-1578
> Project: Derby
>  Issue Type: Bug
>  Components: Regression Test Failure
> Environment: JDK 1.5
>Reporter: David Van Couvering
> Assigned To: David Van Couvering
>
> The following tests are having regressions.  The DerbyNet failures make 
> sense, I don't test DerbyNet on my environment.  The other failures I should 
> have caught.
> procedureInTrigger
> procedure (DerbyNet and DerbyNetClient)
> importExport (DerbyNet)
> ieptests (DerbyNet)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-6b-clientimpl.diff

'derby-1417-6b-clientimpl.diff' deprecates 6a.
Changes:
 1) Add missing license to two files.
 2) Added static factory methods to EncodedInputStream for UTF-8- and 
UTF-16BE-streams.
 Set byte buffer size to 3 and 2 times size of char buffer, respectively.
 'createUTF8Stream' is public, 'createUTF16BEStream' is package private.
 I made class 'EncodedInputStream' public final, and its constructor 
private.
 3) Updated two classes (Request and Clob) to use the new static methods.

When applying patch, do a 'svn rename 
java/client/org/apache/derby/client/net/UTF32BEEncodedInputStream.java 
java/client/org/apache/derby/client/net/EncodedInputStream.java' first. Just 
press ENTER (answer no) at the two prompts when running the patch tool.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat, 
> derby-1417-6b-clientimpl.diff
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-6c-clientimpl.diff

'derby-1417-6c-clientimpl.diff' deprecates 6b.
Added both size of the character buffer and the initial size of the byte buffer 
to the constructor of EncodedInputStream.
Made the required changes elsewhere due to this addition.

Suite jdbc40 ran without failures, and all failures seen during derbyall (17 in 
total) have been verified to be caused by other issues (15 because of 
DERBY-1578 and 1 because of local environment errors and 1 has already been 
fixed in trunk).

The 'svn rename' command must still be run before the patch is applied.

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat, 
> derby-1417-6b-clientimpl.diff, derby-1417-6c-clientimpl.diff
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1510) 'SQLBinary.readFromStream' can enter endless loop

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1510?page=all ]

Kristian Waagan updated DERBY-1510:
---

Attachment: derby-1510-1a.diff

'derby-1510-1a.diff' makes sure derby does not enter an endless loop if 
InputStream.available() returns 0 and we have already filled the buffer. 
Before, it was possible to start looping with a read(byte[], pos, 0) call (my 
laptop used 100% CPU for nearly 29 hours because of this...).

The fix is minimal. If anyone wants to rewrite more of the method, please do so.

Please review/commit the patch.

> 'SQLBinary.readFromStream' can enter endless loop
> -
>
> Key: DERBY-1510
> URL: http://issues.apache.org/jira/browse/DERBY-1510
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, SQL
>Affects Versions: 10.2.0.0
>Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
>Priority: Minor
> Attachments: derby-1510-1a.diff
>
>
> Under certain circumstances, the method 'SQLBinary.readFromStream' can enter 
> an endless loop while reading the stream. The following must be true for the 
> bug to occur: 
>  * There must be more data in the stream than what can fit into the initial 
> buffer (32 K).
>  * The method 'available' of the stream returns 0.
> Since the default return value for 'InputStream.available' is 0, and the 
> method reading the stream can be used for data types CHAR FOR BIT DATA, 
> VARCHAR FOR BIT DATA and LONG VARCHAR FOR BIT DATA, the bug should be fixed. 
> The maximum length is 32700 bytes.
> The method will also be used by SQLBlob, but it may be better to introduce a 
> new streaming method for it, since the current implementation has 
> memory-problems for large data (materializes the whole stream). A separate 
> issue should/will be created for this.
> The symptom for this bug is a hang when calling one of the execute methods of 
> Prepared- or CallableStatement and maybe also certain set methods in 
> ResultSet.
> The visibility of this bug is very low, but the impact is severe/critical. 
> When the JDBC 4 length less streaming overloads are added (DERBY-1417), 
> visibility might increase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1510) 'SQLBinary.readFromStream' can enter endless loop

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1510?page=all ]

Kristian Waagan updated DERBY-1510:
---

Derby Info: [Patch Available]

> 'SQLBinary.readFromStream' can enter endless loop
> -
>
> Key: DERBY-1510
> URL: http://issues.apache.org/jira/browse/DERBY-1510
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, SQL
>Affects Versions: 10.2.0.0
>Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
>Priority: Minor
> Attachments: derby-1510-1a.diff
>
>
> Under certain circumstances, the method 'SQLBinary.readFromStream' can enter 
> an endless loop while reading the stream. The following must be true for the 
> bug to occur: 
>  * There must be more data in the stream than what can fit into the initial 
> buffer (32 K).
>  * The method 'available' of the stream returns 0.
> Since the default return value for 'InputStream.available' is 0, and the 
> method reading the stream can be used for data types CHAR FOR BIT DATA, 
> VARCHAR FOR BIT DATA and LONG VARCHAR FOR BIT DATA, the bug should be fixed. 
> The maximum length is 32700 bytes.
> The method will also be used by SQLBlob, but it may be better to introduce a 
> new streaming method for it, since the current implementation has 
> memory-problems for large data (materializes the whole stream). A separate 
> issue should/will be created for this.
> The symptom for this bug is a hang when calling one of the execute methods of 
> Prepared- or CallableStatement and maybe also certain set methods in 
> ResultSet.
> The visibility of this bug is very low, but the impact is severe/critical. 
> When the JDBC 4 length less streaming overloads are added (DERBY-1417), 
> visibility might increase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Attachment: derby-1417-6d-clientimpl.diff

Thanks for the review Knut Anders.
I have uploaded revision d of patch 6.
See my comments and answers below.

  1) You see this bug because you are able to access the Clob-object
 being used for input to the database. This is a shortcut taken in
 my implementation, based on the (faulty) assumption that the
 Clob-object is never passed to the user. Internally, the number of
 bytes are used. See comment at the bottom.

  2) Fixed. The list of supported encodings is found either in the
 package summary for java.lang (JDK < 1.4), or in the JavaDoc for
 java.nio.Charset.

  3) I have removed it from the constructor I added (which was a copy of
 the existing one), but left it as it is in the constructor that was
 already there. I think that change belong in a separate
 cleanup-patch.
 Note that I also removed the block for UTF-8 encoding, as this is
 never used for length less Clobs (encoding is always US-ASCII when
 passing an InputStream - set-/updateAsciiStream). I left the
 encoding argument for now, along with the check. This is handy
 when/if we change to ISO-8859-1. Besides from that, the encoding
 argument could be removed from this constructor
 (Agent,InputStream,String).

  4) Fixed this for the constructor I added. Again I suggest a separate
 cleanup-patch for the other constructor.

  5) Fixed.

  6) Fixed. I also removed an unused import.

  7) Fixed (deleted setUp and tearDown).

  8) Changed.

As you can see, I have chosen not to address some of your comments on the
code that is not directly related to my patch. I don't want to mix other
bug fixes and improvements with my patch for this issue. One of the main
reasons for this, is that the faulty assumption that a Clob used for
input is not passed to the user is used for the whole implementation, not
just mine.

In my opinion, Clob is ready for a cleanup/rewrite and this should be
done separately from this issue.

Thanks,

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat, 
> derby-1417-6b-clientimpl.diff, derby-1417-6c-clientimpl.diff, 
> derby-1417-6d-clientimpl.diff
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateChara

[jira] Closed: (DERBY-1510) 'SQLBinary.readFromStream' can enter endless loop

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1510?page=all ]

Kristian Waagan closed DERBY-1510.
--

Fix Version/s: 10.2.0.0
   Resolution: Fixed
   Derby Info:   (was: [Patch Available])

Verified the fix. I no longer see the infinite looping when running my test.

> 'SQLBinary.readFromStream' can enter endless loop
> -
>
> Key: DERBY-1510
> URL: http://issues.apache.org/jira/browse/DERBY-1510
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC, SQL
>Affects Versions: 10.2.0.0
>Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
>Priority: Minor
> Fix For: 10.2.0.0
>
> Attachments: derby-1510-1a.diff
>
>
> Under certain circumstances, the method 'SQLBinary.readFromStream' can enter 
> an endless loop while reading the stream. The following must be true for the 
> bug to occur: 
>  * There must be more data in the stream than what can fit into the initial 
> buffer (32 K).
>  * The method 'available' of the stream returns 0.
> Since the default return value for 'InputStream.available' is 0, and the 
> method reading the stream can be used for data types CHAR FOR BIT DATA, 
> VARCHAR FOR BIT DATA and LONG VARCHAR FOR BIT DATA, the bug should be fixed. 
> The maximum length is 32700 bytes.
> The method will also be used by SQLBlob, but it may be better to introduce a 
> new streaming method for it, since the current implementation has 
> memory-problems for large data (materializes the whole stream). A separate 
> issue should/will be created for this.
> The symptom for this bug is a hang when calling one of the execute methods of 
> Prepared- or CallableStatement and maybe also certain set methods in 
> ResultSet.
> The visibility of this bug is very low, but the impact is severe/critical. 
> When the JDBC 4 length less streaming overloads are added (DERBY-1417), 
> visibility might increase.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-1310) Add apache notice to test file phaseTester.java

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1310?page=all ]

Kristian Waagan closed DERBY-1310.
--


> Add apache notice to test file phaseTester.java
> ---
>
> Key: DERBY-1310
> URL: http://issues.apache.org/jira/browse/DERBY-1310
> Project: Derby
>  Issue Type: Bug
>  Components: Test
>Affects Versions: 10.1.3.0, 10.2.0.0
>Reporter: Ramandeep Kaur
> Assigned To: Ramandeep Kaur
>Priority: Minor
> Fix For: 10.1.3.0, 10.2.0.0
>
>
> Need to add Apache notice to 
> src/java/testing/org/apache/derbyTesting/upgradeTests/phaseTester.java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-1445) Add new streaming overloads and modify some existing ones.

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1445?page=all ]

Kristian Waagan closed DERBY-1445.
--


The new JDBC 4 overloads with a long argument for length have been implemented. 
No issues have popped up, closing.

>  Add new streaming overloads and modify some existing ones.
> ---
>
> Key: DERBY-1445
> URL: http://issues.apache.org/jira/browse/DERBY-1445
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Reporter: V.Narayanan
> Assigned To: V.Narayanan
> Fix For: 10.2.0.0
>
> Attachments: JDBC40_long_length_overloads.diff, 
> JDBC40_long_length_overloads.stat, JDBC40_long_length_overloads_ver2.diff, 
> JDBC40_long_length_overloads_ver2.stat, 
> JDBC40_long_length_overloads_ver3.diff, 
> JDBC40_long_length_overloads_ver3.stat, ver3-washed-v1.diff, 
> ver3-washed-v1.stat, ver3-washed.diff
>
>
> The task involves Adding and modifying the following methods, which were 
> recently added by the JDBC4 expert group and which appeared in Mustang build 
> 86:
> add PreparedStatement.setAsciiStream (int columnIndex, InputStream x, 
> long length)
>   add PreparedStatement.setBinaryStream (int columnIndex, InputStream x, 
> long length
>   add PreparedStatement.setCharacterStream (int columnIndex, Reader x, 
> long length)
>   add CallableStatement.setAsciiStream (String columnName, InputStream x, 
> long length)
>   add CallableStatement.setBinaryStream (String columnName, InputStream 
> x, long length)
>   add CallableStatement.setCharacterStream (String columnName, Reader x, 
> long length)
>   add ResultSet.updateAsciiStream (int columnIndex, InputStream x, long 
> length)
>   add ResultSet.updateBinaryStream (int columnIndex, InputStream x, long 
> length)
>   add ResultSet.updateCharacterStream (int columnIndex, Reader x, long 
> length)
>   add ResultSet.updateAsciiStream (String columnName, InputStream x, long 
> length)
>   add ResultSet.updateBinaryStream (String columnName, InputStream x, 
> long length)
>   add ResultSet.updateCharacterStream (String columnName, Reader x, long 
> length)
>   add ResultSet.updateBlob (int columnIndex, InputStream x, long length)
>   add ResultSet.updateBlob (String columnName, InputStream x, long length)
>   add ResultSet.updateClob (int columnIndex, Reader x, long length)
>   add ResultSet.updateClob (String columnName, Reader x, long length)
>   add ResultSet.updateNClob (int columnIndex, Reader x, long length)
>   add ResultSet.updateNClob (String columnName, Reader x, long length)
>   modify ResultSet.updateNCharacterStream(int columnIndex, Reader x, int 
> length) to ResultSet.updateNCharacterStream(int columnIndex, Reader x, long
> length)
>   modify ResultSet.updateNCharacterStream(String columnName, Reader x, 
> int length) to ResultSet.updateNCharacterStream(String columnName, 
> Reader x, long length)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (DERBY-1396) ReEncodedInputStream may fail to read all of source Reader.

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1396?page=all ]

Kristian Waagan closed DERBY-1396.
--


>  ReEncodedInputStream may fail to read all of source Reader.
> 
>
> Key: DERBY-1396
> URL: http://issues.apache.org/jira/browse/DERBY-1396
> Project: Derby
>  Issue Type: Bug
>  Components: Network Server
>Affects Versions: 10.2.0.0
>Reporter: Tomohito Nakayama
> Assigned To: Tomohito Nakayama
> Fix For: 10.2.0.0
>
> Attachments: DERBY-1396.patch
>
>
> The class org.apache.derby.impl.drda.ReEncodedInputStream seems to have a 
> bug...
> In this class, there exists next code.
> int count;
>   if(( count = reader.read(decodedBuffer_, 0, BUFFERED_CHAR_LEN )) < 1 ){
>   return null;
>   }
> In this code, the condition of "<1" was intended to judge whether reader was 
> read entirely.
> However,spec of java api says that reader returns -1 if the end of the reader 
> has been reached and not 0.
> Then "<1" is not appropriate.
> Current code judges 0 as the end of reader.
> Then, if 0 was returned in the meaning that "No character was read now but 
> may continue" as possible in java api, 
> this code will not work correctly...

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1255) Implement new JDBC4 methods for creating empty LOBs in the embedded client

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1255?page=comments#action_12424512 ] 

Kristian Waagan commented on DERBY-1255:


The comment by Rick from 18th of May says "Looks like a solid first increment 
of support needed for this feature.".
Is there more work to be done for this issue, or is it complete?

If all the work has been completed, please close this issue.

> Implement new JDBC4 methods for creating empty LOBs in the embedded client
> --
>
> Key: DERBY-1255
> URL: http://issues.apache.org/jira/browse/DERBY-1255
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: V.Narayanan
> Fix For: 10.2.0.0
>
> Attachments: ClobBlob_create_v1.diff, ClobBlob_create_v1.stat
>
>
> Implement Connection.createClob() and Connection.createBlob(). Right now 
> these methods are implemented in the network client but not the embedded 
> client.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1286) Fill in Clob methods required for JDBC3 compliance

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1286?page=comments#action_12424527 ] 

Kristian Waagan commented on DERBY-1286:


Just want to point out that the method Clob.getCharacterStream(long,long) was 
added in JDBC4.



> Fill in Clob methods required for JDBC3 compliance
> --
>
> Key: DERBY-1286
> URL: http://issues.apache.org/jira/browse/DERBY-1286
> Project: Derby
>  Issue Type: Improvement
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
>
> Fill in Clob methods which we need to be JDBC3-compliant:
> - The following java.sql.CallableStatement methods:
>   * getClob(int)
> - The following java.sql.ResultSet methods:
>   * updateClob(int,java.sql.Clob)
>   * updateClob(java.lang.String,java.sql.Clob)
> - The following java.sql.Clob methods:
>   * setString(long,java.lang.String)
>   * setString(long,java.lang.String,int,int)
>   * setAsciiStream(long)
>   * getCharacterStream(long,long)
>   * setCharacterStream(long)
>   * truncate(long)

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (DERBY-1417) Add new, lengthless overloads to the streaming api

[Kristian Waagan (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1417?page=all ]

Kristian Waagan updated DERBY-1417:
---

Derby Info:   (was: [Patch Available])

> Add new, lengthless overloads to the streaming api
> --
>
> Key: DERBY-1417
> URL: http://issues.apache.org/jira/browse/DERBY-1417
> Project: Derby
>  Issue Type: New Feature
>  Components: JDBC
>Affects Versions: 10.2.0.0
>Reporter: Rick Hillegas
> Assigned To: Kristian Waagan
> Fix For: 10.2.0.0
>
> Attachments: derby-1417-01-castsInTests.diff, 
> derby-1417-1a-notImplemented.diff, derby-1417-1a-notImplemented.stat, 
> derby-1417-2a-rstest-refactor.diff, derby-1417-3a-embimpl-and-tests.diff, 
> derby-1417-3a-embimpl-and-tests.stat, derby-1417-3b-embimpl-and-tests.diff, 
> derby-1417-3b-embimpl-and-tests.stat, derby-1417-4a-disable-psTestsDnc.diff, 
> derby-1417-5a-brokered.diff, derby-1417-5a-brokered.stat, 
> derby-1417-6a-clientimpl.diff, derby-1417-6a-clientimpl.stat, 
> derby-1417-6b-clientimpl.diff, derby-1417-6c-clientimpl.diff, 
> derby-1417-6d-clientimpl.diff
>
>
> The JDBC4 Expert Group has approved a new set of overloads for the streaming 
> methods. These overloads do not take a length argument. Here are the new 
> overloads:
> PreparedStatement.setAsciiStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setBinaryStream(int parameterIndex, java.io.InputStream x)
> PreparedStatement.setCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setNCharacterStream(int parameterIndex, java.io.Reader 
> reader)
> PreparedStatement.setBlob(int parameterIndex, java.io.InputStream inputStream)
> PreparedStatement.setClob(int parameterIndex, java.io.Reader reader)
> PreparedStatement.setNClob(int parameterIndex, java.io.Reader reader)
> CallableStatement.setAsciiStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setBinaryStream(java.lang.String parameterName, 
> java.io.InputStream x)
> CallableStatement.setCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setNCharacterStream(java.lang.String parameterName, 
> java.io.Reader reader)
> CallableStatement.setBlob(java.lang.String parameterName, java.io.InputStream 
> inputStream)
> CallableStatement.setClob(java.lang.String parameterName, java.io.Reader 
> reader)
> CallableStatement.setNClob(java.lang.String parameterName, java.io.Reader 
> reader)
> ResultSet.updateAsciiStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateAsciiStream(java.lang.String columnLabel, java.io.InputStream 
> x)
> ResultSet.updateBinaryStream(int columnIndex, java.io.InputStream x)
> ResultSet.updateBinaryStream(java.lang.String columnLabel, 
> java.io.InputStream x, int length)
> ResultSet.updateCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)
> ResultSet.updateNCharacterStream(int columnIndex, java.io.Reader x)
> ResultSet.updateNCharacterStream(java.lang.String columnLabel, java.io.Reader 
> x)  
> ResultSet.updateBlob(int columnIndex, java.io.InputStream inputStream)
> ResultSet.updateBlob(java.lang.String columnLabel, java.io.InputStream 
> inputStream)
> ResultSet.updateClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateClob(java.lang.String columnLabel, java.io.Reader reader)
> ResultSet.updateNClob(int columnIndex, java.io.Reader reader)
> ResultSet.updateNClob(java.lang.String columnLabel, java.io.Reader reader)
> We should add these new overloads soon so that the build will not break when 
> this methods turn up in a published Mustang build.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (DERBY-1615) Rewrite the Clob implementation in the client driver

[Kristian Waagan (JIRA)]

Rewrite the Clob implementation in the client driver


 Key: DERBY-1615
 URL: http://issues.apache.org/jira/browse/DERBY-1615
 Project: Derby
  Issue Type: Improvement
  Components: JDBC, Network Client
Reporter: Kristian Waagan


The implementation of java.sql.Clob in the client driver is cracking up, and 
should be rewritten.
A number of bugs have been discovered, and the implementation has traces of old 
and/or deprecated features. Further, several mandatory methods (JDBC 3 & 4) 
have not yet been implemented and could benefit from a fresh start.
I think maintainability for this piece of code has dropped to an unacceptable 
level.

It seems the implementation is based on an assumption that no longer holds; 
that a Clob object used for input to the database is never passed to the user. 
The consequence of this, is that the internal state of the Clob object is not 
valid [at all times], which causes exceptions when the user invokes methods on 
it.

A number of related Jira issues have been linked to this issue to aid the 
reimplementation process.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Commented: (DERBY-1616) Lots of jdk1.6 regression test failures with diffs because of SQL Exception instead of java.sql.SQLException

[Kristian Waagan (JIRA)]

[ 
http://issues.apache.org/jira/browse/DERBY-1616?page=comments#action_12424613 ] 

Kristian Waagan commented on DERBY-1616:


The 3 tests that are part of the jdbc40 suite don't fail anymore.
I think 15 tests might be handled, or at least analyzed, by DERBY-1578, but I 
don't know the status of that issue.
Finally, isn't stress.multi still failing intermittently?

> Lots of jdk1.6 regression test failures with diffs because of  SQL Exception 
> instead of java.sql.SQLException
> -
>
> Key: DERBY-1616
> URL: http://issues.apache.org/jira/browse/DERBY-1616
> Project: Derby
>  Issue Type: Bug
>Affects Versions: 10.2.0.0
> Environment: jdk16 /windows.
>Reporter: Sunitha Kambhampati
> Fix For: 10.2.0.0
>
> Attachments: derbyall_report.txt
>
>
> jdk16 derbyall derbyall: 19 failures
> derbyall/derbyall.fail:lang/compressTable.sql
> derbyall/derbyall.fail:lang/nestedCommit.sql
> derbyall/derbyall.fail:lang/outparams.java
> derbyall/derbyall.fail:lang/procedure.java
> derbyall/derbyall.fail:lang/procedureInTrigger.sql
> derbyall/derbyall.fail:tools/importExportThruIJ.sql
> derbyall/derbyall.fail:tools/ieptests.sql
> derbyall/derbyall.fail:tools/iepnegativetests.sql
> derbyall/derbyall.fail:jdbcapi/statementJdbc20.java
> derbyall/derbyall.fail:jdbcapi/statementJdbc30.java
> derbyall/derbyall.fail:jdbcapi/parameterMapping.java
> derbyall/derbyall.fail:i18n/iepnegativetests_ES.sql
> 
> derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/ClosedObjectTest.junit
> 
> derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/UnsupportedVetter.junit
> 
> derbyall/derbynetclientmats/derbynetclientmats.fail:jdbc4/VerifySignatures.junit
> derbyall/encryptionAll/encryption.fail:stress/stress.multi
> derbyall/encryptionAll/storemats.fail:store/streamingColumn.java
> derbyall/storeall/storeall.fail:store/TransactionTable.sql
> derbyall/storeall/storemats.fail:store/streamingColumn.java

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira