Jenkins build is back to normal : Derby-trunk-suites.All #80

[Apache Jenkins Server]

See 

[Java DB - testing] Failure continuous trunk (rev 1742756)

[ingemar . aberg]

Java DB testing and reporting infrastructure.

Failure continuous trunk (rev 1742756)

There were 1 failures.

[jira] [Updated] (DERBY-6856) Make it possible to build Derby using JDK 9

[Rick Hillegas (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick Hillegas updated DERBY-6856:
-
Attachment: derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff

Attaching derby-6856-04-aa-autoboxingDeprecationWarnings-part2.diff. This is a 
second and hopefully last tranche of fixes to eliminate the autoboxing-related 
deprecation warnings when Derby is compiled with build 116 of JDK 9. I am 
running tests under JDK 8 on sane jars compiled under JDK 8 now.

Touches the following files:

{noformat}
M   java/build/org/apache/derbyBuild/build.xml
M   java/build/org/apache/derbyBuild/ODBCMetadataGenerator.java
M   java/build/org/apache/derbyBuild/ClassSizeCrawler.java
M   java/build/org/apache/derbyBuild/classlister.java
M   java/tools/org/apache/derby/impl/tools/ij/xaHelper.java
M   java/tools/org/apache/derby/impl/tools/ij/mtGrammar.jj
M   java/tools/org/apache/derby/impl/tools/ij/ijVectorResult.java
M   java/tools/org/apache/derby/impl/tools/optional/DBMDWrapper.java
M   java/tools/org/apache/derby/impl/tools/build.xml
M   java/demo/nserverdemo/SimpleNetworkClientSample.java
M   java/demo/nserverdemo/NsSampleClientThread.java
M   java/demo/build.xml
M   java/engine/org/apache/derby/iapi/jdbc/DRDAServerStarter.java
M   java/engine/org/apache/derby/iapi/jdbc/build.xml
M   java/engine/org/apache/derby/iapi/services/build.xml
M   java/engine/org/apache/derby/iapi/services/cache/ClassSize.java
M   java/engine/org/apache/derby/iapi/services/locks/ShExLockable.java
M   java/engine/org/apache/derby/iapi/types/SQLReal.java
M   java/engine/org/apache/derby/iapi/types/HarmonySerialBlob.java
M   java/engine/org/apache/derby/iapi/types/HarmonySerialClob.java
M   java/engine/org/apache/derby/iapi/types/build.xml
M   java/engine/org/apache/derby/iapi/types/SQLLongint.java
M   java/engine/org/apache/derby/iapi/types/SQLSmallint.java
M   java/engine/org/apache/derby/iapi/types/SQLInteger.java
M   java/engine/org/apache/derby/iapi/types/SQLTinyint.java
M   java/engine/org/apache/derby/iapi/types/SQLChar.java
M   java/engine/org/apache/derby/iapi/types/SQLBoolean.java
M   java/engine/org/apache/derby/iapi/types/NumberDataType.java
M   java/engine/org/apache/derby/iapi/types/SQLDouble.java
M   java/engine/org/apache/derby/iapi/store/raw/xact/RawTransaction.java
M   java/engine/org/apache/derby/iapi/store/raw/ContainerKey.java
M   java/engine/org/apache/derby/impl/load/ColumnInfo.java
M   java/engine/org/apache/derby/impl/load/Import.java
M   java/engine/org/apache/derby/impl/load/build.xml
M   java/engine/org/apache/derby/impl/load/Export.java
M   java/engine/org/apache/derby/impl/load/LoadError.java
M   java/engine/org/apache/derby/impl/sql/compile/CastNode.java
M   java/engine/org/apache/derby/impl/sql/compile/FromVTI.java
M   java/engine/org/apache/derby/impl/sql/compile/ResultColumnList.java
M   java/engine/org/apache/derby/impl/sql/build.xml
M   java/engine/org/apache/derby/impl/sql/execute/IndexChanger.java
M   java/engine/org/apache/derby/impl/sql/execute/AutoincrementCounter.java
M   java/engine/org/apache/derby/impl/sql/execute/InsertResultSet.java
M   
java/engine/org/apache/derby/impl/sql/execute/CreateSequenceConstantAction.java
M   java/engine/org/apache/derby/impl/sql/execute/JarUtil.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealBasicNoPutResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealRowResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealMaterializedResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealNestedLoopLeftOuterJoinStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealSortStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealHashScanStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealHashLeftOuterJoinStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealDeleteVTIResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealUnionResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealSetOpResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealLastIndexKeyScanStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealJoinResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealScalarAggregateStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealInsertResultSetStatistics.java
M   
java/engine/org/apache/derby/impl/sql/execute/rts/RealProjectRestrictStatistics.java
M   

[jira] [Commented] (DERBY-6856) Make it possible to build Derby using JDK 9

[Rick Hillegas (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275401#comment-15275401
 ] 

Rick Hillegas commented on DERBY-6856:
--

Thanks for fixing that, Bryan. I am about to post a follow-on tranche of 
additional autoboxing-related changes. Let me know if you see any similar 
blunders in that tranche. Thanks.

> 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: 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 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-6856) Make it possible to build Derby using JDK 9

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275390#comment-15275390
 ] 

ASF subversion and git services commented on DERBY-6856:


Commit 1742756 from [~bryanpendleton] in branch 'code/trunk'
[ https://svn.apache.org/r1742756 ]

DERBY-6856: Make it possible to build Derby using JDK 9

This change reverts one particular change from revision 1742289.

The java.util.List class supports two remove methods:
remove(Object o) and remove(int i). In the DatabaseMetaDataTest's
testGetTypeInfo test, there is a List, and changing
the autoboxing code to call remove(Types.BOOLEAN) rather than
remove(new Integer(Types.BOOLEAN)) caused the JDK 8 compiler to
choose remove(int i) rather than remove(Object o), thus
causing failures in the upgrade test suite.

This change returns the test code to using the explicit
object creation in order to ensure we call remove(Object o).

> 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: 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 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] [Comment Edited] (DERBY-6856) Make it possible to build Derby using JDK 9

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275335#comment-15275335
 ] 

