Re: Re: 10.1.3.1 release notes draft page

[Andrew McIntyre]

I've posted a new draft of the release notes page at:

http://people.apache.org/~fuzzylogic/releases/release-10.1.3.1.html

Please let me know if you find any issues with this draft.

Thanks,
andrew

[jira] Commented: (DERBY-75) Clean up import and JavaDoc for MethodNode hierarchy

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre commented on DERBY-75:
--

If there are no objections, I will close this issue in the next week or so, 
since the javadoc in 10.2 has been cleaned up.

> Clean up import and JavaDoc for MethodNode hierarchy
> 
>
>  Key: DERBY-75
>  URL: http://issues.apache.org/jira/browse/DERBY-75
>  Project: Derby
> Type: Improvement

>   Components: Javadoc
> Reporter: Jeremy Boynes
>  Attachments: derby_methodNode_doc.patch
>
> Patch to clean up invalid JavaDoc tags and unused imports so Idea stops 
> complaining

-- 
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-1319) Need documentation on the toursdb schema.

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre commented on DERBY-1319:


Since we added the toursdb example database with 10.2, this is a good candidate 
for FixIn 10.2, though not critical.

> Need documentation on the toursdb schema.
> -
>
>  Key: DERBY-1319
>  URL: http://issues.apache.org/jira/browse/DERBY-1319
>  Project: Derby
> Type: Sub-task

>   Components: Demos/Scripts
> Versions: 10.2.0.0
> Reporter: Stan Bradbury
> Priority: Minor

>
> Docuement the toursdb schema and provide examplet queries so toursdb can be 
> used by newbie Derby users.  To jump start this here is a query that 
> demonstrates how to join the tables in the schema to list the with seats 
> available on a given day from one city to another.  It's not pretty - a good 
> candidate for a view. (sans the hardcoded values listed below:  
> This example hardcodes the following string values:
>Travel Date:  '2004-04-12' ,  Departing city: Copenhagen , Destination 
> city: Paris
> select  f.flight_id, a.airline_full, 
> fa.flight_date|| ' ' || f.depart_time Departing,
> CAST(orig_city.city_name ||', ' || orig_ctry.country as varchar(30)) as 
> Origin, 
>f.flying_time Hours, f.arrive_time Arriving,
>CAST(dest_city.city_name ||', ' || dest_ctry.country as varchar(30))  as 
> Destination
> from flights f, airlines a, countries orig_ctry, cities orig_city, 
>countries dest_ctry, cities dest_city, flightavailability fa
> where f.flight_id = fa.flight_id and f.segment_number = fa.segment_number
>   and orig_city.airport = f.orig_airport and dest_city.airport = 
> f.dest_airport
>   and orig_city.country_iso_code = orig_ctry.country_iso_code
>   and dest_city.country_iso_code = dest_ctry.country_iso_code
>   and f.flight_id like a.airline || '%'
>and fa.flight_date = '2004-04-12' 
>   and (a.business_seats - fa.business_seats_taken) > 0
>   and orig_city.city_name = 'Copenhagen' and dest_city.city_name = 'Paris'
> order by f.flight_id, f.segment_number
> NOTE: uses some kludgy formatting tricks
> To cut N paste  the query all at once into IJ set maximumdisplaywidth larger 
> (about 985 characters in the query)

-- 
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-1471) Implement layer B streaming for new methods defined in JDBC4.0

[Tomohito Nakayama (JIRA)]

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

Tomohito Nakayama reassigned DERBY-1471:


Assign To: Tomohito Nakayama

> Implement layer B streaming for new methods defined in JDBC4.0
> --
>
>  Key: DERBY-1471
>  URL: http://issues.apache.org/jira/browse/DERBY-1471
>  Project: Derby
> Type: New Feature

>   Components: Network Client
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama

>
> JDBC 4.0 introduced new methods which take parameters for object to be sent 
> to sever without length information.
> For those methods, Layer B streaming is best way to implement sending object 
> to server.
> This issue is representation of DERBY-1417 in Network 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] Assigned: (DERBY-1472) Avoid expanding object to memory before sending it to server.

[Tomohito Nakayama (JIRA)]

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

Tomohito Nakayama reassigned DERBY-1472:


Assign To: Tomohito Nakayama

> Avoid expanding object to memory before sending it to server.
> -
>
>  Key: DERBY-1472
>  URL: http://issues.apache.org/jira/browse/DERBY-1472
>  Project: Derby
> Type: Improvement

>   Components: Network Client
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama

>
> Object , such as blob/clob, is expanded to memory before sending it to server.
> This behavior easily causes OutOfMemoryError, and it is desirable to remove 
> this process of expanding .

-- 
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-112) Variable name 'enum' used in a couple of places

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-112?page=all ]
 
Andrew McIntyre resolved DERBY-112:
---

Fix Version: 10.2.0.0
 Resolution: Fixed

This issue has been resolved by the move to JavaCC 4.0.

> Variable name 'enum' used in a couple of places
> ---
>
>  Key: DERBY-112
>  URL: http://issues.apache.org/jira/browse/DERBY-112
>  Project: Derby
> Type: Improvement

>   Components: Build tools
>  Environment: win xp
> Reporter: Jonathan Nash
> Priority: Trivial
>  Fix For: 10.2.0.0

>
> I noticed the variable name 'enum' was used in a couple of places like 
> SQLParser.java and ij.java. 'enum' is now a keyword in Java 1.5. I just 
> changed the variable name to avoid any future conflicts.
> This is my first code submission. Please let me know if all changes submitted 
> should be linked to a corresponding item in JIRA?

-- 
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-1301) Improve streaming of large objects for network server and client,from client to server

[Tomohito Nakayama (JIRA)]

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

Tomohito Nakayama commented on DERBY-1301:
--

DERBY-1471 and DERBY-1472 was found as issue which relates strongly to 
DERBY-1301.


>  Improve streaming of large objects for network server and client,from client 
> to server
> ---
>
>  Key: DERBY-1301
>  URL: http://issues.apache.org/jira/browse/DERBY-1301
>  Project: Derby
> Type: Improvement

>   Components: Network Client
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama

>
> Patch developed in DERBY-326 acted on streaming from server to client.
> I think similar modification should be done from client to server too.

-- 
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-1348) upgradeTests/Upgrade_10_1_10_2.java test fails with java.lang.NoClassDefFoundError: org/apache/derby/iapi/services/info/JVMInfo

[Andrew McIntyre (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1348?page=all ]
 
Andrew McIntyre resolved DERBY-1348:


Resolution: Fixed
 Assign To: Andrew McIntyre

Marking this specific issue resolved.

Comment regarding the test harness' use of properties still applies. :-)

> upgradeTests/Upgrade_10_1_10_2.java test fails with 
> java.lang.NoClassDefFoundError: org/apache/derby/iapi/services/info/JVMInfo
> ---
>
>  Key: DERBY-1348
>  URL: http://issues.apache.org/jira/browse/DERBY-1348
>  Project: Derby
> Type: Bug

>   Components: Build tools
> Versions: 10.2.0.0
>  Environment: Windows Xp and IBM sdk 1.4.2 / Sun JDK 1.5
> Reporter: Rajesh Kartha
> Assignee: Andrew McIntyre
>  Fix For: 10.2.0.0

>
> The test
> derbyall/derbyall.fail:upgradeTests/Upgrade_10_1_10_2.java
> has been failing in the nighlies on IBM SDK 142 and Sun JDK 15 with the 
> following:
> Derby version - 10.2.0.0 alpha - (409280)
> > FAIL - Unexpected exception - null
> > Possible Reason - Test could not find the location of jar files. Please 
> > check if you are running with jar files in the classpath. The test does not 
> > run with classes folder in the classpath. Also, check that old jars are 
> > checked out from the repository or specified in derbyTesting.jar.path 
> > property in ant.properties
> > java.lang.reflect.InvocationTargetException
> > Caused by: java.lang.NoClassDefFoundError: 
> > org/apache/derby/iapi/services/info/JVMInfo
> > ... 9 more
> > Exception: null
> > java.lang.reflect.InvocationTargetException
> > Caused by: java.lang.NoClassDefFoundError: 
> > org/apache/derby/iapi/services/info/JVMInfo
> > ... 9 more

-- 
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-496) unit test 'org.apache.derbyTesting.unitTests.services.T_Diagnosticable' was failed

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-496:
--

Component: Regression Test Failure
   (was: Build tools)

> unit test 'org.apache.derbyTesting.unitTests.services.T_Diagnosticable' was 
> failed
> --
>
>  Key: DERBY-496
>  URL: http://issues.apache.org/jira/browse/DERBY-496
>  Project: Derby
> Type: Bug

>   Components: Regression Test Failure
>  Environment: [EMAIL PROTECTED]:~$ cat /proc/version
> Linux version 2.4.27-2-386 ([EMAIL PROTECTED]) (gcc version 3.3. 5 (Debian 
> 1:3.3.5-12)) #1 Mon May 16 16:47:51 JST 2005
> [EMAIL PROTECTED]:~$ java -version
> java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama
>  Attachments: DERBY-496.patch, DERBY-496_2.patch, DERBY-496_2_addition.patch, 
> derby.log
>
> As summary.
> I found next exception in derby.log.
> [main] FAIL - org.apache.derbyTesting.unitTests.harness.T_Fail: Test failed - 
> DiagnosticUtil.toDiagString() failed, got: (T_DiagTestClass1.toString(): 
> object with diag interface), expected: (D_T_DiagTestClass1: object with diag 
> interface).
> org.apache.derbyTesting.unitTests.harness.T_Fail: Test failed - 
> DiagnosticUtil.toDiagString() failed, got: (T_DiagTestClass1.toString(): 
> object with diag interface), expected: (D_T_DiagTestClass1: object with diag 
> interface).
>   at 
> org.apache.derbyTesting.unitTests.harness.T_Fail.testFailMsg(T_Fail.java:95)
>   at 
> org.apache.derbyTesting.unitTests.services.T_Diagnosticable.t_001(T_Diagnosticable.java:105)
>   at 
> org.apache.derbyTesting.unitTests.services.T_Diagnosticable.runTestSet(T_Diagnosticable.java:207)
>   at 
> org.apache.derbyTesting.unitTests.harness.T_MultiIterations.runTests(T_MultiIterations.java:94)
>   at 
> org.apache.derbyTesting.unitTests.harness.T_Generic.Execute(T_Generic.java:117)
>   at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runATest(BasicUnitTestManager.java:183)
>   at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runTests(BasicUnitTestManager.java:245)
>   at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.boot(BasicUnitTestManager.java:92)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996)
>   at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1834)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startServices(BaseMonitor.java:966)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:398)
>   at 
> org.apache.derby.impl.services.monitor.FileMonitor.(FileMonitor.java:57)
>   at 
> org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:288)
>   at 
> org.apache.derbyTesting.unitTests.harness.UnitTestMain.main(UnitTestMain.java:50)

-- 
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-496) unit test 'org.apache.derbyTesting.unitTests.services.T_Diagnosticable' was failed

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre commented on DERBY-496:
---

I've seen some recent reports of this failure. Knut Anders Hatlen reported that 
this failed for him on a couple of platforms for 10.1.3. There were also recent 
reports of failure in this test attached to DERBY-1386 and DERBY-1058.


> unit test 'org.apache.derbyTesting.unitTests.services.T_Diagnosticable' was 
> failed
> --
>
>  Key: DERBY-496
>  URL: http://issues.apache.org/jira/browse/DERBY-496
>  Project: Derby
> Type: Bug

>   Components: Regression Test Failure
>  Environment: [EMAIL PROTECTED]:~$ cat /proc/version
> Linux version 2.4.27-2-386 ([EMAIL PROTECTED]) (gcc version 3.3. 5 (Debian 
> 1:3.3.5-12)) #1 Mon May 16 16:47:51 JST 2005
> [EMAIL PROTECTED]:~$ java -version
> java version "1.4.2_08"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_08-b03)
> Java HotSpot(TM) Client VM (build 1.4.2_08-b03, mixed mode)
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama
>  Attachments: DERBY-496.patch, DERBY-496_2.patch, DERBY-496_2_addition.patch, 
> derby.log
>
> As summary.
> I found next exception in derby.log.
> [main] FAIL - org.apache.derbyTesting.unitTests.harness.T_Fail: Test failed - 
> DiagnosticUtil.toDiagString() failed, got: (T_DiagTestClass1.toString(): 
> object with diag interface), expected: (D_T_DiagTestClass1: object with diag 
> interface).
> org.apache.derbyTesting.unitTests.harness.T_Fail: Test failed - 
> DiagnosticUtil.toDiagString() failed, got: (T_DiagTestClass1.toString(): 
> object with diag interface), expected: (D_T_DiagTestClass1: object with diag 
> interface).
>   at 
> org.apache.derbyTesting.unitTests.harness.T_Fail.testFailMsg(T_Fail.java:95)
>   at 
> org.apache.derbyTesting.unitTests.services.T_Diagnosticable.t_001(T_Diagnosticable.java:105)
>   at 
> org.apache.derbyTesting.unitTests.services.T_Diagnosticable.runTestSet(T_Diagnosticable.java:207)
>   at 
> org.apache.derbyTesting.unitTests.harness.T_MultiIterations.runTests(T_MultiIterations.java:94)
>   at 
> org.apache.derbyTesting.unitTests.harness.T_Generic.Execute(T_Generic.java:117)
>   at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runATest(BasicUnitTestManager.java:183)
>   at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.runTests(BasicUnitTestManager.java:245)
>   at 
> org.apache.derbyTesting.unitTests.harness.BasicUnitTestManager.boot(BasicUnitTestManager.java:92)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.boot(BaseMonitor.java:1996)
>   at 
> org.apache.derby.impl.services.monitor.TopService.bootModule(TopService.java:290)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1834)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.startServices(BaseMonitor.java:966)
>   at 
> org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:398)
>   at 
> org.apache.derby.impl.services.monitor.FileMonitor.(FileMonitor.java:57)
>   at 
> org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:288)
>   at 
> org.apache.derbyTesting.unitTests.harness.UnitTestMain.main(UnitTestMain.java:50)

-- 
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-1472) Avoid expanding object to memory before sending it to server.

[Tomohito Nakayama (JIRA)]

Avoid expanding object to memory before sending it to server.
-

 Key: DERBY-1472
 URL: http://issues.apache.org/jira/browse/DERBY-1472
 Project: Derby
Type: Improvement

  Components: Network Client  
Reporter: Tomohito Nakayama


Object , such as blob/clob, is expanded to memory before sending it to server.
This behavior easily causes OutOfMemoryError, and it is desirable to remove 
this process of expanding .



-- 
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-1471) Implement layer B streaming for new methods defined in JDBC4.0

[Tomohito Nakayama (JIRA)]

Implement layer B streaming for new methods defined in JDBC4.0
--

 Key: DERBY-1471
 URL: http://issues.apache.org/jira/browse/DERBY-1471
 Project: Derby
Type: New Feature

  Components: Network Client  
Reporter: Tomohito Nakayama


JDBC 4.0 introduced new methods which take parameters for object to be sent to 
sever without length information.

For those methods, Layer B streaming is best way to implement sending object to 
server.

This issue is representation of DERBY-1417 in Network 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

Re: Code coverage results for 10.1.3 (417277) release candidate

[Andrew McIntyre]

On 6/29/06, Ramandeep Kaur <[EMAIL PROTECTED]> wrote:


I ran code coverage for 10.1.3 - svn revision no 417277 with sun jdk131, sun
jdk142, sun jdk15 on Windows 2000


These code coverage results can now be viewed at:

http://people.apache.org/~fuzzylogic/codecoverage/417277/

andrew

Re: Wondering to myself about doing layer B streaming from client to server

[TomohitoNakayama]

Hello Knut.
Thank you for your counsel :)

Knut Anders Hatlen wrote:


TomohitoNakayama <[EMAIL PROTECTED]> writes:

 


Hello.

Continuing DERBY-1301(http://issues.apache.org/jira/browse/DERBY-1301),
I came to have question whether layer B streaming should be done when
lob was sent from client to server.

Reading javadoc for java.sql package, I found that methods passing
stream object to driver always takes parameter for length information.
Then, driver can simply pass that length information to server.

I think there are no need for driver to execute layer B streaming,
because caller of driver always pass length of streamed object to driver.
   



Hi Tomohito,

I don't know how it relates to layer B streaming, but JDBC 4.0 will
add methods with a stream parameter and no length parameter. The
javadocs at http://download.java.net/jdk6/docs/api/ have not been
updated with these methods yet, but I believe they will be in a week
or two. You can find more details in DERBY-1417.
 


I see.
I recognize there exists need for layer B streaming, which does not 
require to send length information, concerning JDBC4.0.




However, here comes another question.

DERBY-550(http://issues.apache.org/jira/browse/DERBY-550), which is
linked from DERBY-1301 told that
current implementation of org.apache.derby.jdbc.ClientDriver expands
object to be streamed into memory and
this behavior tends to cause OutOfMemoryError.

Are there any reason why current driver expands object into memory,
though length of the object is served as parameter of method ?
   



Probably because it was the easiest way to implement it. I don't see
any good technical reasons for doing it like that.
 


I see.
Then, it is issue to be improved, I suppose.


Well
I think it is needed to survey some more around current implementation
of driver and
clear the mystery in org.apache.derby.jdbc.ClientDriver, around
expanding object into memory before sending 
   



It would be great to improve the stream handling on the client. I have
just briefly looked at the code, but it seems clear that this is a
part of the code that has room for improvement. Thanks for looking
into it!

 


I think here we found two issue.
1) Implement layer B streaming for new methods defined in JDBC4.0.
2) Remove expanding object to memory before sending it.

