Re: Build issue
HI All, Yes there was a conflict for basetestcase file and i did MC(My conflict) as an option... Is that what caused the issue ? With Regards Jayaram On Fri, Aug 19, 2011 at 12:47 AM, Kathey Marsden kmarsdende...@sbcglobal.net wrote: On 8/18/2011 8:04 PM, Jayaram Subramanian wrote: Hi All, When doing ant all, i suddenly ended up getting the following issue.. Any clues? compilet1: [javac] Compiling 162 source files to C:\java\derby\source\trunk\classes [javac] C:\java\derby\source\trunk\java\testing\org\apache\derbyTesting\func tionTests\tests\store\RecoveryTest.java:92: cannot find symbol [javac] symbol : method assertLaunchedJUnitTestMethod(java.lang.String) [javac] location: class org.apache.derbyTesting.functionTests.tests.store.Re coveryTest [javac] assertLaunchedJUnitTestMethod(org.apache.derbyTesting.funct ionTests.tests.store.RecoveryTest.launchRecoveryInsert); [javac] ^ [javac] 1 error Hi Jayaram, The method assertLaunchedJUnitTestMethod was added to BaseTestCase.java as part of the DERBY-4249 change. When you did an svn update you should have gotten the new version of this file or it should have merged with your changes if you are editing the same file unless you saw a conflict. Did you see a conflict when you did svn update? If there was no conflict, perhaps also after svn update, you needed to do an ant clobber before rebuilding. If there was a conflict you should have been asked how you wished to handle it. Thanks Kathey
Re: Build issue
On 8/19/2011 4:37 AM, Jayaram Subramanian wrote: HI All, Yes there was a conflict for basetestcase file and i did MC(My conflict) as an option... Is that what caused the issue ? Probably that is the issue. There is some conflict for which your changes took precedence and you lost the changes that were in trunk. At this point you'll probably want to fix things up manually. If you have the subclipse plugin installed in eclipse, you can right click on the file and choose compare latest from repository. If you have a visual diff tool you can look at the diff this way. svn cat -r HEAD BaseTestCase.java BaseTestCase.java.HEAD diff BaseTestCase.java BaseTestCase.java.HEAD replacing diff with your visual difftool. If your changes are not too extensive, sometimes it is easiest just to make a copy of your changed file, svn revert it and make the changes again manually. When I have a conflict with svn update, I usually make a copy of my file and choose their conflict, just because I figure I will be able to better figure out what went wrong with my code and redo the change vs the code I am bringing in. HTH Kathey
Regression Test Report - Daily 1159289 - Sun DBTG
[Auto-generated mail] *Daily* 1159289/2011-08-18 18:00:24 MEST Failed TestsOK Skip Duration Suite --- *Jvm: 1.6* lin 01421614216 0 1562.97% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 046.78% derbyall UNKNOWNUNKNOWNUNKNOWN UNKNOWN 0.00% compatibility 022 0 .% demoSuite sles F:0,E:11421614215 0 969.06% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 039.91% derbyall 022 0 142.50% compatibility 022 0 .% demoSuite sol 01420414204 0 1142.17% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 035.59% derbyall 022 0 156.38% compatibility 022 0 .% demoSuite sol32 01420414204 0 .% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 0 .% derbyall 022 0 .% compatibility 022 0 .% demoSuite solN+1 01420414204 0 217.68% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 054.75% derbyall 022 0 161.18% compatibility 022 0 .% demoSuite sparc 01420414204 0 584.05% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 027.03% derbyall 022 0 138.05% compatibility 022 0 .% demoSuite vista 01421414214 0 184.67% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 048.55% derbyall NA NA NANA compatibility 022 0 .% demoSuite vista-64 01421414214 0 264.80% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 047.89% derbyall NA NA NANA compatibility 022 0 .% demoSuite w2003 01421414214 0 363.64% suitesAll 01515 0 .% jdbcapiAutoLoad 01414 0 .% JDBCDriversAll 01515 0 .% JDBCDriversClient 01414 0 .% JDBCDriversEmbedded 0181181 059.07% derbyall NA NA NANA compatibility 022 0 .% demoSuite Details in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1159289.html Attempted failure analysis in http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/FailReports/1159289_bySig.html *Jvm: 1.5* lin 0182182 044.23% derbyall 01224012240 0 2614.44% suitesAll sles 0182182 037.00% derbyall 01224012240 0 1507.76% suitesAll sol 0182182 037.66% derbyall 01222812228 0 2160.44% suitesAll sol32 0182182 0 .% derbyall 01222812228 0 .% suitesAll solN+1 0182182 049.32% derbyall 01222812228 0 2182.98% suitesAll sparc 0182182 026.60% derbyall 01222812228 0 1363.41% suitesAll vista 0182182 037.30% derbyall 01223812238 0 1285.08% suitesAll vista-64 0182182 047.84% derbyall 01223812238 0 297.99% suitesAll w2003 0182182 0
[jira] [Commented] (DERBY-5385) Improve documentation for OFFSET/FETCH NEXT
[ https://issues.apache.org/jira/browse/DERBY-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087780#comment-13087780 ] Dag H. Wanvik commented on DERBY-5385: -- Thanks, Kim. Thanges look good to me. But this observatiob by Tiago was the reason we kept DERBY-4518 open, I believe: I couldn't find an example under The result offset and fetch first clauses that demonstrates the use of OFFSET within sub-queries. There is an example under Duplicates in UNION, INTERSECT, and EXCEPT ALL results but at least to me, that wouldn't be the first logical place I'd visit to find examples of OFFSET usage on sub-queries. Perhaps it might be good to to point to the example of use in sub-queries from The result offset and fetch first clauses section's examples, or make another one there? Improve documentation for OFFSET/FETCH NEXT --- Key: DERBY-5385 URL: https://issues.apache.org/jira/browse/DERBY-5385 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2 Reporter: Dag H. Wanvik Assignee: Kim Haase Attachments: DERBY-5385.diff, rrefsqljoffsetfetch.html cf the suggestion in DERBY-4518. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (DERBY-5385) Improve documentation for OFFSET/FETCH NEXT
[ https://issues.apache.org/jira/browse/DERBY-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087780#comment-13087780 ] Dag H. Wanvik edited comment on DERBY-5385 at 8/19/11 4:07 PM: --- Thanks, Kim. Changes look good to me. But this observation by Tiago was the reason we kept DERBY-4518 open, I believe: I couldn't find an example under The result offset and fetch first clauses that demonstrates the use of OFFSET within sub-queries. There is an example under Duplicates in UNION, INTERSECT, and EXCEPT ALL results but at least to me, that wouldn't be the first logical place I'd visit to find examples of OFFSET usage on sub-queries. Perhaps it might be good to to point to the example of use in sub-queries from The result offset and fetch first clauses section's examples, or make another one there? was (Author: dagw): Thanks, Kim. Thanges look good to me. But this observatiob by Tiago was the reason we kept DERBY-4518 open, I believe: I couldn't find an example under The result offset and fetch first clauses that demonstrates the use of OFFSET within sub-queries. There is an example under Duplicates in UNION, INTERSECT, and EXCEPT ALL results but at least to me, that wouldn't be the first logical place I'd visit to find examples of OFFSET usage on sub-queries. Perhaps it might be good to to point to the example of use in sub-queries from The result offset and fetch first clauses section's examples, or make another one there? Improve documentation for OFFSET/FETCH NEXT --- Key: DERBY-5385 URL: https://issues.apache.org/jira/browse/DERBY-5385 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2 Reporter: Dag H. Wanvik Assignee: Kim Haase Attachments: DERBY-5385.diff, rrefsqljoffsetfetch.html cf the suggestion in DERBY-4518. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-3676) Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far
[
https://issues.apache.org/jira/browse/DERBY-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087790#comment-13087790
]
Rick Hillegas commented on DERBY-3676:
--
I would like to understand the vulnerability better. I don't think that Derby
uses (Prepared)Statement.toString() when it prints diagnostic information to
derby.log after you set derby.language.logStatementText=true. As I understand
the attack, the problem is with the (Prepared)Statement once it is in the
application. In a sloppy application, (Prepared)Statements could be visible
across threads/sessions, allowing blackhats to snoop sensitive information.
Is that the attack?
---
Here are some rambling thoughts about how to protect against this attack:
I am positive about controlling this new toString() behavior with a permission
which would be checked when running under a Java SecurityManager as Dag
suggests and as is done with DriverManager.setLogWriter(). See
http://download.oracle.com/javase/7/docs/api/java/sql/DriverManager.html#setLogWriter%28java.io.PrintWriter%29
and http://download.oracle.com/javase/7/docs/api/java/sql/SQLPermission.html
For reference: if you are running under a Java SecurityManager, the
DriverManager.setLogWriter() method succeeds only if your security policy
grants the setLog SQLPermission to your application's code domain. E.g.:
grant codeBase file:///Applications/myApp.jar
{
permission java.sql.SQLPermission setLog;
};
We could require something similar in order to protect the
(Prepared)Statement.toString() method from abuse:
grant codeBase file:///Applications/myApp.jar
{
permission java.sql.SQLPermission com.apache.derby.client.am.Statement,
toString;
permission java.sql.SQLPermission
com.apache.derby.impl.jdbc.EmbedStatement, toString;
};
If the permission is granted, then the new toString() behavior would be in
effect. Otherwise, you would get the old toString() behavior.
Make the toString() method of Derby PreparedStatements print out SQL text
with ? parameters replaced by the values that have been set so far
Key: DERBY-3676
URL: https://issues.apache.org/jira/browse/DERBY-3676
Project: Derby
Issue Type: Improvement
Components: JDBC
Reporter: Rick Hillegas
Assignee: Siddharth Srivastava
Attachments: humanstringprepared.txt, humanstringprepared.txt,
humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt,
humanstringprepared.txt, humanstringprepared.txt, ick.txt, ick.txt,
prepared.diff, statementCacheVTI.sql
This topic came up in the following email thread on the user list:
http://www.nabble.com/PreparedStatement.toString%28%29---nice-formatting-td17250811.html#a17250811
Here's what the thread requests:
In mysql, a toString() on a PreparedStatement will do this, eg select x
from foo where x.a = ? will become select x from foo where x.a = 1 with
the appropriate setValue() call.
At first blush, this seems like it might be a simple project for a newcomer.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5385) Improve documentation for OFFSET/FETCH NEXT
[ https://issues.apache.org/jira/browse/DERBY-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087827#comment-13087827 ] Kim Haase commented on DERBY-5385: -- I thought I took that example from Duplicates in UNION, INTERSECT, and EXCEPT ALL results and put it right into this topic. Isn't it there? The comment says Use of ORDER BY and FETCH FIRST in a subquery. Improve documentation for OFFSET/FETCH NEXT --- Key: DERBY-5385 URL: https://issues.apache.org/jira/browse/DERBY-5385 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2 Reporter: Dag H. Wanvik Assignee: Kim Haase Attachments: DERBY-5385.diff, rrefsqljoffsetfetch.html cf the suggestion in DERBY-4518. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-3676) Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far
[ https://issues.apache.org/jira/browse/DERBY-3676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087837#comment-13087837 ] Kathey Marsden commented on DERBY-3676: --- I think including the internal Derby class names in the permission doesn't seem quite right although I guess we would need to specify derby specifically vs other databases. Since this would be diagnostic tool and really shouldn't be used or parsed in any production environment, we could as you suggest always revert to the old output when running under security manager and not even bother with adding a permission at this time. If someone comes back with a reason they have to have it under security manager, then we can talk about their scenario, permission names and security at that time. Also this does seem specific to PreparedStatements as Statement would not have any sql text or parameters directly associated with it. I too think it is good to understand what the exact attack scenarios would be. I am not sure I really understand it with local PreparedStatement instances. DrvierManager.setLogWriter really needed protection because it is a public static method that is part of the Java API. Make the toString() method of Derby PreparedStatements print out SQL text with ? parameters replaced by the values that have been set so far Key: DERBY-3676 URL: https://issues.apache.org/jira/browse/DERBY-3676 Project: Derby Issue Type: Improvement Components: JDBC Reporter: Rick Hillegas Assignee: Siddharth Srivastava Attachments: humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, humanstringprepared.txt, ick.txt, ick.txt, prepared.diff, statementCacheVTI.sql This topic came up in the following email thread on the user list: http://www.nabble.com/PreparedStatement.toString%28%29---nice-formatting-td17250811.html#a17250811 Here's what the thread requests: In mysql, a toString() on a PreparedStatement will do this, eg select x from foo where x.a = ? will become select x from foo where x.a = 1 with the appropriate setValue() call. At first blush, this seems like it might be a simple project for a newcomer. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13087849#comment-13087849 ] Kathey Marsden commented on DERBY-5363: --- Hi Dag, I was wondering what would happen in practice in the following upgrade scenario: 1) Assume the site has been starting network server from the command line with various users, relying on umask settings to control permissions. 2) They upgrade to 10.9 with your changes and of course didn't read the release notes to set the property. 3) User A starts network server and a client connects creating the new more restrictive derby.log and stops the server. 4) User B starts network server and a client connects, but presumably can't access derby.log. What kind of error would they get? What recovery steps do they need to take ? Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [jira] [Commented] (DERBY-5387) Memory leak or unbounded consumption problem when running a utility to copy one database to another using SYSCS_EXPORT_TABLE and SYSCS_IMPORT_TABLE
Can you point me to the docs on how to do a debug build. I have build derby recently both sane and insane builds and know how to run the tests now, so point me in the correct direction and I will investigate more. Also, I believe you are correct on the leaking. Good catch! I will fix that retry and update the JIRA issue if this changes anything. -Original Message- From: Kristian Waagan (JIRA) [mailto:j...@apache.org] Sent: Thursday, August 18, 2011 7:46 AM To: derby-dev@db.apache.org Subject: [jira] [Commented] (DERBY-5387) Memory leak or unbounded consumption problem when running a utility to copy one database to another using SYSCS_EXPORT_TABLE and SYSCS_IMPORT_TABLE [ https://issues.apache.org/jira/browse/DERBY-5387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086970#comment-13086970 ] Kristian Waagan commented on DERBY-5387: This may be somewhat tricky to investigate. To isolate the problem, are you able to first export the tables, and then import the largest file? If that works, there must be a problem with cleaning up / releasing resources. If it doesn't work there's a problem in the insert/sort code. For instance, the memory figures are wrong - causing Derby to grow the sort buffer too much (i.e. the sort fails to spill to disk). You could try with a debug build and enable output for the sort buffer. The output is far from perfect, but you'll get some indications of what's going on. This will take even longer to run, so save the output to file and go do something else... (I think this output goes to std err by default). Enable by running the debug build with -Dderby.debug.true=SortTuning. If you can somehow provide a link to the heap dump that *could* also help (too large to be attached here). **NOTE**: If the data is confidential, this is not an option! Finally, a junk data generator and small program to actually run the import would be another way to allow people to debug this. On another matter, if I understand the code correctly, the dbcopy code is leaking connections to the source database (line 537). Memory leak or unbounded consumption problem when running a utility to copy one database to another using SYSCS_EXPORT_TABLE and SYSCS_IMPORT_TABLE --- Key: DERBY-5387 URL: https://issues.apache.org/jira/browse/DERBY-5387 Project: Derby Issue Type: Bug Components: SQL Affects Versions: 10.8.1.2 Environment: Solaris 10/9, Oracle Java 1.6.0_22, 1Gb heap space (also ran with 8Gb heap space with no difference other than how long it takes to run out of memory). Reporter: Brett Bergquist Priority: Critical Attachments: dbcopy.zip, java_pid2364_Leak_Hunter.zip, java_pid2364_Leak_Suspects.zip I have a utility that copies one database to another by using 'dblook to export the schema from the first which is then uses to create the copy's schema. The tables are exported from the first database using the SYSCS_EXPORT_TABLE and imported into the second database using SYSCS_IMPORT_TABLE, processing each table before moving on to the next. The the constraints and indexes present in the schema generated by 'dblook' are applied to the second database. The utility runs out of memory regardless of the amount of memory given when run on a very large database (one table has 75 million rows in it and the total database size is 110Gb of disk storage). The utility does complete on a smaller database. I will attach the source code for the utility. Also added the -XX:+HeapDumpOnOutOfMemory flag and ran with -Xmx1024m heap. I will attach the suspected leaks report generated by the Eclipse MemoryAnalyzer tool. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5385) Improve documentation for OFFSET/FETCH NEXT
[ https://issues.apache.org/jira/browse/DERBY-5385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088025#comment-13088025 ] Dag H. Wanvik commented on DERBY-5385: -- Sure it's there. I must have looked at this before my morning coffee.. Sorry ;-) +1 Improve documentation for OFFSET/FETCH NEXT --- Key: DERBY-5385 URL: https://issues.apache.org/jira/browse/DERBY-5385 Project: Derby Issue Type: Improvement Components: Documentation Affects Versions: 10.6.1.0, 10.6.2.1, 10.7.1.1, 10.8.1.2 Reporter: Dag H. Wanvik Assignee: Kim Haase Attachments: DERBY-5385.diff, rrefsqljoffsetfetch.html cf the suggestion in DERBY-4518. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088051#comment-13088051 ] Dag H. Wanvik commented on DERBY-5363: -- Right, if the two users relied on group write access to derby.log (as they would have had to to be able to use the same derby.log file earlier), user B who tried to *append* to the already created derby.log (created by user A), would experience an error, cf below. I.e. the fact that derby.log is not accessible results in this error message on the console: Sat Aug 20 00:46:04 CEST 2011 Thread[main,5,main] java.io.FileNotFoundException: derby.log (Ingen tilgang) Ingen adgang: Norwegian for no access :.) Derby then proceeds to use the console as error stream. The workaround would be to specify -Dderby.error.derby.stream.error.file=file, cf. end of enclosed session trace. dags-lenovo:~/java/sb/sb1$ ls -l derby.log -rwx-- 1 dag None 1079 Aug 10 00:33 derby.log dags-lenovo:~/java/sb/sb1$ chmod 000 derby.log dags-lenovo:~/java/sb/sb1$ ls -l derby.log -- 1 dag None 1079 Aug 10 00:33 derby.log dags-lenovo:~/java/sb/sb1$ java org.apache.derby.tools.ij ij version 10.9 ij connect 'jdbc:derby:wombat'; Sat Aug 20 00:46:04 CEST 2011 Thread[main,5,main] java.io.FileNotFoundException: derby.log (Ingen tilgang) Sat Aug 20 00:46:05 CEST 2011 Thread[main,5,main] Cleanup action starting java.sql.SQLException: Database 'wombat' not found. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:227) at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java:3085) at org.apache.derby.impl.jdbc.EmbedConnection.handleDBNotFound(EmbedConnection.java:735) : dags-lenovo:~/java/sb/sb1$ java -Dderby.stream.error.file=error.txt org.apache.derby.tools.ij ij version 10.9 ij connect 'jdbc:derby:wombat'; ERROR XJ004: Database 'wombat' not found. ij exit; dags-lenovo:~/java/sb/sb1$ Use exit to leave the shell. dags-lenovo:~/java/sb/sb1$ cat error.txt Sat Aug 20 00:54:38 CEST 2011 Thread[main,5,main] Cleanup action starting java.sql.SQLException: Database 'wombat' not found. at org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:98) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:142) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Util.java:227) at org.apache.derby.impl.jdbc.EmbedConnection.newSQLException(EmbedConnection.java:3085) Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with = JDK6
[ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088077#comment-13088077 ] Kathey Marsden commented on DERBY-5363: --- Assuming they want to continue with the old behavior, would a resolution at this point be as simple as take down the server, chmod the derby.log and add derby.storage.useDefaultFilePermissions=true to the derby.properties file? Tighten default permissions of DB files with = JDK6 Key: DERBY-5363 URL: https://issues.apache.org/jira/browse/DERBY-5363 Project: Derby Issue Type: Improvement Reporter: Dag H. Wanvik Attachments: permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql Before Java 6, files created by Derby would have the default permissions of the operating system context. Under Unix, this would depend on the effective umask of the process that started the Java VM. In Java 6 and 7, there are methods available that allows tightening up this (File.setReadable, setWritable), making it less likely that somebody would accidentally run Derby with a too lenient default. I suggest we take advantage of this, and let Derby by default (in Java 6 and higher) limit the visibility to the OS user that starts the VM, e.g. on Unix this would be equivalent to running with umask 0077. More secure by default is good, I think. We could have a flag, e.g. derby.storage.useDefaultFilePermissions that when set to true, would give the old behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5300) Change derby.tests.trace to print the class as well as fixture name
[ https://issues.apache.org/jira/browse/DERBY-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayaram Subramanian updated DERBY-5300: --- Attachment: svnstat-classinfixture.txt classinfixture_Aug182011.txt Attaching the patch Change derby.tests.trace to print the class as well as fixture name --- Key: DERBY-5300 URL: https://issues.apache.org/jira/browse/DERBY-5300 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.9.0.0 Reporter: Kathey Marsden Assignee: Jayaram Subramanian Priority: Trivial Attachments: classinfixture_Aug182011.txt, derby-5300-1a-print_jdbc_client.diff, svnstat-classinfixture.txt I was thinking it would be good for the test output with -Dderby.tests.trace=true to have the class name as well as the fixture as I think if I had a nickel for every time I grepped for a fixture name to find out what class it is in, I would have a pretty big piggy bank. It could print the full class name, like this: org.apache.derbyTesting.functionTests.tests.lang.SimpleTest.testBasicOperations used 844 ms . or strip off the org.apache.derbyTesting.functionTests for less output like: tests.lang.SimpleTest.testBugFixes used 6265 ms . Any preferences? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DERBY-5300) Change derby.tests.trace to print the class as well as fixture name
[ https://issues.apache.org/jira/browse/DERBY-5300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jayaram Subramanian updated DERBY-5300: --- Issue fix info: [Newcomer, Patch Available] (was: [Newcomer]) Change derby.tests.trace to print the class as well as fixture name --- Key: DERBY-5300 URL: https://issues.apache.org/jira/browse/DERBY-5300 Project: Derby Issue Type: Improvement Components: Test Affects Versions: 10.9.0.0 Reporter: Kathey Marsden Assignee: Jayaram Subramanian Priority: Trivial Attachments: classinfixture_Aug182011.txt, derby-5300-1a-print_jdbc_client.diff, svnstat-classinfixture.txt I was thinking it would be good for the test output with -Dderby.tests.trace=true to have the class name as well as the fixture as I think if I had a nickel for every time I grepped for a fixture name to find out what class it is in, I would have a pretty big piggy bank. It could print the full class name, like this: org.apache.derbyTesting.functionTests.tests.lang.SimpleTest.testBasicOperations used 844 ms . or strip off the org.apache.derbyTesting.functionTests for less output like: tests.lang.SimpleTest.testBugFixes used 6265 ms . Any preferences? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DERBY-5359) Missing xmlns attribute for html element in docs
[ https://issues.apache.org/jira/browse/DERBY-5359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13088115#comment-13088115 ] Jayaram Subramanian commented on DERBY-5359: Hi Knut I am interested in taking up this task.. Is that fine and kindly direct me on where to start off here. Missing xmlns attribute for html element in docs Key: DERBY-5359 URL: https://issues.apache.org/jira/browse/DERBY-5359 Project: Derby Issue Type: Bug Components: Documentation Affects Versions: 10.9.0.0 Reporter: Knut Anders Hatlen The html files in the documentation that are declared as XHTML don't pass as valid XHTML because the html elements lack the xmlns attribute. Examples: http://db.apache.org/derby/docs/dev/ref/index.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Findex.html http://db.apache.org/derby/docs/dev/ref/toc.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Ftoc.html http://db.apache.org/derby/docs/dev/ref/rrefcallprocedure.html -- http://validator.w3.org/check?uri=http%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2Fdev%2Fref%2Frrefcallprocedure.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