Bryan Pendleton edited comment on DERBY-6856 at 5/7/16 6:34 PM:


Hi Rick,

I think that this change to jdbcapi/DatabaseMetaDataTest.java is not correct:

{code}
@@ -2325,7 +2325,7 @@
 // DERBY-4946: Boolean isn't supported if DB is soft-upgraded from
 // pre-10.7 version
 if (!booleanSupported) {
-supportedTypes.remove(new Integer(Types.BOOLEAN));
+supportedTypes.remove(Types.BOOLEAN);
 }
{code}

The problem is that there is a List.remove(Object o) and a List.remove(int i), 
and
the effect of the above change is to change us from calling the first method
to calling the second one.

So instead of removing Types.BOOLEAN from the supportedTypes list, we
are (trying to) remove object number 16 from the supportedTypes list.

With the current head of trunk, if I run

ant 
-Dderby.junit.testclass=org.apache.derbyTesting.functionTests.testupgradeTests._Suite
 junit-single

I get 14 failures which I believe are due to this.

I'm going to investigate reverting this one change, to see if the tests go back 
to working,
and if so I'll commit that.



was (Author: bryanpendleton):
Hi Rick,

I think that this change to jdbcapi/DatabaseMetaDataTest.java is not correct:

@@ -2325,7 +2325,7 @@
 // DERBY-4946: Boolean isn't supported if DB is soft-upgraded from
 // pre-10.7 version
 if (!booleanSupported) {
-supportedTypes.remove(new Integer(Types.BOOLEAN));
+supportedTypes.remove(Types.BOOLEAN);
 }