I will file them on JIRA and continue.

Best regards.

--
/*

   Tomohito Nakayama
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]
   [EMAIL PROTECTED]

   Naka
   http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/ 

[jira] Updated: (DERBY-873) OSGi bundle activator not JSR169 compliant

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-873:
--

Component: Unknown

> OSGi bundle activator not JSR169 compliant
> --
>
>  Key: DERBY-873
>  URL: http://issues.apache.org/jira/browse/DERBY-873
>  Project: Derby
> Type: Bug

>   Components: Unknown
> Versions: 10.0.2.0
> Reporter: Byron K. Appelt
> Priority: Minor

>
> EmbeddedActivator contains references to java.sql.DriverManager which is not 
> included in JSR169.

-- 
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-873) OSGi bundle activator not JSR169 compliant

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-873:
--


Assigning to component Unknown for now. This should maybe be assigned to the 
Services component.

> OSGi bundle activator not JSR169 compliant
> --
>
>  Key: DERBY-873
>  URL: http://issues.apache.org/jira/browse/DERBY-873
>  Project: Derby
> Type: Bug

> Versions: 10.0.2.0
> Reporter: Byron K. Appelt
> Priority: Minor

>
> EmbeddedActivator contains references to java.sql.DriverManager which is not 
> included in JSR169.

-- 
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-1377) Update copyright headers to comply with new ASF policy

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1377:
---

Component: Documentation

> Update copyright headers to comply with new ASF policy
> --
>
>  Key: DERBY-1377
>  URL: http://issues.apache.org/jira/browse/DERBY-1377
>  Project: Derby
> Type: Task

>   Components: Documentation
> Versions: 10.2.0.0
> Reporter: Jean T. Anderson
> Priority: Blocker

>
> A new copyright header policy will take effect for distributions released 
> starting on Aug 1, 2006. Committers will receive notification, but a heads up 
> with details is in the legal-discuss thread starting with 
> http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200606.mbox/[EMAIL 
> PROTECTED]

-- 
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-1320) Test lang/procedure.java fails with ibm1.5 jvm

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1320:
---

 type: Test  (was: Bug)
Component: Test
   (was: Unknown)

> Test lang/procedure.java fails with ibm1.5 jvm
> --
>
>  Key: DERBY-1320
>  URL: http://issues.apache.org/jira/browse/DERBY-1320
>  Project: Derby
> Type: Test

>   Components: Test, Regression Test Failure
> Versions: 10.2.0.0
>  Environment: IBM 1.5 JVM /linux 
> Reporter: Sunitha Kambhampati
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: procedure.diff, procedure.java
>
> lang/procedure.java fails on IBM1.5 jvm on linux machine.I spoke to 
> Manjula who filed DERBY-1108 that this is related to that issue and is a JVM 
> bug. The JVM team has been notified.Please note: I have marked this as a 
> Regression Test Failure although this test has not passed with IBM 1.5 JVM 
> atleast in our nightly regression test runs,  so it is not a regression of 
> the product. 
> diff:
> * Diff file derbyall/derbylang/procedure.diff
> *** Start: procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:16 ***
> 1018 del
> < testImplicitClose(): PASSED
> 1018 add
> > testImplicitClose(): FAILED (no exception thrown)
> Test Failed.
> *** End:   procedure jdk1.5.0 derbyall:derbylang 2006-05-10 22:17:31 ***
> here is machine info.
> -- Java Information --
> Java Version:1.5.0
> Java Vendor: IBM Corporation
> Java home:   /local1/cloudtst/dev/src/ibm15/jre
> Java classpath:  
> /local1/cloudtst/dev/src/jars/insane/derby.jar:/local1/cloudtst/dev/src/jars/insane/derbytools.jar:/local1/cloudtst/dev/src/jars/insane/derbynet.jar:/local1/cloudtst/dev/src/jars/insane/derbyclient.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/jcc/db2jcc.jar:/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar:/local1/cloudtst/dev/src/jars/insane/derbyTesting.jar:/local1/cloudtst/dev/src/tools/java/jakarta-oro-2.0.8.jar:/local1/cloudtst/dev/src/tools/java/junit.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_de_DE.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_es.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_fr.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_it.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ja_JP.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_ko_KR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_pt_BR.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_CN.jar:/local1/cloudtst/dev/src/jars/insane/derbyLocale_zh_TW.jar:/local1/cloudtst/dev/src/jars/insane/derbyrun.jar:
> OS name: Linux
> OS architecture: x86
> OS version:  2.6.5-7.252-bigsmp
> Java user name:  cloudtst
> Java user home:  /u/cloudtst
> Java user dir:   
> /local1/cloudtst/dev/src/NightlyBuildResults.2006-05-10/ibm15_derbyall
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [/local1/cloudtst/dev/src/jars/insane/derby.jar] 10.2.0.0 alpha - (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbytools.jar] 10.2.0.0 alpha - 
> (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbynet.jar] 10.2.0.0 alpha - (405653)
> [/local1/cloudtst/dev/src/jars/insane/derbyclient.jar] 10.2.0.0 alpha - 
> (405653)
> [/local1/cloudtst/dev/src/jcc/db2jcc.jar] 2.6 - (90)
> [/local1/cloudtst/dev/src/jcc/db2jcc_license_c.jar] 2.6 - (90)
> --

-- 
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-1164) 'show tables' and 'describe' commands in ij

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1164:
---

Fix Version: 10.2.0.0
  Assign To: Håvard Mork

> 'show tables' and 'describe' commands in ij
> ---
>
>  Key: DERBY-1164
>  URL: http://issues.apache.org/jira/browse/DERBY-1164
>  Project: Derby
> Type: New Feature

>   Components: Tools
> Reporter: Håvard Mork
> Assignee: Håvard Mork
> Priority: Trivial
>  Fix For: 10.2.0.0
>  Attachments: 1164.diff, 1164_2.diff, 1164_3.diff, 1164_4.diff
>
> New users migrating from mysql are familiar with commands 'show tables' and 
> 'describe'  to respectively display all permanent tables, and show fields in 
> a given table. These are not standard sql, but I suggest to implement them 
> only in the IJ tool for user-friendliness.
> As suggested in db-dev, using DatabaseMetaData should provide the necessary 
> query strings.

-- 
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-1427) sysinfo does not write Java SE and JDBC version when running under JDK 1.6

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1427:
---

Fix Version: 10.2.0.0

> sysinfo does not write Java SE and JDBC version when running under JDK 1.6
> --
>
>  Key: DERBY-1427
>  URL: http://issues.apache.org/jira/browse/DERBY-1427
>  Project: Derby
> Type: Bug

>   Components: Tools
> Versions: 10.2.0.0
>  Environment: Sun JDK 1.6
> Reporter: Olav Sandstaa
> Priority: Minor
>  Fix For: 10.2.0.0

>
> When running sysinfo with jdk 1.6 information about which Java SE and JDBC 
> versions that is supported is missing in the output. The following is written:
> - Derby Information 
> JRE - JDBC: ?-?
> The complete output from sysinfo:
> -- Java Information --
> Java Version:1.6.0-beta2
> Java Vendor: Sun Microsystems Inc.
> Java home:   /usr/local/java/jdk1.6.0_b86/jre
> Java classpath:  jars/sane/derby.jar
> OS name: SunOS
> OS architecture: x86
> OS version:  5.10
> Java user name:  os136802
> Java user home:  /home/os136802
> Java user dir:   /home/os136802/derby/develop/jdk16/trunk
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.6
> - Derby Information 
> JRE - JDBC: ?-?
> [/home/os136802/derby/develop/jdk16/trunk/jars/sane/derby.jar] 10.2.0.4 alpha 
> - (415258M)
> --
> - Locale Information -
> Current Locale :  [English/United States [en_US]]
> Found support for locale: [de_DE]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [es]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [fr]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [it]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [ja_JP]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [ko_KR]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [pt_BR]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [zh_CN]
>  version: 10.2.0.4 alpha - (415258M)
> Found support for locale: [zh_TW]
>  version: 10.2.0.4 alpha - (415258M)
> --

-- 
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

Off email next week

[David Van Couvering]

Like Rick, I'll be on holiday next week, talk to you all the following 
Tuesday.


David

Sharing jira filters enabled for derby-developers (was Re: making a jira filter public)

[Andrew McIntyre]

I have granted permission to create shared filters to all members of
the derby-developers group. Please keep the global list of filters
tidy and keep the sharing within the derby-developers group. Don't
share the filter globally unless there's a really good reason.

On 6/30/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:


Michelle Caisse wrote:

> Whether or not one can see the Share link is a question of karma.
> Someone of greater karma can grant this privilege to someone of lesser
> karma.

I respectfully ask for more karma!


Granted. The granularity is such that it can be granted to a group,
not specific users.

andrew

[jira] Updated: (DERBY-1273) Sysinfo should print a better message when it gets Security Exceptions accessing classpath info when run under security manager

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1273:
---

Fix Version: 10.2.0.0

> Sysinfo should print a better  message when it gets Security Exceptions 
> accessing classpath info when run under security manager
> 
>
>  Key: DERBY-1273
>  URL: http://issues.apache.org/jira/browse/DERBY-1273
>  Project: Derby
> Type: Improvement

>   Components: Tools
> Versions: 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Andrew McIntyre
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: DERBY-1273.diff, derby-1273-v2.diff
>
> If sysinfo does not have getProtectionDomain privileges it cannot get some 
> information during classpath handling.  
> When this occurs it prints   Java Security Exceptions in the output e.g.
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [C:\bryan\src\derby\main\trunk\jars\sane\derby.jar] 10.2.0.0 alpha - (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbytools.jar] 10.2.0.0 alpha - 
> (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbynet.jar] 10.2.0.0 alpha - 
> (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbyclient.jar] 10.2.0.0 alpha - 
> (398049M)
> [Unable to access Protection Domain or Code Source for class class 
> com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission 
> getProtectionDomain)] 2.4 - (17)
> [C:\bryan\src\derby\main\trunk\jars\sane\db2jcc_license_c.jar] 2.4 - (17)
> [Java Security Exception: access denied (java.io.FilePermission 
> c:\bryan\src\derby\main\trunk\tools\java\jakarta-oro-2.0.8.jar read)] 
> [Java Security Exception: access denied (java.io.FilePermission 
> c:\bryan\src\derby\main\trunk\tools\java\junit.jar read)] 
> See DERBY-1229 notes.html for a complete explanation of the output.
> I am actually not sure what information is actually missing from sysinfo in 
> this case but  I  think it would be better if sysinfo just printed the 
> classpath  and then printed a generic warning with the information that it 
> was not able to report rather than printing the Security exceptions 
> explicitly.
> This would be especially helpful for NetworkServerControl sysinfo because 
> users are always encouraged to run network server in security manager.

-- 
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-1273) Sysinfo should print a better message when it gets Security Exceptions accessing classpath info when run under security manager

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre reassigned DERBY-1273:
--

Assign To: Andrew McIntyre

> Sysinfo should print a better  message when it gets Security Exceptions 
> accessing classpath info when run under security manager
> 
>
>  Key: DERBY-1273
>  URL: http://issues.apache.org/jira/browse/DERBY-1273
>  Project: Derby
> Type: Improvement

>   Components: Tools
> Versions: 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Andrew McIntyre
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: DERBY-1273.diff, derby-1273-v2.diff
>
> If sysinfo does not have getProtectionDomain privileges it cannot get some 
> information during classpath handling.  
> When this occurs it prints   Java Security Exceptions in the output e.g.
> JRE - JDBC: J2SE 1.4.2 - JDBC 3.0
> [C:\bryan\src\derby\main\trunk\jars\sane\derby.jar] 10.2.0.0 alpha - (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbytools.jar] 10.2.0.0 alpha - 
> (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbynet.jar] 10.2.0.0 alpha - 
> (398049M)
> [C:\bryan\src\derby\main\trunk\jars\sane\derbyclient.jar] 10.2.0.0 alpha - 
> (398049M)
> [Unable to access Protection Domain or Code Source for class class 
> com.ibm.db2.jcc.DB2Driver: access denied (java.lang.RuntimePermission 
> getProtectionDomain)] 2.4 - (17)
> [C:\bryan\src\derby\main\trunk\jars\sane\db2jcc_license_c.jar] 2.4 - (17)
> [Java Security Exception: access denied (java.io.FilePermission 
> c:\bryan\src\derby\main\trunk\tools\java\jakarta-oro-2.0.8.jar read)] 
> [Java Security Exception: access denied (java.io.FilePermission 
> c:\bryan\src\derby\main\trunk\tools\java\junit.jar read)] 
> See DERBY-1229 notes.html for a complete explanation of the output.
> I am actually not sure what information is actually missing from sysinfo in 
> this case but  I  think it would be better if sysinfo just printed the 
> classpath  and then printed a generic warning with the information that it 
> was not able to report rather than printing the Security exceptions 
> explicitly.
> This would be especially helpful for NetworkServerControl sysinfo because 
> users are always encouraged to run network server in security manager.

-- 
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-982) sysinfo api does not provide genus name for client

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-982:
--

Fix Version: 10.2.0.0

> sysinfo api does not provide genus name for client
> --
>
>  Key: DERBY-982
>  URL: http://issues.apache.org/jira/browse/DERBY-982
>  Project: Derby
> Type: Bug

>   Components: Tools
> Reporter: Kathey Marsden
> Assignee: Andrew McIntyre
>  Fix For: 10.2.0.0
>  Attachments: derby-982.diff, derby-982_v2.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] Updated: (DERBY-1032) Create new scripts which follow common practice at Apache

[Andrew McIntyre (JIRA)]

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

Andrew McIntyre updated DERBY-1032:
---

Fix Version: 10.2.0.0

> Create new scripts which follow common practice at Apache
> -
>
>  Key: DERBY-1032
>  URL: http://issues.apache.org/jira/browse/DERBY-1032
>  Project: Derby
> Type: Improvement

>   Components: Demos/Scripts
> Versions: 10.2.0.0
> Reporter: Andrew McIntyre
> Assignee: Andrew McIntyre
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: derby-1032-bin-sh.tgz
>
> Scripts for Derby should be written to follow common practice at Apache. This 
> means locating them in a bin directory, and self configuring from the minimum 
> amount of information necessary: installation location and in our case, the 
> location of Java, from the variables DERBY_HOME and JAVA_HOME respectively. 
> If these variables are not set, we should report this to the user. Good 
> examples are available in Ant, Forrest, and Maven, and much of the same setup 
> code can be reused from those projects.

-- 
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

Re: making a jira filter public

[Kathey Marsden]

Rick Hillegas wrote:

Thanks, Kathey. I have substituted your pessimistic query for my 
optimistic one and added the critical/blocker query.


I see now that your original query was for bugs  that developers have 
marked to be fixed in 10.2 , which is interesting too, but maybe it 
could be all issues, not just bugs. That would be 108 on the current 
10.2 fix list.

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=11187&status=1&status=3&status=4&sorter/field=issuekey&sorter/order=DESC

32 business days until August 10, so that would be 3.375 issues per day 
for the community assuming everyone has the issues they plan to fix for 
10.2 marked as such. Doesn't sound so bad.


Interestingly though 71 of the issues marked Fix Version 10.2  are 
currently unassigned.

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=11187&assigneeSelect=unassigned&status=1&status=3&status=4&sorter/field=issuekey&sorter/order=DESC

72 issues are assigned but do not have a fix version marked 
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&fixfor=-1&assigneeSelect=specificgroup&assignee=derby-developers&status=1&status=3&status=4&sorter/field=issuekey&sorter/order=DESC


What do all these numbers mean?
Probably nothing.  A lot of the information is skewed because of  Jira 
maintenance issues, like DERBY-1442, marked Fix Version 10.2.0.0 but   
probably intended as the Affects Version.  Jira currently could use a 
good house-cleaning to make the reports meaningful.  I posted some Jira 
maintenance reports on the Wiki at 
http://wiki.apache.org/db-derby/DerbyJiraReports.


I started some obvious  cleanup  because I need to pull out some metrics 
(Sorry for all the spam).
It would be great if folks could look at the maintenance  reports  at 
http://wiki.apache.org/db-derby/DerbyJiraReports and restrict to CURRENT 
USER for  Reporter or Assignee as appropriate.  Also it would be 
interesting to see the numbers if folks mark the issues Fix Version 10.2 
that they plan to fix for the release.


Kathey

[jira] Updated: (DERBY-624) Running derbynetclientmats and derbynetmats requires accessDeclaredMembers permission to be granted with sane=true

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-624:
-

Component: Network Server
   Services

> Running derbynetclientmats and derbynetmats requires accessDeclaredMembers 
> permission to be granted with sane=true
> --
>
>  Key: DERBY-624
>  URL: http://issues.apache.org/jira/browse/DERBY-624
>  Project: Derby
> Type: Bug

>   Components: Network Server, Services
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Daniel John Debrunner
>  Fix For: 10.2.0.0, 10.1.2.0, 10.1.1.2

>
> About 17 tests fail if this permission is not granted. Permission should not 
> be required to run Derby in embedded or network server mode.
> permission java.lang.RuntimePermission "accessDeclaredMembers";
> In some (all?) cases it is because getDeclaredConstrunctor or 
> getDeclaredMethod is called when the getPublic versions would suffice.

-- 
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-625) hang in unit/cacheService.unit with wctme5.7

[Kathey Marsden (JIRA)]

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

Kathey Marsden commented on DERBY-625:
--

There is no component as this is a JVM JIT issue

> hang in unit/cacheService.unit with wctme5.7
> 
>
>  Key: DERBY-625
>  URL: http://issues.apache.org/jira/browse/DERBY-625
>  Project: Derby
> Type: Bug

> Versions: 10.1.1.0, 10.2.0.0
>  Environment: windows with wctme5.7 (j9 version 2.2)
> Reporter: Myrna van Lunteren
> Priority: Minor
>  Attachments: j9_22_hang.breakout
>
> Test unit/cacheService.unit hangs with wctme5.7 jvm since June...
> Can someone familiar with services please have a look?
> The hang was not noticed in a timely fashion because our scripts only run 
> with wctme5.7 once a week, 
> and for 3 months, our nightly tests took too long to complete - and no one 
> paid attention (me included).
> I've done some historical research on this, but am no closer to deciding if 
> this is a jvm bug exposed by changed derby functionality or a 'new' derby bug 
> exposed by the wctme5.7 (j9 version 2.2) jvm.
> Efforts are hampered by 
> - absence of commit archive details between June 13 and July 1
> - svn cannot backtrack to revisions that happened during incubator time
> This is what I found so far:
> - in main
>   - the test ran fine on 6/18/2005, but failed on 6/25/2005.
>   - From saved commits emails, it appears relevant revisions are between  
> 191353 (jean)
>   and 201792 (kathey), jean's are all dita related,  2 of kathey's 
> are functionTests only changes.
> This leaves the following 2
>   201792 - kmarsden - DERBY-389,
> 
> incubator/derby/code/trunk/java/engine/org/apache/derby/impl/sql/conn/GenericLanguageConnectionContext.java
>   191755 - kmarsden - DERBY-8 and DERBY-366; mostly test/master 
> updates, but additionally changed:
>
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection.java
>
> incubator/derby/code/trunk/java/engine/org/apache/derby/iapi/jdbc/BrokeredConnection30.java
>   - I backtracked the changes from these revisions but still the hang 
> persists...
>   
>   
> - 10.1 
>   - I tested build 224373 and 208786 and the could reproduce the hang; 
> but 
> with build 190628 (which happened to be stting around on my machine) 
> there was no hang.
> Thus, with 10.1 branch, the problem was introduced/backported between 
> revision
> 190628 and revision 208786.
>- Looking at a combination of the commit archive for July and my saved 
> commit emails, again, most of these are innocent test or dita updates.
>- The following are more interesting:
>   - 201659 - satheesh - DERBY-388 - 
>   
> incubator/derby/code/branches/10.0/java/engine/org/apache/derby/impl/sql/GenericPreparedStatement.java
>   - 208697 - dan - cleanup of published javadoc for embedded jdbc 
> objects
>  
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedConnectionPoolDataSource.java
>  
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDataSource.java
>  
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedDriver.java
>  
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedSimpleDataSource.java
>  
> incubator/derby/code/branches/10.1/java/engine/org/apache/derby/jdbc/EmbeddedXADataSource.java
>   - 208776 - andrew - monster commit backport fixes for DERBY-8, 
> DERBY-247, DERBY-276, 
> DERBY-348, DERBY-354,DERBY-361, DERBY-366, DERBY-389, 
> DERBY-405, DERBY-416, and DERBY-420
>   - I tried to backtrack my 10.1 branch to revision 208775, but that 
> resulted in:
>   svn: REPORT request failed on '/repos/asf/!svn/vcc/default'
>   svn:
>   Cannot replace a directory from within
> In short, historical research has gotten me nowhere.
> I looked at the stack of the threads when the program is hanging but it tells 
> me nothing either.
> I will attached the stack threads obtained by running the following command:
>   j9 -jcl:max 
> -Xbootclasspath/p:c:/ive22/lib/database_enabler.jar;c:ive22/lib/classes.zip 
> org.apache.derbyTesting.unitTests.harness.UnitTestMain 
>  on windows and subsequently pressing ctrl-break, and derby.log
> Note: this problem does not occur with wsdd5.6 (j9 version 2.1). The test 
> never runs/ran with j9foundation (also wctme5.7).   

-- 
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.atl

[jira] Updated: (DERBY-649) Useful indexes not used in UNION ALL

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-649:
-

Component: SQL

> Useful indexes not used in UNION ALL
> 
>
>  Key: DERBY-649
>  URL: http://issues.apache.org/jira/browse/DERBY-649
>  Project: Derby
> Type: Bug

>   Components: SQL
> Reporter: Rick Hillegas
>  Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.2
>  Attachments: DERBY-649.patch, DERBY-649.stat
>
> Frederic Moreau reports 
> (http://mail-archives.apache.org/mod_mbox/db-derby-user/200510.mbox/browser):
> Hello,
> The optimizer does not take my indexes into account when I do a select on 
> a 'UNION ALL' type of view ; therefore, table scans are done and 
> performances are bad.
> Note : my indexes are taken into account if I try equivalent selects on 
> tables (instead of views).
> Please find below a sample illustrating the problem using the 
> RUNTIMESTATISTICS calls.
> Could anynone help me on this subject ?
> Thank you.
> My cloudscape version is the 10.0.2.1 one.
> I also tried it on the 10.1.1.0 version (same result).
>   c:\>java -classpath 
> "%CLOUDSCAPE_INSTALL%\lib\derbyclient.jar;%CLOUDSCAPE_INSTALL%\lib\derbytools.jar"
>  
> -Dij.driver=org.apache.derby.jdbc.ClientDriver 
> -Dij.protocol=jdbc:derby://localhost:1527/ -Dij.user=APP -Dij.password=APP 
> -Dij.maximumDisplayWidth=32768 org.apache.derby.tools.ij  ij> connect 
> 'testdb' ;
>   ij> ;
>   ij> create table test.table1(a integer, b integer, c integer);
>   ij> create index test.table1idx on test.table1(b);
>   ij> ;
>   ij> create table test.table2(a integer, b integer, c integer);
>   ij> create index test.table2idx on test.table2(b);
>   ij> ;
>   ij> create view test.view0 as select all a,b from test.table1 union all 
> select a,b from test.table2;
>   ij> ;
>   ij> CALL SYSCS_UTIL.SYSCS_SET_RUNTIMESTATISTICS(1);
>   ij> select a from test.table1 where b=25;
>   ij> VALUES SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
> ...
> Index Scan ResultSet for TABLE1 using index TABLE1IDX at read 
> committed isolation level using instantaneous share row locking chosen by 
> the optimizer
> ...
>   ij> select a from test.table2 where b=25;
>   ij> VALUES SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
> ...
> Index Scan ResultSet for TABLE2 using index TABLE2IDX at read 
> committed isolation level using instantaneous share row locking chosen by 
> the optimizer
> ...
>   ij> select a from test.view0 where b=25;
>   ij> VALUES SYSCS_UTIL.SYSCS_GET_RUNTIMESTATISTICS();
> ...
> Table Scan ResultSet for TABLE1 at read committed isolation level 
> using share row locking chosen by the optimizer
> ...
> Table Scan ResultSet for TABLE2 at read committed isolation level 
> using share row locking chosen by the optimizer
> ...
>   ij> ;

-- 
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-663) Test of derby fails because difference in encoding of eol make sizes of test data files different between platforms.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-663:
-

Component: Test

> Test of derby fails because difference in encoding of eol make sizes of test 
> data files different between platforms.
> 
>
>  Key: DERBY-663
>  URL: http://issues.apache.org/jira/browse/DERBY-663
>  Project: Derby
> Type: Bug

>   Components: Test
> Versions: 10.2.0.0
>  Environment: [EMAIL PROTECTED]:~/ProgramDev/derby/trunk$ cat /proc/version 
> Linux version 2.4.27-2-386 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
> 1:3.3.5-12)) #1 Mon May 16 16:47:51 JST 2005
> Reporter: Tomohito Nakayama
> Assignee: Oyvind Bakksjo
>  Fix For: 10.2.0.0

>
> I found concrete failure in jdbc/resultsetStream.java .
> * Diff file jdbcapi/jdbcapi/resultsetStream.diff
> *** Start: resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:16:58 ***
> 10 del
> < len=56
> 11 del
> < number of reads=56
> 11a10,11
> > len=55
> > number of reads=55
> Test Failed.
> *** End:   resultsetStream jdk1.5.0_03 jdbcapi:jdbcapi 2005-10-29 20:17:00 ***
> Surveying code and history of source repository, this test program seems to 
> fail because test program suppose size of data file named "short.txt" as "56 
> bytes" assuming data file encodes eol as CR LF .
> There seems to be some more substantially same failures .

-- 
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-689) Various improvements to compatibility test.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-689:
-

Component: Test

> Various improvements to compatibility test.
> ---
>
>  Key: DERBY-689
>  URL: http://issues.apache.org/jira/browse/DERBY-689
>  Project: Derby
> Type: Improvement

>   Components: Test
> Reporter: Rick Hillegas
> Assignee: Rick Hillegas
>  Attachments: bug689.diff, bug689_2.diff
>
> Improve compatibility test as various reviewers requested.

-- 
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-739) Reduce generated code required to access a parameter's value

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-739:
-

Component: Services

> Reduce generated code required to access a parameter's value
> 
>
>  Key: DERBY-739
>  URL: http://issues.apache.org/jira/browse/DERBY-739
>  Project: Derby
> Type: Sub-task

>   Components: Services
> Reporter: Daniel John Debrunner
> Assignee: Kathey Marsden
> Priority: Minor
>  Fix For: 10.2.0.0
>  Attachments: derby739_2.diff
>
> When accessing a parameter the generated code is:
> this.pvs.getParameter(23);
> A slightly shorter form would be
> this.getParameter(23);
> if a getParameter() method was added to BaseActivation that simply did:
>  protected final DataValueDescriptor getParameter(int n) { return 
> pvs.getParameter(n); }
> --
> An interesting separate idea, to reduce the number of constant pool entries 
> would be to have multiple getParameter() methods, that took values from 0-5 
> to construct the actual parameter number.
> getParameter(3) -- >  3 parameter (0 based)
> getParameter(2, 1) --> 13 parameter (2*6 + 1)
> getParameter(5, 1, 4) --> 190 parameter (5*36 + 1*6+ 4)
> above the limit of three args, revert to getParameter(n)
> This should probably be a separate issue and probably would increease code 
> size which would not help DERBY-732 , it's a tradeoff between constant pool 
> entries and code size.

-- 
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-807) Failure in derbyall/derbylang since r366564 | 2006-01-06 21:44:57 +0100 (Fri, 06 Jan 2006) | Add grantRevoke test to derbyLang suite.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-807:
-

Component: Build tools

> Failure in derbyall/derbylang since  r366564 | 2006-01-06 21:44:57 +0100 
> (Fri, 06 Jan 2006) | Add grantRevoke test to derbyLang suite.
> --
>
>  Key: DERBY-807
>  URL: http://issues.apache.org/jira/browse/DERBY-807
>  Project: Derby
> Type: Bug

>   Components: Build tools
> Versions: 10.2.0.0
>  Environment: "All"
> Reporter: Ole Solberg
> Assignee: Satheesh Bandaram
> Priority: Minor
>  Fix For: 10.2.0.0

>
> Example:
> * Diff file derbylang/derbylang/grantRevoke.diff
> *** Start: grantRevoke jdk1.5.0_04 derbylang:derbylang 2006-01-07 00:04:53 ***
> 6 del
> < 0 rows inserted/updated/deleted
> 6a6
> > ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> +
> +
> See e.g.
> http://www.multinet.no/~solberg/public/Apache/TinderBox_Derby/Limited/derbylang_history.html
> http://www.multinet.no/~solberg/public/Apache/Derby/Limited/derbylang_history.html

-- 
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-838) Create internationalization framework for network client

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-838:
-

Component: Network Client

> Create internationalization framework for network client
> 
>
>  Key: DERBY-838
>  URL: http://issues.apache.org/jira/browse/DERBY-838
>  Project: Derby
> Type: Sub-task

>   Components: Network Client
> Reporter: David Van Couvering
> Assignee: David Van Couvering
>  Fix For: 10.2.0.0

>
> This sub-task is to establish the internationalization framework for the 
> network client.  Once this is established multiple individuals could 
> conceivably internationalize messages in parallel.  I will be creating 
> separate subtasks for groups of classes to have their messages 
> internationalized, and will make them Newcomer tasks.

-- 
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-852) Convert SqlException to no longer extend SQLException

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-852:
-

Component: Network Client

> Convert SqlException to no longer extend SQLException
> -
>
>  Key: DERBY-852
>  URL: http://issues.apache.org/jira/browse/DERBY-852
>  Project: Derby
> Type: Sub-task

>   Components: Network Client
> Reporter: David Van Couvering
> Assignee: David Van Couvering
>  Fix For: 10.2.0.0

>


-- 
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-888) improve performance of page allocation

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-888:
-

Component: Store

> improve performance of page allocation
> --
>
>  Key: DERBY-888
>  URL: http://issues.apache.org/jira/browse/DERBY-888
>  Project: Derby
> Type: Improvement

>   Components: Store
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Priority: Minor
>  Fix For: 10.2.0.0

>
> Improve performance of page allocation by no longer requiring sync of the 
> allocated pages.  The reason for the sync
> currently is so that during redo recovery we did not have to handle the case 
> of redoing the allocate and finding no space
> available on the disk.   During tasks like single user load this sync 
> allocation is a significant performance issue - in the
> case where one does 1000 insert per transaction the total time aproaches very 
> close to durability=test where no syncing
> is done in the whole system.
> For instance in a test of loading a 150 meg db with a number of tables and 
> indexes, on a 1.7 ghz laptop with one ide disk,
> sun jdk1.4.2, windows XP
> i got the following types of results:
> default system:  6 minutes
> no alloc sync:  1 minute, 43 seconds
> no syncing:  1 minute , 1 second
> Once syncing is disabled then recovery must be enhanced to handle the 
> possible out of space condition.  Recovery already
> handles out of space during undo, so this will just handle the error the same 
> as that.  It will stop recovery and produce an error
> indicating that user must add disk space and rerun recovery before system can 
> be brought online.  I actually think on most
> JVM's/OS's this won't happen as the system will still be asking the JVM/OS 
> for the space, just not syncing the values in those
> pages to disk.  Most OS's at this point will reserve the space in the file 
> tables and not let others grab that space.  
> This project will make sure that out of space recovery path has tests.  It 
> will also make sure that redo recovery encountering garbage
> in a newly allocated page during redo of an create page is tested.

-- 
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-920) small delta's to replace cloudscape etc with derby in comments/code

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-920:
-

Component: Tools

> small delta's to replace cloudscape etc with derby in comments/code
> ---
>
>  Key: DERBY-920
>  URL: http://issues.apache.org/jira/browse/DERBY-920
>  Project: Derby
> Type: Task

>   Components: Tools
>  Environment: N/A
> Reporter: scott hutinger
> Assignee: Bryan Pendleton
> Priority: Trivial
>  Fix For: 10.2.0.0
>  Attachments: sysinfo-main.diff.gz, updatedDiff.txt
>
> Smaller delta's to modify older source code comments which in some cases 
> should be updated.  Many cases older owners of the source should be kept 
> intact, as it refers to past or future tenses in a context where changes are 
> not needed/wanted.
> Smaller delta's so this might happen some day :-)

-- 
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-922) getSQLException() method in client.am.SqlException does not correctly chain exceptions

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-922:
-

Component: Network Client

> getSQLException() method in client.am.SqlException does not correctly chain 
> exceptions
> --
>
>  Key: DERBY-922
>  URL: http://issues.apache.org/jira/browse/DERBY-922
>  Project: Derby
> Type: Bug

>   Components: Network Client
> Reporter: David Van Couvering
> Assignee: David Van Couvering

>
> This was detected by Knut Anders.  From his email:
> I think
>  
>  if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
>  {
>  sqle.initCause(getCause());
>  }
>  
>  should have been
>  
>  if (JVMInfo.JDK_ID >= JVMInfo.J2SE_14 )
>  {
>  sqle.initCause(this);
>  }
>  
>  It is the SqlException that is the cause of the SQLException. The
>  cause of an SqlException is often null, and if we pass the null value
>  to SQLException.initCause(), we lose all of the driver internal stack
>  trace, and it makes debugging very difficult. All we get in the stack
>  trace is SqlException.getSQLException(), the top-level JDBC method and
>  the application stack.

-- 
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-932) Fix the way JDK 1.6 specific files are built

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-932:
-

Component: Build tools

> Fix the way JDK 1.6 specific files are built
> 
>
>  Key: DERBY-932
>  URL: http://issues.apache.org/jira/browse/DERBY-932
>  Project: Derby
> Type: Bug

>   Components: Build tools
> Reporter: David Van Couvering
> Assignee: David Van Couvering
>  Fix For: 10.2.0.0

>
> Currently these files are built using the exec ant task.  This results in odd 
> behavior, such as the fact as the build doesn't end if there's a build 
> failure with one of these targets.  Also, in NetBeans the compile errors are 
> not "clickable".  Fix this to use javac where you specify the compiler 
> executable path.

-- 
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-998) tests jdbcapi/SURTest.junit and jdbcapi/SURQueryMixTest.junit run twice in derbynetclientmats

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-998:
-

Component: Test

> tests jdbcapi/SURTest.junit and jdbcapi/SURQueryMixTest.junit run twice in 
> derbynetclientmats
> -
>
>  Key: DERBY-998
>  URL: http://issues.apache.org/jira/browse/DERBY-998
>  Project: Derby
> Type: Test

>   Components: Test
> Versions: 10.2.0.0
> Reporter: Myrna van Lunteren
> Priority: Trivial

>
> The tests SURTest.junit and SURQueryMixTest.junit both appear in 
> derbynetclientmats.runall as well as in jdbcapi.runall. So it unnecessarily 
> runs twice, because jdbcapi is already included in the suites in 
> derbynetclientmats.properties. 
> It should be removed from derbynetclientmats.runall.

-- 
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-1006) Client allows setHoldability to HOLD_CURSORS_OVER_COMMIT on both connection and statement in a global transaction

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1006:
--

Component: Network Client

> Client allows setHoldability to HOLD_CURSORS_OVER_COMMIT  on both connection 
> and statement in a global transaction
> --
>
>  Key: DERBY-1006
>  URL: http://issues.apache.org/jira/browse/DERBY-1006
>  Project: Derby
> Type: Bug

>   Components: Network Client
> Versions: 10.1.2.2, 10.3.0.0
> Reporter: Kathey Marsden
> Assignee: Daniel John Debrunner
>  Fix For: 10.2.0.0, 10.1.2.3, 10.1.3.0

>
> Client allows holdability to be set to HOLD_CURSORS_OVER_COMMIT in a global 
> transaction.
> I am not sure of the impact on the server side.
> To reproduce look for this code in checkDataSource30 and take out the return  
> for client.
> if (!TestUtil.isEmbeddedFramework())
>   {
>   // Don't run the rest of the test for client
>   // Network XA BUG: Client allows set 
> HOLD_CURSORS_OVER_COMMIT 
>   // to be set in a a global transaction on the 
> connection and 
>   // statements
>   conn.close();
>   return;
>   }
>   
> xid = getXid(24, (byte) 21, (byte) 01);
>   xr.start(xid, XAResource.TMNOFLAGS);
>   System.out.println("CONNECTION(xa) HOLDABILITY " + 
> (conn.getHoldability() == ResultSet.HOLD_CURSORS_OVER_COMMIT));
>   try {
>   
> conn.setHoldability(ResultSet.HOLD_CURSORS_OVER_COMMIT);
>   System.out.println("FAIL allowed to set hold 
> mode in xa transaction");
>   } catch (SQLException sqle) {
>   System.out.println("Expected 
> SQLException(setHoldability) " + sqle.getMessage());
>   }

-- 
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-1013) jdbc4 test suite test classes are using Util.notImplemented

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1013:
--

Component: Test

> jdbc4 test suite test classes are using Util.notImplemented
> ---
>
>  Key: DERBY-1013
>  URL: http://issues.apache.org/jira/browse/DERBY-1013
>  Project: Derby
> Type: Bug

>   Components: Test
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>  Attachments: derby-1013.diff
>
> jdbc4 test suite test classes are using Util.notImplemented to get exception 
> text and then using the message comparison to check if the message are same 
> in the thrown exception. This may cause problem in future because the jdbc4 
> code is using SQLState.NOT_IMPLEMENTED with a paramter (feature name). As the 
> test classes are creating the exception without any parameter the test 
> comparision will fail. 
> In this patch I have modified the test code to test for sql state which won't 
> change.

-- 
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-1045) forupdate.sql , holdCursorIJ.sql ..etc are failing when run with 10.1 client againest trunk

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1045:
--

 Component: Build tools
JDBC
Derby Info: [Regression]

> forupdate.sql , holdCursorIJ.sql ..etc are failing when run with 10.1 client 
> againest trunk
> ---
>
>  Key: DERBY-1045
>  URL: http://issues.apache.org/jira/browse/DERBY-1045
>  Project: Derby
> Type: Bug

>   Components: Build tools, JDBC
> Versions: 10.2.0.0
>  Environment: Java Version:1.5.0_02
> Java Vendor: Sun Microsystems Inc.
> Java home:   d:\dev\src\jdk15\jre
> Java classpath:  
> d:/dev/src/classes/derby.jar;d:/dev/src/classes/derbytools.jar;d:/dev/src/classes/derbynet.jar;d:/dev/src/classes/v10_1_client/derbyclient.jar;d:/dev/src/classes/functionTests.jar;d:/dev/src/classes/v10_1_client/derbyTesting.jar;d:/dev/src/tools/java/jndi/fscontext.jar;d:/dev/src/tools/java/junit.jar;d:/dev/src/classes/derbyLocale_zh_TW.jar;d:/dev/src/classes/derbyLocale_zh_CN.jar;d:/dev/src/classes/derbyLocale_pt_BR.jar;d:/dev/src/classes/derbyLocale_ko_KR.jar;d:/dev/src/classes/derbyLocale_ja_JP.jar;d:/dev/src/classes/derbyLocale_it.jar;d:/dev/src/classes/derbyLocale_fr.jar;d:/dev/src/classes/derbyLocale_es.jar;d:/dev/src/classes/derbyLocale_de_DE.jar;
> OS name: Windows 2000
> OS architecture: x86
> OS version:  5.0
> Java user dir:   
> D:\dev\src\JarResults.2006-02-22\jdk15_derbynetclientmats_client_v101
> java.specification.name: Java Platform API Specification
> java.specification.version: 1.5
> - Derby Information 
> JRE - JDBC: J2SE 5.0 - JDBC 3.0
> [D:\dev\src\classes\derby.jar] 10.2.0.0 alpha - (380027)
> [D:\dev\src\classes\derbytools.jar] 10.2.0.0 alpha - (380027)
> [D:\dev\src\classes\derbynet.jar] 10.2.0.0 alpha - (380027)
> [D:\dev\src\classes\v10_1_client\derbyclient.jar] 10.1.2.3 - (379660)
> Reporter: Suresh Thalamati
> Assignee: Andrew McIntyre
>  Fix For: 10.2.0.0
>  Attachments: derbynetclientmats_report.txt
>
> derbynetclientmats/derbynetmats/derbynetmats.fail:lang/forupdate.sql
> derbynetclientmats/derbynetmats/derbynetmats.fail:lang/holdCursorIJ.sql
> 
> derbynetclientmats/derbynetmats/derbynetmats.fail:store/holdCursorJDBC30.sql
> derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/LOBTest.java
> 
> derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/blobclob4BLOB.java
> 
> derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/parameterMapping.java
> 
> derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/setTransactionIsolation.java
> 
> derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/metadataJdbc20.java
> 
> derbynetclientmats/derbynetmats/derbynetmats.fail:jdbcapi/connectionJdbc20.java
> Sample diff :
> *** Start: forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 
> 2006-02-23 07:30:19 ***
> 23 del
> < ERROR 42X01: Syntax error: Encountered "" at line 1, column 23.
> 23a23
> > ERROR 42X01: Syntax error: Encountered "" at line 3, column 23.
> 59 del
> < ERROR (no SQLState): Invalid cursor name "C1" in the Update/Delete 
> statement.
> 59a59
> > ERROR 42X30: Cursor 'SQL_CURLH000C1' not found. Verify that autocommit is 
> > OFF.
> 132 del
> < ERROR (no SQLState): Invalid cursor name "C4" in the Update/Delete 
> statement.
> 132a132
> > ERROR 42X30: Cursor 'SQL_CURLH000C1' not found. Verify that autocommit is 
> > OFF.
> 135 del
> < ERROR (no SQLState): Invalid cursor name "C4" in the Update/Delete 
> statement.
> 135a135
> > ERROR 42X30: Cursor 'SQL_CURLH000C1' not found. Verify that autocommit is 
> > OFF.
> 180 del
> < ERROR 42X01: Syntax error: Encountered "." at line 1, column 34.
> 180a180
> > ERROR 42X01: Syntax error: Encountered "." at line 3, column 34.
> Test Failed.
> *** End:   forupdate jdk1.5.0_02 DerbyNetClient derbynetmats:derbynetmats 2006

-- 
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-1067) support holdable Scrollable Updatable Resultsets

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1067:
--

Component: JDBC
   Network Client

> support holdable Scrollable Updatable Resultsets
> 
>
>  Key: DERBY-1067
>  URL: http://issues.apache.org/jira/browse/DERBY-1067
>  Project: Derby
> Type: Sub-task

>   Components: JDBC, Network Client
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
>  Fix For: 10.2.0.0
>  Attachments: DERBY-1067.diff, DERBY-1067.stat, DERBY-1067v2.diff, 
> DERBY-1067v2.stat, DERBY-1067v3.diff, DERBY-1067v4.diff, derbyall_report.txt, 
> storeunit_report.txt
>


-- 
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-1070) add tests for holdable SUR

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1070:
--

Component: Test

> add tests for holdable SUR
> --
>
>  Key: DERBY-1070
>  URL: http://issues.apache.org/jira/browse/DERBY-1070
>  Project: Derby
> Type: Sub-task

>   Components: Test
> Reporter: Andreas Korneliussen
> Assignee: Andreas Korneliussen
>  Fix For: 10.2.0.0
>  Attachments: DERBY-1070.diff, DERBY-1070.stat, DERBY-1070v2.diff
>


-- 
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-1105) derbyall failures due to change in exception type

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1105:
--

 Component: JDBC
Derby Info: [Regression]

> derbyall failures due to change in exception type
> -
>
>  Key: DERBY-1105
>  URL: http://issues.apache.org/jira/browse/DERBY-1105
>  Project: Derby
> Type: Sub-task

>   Components: JDBC
> Versions: 10.2.0.0
>  Environment: jdk 1.6
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>  Attachments: derby-1105.diff.gz, derby-1105.stat
>
> due to change in exception type in embedded driver there are several failures 
> in derbyall under jdk1.6. The out file ot the test case should be changed in 
> such a way that it works on jdk1.6 and older jdk's without fails

-- 
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-1119) Creating a schema with DumpParseTree, DumpBindTree properties set causes NullPointException.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1119:
--

Component: SQL

> Creating a schema with DumpParseTree, DumpBindTree properties set causes 
> NullPointException.
> 
>
>  Key: DERBY-1119
>  URL: http://issues.apache.org/jira/browse/DERBY-1119
>  Project: Derby
> Type: Bug

>   Components: SQL
> Versions: 10.1.2.0, 10.2.0.0
> Reporter: Satheesh Bandaram
> Assignee: Satheesh Bandaram
> Priority: Minor
>  Fix For: 10.2.0.0

>
> Noticed it in 10.2, but also reproduces with 10.1.
> Set the following property and then try creating a schema as follows:
> derby.debug.true=DumpBindTree,DumpParseTree,DumpOptimizedTree
> C:\p4clients\sat_52\bug>java -Dij.protocol=jdbc:derby: 
> org.apache.derby.tools.ij
> ij version 10.2
> ij> connect 'tdb;user=sam';
> ij> create schema mysam1;
> ERROR XJ001: Java exception: ': java.lang.NullPointerException'.
> I suspect the problem is because DDLStatementNode.java expects an object name 
> that most DDL statements set, but not CreateSchemaNode.java.
>   
>   public String toString()
>   {
>   if (SanityManager.DEBUG)
>   {
>   return objectName.toString() + super.toString();
>   <==
>   } 
>   else
>   {
>   return "";
>   }
>   }
> CreateSchemaNode.java:
>   /*
>   ** DDLStatementNode expects tables, null out
>   ** objectName explicitly to clarify that we
>   ** can't hang with schema.object specifiers.
>   */
>   initAndCheck(null); 
>   
> Here is exception stack:
> java.lang.NullPointerException
>   at 
> org.apache.derby.impl.sql.compile.DDLStatementNode.toString(DDLStatementNode.java:149)
>   at 
> org.apache.derby.impl.sql.compile.CreateSchemaNode.toString(CreateSchemaNode.java:94)
>   at 
> org.apache.derby.impl.sql.compile.QueryTreeNode.treePrint(QueryTreeNode.java:329)
>   at 
> org.apache.derby.impl.sql.GenericStatement.prepMinion(GenericStatement.java:318)
>   at 
> org.apache.derby.impl.sql.GenericStatement.prepare(GenericStatement.java:118)
>   at 
> org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.prepareInternalStatement(GenericLanguageConnectionContext.java:725)
>   at 
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:533)
>   at 
> org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:480)
>   at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:313)
>   at org.apache.derby.impl.tools.ij.utilMain.doCatch(utilMain.java:433)
>   at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)
>   at org.apache.derby.impl.tools.ij.Main.go(Main.java:203)
>   at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:169)
>   at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
>   at org.apache.derby.tools.ij.main(ij.java:60)
> Cleanup action completed

