[Java DB - testing] Error continuous 10.13 (rev 1772493)
Java DB testing and reporting infrastructure. Error continuous 10.13 (rev 1772493) There were execution errors and/or timeouts.
[Java DB - testing] Error nightly trunk (rev 1772428)
Java DB testing and reporting infrastructure. Error nightly trunk (rev 1772428) There were execution errors and/or timeouts. There were at least 1 failures.
[jira] [Commented] (DERBY-6918) Problem with schema name starting with number followed by a dot
[
https://issues.apache.org/jira/browse/DERBY-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15718848#comment-15718848
]
Bryan Pendleton commented on DERBY-6918:
The code merge was straightforward, so I've merged the fix back to 10.13
and committed it.
I'm not sure when the next release from the 10.13 branch might occur;
one thing that would help would be if you could build a copy of 10.13
from source yourself, and perform some additional testing to verify
that this fix is working properly in your environment.
> Problem with schema name starting with number followed by a dot
> ---
>
> Key: DERBY-6918
> URL: https://issues.apache.org/jira/browse/DERBY-6918
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Hooman Valibeigi
>Assignee: Bryan Pendleton
> Fix For: 10.14.0.0
>
> Attachments: schemaNames.diff
>
>
> It seems that there is a problem with schema names that start with a number
> followed by a dot.
> Please take a look at the following script. Everything works fine but the
> last line which is a delete statement. Note that having the foreign key
> constraints was necessary to make it reproduce the problem.
> create schema "1.a";
> create table "1.a"."role"
> (
> "id" integer generated always as identity,
> "name" varchar(255) not null
> );
> alter table "1.a"."role" add constraint "role_pk"
> primary key ("id");
> create table "1.a"."user"
> (
> "id" integer generated always as identity,
> "name" varchar(255) not null
> );
> alter table "1.a"."user" add constraint "user_pk"
> primary key ("id");
> create table "1.a"."user_role"
> (
> "role" integer not null,
> "user" integer not null
> );
> alter table "1.a"."user_role" add constraint "user_role_fk1"
> foreign key ("role")
> references "1.a"."role" ("id")
> on delete cascade;
> alter table "1.a"."user_role" add constraint "user_role_fk2"
> foreign key ("user")
> references "1.a"."user" ("id")
> on delete cascade;
> alter table "1.a"."user_role" add constraint "user_role_u1"
> unique ("user", "role");
> insert into "1.a"."role" ("name") values ('r1');
> insert into "1.a"."user" ("name") values ('u1');
> insert into "1.a"."user_role" ("role","user") values (1,1);
> select * from "1.a"."user";
> delete from "1.a"."user";
> Last delete statement fails. The error is:
> Schema '1' does not exist [SQL State=42Y07, DB Errorcode=2]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6918) Problem with schema name starting with number followed by a dot
[
https://issues.apache.org/jira/browse/DERBY-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15718844#comment-15718844
]
ASF subversion and git services commented on DERBY-6918:
Commit 1772493 from [~bryanpendleton] in branch 'code/branches/10.13'
[ https://svn.apache.org/r1772493 ]
DERBY-6918: Problem with schema name containing a period
Merged: svn merge -r 1772427:1772428
https://svn.apache.org/repos/asf/db/derby/code/trunk
No merge conflicts; no additional changes.
> Problem with schema name starting with number followed by a dot
> ---
>
> Key: DERBY-6918
> URL: https://issues.apache.org/jira/browse/DERBY-6918
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Hooman Valibeigi
>Assignee: Bryan Pendleton
> Fix For: 10.14.0.0
>
> Attachments: schemaNames.diff
>
>
> It seems that there is a problem with schema names that start with a number
> followed by a dot.
> Please take a look at the following script. Everything works fine but the
> last line which is a delete statement. Note that having the foreign key
> constraints was necessary to make it reproduce the problem.
> create schema "1.a";
> create table "1.a"."role"
> (
> "id" integer generated always as identity,
> "name" varchar(255) not null
> );
> alter table "1.a"."role" add constraint "role_pk"
> primary key ("id");
> create table "1.a"."user"
> (
> "id" integer generated always as identity,
> "name" varchar(255) not null
> );
> alter table "1.a"."user" add constraint "user_pk"
> primary key ("id");
> create table "1.a"."user_role"
> (
> "role" integer not null,
> "user" integer not null
> );
> alter table "1.a"."user_role" add constraint "user_role_fk1"
> foreign key ("role")
> references "1.a"."role" ("id")
> on delete cascade;
> alter table "1.a"."user_role" add constraint "user_role_fk2"
> foreign key ("user")
> references "1.a"."user" ("id")
> on delete cascade;
> alter table "1.a"."user_role" add constraint "user_role_u1"
> unique ("user", "role");
> insert into "1.a"."role" ("name") values ('r1');
> insert into "1.a"."user" ("name") values ('u1');
> insert into "1.a"."user_role" ("role","user") values (1,1);
> select * from "1.a"."user";
> delete from "1.a"."user";
> Last delete statement fails. The error is:
> Schema '1' does not exist [SQL State=42Y07, DB Errorcode=2]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: JDK 9 & JDK 9 with Project Jigsaw b144 are available on java.net
Hi Rory,
Build 140 did not display the file permissions problems described here:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-October/005062.html. However,
I did see file permissions problems with JDK 9 build 144. It has taken
me a while to write a compact repro for the file permissions problems,
but I have finally succeeded. My results are described in the comments
dated from 2016-11-15 through 2016-12-03 on the following JIRA issue:
https://issues.apache.org/jira/browse/DERBY-6856
I am attaching the repro to this mail message, along with the following
summary, copied from DERBY-6856:
---
It has taken me a while, but I now have a compact repro for the
regression in JDK 9 build 144. I am attaching the following files:
PTest.java - A test which shows this problem
ptestScript - A script for building the test and running it
To show the problem, put PTest.java in the current directory and run
ptestScript. The script will compile the test class and put the test
class inside a jar file in the parent directory. Then the script will
run the test in setup mode, creating a subdirectory of the current
directory and a policy file. Finally, the script will run the test under
a security manager, demonstrating the problem on JDK 9 build 144.
I have observed the following:
1) The problem only occurs if the jar file which receives privileges is
in the parent directory of the current directory. If the jar file is in
the current directory, then the problem does not occur.
2) The problem only occurs if the policy file grants write permission as
well as read permission on the target directory.
Here is the output of the script when it is run using JDK 8:
--
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
Compile the test and jar it up...
Run the test in setup mode, creating a subdirectory and policy file...
Policy file is...
grant codeBase "file:/Users/rhillegas/derby/PTest.jar" {
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "write";
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "read";
};
Now run the experiment under a security manager...
Checking for existence of
/Users/rhillegas/derby/mainline/ptestdir/zdummy.txt
'/Users/rhillegas/derby/mainline/ptestdir/zdummy.txt' exists = false
--
Here is the output from the script when the current environment uses jdk
9 build 144:
--
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+144)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode)
Compile the test and jar it up...
Run the test in setup mode, creating a subdirectory and policy file...
Policy file is...
grant codeBase "file:/Users/rhillegas/derby/PTest.jar" {
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "write";
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "read";
};
Now run the experiment under a security manager...
Checking for existence of
/Users/rhillegas/derby/mainline/ptestdir/zdummy.txt
Caught a java.security.AccessControlException bearing this message:
access denied ("java.io.FilePermission"
"/Users/rhillegas/derby/mainline/ptestdir/zdummy.txt" "read")
--
Best regards,
-Rick
On 11/14/16, 4:04 AM, Rory O'Donnell wrote:
Hi Rick,
Early Access b144
Early Access b144 .
There have been a number of fixes to bugs reported by Open Source
projects since the last availability email :
* JDK-8156149 : Blurry rendering on Windows 7 at 125% screen setting
* JDK-8167431 : tools javac takes too long time to resolve
interface dependency
* JDK-8062810 : infrastructure Examine src.zip in JDK image and
decide if source classes should be organized by module
*Proposal* - latest update
* b142 of JDK 9 with project Jigsaw has the initial
implementation of open modules and open packages as detailed in
the recent proposal for #ReflectiveAccessToNonExportedTypes [1]
*Tool*
Adapted from JEP 277 [2]
* A static analysis tool jdeprscan has been provided that scans a
jar file (or some other aggregation of class files) for uses of
deprecated API elements.
*Schedule*
* The proposed JDK 9 schedule has been adopted and posted on the
Open JDK 9 Project Page [3]
Rgds,Rory
[1]
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
[2] http://openjdk.java.net/jeps/277
[3]
[jira] [Updated] (DERBY-6856) Make it possible to build Derby using JDK 9
[
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-6856:
-
Attachment: ptestScript
PTest.java
It has taken me a while, but I now have a compact repro for the regression in
JDK 9 build 144. I am attaching the following files:
PTest.java - A test which shows this problem
ptestScript - A script for building the test and running it
To show the problem, put PTest.java in the current directory and run
ptestScript. The script will compile the test class and put the test class
inside a jar file in the parent directory. Then the script will run the test in
setup mode, creating a subdirectory of the current directory and a policy file.
Finally, the script will run the test under a security manager, demonstrating
the problem on JDK 9 build 144.
I have observed the following:
1) The problem only occurs if the jar file which receives privileges is in the
parent directory of the current directory. If the jar file is in the current
directory, then the problem does not occur.
2) The problem only occurs if the policy file grants write permission as well
as read permission on the target directory.
Here is the output of the test when run under JDK 8:
{noformat}
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)
Compile the test and jar it up...
Run the test in setup mode, creating a subdirectory and policy file...
Policy file is...
grant codeBase "file:/Users/rhillegas/derby/PTest.jar" {
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "write";
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "read";
};
Now run the experiment under a security manager...
Checking for existence of /Users/rhillegas/derby/mainline/ptestdir/zdummy.txt
'/Users/rhillegas/derby/mainline/ptestdir/zdummy.txt' exists = false
{noformat}
Here is the output from the script when the current environment uses jdk 9
build 144:
{noformat}
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+144)
Java HotSpot(TM) 64-Bit Server VM (build 9-ea+144, mixed mode)
Compile the test and jar it up...
Run the test in setup mode, creating a subdirectory and policy file...
Policy file is...
grant codeBase "file:/Users/rhillegas/derby/PTest.jar" {
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "write";
permission java.io.FilePermission
"/Users/rhillegas/derby/mainline/ptestdir/-", "read";
};
Now run the experiment under a security manager...
Checking for existence of /Users/rhillegas/derby/mainline/ptestdir/zdummy.txt
Caught a java.security.AccessControlException bearing this message: access
denied ("java.io.FilePermission"
"/Users/rhillegas/derby/mainline/ptestdir/zdummy.txt" "read")
{noformat}
> Make it possible to build Derby using JDK 9
> ---
>
> Key: DERBY-6856
> URL: https://issues.apache.org/jira/browse/DERBY-6856
> Project: Derby
> Issue Type: Improvement
> Components: Build tools
>Affects Versions: 10.12.1.1
>Reporter: Rick Hillegas
> Attachments: PTest.java, derby-6856-01-ab-addShardingKey.diff,
> derby-6856-01-ac-cleanup.diff, derby-6856-02-aa-addShardingKey.diff,
> derby-6856-03-aa-autoboxingDeprecationWarnings.diff,
> derby-6856-03-ab-autoboxingDeprecationWarnings.diff,
> derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff,
> derby-6856-04-ab-autoboxingDeprecationWarnings-part2.diff,
> derby-6856-05-ac-roundingMode-Class.newInstance.diff,
> derby-6856-05-af-roundingMode-Class.getDeclaredConstructor.diff,
> derby-6856-05-ag-roundingMode-Class.newInstance.diff,
> derby-6856-06-aa-observable.diff, derby-6856-07-aa-oneMoreNewInstance.diff,
> derby-6856-08-aa-cleanupJavadoc.diff, derby-6856-09-aa-javadocEntities.diff,
> derby-6856-XX-ab-base.diff, derby-6856-XX-ac-base.diff, ptestScript
>
>
> Derby can't be built with JDK 9. Java 9 introduces new JDBC classes like
> java.sql.ShardingKey and methods which refer to these new classes.
> In addition, project Jigsaw has created a new way to name classes (see
> http://openjdk.java.net/jeps/220). This breaks the PropertySetter build tool
> which we use so that old JVMs can compile Derby and so that Derby can be
> compiled to run on old JVMs.
> It is likely that we will need to leave this issue open throughout the
> development cycle of Java 9.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DERBY-6918) Problem with schema name starting with number followed by a dot
[
https://issues.apache.org/jira/browse/DERBY-6918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15717792#comment-15717792
]
Hooman Valibeigi commented on DERBY-6918:
-
Bryan thanks a lot for fixing this.
Is it possible to release it as a hotfix for 10.13? Otherwise we have to wait
for 10.14 to be released on maven central.
> Problem with schema name starting with number followed by a dot
> ---
>
> Key: DERBY-6918
> URL: https://issues.apache.org/jira/browse/DERBY-6918
> Project: Derby
> Issue Type: Bug
> Components: SQL
>Affects Versions: 10.13.1.1
>Reporter: Hooman Valibeigi
>Assignee: Bryan Pendleton
> Fix For: 10.14.0.0
>
> Attachments: schemaNames.diff
>
>
> It seems that there is a problem with schema names that start with a number
> followed by a dot.
> Please take a look at the following script. Everything works fine but the
> last line which is a delete statement. Note that having the foreign key
> constraints was necessary to make it reproduce the problem.
> create schema "1.a";
> create table "1.a"."role"
> (
> "id" integer generated always as identity,
> "name" varchar(255) not null
> );
> alter table "1.a"."role" add constraint "role_pk"
> primary key ("id");
> create table "1.a"."user"
> (
> "id" integer generated always as identity,
> "name" varchar(255) not null
> );
> alter table "1.a"."user" add constraint "user_pk"
> primary key ("id");
> create table "1.a"."user_role"
> (
> "role" integer not null,
> "user" integer not null
> );
> alter table "1.a"."user_role" add constraint "user_role_fk1"
> foreign key ("role")
> references "1.a"."role" ("id")
> on delete cascade;
> alter table "1.a"."user_role" add constraint "user_role_fk2"
> foreign key ("user")
> references "1.a"."user" ("id")
> on delete cascade;
> alter table "1.a"."user_role" add constraint "user_role_u1"
> unique ("user", "role");
> insert into "1.a"."role" ("name") values ('r1');
> insert into "1.a"."user" ("name") values ('u1');
> insert into "1.a"."user_role" ("role","user") values (1,1);
> select * from "1.a"."user";
> delete from "1.a"."user";
> Last delete statement fails. The error is:
> Schema '1' does not exist [SQL State=42Y07, DB Errorcode=2]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