The problem is that there is a List.remove(Object o) and a List.remove(int i), 
and
the effect of the above change is to change us from calling the first method
to calling the second one.

So instead of removing Types.BOOLEAN from the supportedTypes list, we
are (trying to) remove object number 16 from the supportedTypes list.

With the current head of trunk, if I run

ant 
-Dderby.junit.testclass=org.apache.derbyTesting.functionTests.testupgradeTests._Suite
 junit-single

I get 14 failures which I believe are due to this.

I'm going to investigate reverting this one change, to see if the tests go back 
to working,
and if so I'll commit that.


> 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: 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 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-6856) Make it possible to build Derby using JDK 9

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-6856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275335#comment-15275335
 ] 

Bryan Pendleton commented on DERBY-6856:


Hi Rick,

I think that this change to jdbcapi/DatabaseMetaDataTest.java is not correct:

@@ -2325,7 +2325,7 @@
 // DERBY-4946: Boolean isn't supported if DB is soft-upgraded from
 // pre-10.7 version
 if (!booleanSupported) {
-supportedTypes.remove(new Integer(Types.BOOLEAN));
+supportedTypes.remove(Types.BOOLEAN);
 }

The problem is that there is a List.remove(Object o) and a List.remove(int i), 
and
the effect of the above change is to change us from calling the first method
to calling the second one.

So instead of removing Types.BOOLEAN from the supportedTypes list, we
are (trying to) remove object number 16 from the supportedTypes list.

With the current head of trunk, if I run

ant 
-Dderby.junit.testclass=org.apache.derbyTesting.functionTests.testupgradeTests._Suite
 junit-single

I get 14 failures which I believe are due to this.

I'm going to investigate reverting this one change, to see if the tests go back 
to working,
and if so I'll commit that.


> 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: 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 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-3181) isNullable on ResultSetMetaData from DatabaseMetaData.getBestRowIdentifier values are opposite when there is no rows in ResultSet vs. when there is a row.

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275333#comment-15275333
 ] 

Bryan Pendleton commented on DERBY-3181:


Hi Danoja, it appears that my test failures are actually caused by DERBY-6856, 
and are not related to our work on this issue. If you are
getting "Unexpected type DATE" in your upgrade tests, it is because
of DERBY-6856. I will work on that problem separately.

> isNullable on ResultSetMetaData from DatabaseMetaData.getBestRowIdentifier 
> values are opposite when there is no rows in ResultSet vs. when there is a 
> row.
> --
>
> Key: DERBY-3181
> URL: https://issues.apache.org/jira/browse/DERBY-3181
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.4.1.3
>Reporter: Myrna van Lunteren
>Assignee: Danoja Dias
>Priority: Trivial
>  Labels: derby_triage10_5_2
> Attachments: Derby-3181.diff, repro.java, testChange.diff
>
>
> With code like the following: 
>DatabaseMetaData dmd = conn.getMetaData(); 
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",3,true);
> ResultSetMetaData rsmd = rs.getMetaData(); 
> int actualCols = rsmd.getColumnCount(); 
> for (int i = 0; i < actualCols; i++) 
> { 
>  System.out.print("getColumnName: " + rsmd.getColumnName(i+1) 
> + ", isNullable: "); 
>  System.out.println(rsmd.isNullable(i+1)); 
> } 
> The printed values for isNullable returned are opposite of what they are when 
> the getBestRowIdentifier call looks like this:
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",1,true);
> In the latter case, the values are:
> getColumnName: SCOPE, isNullable: 0
> getColumnName: COLUMN_NAME, isNullable: 1
> getColumnName: DATA_TYPE, isNullable: 0
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 0
> getColumnName: BUFFER_LENGTH, isNullable: 0
> getColumnName: DECIMAL_DIGITS, isNullable: 0
> getColumnName: PSEUDO_COLUMN, isNullable: 0
> In the first case, the values are:
> getColumnName: SCOPE, isNullable: 1
> getColumnName: COLUMN_NAME, isNullable: 0
> getColumnName: DATA_TYPE, isNullable: 1
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 1
> getColumnName: BUFFER_LENGTH, isNullable: 1
> getColumnName: DECIMAL_DIGITS, isNullable: 1
> getColumnName: PSEUDO_COLUMN, isNullable: 1
> The isNullable value should be stable. 
> It's probably worthwhile verifying what the value *should* be in the first 
> place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DERBY-3181) isNullable on ResultSetMetaData from DatabaseMetaData.getBestRowIdentifier values are opposite when there is no rows in ResultSet vs. when there is a row.