-- 
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-1125) Getting security exception when derbyclient.jar is before derby.jar because classes in iapi.services.info have been added to derbyclient.jar

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1125:
--

Component: Build tools

> Getting security exception when derbyclient.jar is before derby.jar  because 
> classes in iapi.services.info have been added to derbyclient.jar
> -
>
>  Key: DERBY-1125
>  URL: http://issues.apache.org/jira/browse/DERBY-1125
>  Project: Derby
> Type: Bug

>   Components: Build tools
> Versions: 10.2.0.0
> Reporter: David Van Couvering
> Assignee: David Van Couvering
> Priority: Critical
>  Fix For: 10.2.0.0

>
> This security exception can occur if derbyclient.jar is before derby.jar 
> after revision 370815.  
> See:
> http://www.nabble.com/regression-%21-all-tests-in-jdbcapi-fails-for-me-t1298249.html#a3462544
> From Andrew's email:
> On 3/17/06, Andreas Korneliussen <[EMAIL PROTECTED]> wrote:
> > 
> >
> > Exception: java.lang.SecurityException: sealing violation: can't seal 
> > package org.apache.derby.iapi.services.info:
> already loaded
> See DERBY-848 and DERBY-1046.
> iapi.services.info.ProductVersionHolder and friends were added to
> derbyclient.jar by David in DERBY-848, specifically with revision
> 370815.
> There are two clear solutions: unseal iapi.services.info or copy the
> info classes to a new shared info package.

-- 
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-1140) Provide JDBC4 SQLException subclasses support in network driver

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1140:
--

Component: Network Client

> Provide JDBC4 SQLException subclasses support in network driver
> ---
>
>  Key: DERBY-1140
>  URL: http://issues.apache.org/jira/browse/DERBY-1140
>  Project: Derby
> Type: Sub-task

>   Components: Network Client
> Versions: 10.2.0.0
>  Environment: jdk1.6 
> Reporter: Anurag Shekhar
> Assignee: Anurag Shekhar
>  Attachments: bug1140_magic.diff, derby-1140.diff, 
> derby-1140_2-outfiles.diff, derby-1140_2.diff, derby-1140_3.diff, svnstat.out
>


-- 
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-1126) SanityState.java is not being removed

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1126:
--

Component: Build tools

> SanityState.java is not being removed
> -
>
>  Key: DERBY-1126
>  URL: http://issues.apache.org/jira/browse/DERBY-1126
>  Project: Derby
> Type: Bug

>   Components: Build tools
> Reporter: David Van Couvering
> Assignee: David Van Couvering

>
> Prior to moving SanitiyState.java over to the shared packages, once 
> SanityState.class was built, SanityState.java was removed, to avoid it 
> accidentally being committed to the repository since it is a generated file.  
> That is no longer happening, and needs to be fixed.

-- 
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-1159) PreparedStatement.executeUpdate throws a XJ05C exception in a global transaction if the statement is HOLD_CURSORS_OVER_COMMIT

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1159:
--

Component: JDBC

> PreparedStatement.executeUpdate throws a XJ05C exception in a global 
> transaction if the statement is HOLD_CURSORS_OVER_COMMIT
> -
>
>  Key: DERBY-1159
>  URL: http://issues.apache.org/jira/browse/DERBY-1159
>  Project: Derby
> Type: Bug

>   Components: JDBC
> Versions: 10.2.0.0, 10.1.2.1
> Reporter: Daniel John Debrunner
> Assignee: Daniel John Debrunner
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.4