[Bryan Pendleton (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275261#comment-15275261
 ] 

Bryan Pendleton commented on DERBY-3181:


Indeed, it looks like I am still seeing some problems in the upgradeTests, too.
But my results are not the same as yours. Can you look in your results?
You should have a directory named "junit_MMDD_HHMM" in your trunk
directory, and in there should be all the results of your testing. There
should be a file named 
TEST-org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite.xml
and that file should have information about each test failure. In that
file, use your text editor to search for the strings 'error message=' and
'failure message=' to see information about each error and each test failure.

In my case, my results were:
[junit] Tests run: 6439, Failures: 14, Errors: 0, Skipped: 0, Time elapsed: 
2,491.535 sec
[junit] Test 
org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite FAILED

and in my XML file I see only one failure, but the same failure occurred
all 14 times:
  
junit.framework.AssertionFailedError:
 Unexpected type DATE
at 
org.apache.derbyTesting.functionTests.tests.jdbcapi.DatabaseMetaDataTest.testGetTypeInfo(DatabaseMetaDataTest.java:2346)
at 
org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:120)
...

I will have to study this some more; I am not sure what is causing this
particular test to fail, and why it occurs only during the upgrade testing.

What do your errors and failures look like?+

> isNullable on ResultSetMetaData from DatabaseMetaData.getBestRowIdentifier 
> values are opposite when there is no rows in ResultSet vs. when there is a 
> row.
> --
>
> Key: DERBY-3181
> URL: https://issues.apache.org/jira/browse/DERBY-3181
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.4.1.3
>Reporter: Myrna van Lunteren
>Assignee: Danoja Dias
>Priority: Trivial
>  Labels: derby_triage10_5_2
> Attachments: Derby-3181.diff, repro.java, testChange.diff
>
>
> With code like the following: 
>DatabaseMetaData dmd = conn.getMetaData(); 
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",3,true);
> ResultSetMetaData rsmd = rs.getMetaData(); 
> int actualCols = rsmd.getColumnCount(); 
> for (int i = 0; i < actualCols; i++) 
> { 
>  System.out.print("getColumnName: " + rsmd.getColumnName(i+1) 
> + ", isNullable: "); 
>  System.out.println(rsmd.isNullable(i+1)); 
> } 
> The printed values for isNullable returned are opposite of what they are when 
> the getBestRowIdentifier call looks like this:
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",1,true);
> In the latter case, the values are:
> getColumnName: SCOPE, isNullable: 0
> getColumnName: COLUMN_NAME, isNullable: 1
> getColumnName: DATA_TYPE, isNullable: 0
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 0
> getColumnName: BUFFER_LENGTH, isNullable: 0
> getColumnName: DECIMAL_DIGITS, isNullable: 0
> getColumnName: PSEUDO_COLUMN, isNullable: 0
> In the first case, the values are:
> getColumnName: SCOPE, isNullable: 1
> getColumnName: COLUMN_NAME, isNullable: 0
> getColumnName: DATA_TYPE, isNullable: 1
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 1
> getColumnName: BUFFER_LENGTH, isNullable: 1
> getColumnName: DECIMAL_DIGITS, isNullable: 1
> getColumnName: PSEUDO_COLUMN, isNullable: 1
> The isNullable value should be stable. 
> It's probably worthwhile verifying what the value *should* be in the first 
> place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: blank html frames in Jenkins-built documentation