>
> SQLSTATE(XJ05C): Cannot set holdability ResultSet.HOLD_CURSORS_OVER_COMMIT for
>  a global transaction.
> Exception is thrown in client, in embedded the statement executes 
> successfully.
> Since HOLD_CURSORS_OVER_COMMIT  only applies to ResultSets  and executeUpdate 
> states it only succeeds if the statement
> does not generate ResultSets, then this combination should succeed.
> Probably related to the fact that in embedded an execute() call on the same 
> PreparedStatement will thrown a  XJ05C exception
> Workaround is to prepare the statement explicitly with 
> CLOSE_CURSORS_AT_COMMIT.

-- 
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-1185) Move all client messages to messages.properties

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1185:
--

Component: Network Client

> Move all client messages to messages.properties
> ---
>
>  Key: DERBY-1185
>  URL: http://issues.apache.org/jira/browse/DERBY-1185
>  Project: Derby
> Type: Sub-task

>   Components: Network Client
> Reporter: David Van Couvering
> Assignee: David Van Couvering
> Priority: Minor

>
> Right now messages that are deemed network client specific are placed 
> manually in clientmessages.properties.  This is a JIRA for moving these 
> messages to messages.properties and using splitmessages.java to copy over the 
> messages the client needs to clientmessages.properties at build time.  The 
> goal is to reduce the overall complexity of adding messages to the client,and 
> also to help ensure that messages across client and embedded drivers are 
> consistent and coherent.

-- 
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-1187) defragment of inplace compress pass for described dataset is not freeing up empty pages.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1187:
--

Component: Store

> defragment of inplace compress pass for described dataset is not freeing up 
> empty pages.
> 
>
>  Key: DERBY-1187
>  URL: http://issues.apache.org/jira/browse/DERBY-1187
>  Project: Derby
> Type: Bug

>   Components: Store
> Versions: 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 10.1.2.1, 10.1.2.2, 
> 10.1.2.3, 10.2.0.0
> Reporter: Mike Matrigali
> Assignee: Mike Matrigali
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.4

>
> For the following script defragment pass is not freeing up the free pages:
> drop table t1;
> create table t1 (i integer primary key, j integer, c char(200));
> insert into t1 values (1, 1, 'a');
> insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
> insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
> insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
> insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
> insert into t1 (select t1.i + 16,   t1.j + 16,   t1.c from t1);
> insert into t1 (select t1.i + 32,   t1.j + 32,   t1.c from t1);
> insert into t1 (select t1.i + 64,   t1.j + 64,   t1.c from t1);
> insert into t1 (select t1.i + 128,  t1.j + 128,  t1.c from t1);
> insert into t1 (select t1.i + 256,  t1.j + 256,  t1.c from t1);
> insert into t1 (select t1.i + 512,  t1.j + 512,  t1.c from t1);
> delete from t1 where i < 512;
> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> Here is example output from a run on the trunk:
> ij> drop table t1;
> 0 rows inserted/updated/deleted
> ij> create table t1 (i integer primary key, j integer, c char(200));
> 0 rows inserted/updated/deleted
> ij> insert into t1 values (1, 1, 'a');
> 1 row inserted/updated/deleted
> ij> insert into t1 (select t1.i + 1,t1.j + 1,t1.c from t1);
> 1 row inserted/updated/deleted
> ij> insert into t1 (select t1.i + 2,t1.j + 2,t1.c from t1);
> 2 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 4,t1.j + 4,t1.c from t1);
> 4 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 8,t1.j + 8,t1.c from t1);
> 8 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 16,   t1.j + 16,   t1.c from t1);
> 16 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 32,   t1.j + 32,   t1.c from t1);
> 32 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 64,   t1.j + 64,   t1.c from t1);
> 64 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 128,  t1.j + 128,  t1.c from t1);
> 128 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 256,  t1.j + 256,  t1.c from t1);
> 256 rows inserted/updated/deleted
> ij> insert into t1 (select t1.i + 512,  t1.j + 512,  t1.c from t1);
> 512 rows inserted/updated/deleted
> ij> delete from t1 where i < 512;
> 511 rows inserted/updated/deleted
> ij> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
> cast(numunfilledpages as int) as unfilled,
> pagesize,
> estimspacesaving
> from new org.apache.derby.diag.SpaceTable('T1') t order by conglomeratename;
> TABNAME |ISIND&|ALLOC  |NUMFREEPAGES|UNFILLED   |PAGESIZE   
> |EST
> IMSPACESAVING
> 
> -
> SQL060406034|1 |7  |0   |0  |4096   |0
> T1  |0 |60 |9   |0  |4096   
> |368
> 64
> 2 rows selected
> ij> CALL SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE('APP', 'T1', 1, 1, 1);
> 0 rows inserted/updated/deleted
> ij> select
> cast(conglomeratename as char(12)) as tabname,
> isindex,
> cast(numallocatedpages as int) as alloc,
> numfreepages,
>  

[jira] Updated: (DERBY-1263) build.xml doesn't create the ${basedir}/src/dtd directory

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1263:
--

Component: Build tools

> build.xml doesn't  create the  ${basedir}/src/dtd directory
> ---
>
>  Key: DERBY-1263
>  URL: http://issues.apache.org/jira/browse/DERBY-1263
>  Project: Derby
> Type: Bug

>   Components: Build tools
>  Environment: DITA-sourced documentation
> Reporter: Halley Pacheco de Oliveira
> Assignee: Andrew McIntyre
>  Fix For: 10.2.0.0

>
> The Revision 397627 build.xml file doesn't have the instruction  todir="${basedir}/src/dtd">, or equivalent, to copy the dtd directory from 
> ${basedir}/DITA-OT1.1.2.1/dtd/ to ${basedir}/src/dtd the first time one of 
> the manuals is built, as previous versions of this file had.
> Without the ${basedir}/src/dtd directory, the tags
>   "../dtd/concept.dtd">
> in .dita files, and other tags with references to dtd files, are incorrect.

-- 
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-1362) Class-Path manifest entry for derby.jar is missing from the 10.2.0.2 snapshot

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1362:
--

Component: Build tools

> Class-Path manifest entry for derby.jar is missing from the 10.2.0.2 snapshot
> -
>
>  Key: DERBY-1362
>  URL: http://issues.apache.org/jira/browse/DERBY-1362
>  Project: Derby
> Type: Bug

>   Components: Build tools
> Versions: 10.2.0.0
> Reporter: Daniel John Debrunner
> Assignee: Rick Hillegas
> Priority: Critical
>  Attachments: bug1362_1.diff
>
> The class path manifest entry should include all the supported locales. It is 
> missing from the snapshot.
> I see this entry when I build the jar files myself.
> Class-Path: derbyLocale_de_DE.jar derbyLocale_es.jar derbyLocale_fr.ja
>  r derbyLocale_it.jar derbyLocale_ja_JP.jar derbyLocale_ko_KR.jar derb
>  yLocale_pt_BR.jar derbyLocale_zh_CN.jar derbyLocale_zh_TW.jar

-- 
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-1368) EOFException when reading from blob's binary stream

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1368:
--

Component: JDBC

> EOFException when reading from blob's binary stream
> ---
>
>  Key: DERBY-1368
>  URL: http://issues.apache.org/jira/browse/DERBY-1368
>  Project: Derby
> Type: Bug

>   Components: JDBC
> Versions: 10.1.2.1
> Reporter: Tobias Bocanegra
>  Fix For: 10.2.0.0
>  Attachments: Derby1368.java
>
> reading the 'length()' of a blob reads a previously aquired binary stream.
> test case:
> public static void main(String[] argv) throws Exception {
> String driver = "org.apache.derby.jdbc.EmbeddedDriver";
> String url = "jdbc:derby:derby/test;create=true";
> Class.forName(driver);
> Connection con = DriverManager.getConnection(url, "sa", "");
> con.setAutoCommit(true);
> // create table
> System.out.println("1) creating table...");
> Statement stmt = con.createStatement();
> stmt.execute("create table T1 (ID char(32) PRIMARY KEY, DATA blob(2G) 
> not null)");
> stmt.close();
> // add row
> System.out.println("2) adding row...");
> byte[] data = new byte[1024*1024*1];
> data[0] = 1;
> data[1] = 2;
> PreparedStatement s = con.prepareStatement("insert into T1 (ID, DATA) 
> values (?, ?)");
> s.setString(1, "id");
> s.setBytes(2, data);
> s.execute();
> s.close();
> // read row
> System.out.println("3) reading row...");
> s = con.prepareStatement("select DATA from T1 where ID = ?");
> s.setString(1, "id");
> s.execute();
> ResultSet rs = s.getResultSet();
> rs.next();
> Blob b = rs.getBlob(1);
> // test output
> System.out.println("4) Length: " + b.length());
> InputStream in = b.getBinaryStream();
> System.out.println("   First Byte: " + in.read());
> in.close();
> in = b.getBinaryStream();
> System.out.println("5) Length: " + b.length());
> System.out.println("   First Byte: " + in.read());
> in.close();
> rs.close();
> s.close();
> con.close();
> }
> gives:
> 1) creating table...
> 2) adding row...
> 3) reading row...
> 4) Length: 1048576
>First Byte: 1
> 5) Length: 1048576
>First Byte: -1
> imo, 5) is wrong.

-- 
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-1368) EOFException when reading from blob's binary stream

[Kathey Marsden (JIRA)]

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

Kathey Marsden commented on DERBY-1368:
---

This issue was marked Fixed with no comments, but I verified the  program 
output on 10.2
$ java Derby1368
1) creating table...
2) adding row...
3) reading row...
4) Length: 1048576
 First Byte: 1
5) Length: 1048576
 First Byte: 1

So it does seem to be fixed but don't know exactly what fixed it.
Perhaps Tobias can close if the fix is ok.



> EOFException when reading from blob's binary stream
> ---
>
>  Key: DERBY-1368
>  URL: http://issues.apache.org/jira/browse/DERBY-1368
>  Project: Derby
> Type: Bug

> Versions: 10.1.2.1
> Reporter: Tobias Bocanegra
>  Fix For: 10.2.0.0
>  Attachments: Derby1368.java
>
> reading the 'length()' of a blob reads a previously aquired binary stream.
> test case:
> public static void main(String[] argv) throws Exception {
> String driver = "org.apache.derby.jdbc.EmbeddedDriver";
> String url = "jdbc:derby:derby/test;create=true";
> Class.forName(driver);
> Connection con = DriverManager.getConnection(url, "sa", "");
> con.setAutoCommit(true);
> // create table
> System.out.println("1) creating table...");
> Statement stmt = con.createStatement();
> stmt.execute("create table T1 (ID char(32) PRIMARY KEY, DATA blob(2G) 
> not null)");
> stmt.close();
> // add row
> System.out.println("2) adding row...");
> byte[] data = new byte[1024*1024*1];
> data[0] = 1;
> data[1] = 2;
> PreparedStatement s = con.prepareStatement("insert into T1 (ID, DATA) 
> values (?, ?)");
> s.setString(1, "id");
> s.setBytes(2, data);
> s.execute();
> s.close();
> // read row
> System.out.println("3) reading row...");
> s = con.prepareStatement("select DATA from T1 where ID = ?");
> s.setString(1, "id");
> s.execute();
> ResultSet rs = s.getResultSet();
> rs.next();
> Blob b = rs.getBlob(1);
> // test output
> System.out.println("4) Length: " + b.length());
> InputStream in = b.getBinaryStream();
> System.out.println("   First Byte: " + in.read());
> in.close();
> in = b.getBinaryStream();
> System.out.println("5) Length: " + b.length());
> System.out.println("   First Byte: " + in.read());
> in.close();
> rs.close();
> s.close();
> con.close();
> }
> gives:
> 1) creating table...
> 2) adding row...
> 3) reading row...
> 4) Length: 1048576
>First Byte: 1
> 5) Length: 1048576
>First Byte: -1
> imo, 5) is wrong.

-- 
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-1386) Wrong results with query using LIKE and ESCAPE clause that includes "%", "\", and "_"

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1386:
--

Component: SQL

> Wrong results with query using LIKE and ESCAPE clause that includes "%", "\", 
> and "_"
> -
>
>  Key: DERBY-1386
>  URL: http://issues.apache.org/jira/browse/DERBY-1386
>  Project: Derby
> Type: Bug

>   Components: SQL
> Versions: 10.2.0.0, 10.1.2.5
> Reporter: A B
> Assignee: Knut Anders Hatlen
> Priority: Critical
>  Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.5
>  Attachments: derby-1386-v1.diff, derby-1386-v1.stat
>
> After the fix for DERBY-1262 was checked in, I'm noticing that the following 
> query now returns different results.  Prior to the fix for DERBY-1262 the 
> query returned 2 rows; now it doesn't return any rows.
> create table escTable (c1 char(10));
> insert into escTable values ('%_\a');
> insert into escTable values ('%_b');
> insert into escTable values ('%c');
> insert into escTable values ('d');
> insert into escTable values ('%_\e');
> select c1 from escTable where c1 like '\%\_\\%' ESCAPE '\';
> Before DERBY-1262, the SELECT returned:
> C1
> --
> %_\a
> %_\e
> 2 rows selected
> Now it returns:
> C1
> --
> 0 rows selected
> Brief inspection of the query and data suggest to me that these new results 
> (i.e. no rows) are wrong, and that Derby should in fact return 2 rows/.
> Based on comments in DERBY-1262, I'm creating a new Jira issue for the 
> regression since it has been checked into the 10.1 maintenance branch.  I've 
> set the priority to "Critical" since this could potentially delay a 10.1.3 
> release--I.e. I don't think we'd want to release 10.1.3 knowing that we have 
> a wrong results regression.  But if anyone thinks that's not the correct 
> priority, feel free to speak up.
> Other option, of course, is to back out the change for DERBY-1262 in 10.1 and 
> then lower the priority accordingly.  
> Input/feedback/comments would be appreciated.

-- 
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-1396) ReEncodedInputStream may fail to read all of source Reader.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1396:
--

Component: Network Server

>  ReEncodedInputStream may fail to read all of source Reader.
> 
>
>  Key: DERBY-1396
>  URL: http://issues.apache.org/jira/browse/DERBY-1396
>  Project: Derby
> Type: Bug

>   Components: Network Server
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama
>  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] Updated: (DERBY-1461) Separate writeScalarStream to methods which handle either encrypted or plain streams.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1461:
--

Component: Network Client

> Separate writeScalarStream to methods which handle either encrypted or plain 
> streams.
> -
>
>  Key: DERBY-1461
>  URL: http://issues.apache.org/jira/browse/DERBY-1461
>  Project: Derby
> Type: Sub-task

>   Components: Network Client
> Reporter: Tomohito Nakayama
> Assignee: Tomohito Nakayama
>  Attachments: DERBY-1461.patch
>
> Reading writeScalarStream in Request class,
>  I found it would be possible to separate this method to two methods,
> one is for encrypted stream and another is for plain,
> because original writeScalarStream hardly share code for encrypted and for 
> plain.
> Separating this method will help me to realize DERBY-1301 separatingly for 
> encrypted and plain,
> as I planned in 
> http://issues.apache.org/jira/browse/DERBY-1301#action_12417684 .

-- 
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-1469) For forward-only/read-only result sets, QRYROWSET will be ignored (both on OPNQRY and CNTQRY)--need to investigate to see if this is an issue.

[Kathey Marsden (JIRA)]

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

Kathey Marsden updated DERBY-1469:
--

Component: Network Server

> For forward-only/read-only result sets, QRYROWSET will be ignored (both on 
> OPNQRY and CNTQRY)--need to investigate to see if this is an issue.
> --
>
>  Key: DERBY-1469
>  URL: http://issues.apache.org/jira/browse/DERBY-1469
>  Project: Derby
> Type: Task

>   Components: Network Server
> Versions: 10.2.0.0
> Reporter: A B
> Priority: Minor

>
> Potential problem as described in the following thread:
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659
> More investigation/testing is required with a client that sends an explicit 
> QRYROWSET with a forward-only result set.  This task is for tracking that 
> investigation if/when it occurs...

-- 
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-412) Connection toString should show type information and the meaning of the identifier that it prints

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-412?page=all ]
 
Kathey Marsden closed DERBY-412:



Thanks David for the great embedded fix.
DERBY-293 has been filed for the client correlation.

> Connection toString should show type information and  the meaning of the 
> identifier that it prints
> --
>
>  Key: DERBY-412
>  URL: http://issues.apache.org/jira/browse/DERBY-412
>  Project: Derby
> Type: Improvement

>   Components: JDBC
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
>  Fix For: 10.2.0.0

>
> After the change for DERBY-243 the  connection toString() output is  an 
> integer which correspond to SESSIONID.  The output should identify the type 
> and also the meaning of the identifier that it prints.  Perhaps a format that 
> appends the default toString output with the sessionid information as it 
> prints in the derby.log would be more informative.
> [EMAIL PROTECTED] (SESSONID = 2)
> Ultimately this could be expanded to included other diagnostic information e.g
> [EMAIL PROTECTED] (XID = 132), (SESSIONID = 5), (DATABASE = wombat), (DRDAID 
> = NF01.H324-940125304405039114{7})

-- 
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-435) jdbcapi/checkDataSource.java and jdbapi/checkDataSource30.java to tests should be changed or extended to test client DataSources

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-435?page=all ]
 
Kathey Marsden closed DERBY-435:



These tests are now enabled in the trunk and 10.1.  Thanks Deepa for your work 
on this.

> jdbcapi/checkDataSource.java and  jdbapi/checkDataSource30.java to tests 
> should be changed or extended to test client DataSources
> -
>
>  Key: DERBY-435
>  URL: http://issues.apache.org/jira/browse/DERBY-435
>  Project: Derby
> Type: Sub-task

>   Components: Network Client
> Versions: 10.1.1.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
>  Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.5
>  Attachments: d435-10.1-enable-checkDataSource30.diff, 
> d435-10.1-enable-checkDataSource30.status, d435-10.1-v1.diff, 
> d435-10.1-v1.status, d435-enable-tests-for-fixed-issues.diff, 
> d435-enable-tests-for-fixed-issues.status, d435_enableCheckDataSource.diff, 
> d435_enableCheckDataSource30.diff, derby435.diff
>
> jdbcapi/checkDataSource.java and  jdbapi/checkDataSource30.java currently 
> only test the embedded datasources but the same tests are needed for client 
> datasaources, particularly for xa to complete xa testing.

-- 
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-514) Integrate upgrade tests into test suite

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-514?page=all ]
 
Kathey Marsden closed DERBY-514:



Upgrade tests committed.

> Integrate upgrade tests into test suite
> ---
>
>  Key: DERBY-514
>  URL: http://issues.apache.org/jira/browse/DERBY-514
>  Project: Derby
> Type: Test

>   Components: Test
> Versions: 10.1.2.0, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Deepa Remesh
>  Fix For: 10.2.0.0
>  Attachments: derby-514-buildfiles-v1.diff, derby-514-buildfiles-v1.status, 
> derby-514-patch1-v1.diff, derby-514-patch1-v1.status, 
> derby-514-patch2-runtest-v1.diff, derby-514-patch2-runtest-v1.status, 
> derby-514-patch3-v1.diff, derby-514-patch3-v1.status, 
> derby-514-patch3-v2.diff, derby-514-patch3-v2.status, 
> derby-514-patch4-sed.diff, derby-514-patch4-sed.status, 
> derby-514-patch5-addtoderbyall.diff, derby-514-patch5-addtoderbyall.status, 
> derby-514-patch6-build_changes.diff, derby-514-patch6-build_changes.status, 
> derby-514-patch7-andrew.diff, derby-514-patch7-v2.diff, 
> derby-514-runwithclasses.diff, derby-514-runwithclasses.status
>
> Currently there are no upgrade tests in the derbyAll suite.
> The upgrade tests java/testing/org/apache/derbyTesting are run by script and 
> require that the version to be tested by specified on the command line so 
> that the classpath can be changed.
> # runphases old_major old_minor old_engine new_engine
> #
> # e.g.
> #
> # runphases 10 0 c:/derby/10.0.2.1/lib c:/derby/trunk/jars/sane
> Perhaps this script can be rewritten in Java using class loaders and  
> previous Derby verssions such as 10.0 and 10.1 be checked in so that this 
> testing can   be incorporated into the derbyAll test suite.

-- 
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-1004) Client should not require user to rollback the active transaction before call to PooledConnection.getConnection()

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1004?page=all ]
 
Kathey Marsden closed DERBY-1004:
-


Fix verified by reenabling test 

> Client should not require user to rollback the active transaction before call 
> to PooledConnection.getConnection()
> -
>
>  Key: DERBY-1004
>  URL: http://issues.apache.org/jira/browse/DERBY-1004
>  Project: Derby
> Type: Bug

>   Components: Network Client
> Versions: 10.2.0.0, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Kathey Marsden
> Assignee: David Van Couvering
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-1004.diff
>
> For a PooledConnection.getConnection() the connection gets closed.
>  Embedded automatically rolls back any activity on the connection.
>  Client requires the user to rollback and gives an SQLException  
>  java.sql.Connection.close() requested while a transaction is in progress
> The test jdbcapi/checkDataSource.java shows this bug.   A boolean 
> needRoolbackBeforePCGetConnection has been added to the test and  explicit 
> rollback has been added to the test to get it to run with client.
> To reproduce take out instances of the explicit rollback for client from the 
> test e.g.
> if (needRollbackBeforePCGetConnection)
>   c1.rollback();

-- 
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-1035) With client, Connection.getTransactionIsolation() return value is wrong after changing the isolation level with an SQL statement such as "set current isolation = RS"

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1035?page=all ]
 
Kathey Marsden closed DERBY-1035:
-


Fix verified by re-enabling test case 

> With client, Connection.getTransactionIsolation() return value is wrong after 
> changing the isolation level with an SQL statement such as "set current 
> isolation = RS"
> -
>
>  Key: DERBY-1035
>  URL: http://issues.apache.org/jira/browse/DERBY-1035
>  Project: Derby
> Type: Bug

>   Components: Network Client
> Versions: 10.2.0.0, 10.1.3.0
> Reporter: Kathey Marsden
> Assignee: Deepa Remesh
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0

>
> With client, if the isolation level is set with an SQL Statement such as "SET 
> CURRENT ISOLATION = RS"  the value of  Connection.getTransactionIsolation() 
> will not be correct.
> jdbcapi/checkDataSource has tests for sending SQL statements to change the 
> isolation level:
> e.g.
>   s.executeUpdate("set current isolation = RS");
>   printState("SQL to change isolation in local", cs1);
> I will disable these tests and reference this bug number.
> It is not really clear how to handle this without parsing the statement on 
> the client side.

-- 
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-1036) Embedded and client differ with regard to Statement.setCursor Name. client will disallow duplicate cursor names. Embedded will allow it.

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1036?page=all ]
 
Kathey Marsden closed DERBY-1036:
-


> Embedded and client differ with regard to Statement.setCursor Name. client 
> will disallow duplicate cursor names.  Embedded will allow it.
> -
>
>  Key: DERBY-1036
>  URL: http://issues.apache.org/jira/browse/DERBY-1036
>  Project: Derby
> Type: Sub-task

>   Components: Network Client, JDBC
> Versions: 10.1.3.0, 10.1.2.3, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Dag H. Wanvik
> Priority: Minor
>  Fix For: 10.2.0.0

>
> In looking at the checkDataSource test for DERBY-435, I hit an issue that the 
> test fails with an exception  for duplicate cursor name because it sets the 
> cursor name for  two statements to the same thing.
> Embedded seems to allow this, but it seems to me that client might be right 
> here.  How could embedded differentiate the two for positioned updates?
> There is risk to existing applications if  embedded is changed to throw the 
> error that should be considered if we decide we need to change the embedded 
> behaviour.
> Below are some details from checkDataSource where I hit this. I will change 
> the  names for now as it does not seem relevant to what is being tested.
> PreparedStatement psruState = createFloatStatementForStateChecking(cs1, 
> "select i from ru where i = ?");
> CallableStatement csruState = createFloatCallForStateChecking(cs1, 
> "CALL SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY(?,?)");
> Both of these methods set the cursor name to the same thing:
> s.setCursorName("StokeNewington");
> For embedded it succeeds for client it throws the exception.
> java.sql.SQLException: Duplicate cursor names are not allowed.
>   at org.apache.derby.client.am.SqlException.getSQLException(Unknown 
> Source)
>   at org.apache.derby.client.am.Statement.setCursorName(Unknown Source)
>   at 
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.createFloatStatementForStateChecking(Unknown
>  Source)
>   at 
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.runTest(Unknown
>  Source)
>   at 
> org.apache.derbyTesting.functionTests.tests.jdbcapi.checkDataSource.main(Unknown
>  Source)

-- 
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-1183) Client java.sql.ResultSet.getCursorName() does not return the correct cursor name for Statements after the first execution

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1183?page=all ]
 
Kathey Marsden closed DERBY-1183:
-


Verified fix for 10.2.  Thanks Dag!

> Client java.sql.ResultSet.getCursorName() does not return the correct cursor 
> name for Statements after the first execution
> --
>
>  Key: DERBY-1183
>  URL: http://issues.apache.org/jira/browse/DERBY-1183
>  Project: Derby
> Type: Bug

>   Components: JDBC
> Versions: 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Dag H. Wanvik
>  Fix For: 10.2.0.0
>  Attachments: derby-1183-2.diff, derby-1183-2.stat, derby-1183.diff, 
> derby-1183.stat
>
> For client, if the cursor name is set with java.sql.Statement.setCursorName() 
> the name set by the user only applies to the first execution.  Subsequent 
> executions use the default cursor name.  To reproduce run the progam below as 
> follows:
> D>java -Dframework=DerbyNetClient GetCursorName
> 10.2.0.0 alpha
> Apache Derby
> Apache Derby Network Client JDBC Driver
> rs.getCursorName():MyCursor
> rs.getCursorName():SQL_CURLH000C2
> With embedded it is ok:
> D>java  GetCursorName
> 10.2.0.0 alpha
> Apache Derby
> Apache Derby Embedded JDBC Driver
> rs.getCursorName():MyCursor
> rs.getCursorName():MyCursor
> import java.sql.Connection;
> import java.sql.DatabaseMetaData;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import org.apache.derbyTesting.functionTests.util.TestUtil;
> class GetCursorName
> {
> 
> public static void main (String args [])throws Exception 
> {
>   testGetCursorName();
> }
> 
> public static void testGetCursorName() throws SQLException
> {
>   
>   Connection conn = 
> TestUtil.getConnection("wombat","create=true");
>   Statement stmt = null;
>   ResultSet rs = null;
>   DatabaseMetaData md = conn.getMetaData() ;
>   System.out.println(md.getDatabaseProductVersion());
> System.out.println(md.getDatabaseProductName());
> System.out.println(md.getDriverName());
>   
>   stmt = conn.createStatement();
>   // Setting the cursor name works for one execution ok.
>   stmt.setCursorName("MyCursor");
>   rs = stmt.executeQuery("select count(*) from sys.systables");
>   System.out.println("rs.getCursorName():" + rs.getCursorName());
>   rs.close();
>   //Executing another query seems to clears the cursor name.
>   // getCursorName() will print the default cursor name SQLXXX.
>   rs = stmt.executeQuery("select count(*) from sys.systables");
>   System.out.println("rs.getCursorName():" + rs.getCursorName());
>   rs.close();
>   stmt.close();
> conn.close();
>   }
>   
> }
> I noticed this bug when coverting the checkDataSource test for client.
> I will change that test to set the cursor name for each execution for 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

off list for a week

[Rick Hillegas]

I'm off on vacation for the week of the 4th. Should be back Monday the 10th.

Cheers,
-Rick

[jira] Closed: (DERBY-1327) Identity column can be created with wrong and very large start with value with "J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2)" with JIT on

[Kathey Marsden (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1327?page=all ]
 
Kathey Marsden closed DERBY-1327:
-


Verified fix

> Identity column can be  created with wrong and very large start with value 
> with  "J2RE 1.5.0 IBM Windows 32 build pwi32dev-20060412 (SR2)" with JIT on
> --
>
>  Key: DERBY-1327
>  URL: http://issues.apache.org/jira/browse/DERBY-1327
>  Project: Derby
> Type: Bug

>   Components: SQL
> Versions: 10.1.2.4, 10.2.0.0
> Reporter: Kathey Marsden
> Assignee: Mamta A. Satoor
>  Fix For: 10.2.0.0, 10.1.3.0, 10.1.2.5
>  Attachments: Derby1327WrongStartKeyPatch1CodelineTrunk.txt, 
> Derby1327WrongStartKeyPatch1SvnDiff101.txt, 
> Derby1327WrongStartKeyPatch1SvnStat101.txt
>
> Using the following JRE with JIT on  an identity column may be created with a 
> wrong and very large START WITH value.  When the problem occurs it affects 
> not only the table being created, but also other tables that were created in 
> previous transactions.
> For example attempting to create 1000 tables with identity columns the 126th 
> table creation changes the start with value in sys.syscolumns to 
> 41628850257395713 for ALL 125 tables.  Attempts to insert into any of the 
> tables cause
> "SQL Exception: A truncation error was encountered trying to 
> shrink ... to length 12." 
> This program will create up to 1000 tables until the problem 
> occurs
> Note:
> - The problem does not occur with -Xnojit (JIT OFF)
> - The problem, when it occurs, changes not only the table being 
> created but all previous tables created.  See output below. 
> Every thing was fine up until mytable126 and then all the 
> tables got changed to start with 41628850257395713 
> - Problem occurs with autocommit on/off.
> - The problem occurs after the create table but before the 
> commit.
> - If the non-identity columns are removed the problem does not 
> reproduce.
> import java.sql.DatabaseMetaData;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import java.sql.DriverManager;
> public class BadStartWith
> {
> 
> public static void main (String args [])throws Exception 
> {
>   testBadStartWith();
> }
> 
> /**
>  * After some number of table creations with JIT turned on, the START 
> WITH value 
>  * for the table being created and all the ones already created gets 
> mysteriously
>  * changed with pwi32dev-20060412 (SR2)
>  * 
>  * @throws Exception
>  */
> public static void testBadStartWith() throws Exception
> {
>   
>   
> Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
>   Connection conn = 
> DriverManager.getConnection("jdbc:derby:wombat;create=true");
>conn.setAutoCommit(false);
>   Statement stmt = null;
>   
>   DatabaseMetaData md = conn.getMetaData() ;
>   System.out.println(md.getDatabaseProductVersion());
>System.out.println(md.getDatabaseProductName());
> System.out.println(md.getDriverName());
>   dropAllAppTables(conn);
>   System.out.println("Create tables until we get a wrong Start 
> with value");
>   stmt = conn.createStatement();
>   // numBadStartWith will be changed if any columns get a bad 
> start with value.
>   int numBadStartWith = 0; 
>   try {
>   // create 1000 tables.  Break out if we get a table 
> that has a bad
>   // start with value.
>   for (int i = 0; (i < 1000) && (numBadStartWith == 0); 
> i++)
>   {
>   String tableName = "APP.MYTABLE" + i;
>   String createTableSQL = "CREATE TABLE " + tableName 
> + "  (ROLEID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 2, 
> INCREMENT BY 1), INSTANCEID INTEGER, STATUS INTEGER, LOGICAL_STATE INTEGER, 
> LSTATE_TSTAMP  TIMESTAMP, UPDT_TSTAMP TIMESTAMP, TSTAMP TIMESTAMP, 
> CLALEVEL1_CLALEVEL2_CLALEVEL2ID VARCHAR(255),  
> CLALEVEL1_CLALEVEL2_CLALEVEL3_CLALEVEL3ID VARCHAR(255))";
>   
>   stmt.executeUpdate(createTableSQL);
>   System.out.println(createTableSQL);
> System.out.println("Check before commit");
> numBadStartWith = checkBadStartWithCols(conn,2);
> conn.commit();
> System.out.println("Check after commit");
>   numBadStartWith = checkBadStartWithCols(conn,2);
>   if (numBadStartWith > 0)
>   break;
>   }
>  

Re: making a jira filter public

[Rick Hillegas]

Thanks, Kathey. I have substituted your pessimistic query for my 
optimistic one and added the critical/blocker query.


Kathey Marsden wrote:


Rick Hillegas wrote:

Thanks, Kathey. I have put the permlink link into the wiki page as a 
fallback. Do you know whether this cans the query or the results?




Your link for bugs affecting 10.2 works but I think it  is entirely 
too optimistic.  I find it funny that when you look at 10.2 you see 29 
bugs and when I look at 10.2 I see 192 bugs.  I think this reflects a 
fundamental difference in our perspective on things #:)


No, it just means you're better at this than I am!




We actually have a global filter for Derby Open Code Bugs, (those that 
affect the trunk /10.2 ): and this link should work for that:
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&type=1&pid=10594&component=11407&component=11409&component=11690&component=11410&component=11709&component=11411&component=11415&component=11408&component=11412&component=11414&status=1&status=3&status=4&sorter/field=issuekey&sorter/order=DESC 



I think it would also be good to  include separate links for the  
Critical/Blocker issues that might hold up  the release.
http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&priority=1&priority=2&status=1&status=3&status=4&sorter/field=issuekey&sorter/order=ASC&sorter/field=updated&sorter/order=DESC&sorter/field=priority&sorter/order=DESCrg/jira/secure/ConfigureReport.jspa?filterid=12310892 





I also would love to see a link for issues fixed in 10.2 but I can't 
figure out how to get a report for that.


Kathey

[jira] Commented: (DERBY-1468) Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, which doesn't follow DRDA protocol.

[A B (JIRA)]

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

A B commented on DERBY-1468:


> Army could you please see if solves the issue with the ODBC driver? 

I'm not able to run the full set of ODBC tests because the harness on my 
machine is currently in a bad state (sigh), but I was able to run the repro 
that prompted the filing of this issue, and I have confirmed that with your 
patch applied the ODBC repro runs as it should.

> Since there is no way I know of to reproduce the bug with the network 
> client driver, I have added a test case to the protocol test which sends 
> an OPNQRY for a scrollable cursor with QRYROWSET=0.

Good thinking--sounds like a great plan.  I ran the test with and without your 
patch, and it behaves as you describe.

> EXCSQLSTT should probably have a similar fix for completeness. (A 
> possible way to try to provoke this with the ODBC driver could be to 
> execute a stored procedure that returns a scrollable result set.) 

When I can find the time I will experiment with this.  If this proves to be a 
problem then I'll create a separate Jira issue to address it--one that is _not_ 
considered a regression of DERBY-822 since, as you said, the relevant code 
wasn't touched with 822.

Thanks for addressing this so quickly!

> Server returns data when it receives a QRYROWSET value of zero on an OPNQRY, 
> which doesn't follow DRDA protocol.
> 
>
>  Key: DERBY-1468
>  URL: http://issues.apache.org/jira/browse/DERBY-1468
>  Project: Derby
> Type: Bug

>   Components: Network Server
> Versions: 10.2.0.0
> Reporter: A B
> Assignee: Knut Anders Hatlen
>  Attachments: derby-1468-v1.diff, derby-1468-v1.stat
>
> When a client sends a QRYROWSET value of zero to the server, DRDA indicates 
> that the server should not return any rows.  But the current Derby Server 
> treats a qryrowset value of 0 (zero) the same as it does a value of 1 (one) 
> and thus performs pre-fetching (as of DERBY-822), which it shouldn't do.
> As a result, clients that send a QRYROWSET of 0 and do not expect data could 
> see unexpected results--for example, the DB2 ODBC driver will return the 
> first row of data twice for scrollable cursors because of this issue.
> Relevant discussion:
> http://article.gmane.org/gmane.comp.apache.db.derby.devel/22659
> Some quotes from DRDA manuals:
> 1) DRDA Manual v3 for OPNQRY:
> The qryrowset parameter specifies whether a rowset of rows is to be returned 
> with the command.  This is only honored for non-dynamic scrollable cursors 
> (QRYATTSNS not equal to QRYSNSDYN) and for non-scrollable cursors conforming 
> to the limited block query protocol.  The target server fetches no more than 
> the requested number of rows. It may fetch fewer rows if it is restricted by 
> extra query block limits, or if a fetch operation results in a negative 
> SQLSTATE or an SQLSTATE of 02000.
> 2) Page 698 of V.3 says:
> A QRYROWSET value of zero on the OPNQRY and EXCSQLSTT commands instructs the 
> server to return no rows with the OPNQRYRM for the cursor or result set. A 
> QRYROWSET value of zero on the CNTQRY command is invalid for non-rowset 
> cursors and results in the application server generating a SYNTAXRM with a 
> SYNERRCD value of '15'x (reserved value not allowed).

-- 
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

Re: making a jira filter public

[Rick Hillegas]

I respectfully ask for more karma!

Michelle Caisse wrote:

Whether or not one can see the Share link is a question of karma.  
Someone of greater karma can grant this privilege to someone of lesser 
karma.


-- Michelle

Kathey Marsden wrote:


Rick Hillegas wrote:

Thanks, Andrew. I did stumble on the filter management page. My 
question is, once I'm on that page, how do I change my filter from 
Private to Global? Clicking on the Private icon isn't working for me 
and I don't know what other trick to try.




My experience has been that mere mortals cannot do this, but maybe 
that has changed.  Another issue  with global filters is that they 
can be seen all over Apache.  Recently I have been using the 
[Permlink] for jira reports.  You run your  query and press 
[Permlink]  near the top right of the page.  Then you can put that in 
your Wiki page.   I did this for a bunch of the reports on 
http://wiki.apache.org/db-derby/DerbyJiraReports 



The only place I found that I really have to have a global filter now 
is if I want a Single Level Group By Report. Then it has to be keyed 
off a global  filter.


Kathey

Re: making a jira filter public

[Kathey Marsden]

Kathey Marsden wrote:


Rick Hillegas wrote:

Thanks, Kathey. I have put the permlink link into the wiki page as a 
fallback. Do you know whether this cans the query or the results?



Oops didn't answer your questions. It cans the query not the results.

Re: Wiki page for upcoming 10.2 release

[Rick Hillegas]

Thanks, Michelle!

Michelle Caisse wrote:


The second link works for me.

-- Michelle

Rick Hillegas wrote:


Hi Anders,

The JIRA pros are pondering this question. In the meantime, I have 
added another link under the broken one. Could you test-drive the new 
link and see if it works for you?


Thanks,
-Rick

Anders Morken wrote:


Rick Hillegas:
 


In particular, JIRA-pros may want to review whether the pointer to
open 10.2 bugs resolves to the correct query.
  




I'm a JIRA newbie, but when I clicked the "10.2 Open Code Bugs" link
(pointing to
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311067 


) I got the error message "You do not have the permission to view the
selected private filter." Maybe the JIRA pros can make it public or
something? =)