[Rick Hillegas]

Thanks, Uwe and Chris. The change described on 
https://issues.apache.org/jira/browse/INFRA-11746 seems to have fixed 
the problem. I can now see Derby's Jenkins-generated, frames-based, 
html-formatted alpha docs.


Thanks,
-Rick

On 4/25/16 4:19 PM, Uwe Schindler wrote:

I opened https://issues.apache.org/jira/browse/INFRA-11746

Uwe

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


-Original Message-
From: Andrew Bayer [mailto:andrew.ba...@gmail.com]
Sent: Sunday, April 24, 2016 8:09 PM
To: bui...@apache.org
Cc: Rick Hillegas; derby-dev@db.apache.org
Subject: Re: blank html frames in Jenkins-built documentation

Please open an INFRA JIRA.

On Sunday, April 24, 2016, Uwe Schindler  wrote:


Hi,

We have the same problem with our Lucene documentation. Some Lucene
classes refer to JDK documentation. The links just result in a white page
and the mentioned security warning in browser logs.

For other Jenkins servers outside ASF the setting to disable this checks
were added to prevent the javadocs problem.

Unless Java 9 with the new Javadocs style comes, it is impossible to
display Javadocs of previous versions with the frame security issues.
Please disable this as described in Jenkins Wiki. Our build servers are
under full control by infrastructure and comitters. Nobody from the outside
can inject custom pages loaded in frames.

Uwe

Am 24. April 2016 16:34:16 MESZ, schrieb Rick Hillegas<
rick.hille...@gmail.com>:

Hi Infrastructure experts,

The Derby project uses Jenkins to build the latest version of our user
documentation. The resulting documents are linked from the Derby
website
here: http://db.apache.org/derby/manuals/index.html#latest. Some of

the

Jenkins-built documentation is in html format and it uses frames. The
Jenkins machines serve up those web pages as blank frames and my
Firefox
browser's error console reports the following:


Content Security Policy: Couldn't process unknown directive 'sandbox'

Content Security Policy: The page's settings blocked the loading of a
resource at


https://builds.apache.org/job/Derby-

docs/lastSuccessfulBuild/artifact/trunk/out/ref/toc.html

("default-src 'none'").


The frames seem to have been intercepted in order to frustrate a
possible Cross Frame Scripting attack, as described by the default
Jenkins Content Security Policy:


https://wiki.jenkins-

ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringCo
ntentSecurityPolicy-Considerations

The default Jenkins Content Security Policy assumes that Apache
continuous-integration builds are exposed to the two risks listed here:



https://wiki.jenkins-

ci.org/display/JENKINS/Configuring+Content+Security+Policy#ConfiguringCo
ntentSecurityPolicy-Considerations