Thanks,
 

Re: making a jira filter public

[Kathey Marsden]

Rick Hillegas wrote:

Thanks, Kathey. I have put the permlink link into the wiki page as a 
fallback. Do you know whether this cans the query or the results?




Your link for bugs affecting 10.2 works but I think it  is entirely too 
optimistic.  I find it funny that when you look at 10.2 you see 29 bugs 
and when I look at 10.2 I see 192 bugs.  I think this reflects a 
fundamental difference in our perspective on things #:)



We actually have a global filter for Derby Open Code Bugs, (those that 
affect the trunk /10.2 ): and this link should work for that:

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&type=1&pid=10594&component=11407&component=11409&component=11690&component=11410&component=11709&component=11411&component=11415&component=11408&component=11412&component=11414&status=1&status=3&status=4&sorter/field=issuekey&sorter/order=DESC

I think it would also be good to  include separate links for the  
Critical/Blocker issues that might hold up  the release.

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&priority=1&priority=2&status=1&status=3&status=4&sorter/field=issuekey&sorter/order=ASC&sorter/field=updated&sorter/order=DESC&sorter/field=priority&sorter/order=DESCrg/jira/secure/ConfigureReport.jspa?filterid=12310892



I also would love to see a link for issues fixed in 10.2 but I can't 
figure out how to get a report for that.


Kathey

Re: [jira] Commented: (DERBY-1435) Conglomerate does not exist occurs in a specific case after dropping a table referenced by a trigger

[Øystein Grøvlen]

Deepa Remesh wrote:


I took a quick look at DERBY-637 to see if there is anything similar
to the scenario in DERBY-1435. I am new to these areas but I think it
will be good if we have a repro. Someone more familiar may be able to
deduct something. If you still have the repro, it would be helpful if
you can post it.


Unfortunately, as DERBY-637 says, I do not have a repro.  I had been 
inserting records for hours when this occurred so it is not 
straight-forward to make a repro.


--
Øystein

Re: Wiki page for upcoming 10.2 release

[Michelle Caisse]

The second link works for me.

-- Michelle

Rick Hillegas wrote:


Hi Anders,

The JIRA pros are pondering this question. In the meantime, I have 
added another link under the broken one. Could you test-drive the new 
link and see if it works for you?


Thanks,
-Rick

Anders Morken wrote:


Rick Hillegas:
 


In particular, JIRA-pros may want to review whether the pointer to
open 10.2 bugs resolves to the correct query.
  



I'm a JIRA newbie, but when I clicked the "10.2 Open Code Bugs" link
(pointing to
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311067 


) I got the error message "You do not have the permission to view the
selected private filter." Maybe the JIRA pros can make it public or
something? =)

Thanks,
 

Re: Wiki page for upcoming 10.2 release

[Rick Hillegas]

Hi Anders,

The JIRA pros are pondering this question. In the meantime, I have added 
another link under the broken one. Could you test-drive the new link and 
see if it works for you?


Thanks,
-Rick

Anders Morken wrote:


Rick Hillegas:
 


In particular, JIRA-pros may want to review whether the pointer to
open 10.2 bugs resolves to the correct query.
   



I'm a JIRA newbie, but when I clicked the "10.2 Open Code Bugs" link
(pointing to
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311067
) I got the error message "You do not have the permission to view the
selected private filter." Maybe the JIRA pros can make it public or
something? =)

Thanks,
 

Re: making a jira filter public

[Michelle Caisse]

Whether or not one can see the Share link is a question of karma.  
Someone of greater karma can grant this privilege to someone of lesser 
karma.


-- Michelle

Kathey Marsden wrote:


Rick Hillegas wrote:

Thanks, Andrew. I did stumble on the filter management page. My 
question is, once I'm on that page, how do I change my filter from 
Private to Global? Clicking on the Private icon isn't working for me 
and I don't know what other trick to try.



My experience has been that mere mortals cannot do this, but maybe 
that has changed.  Another issue  with global filters is that they can 
be seen all over Apache.  Recently I have been using the [Permlink] 
for jira reports.  You run your  query and press [Permlink]  near the 
top right of the page.  Then you can put that in your Wiki page.   I 
did this for a bunch of the reports on 
http://wiki.apache.org/db-derby/DerbyJiraReports 



The only place I found that I really have to have a global filter now 
is if I want a Single Level Group By Report. Then it has to be keyed 
off a global  filter.


Kathey

Re: making a jira filter public

[Rick Hillegas]

Thanks, Kathey. I have put the permlink link into the wiki page as a 
fallback. Do you know whether this cans the query or the results?


Thanks,
-Rick

Kathey Marsden wrote:


Rick Hillegas wrote:

Thanks, Andrew. I did stumble on the filter management page. My 
question is, once I'm on that page, how do I change my filter from 
Private to Global? Clicking on the Private icon isn't working for me 
and I don't know what other trick to try.



My experience has been that mere mortals cannot do this, but maybe 
that has changed.  Another issue  with global filters is that they can 
be seen all over Apache.  Recently I have been using the [Permlink] 
for jira reports.  You run your  query and press [Permlink]  near the 
top right of the page.  Then you can put that in your Wiki page.   I 
did this for a bunch of the reports on 
http://wiki.apache.org/db-derby/DerbyJiraReports 



The only place I found that I really have to have a global filter now 
is if I want a Single Level Group By Report. Then it has to be keyed 
off a global  filter.


Kathey

Re: making a jira filter public

[Kathey Marsden]

Rick Hillegas wrote:

Thanks, Andrew. I did stumble on the filter management page. My 
question is, once I'm on that page, how do I change my filter from 
Private to Global? Clicking on the Private icon isn't working for me 
and I don't know what other trick to try.


My experience has been that mere mortals cannot do this, but maybe that 
has changed.  Another issue  with global filters is that they can be 
seen all over Apache.  Recently I have been using the [Permlink] for 
jira reports.  You run your  query and press [Permlink]  near the top 
right of the page.  Then you can put that in your Wiki page.   I did 
this for a bunch of the reports on 
http://wiki.apache.org/db-derby/DerbyJiraReports 



The only place I found that I really have to have a global filter now is 
if I want a Single Level Group By Report. Then it has to be keyed off a 
global  filter.


Kathey

Re: making a jira filter public

[Rick Hillegas]

Dang. I don't have a Share link in the Operations column. I have View, 
Edit, Delete, and Add Column Order. Hm.


-Rick

Andrew McIntyre wrote:


On 6/30/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:


Thanks, Andrew. I did stumble on the filter management page. My question
is, once I'm on that page, how do I change my filter from Private to
Global? Clicking on the Private icon isn't working for me and I don't
know what other trick to try.



There should be a 'Share' link in the Operations column in the table
where the filter you created is listed. Clicking that link allows you
to change the sharing of your filter. Or do you not have a 'Share'
link there?

andrew

Re: making a jira filter public

[Andrew McIntyre]

On 6/30/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:

Thanks, Andrew. I did stumble on the filter management page. My question
is, once I'm on that page, how do I change my filter from Private to
Global? Clicking on the Private icon isn't working for me and I don't
know what other trick to try.


There should be a 'Share' link in the Operations column in the table
where the filter you created is listed. Clicking that link allows you
to change the sharing of your filter. Or do you not have a 'Share'
link there?

andrew

Re: making a jira filter public

[Rick Hillegas]

Thanks, Andrew. I did stumble on the filter management page. My question 
is, once I'm on that page, how do I change my filter from Private to 
Global? Clicking on the Private icon isn't working for me and I don't 
know what other trick to try.


Regards,
-Rick

Andrew McIntyre wrote:


On 6/30/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:


The 10.2 release page contains a link to a JIRA filter I created. How do
I make this filter public? Right now, other people are getting a
permissions problem when they click on the link.



When you click Find Issues in the main JIRA menubar, there is a
Filters: Manage link in the top left under the menubar. On the Manage
filters page, you can choose to share any of your saved filters either
globally or just with a specific group (e.g. just with
derby-developers)

andrew

[jira] Updated: (DERBY-1459) Early load of Derby driver with JDBC 4.0 autoloading can lead to derby properties not being processed or derby boot time actions consuming resources when a connection is m

[Rick Hillegas (JIRA)]

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

Rick Hillegas updated DERBY-1459:
-

Attachment: bug1459_v04.diff

Attaching bug1159_v04.diff. This rev of the patch makes the following changes:

1) Adds a unit test (AutoloadBooting) to verify Kathey's scenarios.

2) Makes some changes to AutoloadedDriver.acceptsURL() and 
AutoloadedDriver.connect() so that the DriverManager will not accidentally boot 
Derby while trying to connect through another driver. The problem is that when 
an application requests a Connection, the DriverManager will walk through all 
loaded drivers, passing the request on to each in turn. Depending on where your 
autoloaded driver sits in the list, this may trigger an attempt to connect 
through your driver.


> Early load of Derby driver with JDBC 4.0 autoloading can lead to derby 
> properties not being processed or derby boot time actions consuming resources 
> when a connection is made with another driver
> --
>
>  Key: DERBY-1459
>  URL: http://issues.apache.org/jira/browse/DERBY-1459
>  Project: Derby
> Type: Bug

>   Components: JDBC, Services
> Versions: 10.2.0.0
>  Environment: JDK 1.6 
> Reporter: Kathey Marsden
> Priority: Critical
>  Fix For: 10.2.0.0
>  Attachments: autoloading_scenarios.html, bug1459_v01.diff, bug1459_v02.diff, 
> bug1459_v03.diff, bug1459_v04.diff
>
> The addition of support for autoloading of Derby drivers, DERBY-930, caused 
> two potentially serious regresions for applications.
> 1) Early load of driver can mean that  derby system properties, such as 
> derby.system.home may not be processed by the driver because they are set 
> after the driver is loaded.
> 2) Early load of the driver can mean boot time operations, such as starting 
> network server with derby.drda.startNetworkServer can happen even when Derby 
> is never used if a connection is made to another database such as Oracle.
> The attached file autoloading_scenarios.html  shows scenarios that show these 
> regressions plus another case that will regress if boot time operations are 
> moved to the first Derby embedded connection.   I don't know what solution is 
> available that would handle all three cases.

-- 
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

Re: Revised 10.2 plan for uncoupling the Mustang and Derby release trains

[David Van Couvering]

This looks good to me, +1.  Thanks to everyone for their hard work on 
resolving this.


David

Rick Hillegas wrote:
Thanks to everyone for their suggestions and patience. After discussing 
the JCP issues with many people, including Geir Magnusson and Lance 
Andersen, I would like to propose the following approach for uncoupling 
the Mustang and Derby release trains.


1) Lance will publish his proposed final draft (PFD) of the JDBC4 spec 
under the "early access" license.


2) In mid-September the Derby community will vet and publish a GA 10.2 
release which implements PFD apis.


3) The Apache web page describing 10.2 will start out saying that Derby 
drivers implement PFD apis.


4) If no relevant changes are made to the PFD by the time Mustang goes 
GA, then at the end of October we will update the Apache web page so 
that it says Derby drivers implement final JDBC4 apis.


5) If, however, the final draft changes in some way which affects Derby, 
then we will implement those changes in a follow-on bugfix release at a 
time convenient to the community.


Here again is the refined 10.2 release schedule which has attracted 
consensus:


August 10 : Last feature work committed. Branch created.
August 11 : First release candidate generated.
August 24 : Second release candidate generated.
September 7: Third and hopefully last release candidate generated.
September 15: Targetted end of voting on release candidates.

I hope we are converging on an acceptable plan. Thanks again for your 
patience.


Regards,
-Rick

Re: Wondering to myself about doing layer B streaming from client to server

[Knut Anders Hatlen]

TomohitoNakayama <[EMAIL PROTECTED]> writes:

> Hello.
>
> Continuing DERBY-1301(http://issues.apache.org/jira/browse/DERBY-1301),
> I came to have question whether layer B streaming should be done when
> lob was sent from client to server.
>
> Reading javadoc for java.sql package, I found that methods passing
> stream object to driver always takes parameter for length information.
> Then, driver can simply pass that length information to server.
>
> I think there are no need for driver to execute layer B streaming,
> because caller of driver always pass length of streamed object to driver.

Hi Tomohito,

I don't know how it relates to layer B streaming, but JDBC 4.0 will
add methods with a stream parameter and no length parameter. The
javadocs at http://download.java.net/jdk6/docs/api/ have not been
updated with these methods yet, but I believe they will be in a week
or two. You can find more details in DERBY-1417.

> However, here comes another question.
>
> DERBY-550(http://issues.apache.org/jira/browse/DERBY-550), which is
> linked from DERBY-1301 told that
> current implementation of org.apache.derby.jdbc.ClientDriver expands
> object to be streamed into memory and
> this behavior tends to cause OutOfMemoryError.
>
> Are there any reason why current driver expands object into memory,
> though length of the object is served as parameter of method ?

Probably because it was the easiest way to implement it. I don't see
any good technical reasons for doing it like that.

> Well
> I think it is needed to survey some more around current implementation
> of driver and
> clear the mystery in org.apache.derby.jdbc.ClientDriver, around
> expanding object into memory before sending 

It would be great to improve the stream handling on the client. I have
just briefly looked at the code, but it seems clear that this is a
part of the code that has room for improvement. Thanks for looking
into it!

-- 
Knut Anders

Re: making a jira filter public

[Andrew McIntyre]

On 6/30/06, Rick Hillegas <[EMAIL PROTECTED]> wrote:

The 10.2 release page contains a link to a JIRA filter I created. How do
I make this filter public? Right now, other people are getting a
permissions problem when they click on the link.


When you click Find Issues in the main JIRA menubar, there is a
Filters: Manage link in the top left under the menubar. On the Manage
filters page, you can choose to share any of your saved filters either
globally or just with a specific group (e.g. just with
derby-developers)

andrew

Re: Revised 10.2 plan for uncoupling the Mustang and Derby release trains

[Jean T. Anderson]

Rick's plan looks good to me as long as the license is resolved -- and
it looks like it will be (with time to spare) given Lance's
clarification of the mid July target in
http://www.nabble.com/Re%3A-Revised-10.2-plan-for-uncoupling-the-Mustang-and-Derby-release-trains-p5125470.html

 -jean

Rick Hillegas wrote:
> Thanks to everyone for their suggestions and patience. After discussing
> the JCP issues with many people, including Geir Magnusson and Lance
> Andersen, I would like to propose the following approach for uncoupling
> the Mustang and Derby release trains.
> 
> 1) Lance will publish his proposed final draft (PFD) of the JDBC4 spec
> under the "early access" license.
> 
> 2) In mid-September the Derby community will vet and publish a GA 10.2
> release which implements PFD apis.
> 
> 3) The Apache web page describing 10.2 will start out saying that Derby
> drivers implement PFD apis.
> 
> 4) If no relevant changes are made to the PFD by the time Mustang goes
> GA, then at the end of October we will update the Apache web page so
> that it says Derby drivers implement final JDBC4 apis.
> 
> 5) If, however, the final draft changes in some way which affects Derby,
> then we will implement those changes in a follow-on bugfix release at a
> time convenient to the community.
> 
> Here again is the refined 10.2 release schedule which has attracted
> consensus:
> 
> August 10 : Last feature work committed. Branch created.
> August 11 : First release candidate generated.
> August 24 : Second release candidate generated.
> September 7: Third and hopefully last release candidate generated.
> September 15: Targetted end of voting on release candidates.
> 
> I hope we are converging on an acceptable plan. Thanks again for your
> patience.

making a jira filter public

[Rick Hillegas]

The 10.2 release page contains a link to a JIRA filter I created. How do 
I make this filter public? Right now, other people are getting a 
permissions problem when they click on the link.


Thanks,
-Rick

Re: Wiki page for upcoming 10.2 release

[Anders Morken]

Rick Hillegas:
> In particular, JIRA-pros may want to review whether the pointer to
> open 10.2 bugs resolves to the correct query.

I'm a JIRA newbie, but when I clicked the "10.2 Open Code Bugs" link
(pointing to
http://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=hide&requestId=12311067
) I got the error message "You do not have the permission to view the
selected private filter." Maybe the JIRA pros can make it public or
something? =)

Thanks,
-- 
Anders Morken

My opinions may have changed, but not the fact that I am right!

Re: [jira] Updated: (DERBY-937) Instability in wisconsin test

[Øystein Grøvlen]

Mike Matrigali wrote:


I was working under the assumption that the wisc diffs were the kinds of
issues we had seen in the past.  Where the optimizer had 2 different 
plans which were very close in costing, and due to slight differences in

estimates one plan was chosen over another.


The exception in this case, if I have understood things correctly, is 
that one is not able to explain why there is a slight difference in 
estimates and why the fix solves the problem.  That is why I feel a JIRA 
should be filed to indicate that something else may be wrong here so 
that one remember to investigate this further.


If anyone has done the careful analysis of the different plans and found 
that there is a serious problem with the plans the optimizer was picking 
please go ahead and report a new bug with that info and how to reproduce.


I have not done any careful analysis of the query plans, but as far as I 
have understood, before the fix, the test was as follows:


1. Create table
2. Insert data
3. Create indexes
4. Execute query

The problem was that not the same query plan was chosen every time. 
However, if you insert a compress between 3. and 4., the same query plan 
is chosen every time.  In other words, a compress may affect which plan 
is chosen.  You are saying that since the indexes is just created, a 
subsequent compress should not change estimates.  So what makes the plan 
change in that case?  I think it would be good to investigate that.


My main concern was that spurious "expected" diffs means that almost 
everyone is just going to ignore any real future bug the test might

show up.


I totally agree that we needed to fix the test since it was failing so 
often and doing it this way is better than suspending the entire test. 
However, we should be aware that we are fixing the test without actually 
knowing whether the problem is really in the test or in the product.


--
Øystein

[jira] Updated: (DERBY-963) Allow user friendly string values for security mechanism in client connection url.

[Anders Morken (JIRA)]

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

Anders Morken updated DERBY-963:


Attachment: DERBY-963-code-v1.patch

This (DERBY-963-code-v1.patch) is a first take at enabling more user friendly 
security mechanism names in the connection properties. Needs regression tests 
and doc updates to be of any value to users, though - but if someone takes a 
look at it and decides whether this is the right way to do it and the right 
place to do it that would be useful anyway. =)

> Allow user friendly string values for security mechanism in client connection 
> url.
> --
>
>  Key: DERBY-963
>  URL: http://issues.apache.org/jira/browse/DERBY-963
>  Project: Derby
> Type: Improvement

>   Components: Newcomer, Network Client
> Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.0, 
> 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Sunitha Kambhampati
> Assignee: Anders Morken
> Priority: Minor
>  Attachments: DERBY-963-code-v1.patch
>
> Overview:
> DRDA spec specifies the following secmec (securitymechanism) values.
> USRIDONL = 4
> USRIDPWD = 3
> EUSRIDPWD = 9
> Currently in the client url, one would have to pass in the integer value for 
> securityMechanism. e.g.
> ij>connect 'testdb;securityMechanism=9;user=sa;password=p1';
> when using the datasource, the setSecurityMechanism(int) on the 
> ClientDataSource can be used.
> Constants are
> ClientDataSource.CLEAR_TEXT_PASSWORD_SECURITY (0x03)
> ClientDataSource.USER_ONLY_SECURITY (0x04)
> ClientDataSource.ENCRYPTED_USER_AND_PASSWORD_SECURITY (0x09)
> Add support in client to recognize the user friendly names for the 
> securityMechanism attribute. The values that should be accepted are 
> CLEAR_TEXT_PASSWORD_SECURITY, USER_ONLY_SECURITY, 
> ENCRYPTED_USER_AND_PASSWORD_SECURITY.
> 
> To ensure that the old applications that were written to pass in an integer 
> value for securityMechanism do not break with the new client , the client 
> should probably support both the integer values as well as the string values. 
>  

-- 
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-963) Allow user friendly string values for security mechanism in client connection url.

[Anders Morken (JIRA)]

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

Anders Morken commented on DERBY-963:
-

I've actually had a patch for this in my trunk checkout for a while, but it's 
been forgotten and rotting away as I haven't yet, uhm, "found the inspiration" 
to write regression tests and doc patches for it. I'll see about it soon. =)

> Allow user friendly string values for security mechanism in client connection 
> url.
> --
>
>  Key: DERBY-963
>  URL: http://issues.apache.org/jira/browse/DERBY-963
>  Project: Derby
> Type: Improvement

>   Components: Newcomer, Network Client
> Versions: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.0, 
> 10.1.1.1, 10.1.1.2, 10.1.2.1, 10.1.3.0, 10.1.2.2, 10.1.2.3
> Reporter: Sunitha Kambhampati
> Assignee: Anders Morken
> Priority: Minor

>
> Overview:
> DRDA spec specifies the following secmec (securitymechanism) values.
> USRIDONL = 4
> USRIDPWD = 3
> EUSRIDPWD = 9
> Currently in the client url, one would have to pass in the integer value for 
> securityMechanism. e.g.
> ij>connect 'testdb;securityMechanism=9;user=sa;password=p1';
> when using the datasource, the setSecurityMechanism(int) on the 
> ClientDataSource can be used.
> Constants are
> ClientDataSource.CLEAR_TEXT_PASSWORD_SECURITY (0x03)
> ClientDataSource.USER_ONLY_SECURITY (0x04)
> ClientDataSource.ENCRYPTED_USER_AND_PASSWORD_SECURITY (0x09)
> Add support in client to recognize the user friendly names for the 
> securityMechanism attribute. The values that should be accepted are 
> CLEAR_TEXT_PASSWORD_SECURITY, USER_ONLY_SECURITY, 
> ENCRYPTED_USER_AND_PASSWORD_SECURITY.
> 
> To ensure that the old applications that were written to pass in an integer 
> value for securityMechanism do not break with the new client , the client 
> should probably support both the integer values as well as the string values. 
>  

-- 
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-1000) For LDAP authentication: derby.authentication.server should support ldaps:// as part of the server url.

[Anders Morken (JIRA)]

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

Anders Morken commented on DERBY-1000:
--

Now that DERBY-1174 is resolved the patches attached to this issue is 
technically all you need to let Derby use SSL-enabled LDAP connections to a 
LDAP directory. While I've tested this manually I haven't written a regression 
test for it. You need a lot of manual preparation to test this - most notably 
an SSL-enabled LDAP server to query and bind against, and you need the LDAP 
server's SSL certificate (or the CA certificate that signed the LDAP server's 
cert) in your java installation's trusted certificate store. See 
http://java.sun.com/products/jndi/tutorial/ldap/security/ssl.html for more 
details.
The fact that you need to import the ldap server's cert should probably be 
mentioned in the docs as well. Is the above URL "stable" enough for us to refer 
to in Derby documentation?

> For LDAP authentication: derby.authentication.server should support ldaps:// 
> as part of the server url.
> ---
>
>  Key: DERBY-1000
>  URL: http://issues.apache.org/jira/browse/DERBY-1000
>  Project: Derby
> Type: Bug

>   Components: Newcomer, Security
> Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.1.1, 10.1.1.2, 10.1.2.0, 
> 10.1.2.1, 10.1.2.2, 10.2.0.0
>  Environment: all
> Reporter: Sunitha Kambhampati
> Assignee: Anders Morken
> Priority: Trivial
>  Attachments: DERBY-1000.patch, DERBY1000-docs.patch
>
> derby.authentication.server does not recognize secure ldap url - ie if  the 
> url starts with ldaps:// 
> Trying to connect using LDAP authentication with the following properties set
> derby.authentication.provider=LDAP
> derby.authentication.server=ldaps://xyz.abc.com:636
> derby.authentication.ldap.searchBase='ou=xyz,o=abc.com'
> derby.authentication.ldap.searchFilter='(emailaddress=%USERNAME%)'
> derby.connection.requireAuthentication=true
> throws InvalidNameException
> ij> connect 'jdbc:derby:testdb;user=a;password=p';
> ERROR 08004: Connection refused : javax.naming.InvalidNameException: Invalid 
> name: /xyz.abc.com:636
> Code - LDAPAuthenticationSchemeImpl#setJNDIProviderProperties.
> Problem is the code expects that if Context.PROVIDER_URL is not and if 
> derby.authentication.server is set, then the ldapServer is either of the 
> format //server:port  or it already starts with ldap://  else it just adds 
> ldap://  .
> Thus for a ldaps://xyz.com:636  url , it will become 
> ldap://ldaps://xyz.com:636
>   
>in the code snippet, dflLDAPURL is ldap://
>   if (ldapServer.startsWith(dfltLDAPURL))
>   this.providerURL = ldapServer;
>   else if (ldapServer.startsWith("//"))
>   this.providerURL = "ldap:" + ldapServer;
>   else
>   this.providerURL = dfltLDAPURL + 
> ldapServer;
>   }
>   initDirContextEnv.put(Context.PROVIDER_URL, 
> providerURL);
> We should support specifiying secure ldap , ie ldaps://  in the 
> derby.authentication.server. Add condition to support the ldaps:// 
> ie. 
>   if (ldapServer.startsWith(dfltLDAPURL) || 
> ldapServer.startsWith("ldaps://"))
>   this.providerURL = ldapServer;
> 
> A workaround to the problem is to set the Context.PROVIDER_URL instead.  

-- 
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

Wiki page for upcoming 10.2 release

[Rick Hillegas]

Using Andrew's 10.1.3 wiki page as a template, I have created a first 
cut of a wiki page describing the upcoming 10.2 release 
(http://wiki.apache.org/db-derby/TenTwoRelease). Please feel free to 
improve this page. In particular, JIRA-pros may want to review whether 
the pointer to open 10.2 bugs resolves to the correct query.


Now is a good time to vote on and otherwise identify the bugs we want to 
fix in 10.2.


Thanks!
-Rick

[jira] Closed: (DERBY-1174) NullPointerException in network server with LDAP authentication

[Anders Morken (JIRA)]

 [ http://issues.apache.org/jira/browse/DERBY-1174?page=all ]
 
Anders Morken closed DERBY-1174:



Thanks for the help, Bernt, I'm closing this one.

> NullPointerException in network server with LDAP authentication
> ---
>
>  Key: DERBY-1174
>  URL: http://issues.apache.org/jira/browse/DERBY-1174
>  Project: Derby
> Type: Bug

>   Components: Network Server, Newcomer
> Versions: 10.2.0.0, 10.1.2.1
>  Environment: Linux x86 (Fedora Core 4), 1.4.2_09 Sun JVM
> Reporter: Anders Morken
> Assignee: Anders Morken
> Priority: Minor
>  Fix For: 10.2.0.0, 10.1.3.0
>  Attachments: DERBY-1174.patch, DERBY-1174.patch, derby.log, derby.properties
>
> While trying to fix DERBY-1000 I tried to set up Derby's network server to 
> use LDAP authentication, but I ran into something that looks like a bug, but 
> could just as well be my own configuration mistake. I would appreciate any 
> help in figuring this out. =)
> The problem is a NullPointerException in the Network Server when it tries to 
> initialize the LDAP authentication service. The attached derby.log shows the 
> exception and its stacktrace. The attached derby.properties is what I put in 
> the derby home directory.
> I'm seeing this problem in the trunk as well as my own build of the 10.1 
> branch and the 10.1.2.1 release build available from the Derby web site. ( 
> http://db.apache.org/derby/releases/release-10.1.2.1.cgi )
> The problem is cause by the setInitDirContextEnv method in 
> JNDIAuthenticationSchemeBase receiving a null dbProps argument, which it 
> obviously doesn't expect. Adding a check for a null dbProps argument and 
> returning immediately after creating the initDirContextEnv object fixes the 
> NullPointerException and makes LDAP authentication work for me. This is a 
> reasonable enough robustness fix and shouldn't have any negative impact, but 
> if the source of the problem is that JNDIAuthenticationSchemeBase should 
> never receive that null pointer in the first place, more patching is needed. 
> I'm not sure about this, so I'm leaving it up to the experts to decide 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

Fix Version in Jira and reporting issues fixed in 10.2

[Kathey Marsden]

Trying to query Jira for  report of all the issues fixed in 10.2 I see 
that  we also get  any issues that are already  fixed in  earlier 
versions but were also marked with Fix Version 10.2.0.0

http://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=10594&resolution=1&version=11187&status=5&status=6&sorter/field=issuekey&sorter/order=DESC

This phenomenon is also apparent in the 10.2 release notes:
http://issues.apache.org/jira/secure/ReleaseNote.jspa?version=11187&styleName=Html&projectId=10594&Create=Create

How can  I get a report for just the new fixes for  10.2?

Also, are we really handling Fix Version correctly? In the past I have 
worked with bug tracking systems where "Fix Version" is marked as the 
earliest release where the issue is fixed with  the assumption that all 
forward ports to higher rev levels are taken care of before the issue is 
closed.  This made it more clear how to mark fix version and  
facilitated this type of reporting.   I understand that the forward 
porting assumption might not be always the case in opensource, but I 
think it is the exception when this is not done and  I have heard folks 
comment that the multiple fix versions is confusing and I agree.I 
think I'd like to see Fix Version get marked with the version reported 
by sysinfo  for the lowest  branch  fixed and then snapshot versions 
merged into the real release when it happens.   Thoughts?



Kathey