. I don't believe that Apache's Jenkins builds suffer from the first
risk ("Are less trusted users allowed to create or modify files in
Jenkins workspaces?"). That is because only trusted Apache committers
can trigger Jenkins builds. Do Apache continuous-integration builds
suffer from the second risk ("Are some slaves not fully trusted?").

The Derby developers have begun discussing this problem at


http://apache-database.10148.n7.nabble.com/alpha-docs-not-being-

generated-td145918.html

. I would appreciate your advice about how we can stop html frames from

being intercepted and blanked out when readers link to the
Jenkins-built
documentation.

Thanks,
-Rick

[jira] [Commented] (DERBY-3181) isNullable on ResultSetMetaData from DatabaseMetaData.getBestRowIdentifier values are opposite when there is no rows in ResultSet vs. when there is a row.

[Danoja Dias (JIRA)]

[ 
https://issues.apache.org/jira/browse/DERBY-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15275239#comment-15275239
 ] 

Danoja Dias commented on DERBY-3181:


Hi Bryan,

Are they running clean?
But I got something like this after adding the patch.

junit-core:
[junit] Running org.apache.derbyTesting.junit.EnvTest
[junit] Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
0.987 sec
[junit] Running org.apache.derbyTesting.functionTests.tests.derbynet._Suite
[junit] Tests run: 339, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
863.906 sec
[junit] Running org.apache.derbyTesting.functionTests.tests.tools._Suite
[junit] Tests run: 127, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
200.987 sec
[junit] Running org.apache.derbyTesting.functionTests.tests.demo._Suite
[junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
25.368 sec
[junit] Running org.apache.derbyTesting.functionTests.tests.lang._Suite
[junit] Tests run: 3226, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
11,455.151 sec
[junit] Running org.apache.derbyTesting.functionTests.tests.jdbcapi._Suite
[junit] Tests run: 7881, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
5,330.829 sec
[junit] Running org.apache.derbyTesting.functionTests.tests.store._Suite
[junit] Tests run: 346, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
3,127.492 sec
[junit] Running org.apache.derbyTesting.functionTests.tests.engine._Suite
[junit] Tests run: 39, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
197.515 sec
[junit] Running 
org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationSuite
[junit] Tests run: 23, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
1,306.592 sec
[junit] Running org.apache.derbyTesting.unitTests.junit._Suite
[junit] Tests run: 170, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
47.173 sec
[junit] Running 
org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite
[junit] Tests run: 6439, Failures: 152, Errors: 35, Skipped: 0, Time 
elapsed: 8,246.18 sec
[junit] Test 
org.apache.derbyTesting.functionTests.tests.upgradeTests._Suite FAILED
[junit] Running org.apache.derbyTesting.functionTests.suites.EncryptionSuite
[junit] Tests run: 203, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
199.743 sec


> isNullable on ResultSetMetaData from DatabaseMetaData.getBestRowIdentifier 
> values are opposite when there is no rows in ResultSet vs. when there is a 
> row.
> --
>
> Key: DERBY-3181
> URL: https://issues.apache.org/jira/browse/DERBY-3181
> Project: Derby
>  Issue Type: Bug
>  Components: JDBC
>Affects Versions: 10.4.1.3
>Reporter: Myrna van Lunteren
>Assignee: Danoja Dias
>Priority: Trivial
>  Labels: derby_triage10_5_2
> Attachments: Derby-3181.diff, repro.java, testChange.diff
>
>
> With code like the following: 
>DatabaseMetaData dmd = conn.getMetaData(); 
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",3,true);
> ResultSetMetaData rsmd = rs.getMetaData(); 
> int actualCols = rsmd.getColumnCount(); 
> for (int i = 0; i < actualCols; i++) 
> { 
>  System.out.print("getColumnName: " + rsmd.getColumnName(i+1) 
> + ", isNullable: "); 
>  System.out.println(rsmd.isNullable(i+1)); 
> } 
> The printed values for isNullable returned are opposite of what they are when 
> the getBestRowIdentifier call looks like this:
> ResultSet rs = dmd.getBestRowIdentifier(null,"APP","a",1,true);
> In the latter case, the values are:
> getColumnName: SCOPE, isNullable: 0
> getColumnName: COLUMN_NAME, isNullable: 1
> getColumnName: DATA_TYPE, isNullable: 0
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 0
> getColumnName: BUFFER_LENGTH, isNullable: 0
> getColumnName: DECIMAL_DIGITS, isNullable: 0
> getColumnName: PSEUDO_COLUMN, isNullable: 0
> In the first case, the values are:
> getColumnName: SCOPE, isNullable: 1
> getColumnName: COLUMN_NAME, isNullable: 0
> getColumnName: DATA_TYPE, isNullable: 1
> getColumnName: TYPE_NAME, isNullable: 1
> getColumnName: COLUMN_SIZE, isNullable: 1
> getColumnName: BUFFER_LENGTH, isNullable: 1
> getColumnName: DECIMAL_DIGITS, isNullable: 1
> getColumnName: PSEUDO_COLUMN, isNullable: 1
> The isNullable value should be stable. 
> It's probably worthwhile verifying what the value *should* be in the first 
> place.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)