Uploaded image for project: 'Derby'
  1. Derby
  2. DERBY-1272

Change sysinfo to print to error log (derby.log) on boot of derby if derby.stream.error.logSeverityLevel=0

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Won't Fix
    • Affects Version/s: 10.1.2.1, 10.1.3.1, 10.2.1.6
    • Fix Version/s: None
    • Component/s: Tools
    • Labels:
      None

      Description

      It is often very difficult to collect correct sysinfo output from user environments because sysinfo run from the commandline does not have the same classpath as the jvm that started Derby or Derby was loaded with a custom classloader.

      It would be very helpful in assisting users in diagnosing their issues if sysinfo dumped to the error log if derby.stream.error.logSeverityLevel=0 or even by default.

      1. derby-1272-pre.diff
        1 kB
        Andrew McIntyre
      2. derby-1272-pre2.diff
        6 kB
        Andrew McIntyre
      3. derby-1272-pre3.diff
        2 kB
        Andrew McIntyre
      4. derby-1272-v4.diff
        4 kB
        Andrew McIntyre
      5. DERBY-1272v5.diff
        2 kB
        Ramin Moazeni
      6. DERBY-1272v6.diff
        10 kB
        Ramin Moazeni
      7. DERBY-1272v6.stat
        0.4 kB
        Ramin Moazeni
      8. DERBY-1272v8.diff
        5 kB
        Ramin Moazeni

        Issue Links

          Activity

          Hide
          fuzzylogic Andrew McIntyre added a comment -

          Q-n-D patch for this. Would love to get some feedback on whether this is acceptable and the right place for this or if I should investigate something more involved.

          Show
          fuzzylogic Andrew McIntyre added a comment - Q-n-D patch for this. Would love to get some feedback on whether this is acceptable and the right place for this or if I should investigate something more involved.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          Questions from Kathey Marsden on IRC: I have to go but I looked at the patch briefly. 1)I need to look at all the tmpWriter stuff and see what that is about. 2) Might there be any potential issues with security excceptions or is that all cleared up now? 3) l ike that it will always dump for a sane build. 4) A few comments and using a constant for if (logSeverityLevel == 0) would be nice.

          1 - tmpWriter is our output PrintWriter before we've started InfoStreams. If there's a catastrophic error, we end up writing to the tempWriter instead of the nicely formatted InfoStream. (tempWriter essentially == PrintWriter logging)

          2 - I'm a little concerned about getting derby.stream.error.logSeverityLevel, but I suppose if you can't get derby.* system props, you're in big trouble anyway. Sysinfo catches and deals with all security exceptions properly, even for an empty policy file (most restricted environment), so the call to sysinfo shouldn't be a problem.

          3 - yes, convenient. Before this is ready for submission, i need to make sure all tests pass in both sane and insane builds, although I suspect that we don't actually have a test that depends specifically on the output of the log file.

          4 - I'll beef up the comments before the final. I think the most important part is explaining why we need to use the tempWriter PrintStream if systemStreams is null. (the answer is because if there's a catastrophic error and InfoStreams won't start, we need that sysinfo output somewhere)

          4b - I can use ExceptionSeverity.NO_APPLICABLE_SEVERITY here, but is that more confusing than just 0 here, or not?

          response from kmarsden - Thanks Andrew, I agree that NO_APPLICABLE_SEVERITY is more confusing. Just a comment along with the hard coded 0 would be fine.

          Show
          fuzzylogic Andrew McIntyre added a comment - Questions from Kathey Marsden on IRC: I have to go but I looked at the patch briefly. 1)I need to look at all the tmpWriter stuff and see what that is about. 2) Might there be any potential issues with security excceptions or is that all cleared up now? 3) l ike that it will always dump for a sane build. 4) A few comments and using a constant for if (logSeverityLevel == 0) would be nice. 1 - tmpWriter is our output PrintWriter before we've started InfoStreams. If there's a catastrophic error, we end up writing to the tempWriter instead of the nicely formatted InfoStream. (tempWriter essentially == PrintWriter logging) 2 - I'm a little concerned about getting derby.stream.error.logSeverityLevel, but I suppose if you can't get derby.* system props, you're in big trouble anyway. Sysinfo catches and deals with all security exceptions properly, even for an empty policy file (most restricted environment), so the call to sysinfo shouldn't be a problem. 3 - yes, convenient. Before this is ready for submission, i need to make sure all tests pass in both sane and insane builds, although I suspect that we don't actually have a test that depends specifically on the output of the log file. 4 - I'll beef up the comments before the final. I think the most important part is explaining why we need to use the tempWriter PrintStream if systemStreams is null. (the answer is because if there's a catastrophic error and InfoStreams won't start, we need that sysinfo output somewhere) 4b - I can use ExceptionSeverity.NO_APPLICABLE_SEVERITY here, but is that more confusing than just 0 here, or not? response from kmarsden - Thanks Andrew, I agree that NO_APPLICABLE_SEVERITY is more confusing. Just a comment along with the hard coded 0 would be fine.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          Updated patch that includes tools src dir in sourcepath for impl/services so that it builds correctly on a clobber and rebuild. Needs to side-compile sysinfo, should be ok, since this is a source=1.3 compile.

          Show
          fuzzylogic Andrew McIntyre added a comment - Updated patch that includes tools src dir in sourcepath for impl/services so that it builds correctly on a clobber and rebuild. Needs to side-compile sysinfo, should be ok, since this is a source=1.3 compile.
          Hide
          kmarsden Kathey Marsden added a comment -

          Is it ok to go ahead and mark this issue as patch available? It would be good to get input from those familiar with the Monitor and add this for 10.2 if possible. So often it is difficult to get correct sysinfo output because it is generated from the command line outside of the calling context. This would be a very valuable addition.

          Show
          kmarsden Kathey Marsden added a comment - Is it ok to go ahead and mark this issue as patch available? It would be good to get input from those familiar with the Monitor and add this for 10.2 if possible. So often it is difficult to get correct sysinfo output because it is generated from the command line outside of the calling context. This would be a very valuable addition.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          Attached patch -pre3. Disregard -pre2 patch, which got mixed up with the patch currently attached to 1273.

          Show
          fuzzylogic Andrew McIntyre added a comment - Attached patch -pre3. Disregard -pre2 patch, which got mixed up with the patch currently attached to 1273.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          After a brief discussion with Kathey on iRC, I think the -pre3 patch can be committed if no one sees any potential problems with this approach.

          I guess my initial concern was that this introduces a dependency on tools code, specifically sysinfo, into the engine. However, since we package sysinfo into derby.jar, this may not actually be a concern at all.

          Show
          fuzzylogic Andrew McIntyre added a comment - After a brief discussion with Kathey on iRC, I think the -pre3 patch can be committed if no one sees any potential problems with this approach. I guess my initial concern was that this introduces a dependency on tools code, specifically sysinfo, into the engine. However, since we package sysinfo into derby.jar, this may not actually be a concern at all.
          Hide
          kmarsden Kathey Marsden added a comment -

          Thanks Andrew for this great addition it will surely save many round trips trying to get accurate sysinfo information.

          I applied the pre3 patch and noticed the following:

          1) After ant clobber, I built and got:
          compile_types:
          [javac] Compiling 1 source file to C:\p4\marsden_patch\classes
          [javac] C:\p4\marsden_patch\opensource\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1949: package org.apache.derby.tools does not exist
          [javac] org.apache.derby.tools.sysinfo.getInfo(systemStreams.stream().getPrintWriter());
          [javac] ^
          [javac] C:\p4\marsden_patch\opensource\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1951: package org.apache.derby.tools does not exist
          [javac] org.apache.derby.tools.sysinfo.getInfo(getTempWriter());
          [javac] ^
          [javac] 2 errors

          BUILD FAILED

          2)
          I forced the build and tried the patch with derby.stream.error.logSeverityLevel=0 and the sysinfo in the derby.log seemed to work great. I put it in one of the test derby.properties files to make sure it ran ok with security manager and that worked ok too. It would be good to have this turned on for one of the tests just to make sure security manager issues don't creep in.

          3)
          I also tried it without the property and sysinfo still printed to the log, which is really fine by me as it will save that initial round trip of setting the property, but I don't know how others feel about it.

          4) Just a minor nit I think it would be good if the sysinfo printed after the boot message but as it is fine by me too.

          Thanks again

          Kathey

          Show
          kmarsden Kathey Marsden added a comment - Thanks Andrew for this great addition it will surely save many round trips trying to get accurate sysinfo information. I applied the pre3 patch and noticed the following: 1) After ant clobber, I built and got: compile_types: [javac] Compiling 1 source file to C:\p4\marsden_patch\classes [javac] C:\p4\marsden_patch\opensource\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1949: package org.apache.derby.tools does not exist [javac] org.apache.derby.tools.sysinfo.getInfo(systemStreams.stream().getPrintWriter()); [javac] ^ [javac] C:\p4\marsden_patch\opensource\java\engine\org\apache\derby\impl\services\monitor\BaseMonitor.java:1951: package org.apache.derby.tools does not exist [javac] org.apache.derby.tools.sysinfo.getInfo(getTempWriter()); [javac] ^ [javac] 2 errors BUILD FAILED 2) I forced the build and tried the patch with derby.stream.error.logSeverityLevel=0 and the sysinfo in the derby.log seemed to work great. I put it in one of the test derby.properties files to make sure it ran ok with security manager and that worked ok too. It would be good to have this turned on for one of the tests just to make sure security manager issues don't creep in. 3) I also tried it without the property and sysinfo still printed to the log, which is really fine by me as it will save that initial round trip of setting the property, but I don't know how others feel about it. 4) Just a minor nit I think it would be good if the sysinfo printed after the boot message but as it is fine by me too. Thanks again Kathey
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          1) Are you sure you grabbed the right patch? The build.xml change in the -pre3 patch (which was absent from the -pre1 patch) should have taken care of the problem in #1. Check that your java/engine/org/apache/derby/impl/services/build.xml has been modified to include $

          {derby.tools.src.dir}

          in the srcdir for the compile. If you do have this change in the build.xml, and are still getting this problem, I'll take another look.

          2) a good idea. But then see also #3. I'm not sure how often tests are being run with sane builds, if at all, though.

          3) as it is, sysinfo will always be printed in sane builds, so maybe you were running with a sane build? you liked this aspect of the patch last time you looked at it.

          4) While that would be nice, the reason that I put it where it is in the code is that sysinfo will still be dumped to derby.log even if the engine fails to boot due to some catastrophic error. I'm not sure if it is worth the effort to delay printing sysinfo until after the boot message has printed in order to get pretty formatting for something that is meant to be a diagnostic for serious failures.

          Show
          fuzzylogic Andrew McIntyre added a comment - 1) Are you sure you grabbed the right patch? The build.xml change in the -pre3 patch (which was absent from the -pre1 patch) should have taken care of the problem in #1. Check that your java/engine/org/apache/derby/impl/services/build.xml has been modified to include $ {derby.tools.src.dir} in the srcdir for the compile. If you do have this change in the build.xml, and are still getting this problem, I'll take another look. 2) a good idea. But then see also #3. I'm not sure how often tests are being run with sane builds, if at all, though. 3) as it is, sysinfo will always be printed in sane builds, so maybe you were running with a sane build? you liked this aspect of the patch last time you looked at it. 4) While that would be nice, the reason that I put it where it is in the code is that sysinfo will still be dumped to derby.log even if the engine fails to boot due to some catastrophic error. I'm not sure if it is worth the effort to delay printing sysinfo until after the boot message has printed in order to get pretty formatting for something that is meant to be a diagnostic for serious failures.
          Hide
          kmarsden Kathey Marsden added a comment -

          1) regarding build error
          Andrew said.
          >Check that your java/engine/org/apache/derby/impl/services/build.xml has been modified to include $

          {derby.tools.src.dir}

          in the srcdir for the compile

          Yes I do seem to have this part of the patch and tried clobber and build again and seem to get the same error.

          2) Regarding testing
          Andrew said
          > I'm not sure how often tests are being run with sane builds, if at all, though.
          It should be testable with an insane build if derby.stream.error.logSeverityLevel=0 in one of the <test>_derby.properties files would be good. Perhaps lang/errorStream test would be a good location but perhaps not critical as this is diagnostic info.

          3) Regarding printing regardless of derby.stream.error.logSeverityLevel=0 with sane build.
          My bad. Too long between looking at the patch and trying it #.. I verified it does not print if logSeverityLevel is the default with an insane build

          4) Regarding aesthetic positioning. Your reasoning makes perfect sense to me.

          Short story for me is that it all looks good except for the build error. However I am not so familiar with the Monitor and may not understand the implications especially if sysinfo fails for some reason,what the affect if any there might be on the server coming up, so it would be great to see someone else review the code change with the next patch.

          Show
          kmarsden Kathey Marsden added a comment - 1) regarding build error Andrew said. >Check that your java/engine/org/apache/derby/impl/services/build.xml has been modified to include $ {derby.tools.src.dir} in the srcdir for the compile Yes I do seem to have this part of the patch and tried clobber and build again and seem to get the same error. 2) Regarding testing Andrew said > I'm not sure how often tests are being run with sane builds, if at all, though. It should be testable with an insane build if derby.stream.error.logSeverityLevel=0 in one of the <test>_derby.properties files would be good. Perhaps lang/errorStream test would be a good location but perhaps not critical as this is diagnostic info. 3) Regarding printing regardless of derby.stream.error.logSeverityLevel=0 with sane build. My bad. Too long between looking at the patch and trying it # .. I verified it does not print if logSeverityLevel is the default with an insane build 4) Regarding aesthetic positioning. Your reasoning makes perfect sense to me. Short story for me is that it all looks good except for the build error. However I am not so familiar with the Monitor and may not understand the implications especially if sysinfo fails for some reason,what the affect if any there might be on the server coming up, so it would be great to see someone else review the code change with the next patch.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          I've svn up'd and now I'm seeing this problem too, with the build failing in iapi/types/build.xml with the patch applied.

          This may have uncovered a potential problem, in that something in iapi/types eventually has a dependency on BaseMonitor, which lives in impl. I'm not sure whether or not this is a serious problem, but I thought the iapi classes were not supposed to have dependencies on classes in impl.

          Show
          fuzzylogic Andrew McIntyre added a comment - I've svn up'd and now I'm seeing this problem too, with the build failing in iapi/types/build.xml with the patch applied. This may have uncovered a potential problem, in that something in iapi/types eventually has a dependency on BaseMonitor, which lives in impl. I'm not sure whether or not this is a serious problem, but I thought the iapi classes were not supposed to have dependencies on classes in impl.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          Attaching updated patch which resolves the build failure noted in the previous comments and adds setting logSeverityLevel=0 to the errorStream test as suggested by Kathey.

          Show
          fuzzylogic Andrew McIntyre added a comment - Attaching updated patch which resolves the build failure noted in the previous comments and adds setting logSeverityLevel=0 to the errorStream test as suggested by Kathey.
          Hide
          kmarsden Kathey Marsden added a comment -

          I get this with errorStream.java with insane build. Testing with classes and derby.stream.error.logSeverityLevel=0

          > Test errorStream failed: access denied (java.io.FilePermission C:\p4\marsden_patch\classes read)
          Test Failed.

              • End: errorStream jdk1.4.2_07 2006-07-07 22:06:41 **

          I am not getting a trace in the tmp file.

          Show
          kmarsden Kathey Marsden added a comment - I get this with errorStream.java with insane build. Testing with classes and derby.stream.error.logSeverityLevel=0 > Test errorStream failed: access denied (java.io.FilePermission C:\p4\marsden_patch\classes read) Test Failed. End: errorStream jdk1.4.2_07 2006-07-07 22:06:41 ** I am not getting a trace in the tmp file.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          This passes on my Mac OS X box, with either sane or insane. About which, btw, I'm very confused.

          On Windows XP, it fails with the error you described. Based on the output, the failure is actually in errorStream/VombatusUrsinusHirsitus-err-4.log, and the log there provides a stack trace with the actual SecurityException.

          So, an excellent choice of test for this, although I'm a bit confused with the test results I have currently. Clearly some more investigation is required.

          Thanks for trying out the patch, Kathey. I think this has exposed a security manager issue that needs to be cleaned up inside of sysinfo.

          Show
          fuzzylogic Andrew McIntyre added a comment - This passes on my Mac OS X box, with either sane or insane. About which, btw, I'm very confused. On Windows XP, it fails with the error you described. Based on the output, the failure is actually in errorStream/VombatusUrsinusHirsitus-err-4.log, and the log there provides a stack trace with the actual SecurityException. So, an excellent choice of test for this, although I'm a bit confused with the test results I have currently. Clearly some more investigation is required. Thanks for trying out the patch, Kathey. I think this has exposed a security manager issue that needs to be cleaned up inside of sysinfo.
          Hide
          fuzzylogic Andrew McIntyre added a comment -

          Here's the full stack for the SecurityException found by the errorStream test with the -v4 patch applied:

          Test errorStream failed: access denied (java.io.FilePermission C:\derby-trunk\classes read)
          at java.security.AccessController.checkPermission(AccessController.java:401)
          at java.lang.SecurityManager.checkPermission(SecurityManager.java:524)
          at java.lang.SecurityManager.checkRead(SecurityManager.java:863)
          at java.io.File.exists(File.java:678)
          at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:360)
          at java.io.File.getCanonicalPath(File.java:513)
          at org.apache.derby.impl.tools.sysinfo.Main.formatURL(Main.java:1206)
          at org.apache.derby.impl.tools.sysinfo.Main.loadZipFromResource(Main.java:831)
          at org.apache.derby.impl.tools.sysinfo.Main.getAllInfo(Main.java:735)
          at org.apache.derby.impl.tools.sysinfo.Main.reportDerby(Main.java:212)
          at org.apache.derby.impl.tools.sysinfo.Main.getMainInfo(Main.java:119)
          at org.apache.derby.tools.sysinfo.getInfo(sysinfo.java:200)
          at org.apache.derby.impl.services.monitor.BaseMonitor.dumpTempWriter(BaseMonitor.java:1949)
          at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:383)
          at org.apache.derby.impl.services.monitor.FileMonitor.<init>(FileMonitor.java:59)
          at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:288)
          at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:68)
          at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:178)

          Show
          fuzzylogic Andrew McIntyre added a comment - Here's the full stack for the SecurityException found by the errorStream test with the -v4 patch applied: Test errorStream failed: access denied (java.io.FilePermission C:\derby-trunk\classes read) at java.security.AccessController.checkPermission(AccessController.java:401) at java.lang.SecurityManager.checkPermission(SecurityManager.java:524) at java.lang.SecurityManager.checkRead(SecurityManager.java:863) at java.io.File.exists(File.java:678) at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:360) at java.io.File.getCanonicalPath(File.java:513) at org.apache.derby.impl.tools.sysinfo.Main.formatURL(Main.java:1206) at org.apache.derby.impl.tools.sysinfo.Main.loadZipFromResource(Main.java:831) at org.apache.derby.impl.tools.sysinfo.Main.getAllInfo(Main.java:735) at org.apache.derby.impl.tools.sysinfo.Main.reportDerby(Main.java:212) at org.apache.derby.impl.tools.sysinfo.Main.getMainInfo(Main.java:119) at org.apache.derby.tools.sysinfo.getInfo(sysinfo.java:200) at org.apache.derby.impl.services.monitor.BaseMonitor.dumpTempWriter(BaseMonitor.java:1949) at org.apache.derby.impl.services.monitor.BaseMonitor.runWithState(BaseMonitor.java:383) at org.apache.derby.impl.services.monitor.FileMonitor.<init>(FileMonitor.java:59) at org.apache.derby.iapi.services.monitor.Monitor.startMonitor(Monitor.java:288) at org.apache.derby.iapi.jdbc.JDBCBoot.boot(JDBCBoot.java:68) at org.apache.derby.jdbc.EmbeddedDriver.boot(EmbeddedDriver.java:178)
          Hide
          kmarsden Kathey Marsden added a comment -

          Unchecking patch available as more investigation is needed for the security manager issue with sysinfo printing to derby.log. It may be a generic security manager issue with sysinfo that requires another Jira entry.

          Andrew are you actively working on this issue? I noticed it was unassigned. It would be a huge supportability improvement for 10.2 if it can get in.

          Show
          kmarsden Kathey Marsden added a comment - Unchecking patch available as more investigation is needed for the security manager issue with sysinfo printing to derby.log. It may be a generic security manager issue with sysinfo that requires another Jira entry. Andrew are you actively working on this issue? I noticed it was unassigned. It would be a huge supportability improvement for 10.2 if it can get in.
          Hide
          moazeni Ramin Moazeni added a comment -

          Attaching a new patch built on top of the latest trunk.
          Please note that I added the $

          {derby.tools.src.dir}

          to the
          java/engine/org/apache/derby/iapi/build.xml to get the src to compile instead of
          java/engine/org/apache/derby/impl/services/build.xml and
          java/engine/org/apache/derby/iapi/types/build.xml since I was still
          getting the following errors:
          [javac] Found 2 semantic errors compiling "/home/ramin/opensource/derby/trunk/java/engine/org/apache/derby/impl/services/monitor/BaseMonitor.java":

          [javac] 1945. org.apache.derby.tools.sysinfo.getInfo(systemStreams.stream().getPrintWriter());
          [javac] --------------------
          [javac] *** Semantic Error: "tools" is either a misplaced package name or a non-existent entity. An expression name is expected in this context.

          [javac] 1947. org.apache.derby.tools.sysinfo.getInfo(getTempWriter());
          [javac] --------------------
          [javac] *** Semantic Error: "tools" is either a misplaced package name or a non-existent entity. An expression name is expected in this context.

          With the v5 patch, I am not able to reproduce this issue on Linux and WinXP. I ran the test using
          classes and jars, sane and insane and they all completed successfully without any errors.

          I appreciate your feedback.

          Thanks
          Ramin

          Show
          moazeni Ramin Moazeni added a comment - Attaching a new patch built on top of the latest trunk. Please note that I added the $ {derby.tools.src.dir} to the java/engine/org/apache/derby/iapi/build.xml to get the src to compile instead of java/engine/org/apache/derby/impl/services/build.xml and java/engine/org/apache/derby/iapi/types/build.xml since I was still getting the following errors: [javac] Found 2 semantic errors compiling "/home/ramin/opensource/derby/trunk/java/engine/org/apache/derby/impl/services/monitor/BaseMonitor.java": [javac] 1945. org.apache.derby.tools.sysinfo.getInfo(systemStreams.stream().getPrintWriter()); [javac] -------------------- [javac] *** Semantic Error: "tools" is either a misplaced package name or a non-existent entity. An expression name is expected in this context. [javac] 1947. org.apache.derby.tools.sysinfo.getInfo(getTempWriter()); [javac] -------------------- [javac] *** Semantic Error: "tools" is either a misplaced package name or a non-existent entity. An expression name is expected in this context. With the v5 patch, I am not able to reproduce this issue on Linux and WinXP. I ran the test using classes and jars, sane and insane and they all completed successfully without any errors. I appreciate your feedback. Thanks Ramin
          Hide
          kmarsden Kathey Marsden added a comment - - edited

          Hi Ramin,

          Thanks for bringing this issue back to life. It will surely be very helpful to users and support folks. I looked at the patch and tried it out and it all seemed to work fine. A few comments.

          • I am concerned about adding $derby.tools.src.dir to the build.xml. Sysinfo is available in derby.jar, but the other tools classes are not. Adding derby.tools.src.dir allows access to all the tools classes, which is not ideal. I wonder if using reflection can avoid the need to change the build.xml.
          • Sysinfo prints security exceptions for information it can't access. e.g.
            Java user name: Security Exception: java.security.AccessControlException: Access denied (java.util.PropertyPermission user.name read)

          I am concerned that this might become a red herring for those debugging a problem and thinking this might be the root of it. DERBY-1273 is filed to improve the message though and I think we can handle that as a separate issue. I asked for some feedback from some support people to get an additional opinion. I'll let you know what I hear.

          • The test doesn't seem to actually test that sysinfo printed. It would be good to have a test that tests that.

          Kathey

          Show
          kmarsden Kathey Marsden added a comment - - edited Hi Ramin, Thanks for bringing this issue back to life. It will surely be very helpful to users and support folks. I looked at the patch and tried it out and it all seemed to work fine. A few comments. I am concerned about adding $derby.tools.src.dir to the build.xml. Sysinfo is available in derby.jar, but the other tools classes are not. Adding derby.tools.src.dir allows access to all the tools classes, which is not ideal. I wonder if using reflection can avoid the need to change the build.xml. Sysinfo prints security exceptions for information it can't access. e.g. Java user name: Security Exception: java.security.AccessControlException: Access denied (java.util.PropertyPermission user.name read) I am concerned that this might become a red herring for those debugging a problem and thinking this might be the root of it. DERBY-1273 is filed to improve the message though and I think we can handle that as a separate issue. I asked for some feedback from some support people to get an additional opinion. I'll let you know what I hear. The test doesn't seem to actually test that sysinfo printed. It would be good to have a test that tests that. Kathey
          Hide
          kmarsden Kathey Marsden added a comment -

          This is the feedback I got from support
          >How hard would it be to catch the exceptions: java.security.AccessControlException
          >and replace the exception with a static message like: 'Security Manager does not >permit reading java.util.PropertyPermission' ??
          >This will be less likely to raise any concerns.

          I think that this is the same as DERBY-1273 and I think is a good idea, but I think it could go in after the patch for DERBY-1272.

          Show
          kmarsden Kathey Marsden added a comment - This is the feedback I got from support >How hard would it be to catch the exceptions: java.security.AccessControlException >and replace the exception with a static message like: 'Security Manager does not >permit reading java.util.PropertyPermission' ?? >This will be less likely to raise any concerns. I think that this is the same as DERBY-1273 and I think is a good idea, but I think it could go in after the patch for DERBY-1272 .
          Hide
          kmarsden Kathey Marsden added a comment -

          I think just changing the build.xml as follows will restrict the access to sysinfo
          srcdir="$

          {derby.engine.src.dir}

          ;$

          {derby.tools.src.dir}

          /org/apache/derby/impl/tools/sysinfo"

          I think we should go ahead and check in this change even though the sysinfo output for the security exceptions is not ideal. That can be handled separately as DERBY-1273

          Any objections to checking in this change?

          Kathey

          Show
          kmarsden Kathey Marsden added a comment - I think just changing the build.xml as follows will restrict the access to sysinfo srcdir="$ {derby.engine.src.dir} ;$ {derby.tools.src.dir} /org/apache/derby/impl/tools/sysinfo" I think we should go ahead and check in this change even though the sysinfo output for the security exceptions is not ideal. That can be handled separately as DERBY-1273 Any objections to checking in this change? Kathey
          Hide
          moazeni Ramin Moazeni added a comment -

          In writing test for Derby-1272, the main issue that I have is, the sysinfo
          output is dependent on the platform that is being run. For example,
          Java version, home, classpath, etc can all be different on different
          platforms. I can keep a sysinfo output and save it in functionTests/master
          directory, but this makes writing the test hard since I cannot easily compare the
          entries with the master (canon) file. Do you have any suggestion on
          how to proceed here?

          Show
          moazeni Ramin Moazeni added a comment - In writing test for Derby-1272, the main issue that I have is, the sysinfo output is dependent on the platform that is being run. For example, Java version, home, classpath, etc can all be different on different platforms. I can keep a sysinfo output and save it in functionTests/master directory, but this makes writing the test hard since I cannot easily compare the entries with the master (canon) file. Do you have any suggestion on how to proceed here?
          Hide
          kmarsden Kathey Marsden added a comment -

          Is there some check that we can do just to see if sysinfo prints without trying to compare the full output?

          Show
          kmarsden Kathey Marsden added a comment - Is there some check that we can do just to see if sysinfo prints without trying to compare the full output?
          Hide
          moazeni Ramin Moazeni added a comment -

          Hello,

          I am attaching the v6 patch with this issue.
          I appreciate your review/comments.

          For testing this issue, I added a test for this issue to tools/DerbyLogTest.java.
          Please note that by using
          srcdir="$

          {derby.engine.src.dir}

          ;$

          {derby.tools.src.dir}

          /org/apache/derby/impl/tools/sysinfo"
          I still got errors during build.

          I got errors during suites.All while running this test which was resolved by
          changing the order of the junit tests. I will file a separate jira issue for
          that.

          Thanks
          Ramin Moazeni

          Show
          moazeni Ramin Moazeni added a comment - Hello, I am attaching the v6 patch with this issue. I appreciate your review/comments. For testing this issue, I added a test for this issue to tools/DerbyLogTest.java. Please note that by using srcdir="$ {derby.engine.src.dir} ;$ {derby.tools.src.dir} /org/apache/derby/impl/tools/sysinfo" I still got errors during build. I got errors during suites.All while running this test which was resolved by changing the order of the junit tests. I will file a separate jira issue for that. Thanks Ramin Moazeni
          Hide
          kmarsden Kathey Marsden added a comment -

          What were the problems you were having with the test order?

          Show
          kmarsden Kathey Marsden added a comment - What were the problems you were having with the test order?
          Hide
          moazeni Ramin Moazeni added a comment -

          I was getting the following error which indicates that the derby.stream.error.logSeverityLevel property
          has not been set to 0. When I ran the test individually or _Suite, the test(s) completed successfully.
          Therefore, I changed the test order and got a successful run.

          There were 2 failures:
          1) testDerbyLog(org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest)junit.framework.ComparisonFailure: expected:<------------------ Java Information ------------------> but was:<java.sql.SQLException: Database 'wombat' not found.>
          at org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest.testDerbyLog(DerbyLogTest.java:110)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
          2) testDerbyLog(org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest)junit.framework.ComparisonFailure: expected:<------------------ Java Information ------------------> but was:<java.sql.SQLException: Database 'wombat' not found.>
          at org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest.testDerbyLog(DerbyLogTest.java:110)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)

          FAILURES!!!
          Tests run: 74, Failures: 2, Errors: 0

          Show
          moazeni Ramin Moazeni added a comment - I was getting the following error which indicates that the derby.stream.error.logSeverityLevel property has not been set to 0. When I ran the test individually or _Suite, the test(s) completed successfully. Therefore, I changed the test order and got a successful run. There were 2 failures: 1) testDerbyLog(org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest)junit.framework.ComparisonFailure: expected:<------------------ Java Information ------------------> but was:<java.sql.SQLException: Database 'wombat' not found.> at org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest.testDerbyLog(DerbyLogTest.java:110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) 2) testDerbyLog(org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest)junit.framework.ComparisonFailure: expected:<------------------ Java Information ------------------> but was:<java.sql.SQLException: Database 'wombat' not found.> at org.apache.derbyTesting.functionTests.tests.tools.DerbyLogTest.testDerbyLog(DerbyLogTest.java:110) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) FAILURES!!! Tests run: 74, Failures: 2, Errors: 0
          Hide
          kmarsden Kathey Marsden added a comment -

          Is the issue perhaps be that previous tests have written to the log. If you look at derby.log directly does it perhaps have the sysinfo but later in the file? If that is the case, perhaps setting derby.infolog.append=false would clean up the log before starting.

          Show
          kmarsden Kathey Marsden added a comment - Is the issue perhaps be that previous tests have written to the log. If you look at derby.log directly does it perhaps have the sysinfo but later in the file? If that is the case, perhaps setting derby.infolog.append=false would clean up the log before starting.
          Hide
          kmarsden Kathey Marsden added a comment -

          I backed out the change, because it was causing errors starting Derby wtih classes. In addition to resolving whatever problem is causing sysinfo to fail, we should probably update the patch so that errors running sysinfo are only logged and cannot cause the server to fail to boot.

          Show
          kmarsden Kathey Marsden added a comment - I backed out the change, because it was causing errors starting Derby wtih classes. In addition to resolving whatever problem is causing sysinfo to fail, we should probably update the patch so that errors running sysinfo are only logged and cannot cause the server to fail to boot.
          Hide
          moazeni Ramin Moazeni added a comment -

          Hi Kathey

          I am not able to reproduce this problem with sane=true
          in ant.properties. I am attaching another patch with this
          issue. Can you please try this and let me know if you can
          reproduce the problem?

          Thanks
          Ramin

          Show
          moazeni Ramin Moazeni added a comment - Hi Kathey I am not able to reproduce this problem with sane=true in ant.properties. I am attaching another patch with this issue. Can you please try this and let me know if you can reproduce the problem? Thanks Ramin
          Hide
          kmarsden Kathey Marsden added a comment -

          Hi Ramin,

          Thank you for your continued work on this patch. With the patch I do not see the initializer error pointing my classpath to the classes directory, but I don't really understand how your changes sought to fix it. Could you explain.

          Running lang/triggerGeneral.sql I see a JVM crash with both IBM 1.5 and Sun 1.6 JDK's. The problem seems to arise from the fact that sysinfo registers the JCC driver in the following code in
          package org.apache.derby.impl.tools.sysinfo.Main.checkFile(String filename)

          { c = Class.forName("com.ibm.db2.jcc.DB2Driver"); m = c.getMethod("getJCCBuildNumber", null); o = c.newInstance(); build = (Integer)m.invoke(o,null); } }

          catch (ClassNotFoundException cnfe)

          { c = Class.forName("com.ibm.db2.jcc.DB2Version"); m = c.getMethod("getBuildNumber", null); o = c.newInstance(); build = (Integer)m.invoke(o,null); }

          Then there seems to be some bug in JCC that we are getting the T2 driver for
          jdbc:default:connection. But it seems like a bad side effect of sysinfo that the JCC Driver is getting loaded. I think it would be acceptable for sysinfo to just use
          com.ibm.db2.jcc.DB2Version.getBuildNumber.

          Here is the thread that fails.

          NULL ----------------------
          3XMTHREADINFO "main" (TID:0x41431300, sys_thread_t:0x000382D8, state:R, native ID:0x000012E0) prio=5
          4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.DBConnect(Native Method)
          4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.a(UWConnection.java:673)
          4XESTACKTRACE at com/ibm/db2/jcc/uw/f.b(f.java:254)
          4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.a(UWConnection.java:610)
          4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.b(UWConnection.java:463)
          4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.<init>(UWConnection.java:255)
          4XESTACKTRACE at com/ibm/db2/jcc/DB2Driver.connect(DB2Driver.java:236)
          4XESTACKTRACE at java/sql/DriverManager.getConnection(DriverManager.java:562)
          4XESTACKTRACE at java/sql/DriverManager.getConnection(DriverManager.java:208)
          4XESTACKTRACE at org/apache/derbyTesting/functionTests/tests/lang/userDefMethods.derby388(userDefMethods.java:89)
          4XESTACKTRACE at org/apache/derby/exe/ac12564092x0116xa132x1d95xffffa334cdd074.g0(Bytecode PC:36)
          4XESTACKTRACE at sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method)
          4XESTACKTRACE at sun/reflect/NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64(Compiled Code))
          4XESTACKTRACE at sun/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43(Compiled Code))
          4XESTACKTRACE at java/lang/reflect/Method.invoke(Method.java:615(Compiled Code))
          4XESTACKTRACE at org/apache/derby/impl/services/reflect/ReflectMethod.invoke(ReflectMethod.java:46)
          4XESTACKTRACE at org/apache/derby/impl/sql/execute/CallStatementResultSet.open(CallStatementResultSet.java:57)
          4XESTACKTRACE at org/apache/derby/impl/sql/GenericPreparedStatement.execute(GenericPreparedStatement.java:370(Compiled Code))
          4XESTACKTRACE at org/apache/derby/impl/jdbc/EmbedStatement.executeStatement(EmbedStatement.java:1228)
          4XESTACKTRACE at org/apache/derby/impl/jdbc/EmbedStatement.execute(EmbedStatement.java:618)
          4XESTACKTRACE at org/apache/derby/impl/jdbc/EmbedStatement.execute(EmbedStatement.java:550)
          4XESTACKTRACE at org/apache/derby/impl/tools/ij/ij.executeImmediate(ij.java:330(Compiled Code))
          4XESTACKTRACE at org/apache/derby/impl/tools/ij/utilMain.doCatch(utilMain.java:508)
          4XESTACKTRACE at org/apache/derby/impl/tools/ij/utilMain.runScriptGuts(utilMain.java:350)
          4XESTACKTRACE at org/apache/derby/impl/tools/ij/utilMain.go(utilMain.java:248)
          4XESTACKTRACE at org/apache/derby/impl/tools/ij/Main.go(Main.java:215)
          4XESTACKTRACE at org/apache/derby/impl/tools/ij/Main.mainCore(Main.java:181)
          4XESTACKTRACE at org/apache/derby/impl/tools/ij/Main.main(Main.java:73)
          4XESTACKTRACE at org/apache/derby/tools/ij.main(ij.java:59)
          NULL

          There is a white space diff in AllPackages. There is commented out code that should be removed. There should be comments explaining the class DumpTempWriter, what bothPlaces means and the run method.

          Show
          kmarsden Kathey Marsden added a comment - Hi Ramin, Thank you for your continued work on this patch. With the patch I do not see the initializer error pointing my classpath to the classes directory, but I don't really understand how your changes sought to fix it. Could you explain. Running lang/triggerGeneral.sql I see a JVM crash with both IBM 1.5 and Sun 1.6 JDK's. The problem seems to arise from the fact that sysinfo registers the JCC driver in the following code in package org.apache.derby.impl.tools.sysinfo.Main.checkFile(String filename) { c = Class.forName("com.ibm.db2.jcc.DB2Driver"); m = c.getMethod("getJCCBuildNumber", null); o = c.newInstance(); build = (Integer)m.invoke(o,null); } } catch (ClassNotFoundException cnfe) { c = Class.forName("com.ibm.db2.jcc.DB2Version"); m = c.getMethod("getBuildNumber", null); o = c.newInstance(); build = (Integer)m.invoke(o,null); } Then there seems to be some bug in JCC that we are getting the T2 driver for jdbc:default:connection. But it seems like a bad side effect of sysinfo that the JCC Driver is getting loaded. I think it would be acceptable for sysinfo to just use com.ibm.db2.jcc.DB2Version.getBuildNumber. Here is the thread that fails. NULL ---------------------- 3XMTHREADINFO "main" (TID:0x41431300, sys_thread_t:0x000382D8, state:R, native ID:0x000012E0) prio=5 4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.DBConnect(Native Method) 4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.a(UWConnection.java:673) 4XESTACKTRACE at com/ibm/db2/jcc/uw/f.b(f.java:254) 4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.a(UWConnection.java:610) 4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.b(UWConnection.java:463) 4XESTACKTRACE at com/ibm/db2/jcc/uw/UWConnection.<init>(UWConnection.java:255) 4XESTACKTRACE at com/ibm/db2/jcc/DB2Driver.connect(DB2Driver.java:236) 4XESTACKTRACE at java/sql/DriverManager.getConnection(DriverManager.java:562) 4XESTACKTRACE at java/sql/DriverManager.getConnection(DriverManager.java:208) 4XESTACKTRACE at org/apache/derbyTesting/functionTests/tests/lang/userDefMethods.derby388(userDefMethods.java:89) 4XESTACKTRACE at org/apache/derby/exe/ac12564092x0116xa132x1d95xffffa334cdd074.g0(Bytecode PC:36) 4XESTACKTRACE at sun/reflect/NativeMethodAccessorImpl.invoke0(Native Method) 4XESTACKTRACE at sun/reflect/NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64(Compiled Code)) 4XESTACKTRACE at sun/reflect/DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43(Compiled Code)) 4XESTACKTRACE at java/lang/reflect/Method.invoke(Method.java:615(Compiled Code)) 4XESTACKTRACE at org/apache/derby/impl/services/reflect/ReflectMethod.invoke(ReflectMethod.java:46) 4XESTACKTRACE at org/apache/derby/impl/sql/execute/CallStatementResultSet.open(CallStatementResultSet.java:57) 4XESTACKTRACE at org/apache/derby/impl/sql/GenericPreparedStatement.execute(GenericPreparedStatement.java:370(Compiled Code)) 4XESTACKTRACE at org/apache/derby/impl/jdbc/EmbedStatement.executeStatement(EmbedStatement.java:1228) 4XESTACKTRACE at org/apache/derby/impl/jdbc/EmbedStatement.execute(EmbedStatement.java:618) 4XESTACKTRACE at org/apache/derby/impl/jdbc/EmbedStatement.execute(EmbedStatement.java:550) 4XESTACKTRACE at org/apache/derby/impl/tools/ij/ij.executeImmediate(ij.java:330(Compiled Code)) 4XESTACKTRACE at org/apache/derby/impl/tools/ij/utilMain.doCatch(utilMain.java:508) 4XESTACKTRACE at org/apache/derby/impl/tools/ij/utilMain.runScriptGuts(utilMain.java:350) 4XESTACKTRACE at org/apache/derby/impl/tools/ij/utilMain.go(utilMain.java:248) 4XESTACKTRACE at org/apache/derby/impl/tools/ij/Main.go(Main.java:215) 4XESTACKTRACE at org/apache/derby/impl/tools/ij/Main.mainCore(Main.java:181) 4XESTACKTRACE at org/apache/derby/impl/tools/ij/Main.main(Main.java:73) 4XESTACKTRACE at org/apache/derby/tools/ij.main(ij.java:59) NULL There is a white space diff in AllPackages. There is commented out code that should be removed. There should be comments explaining the class DumpTempWriter, what bothPlaces means and the run method.
          Hide
          dyret Dyre Tjeldvoll added a comment -

          Removing 'patch available' since it would appear that the latest comments cannot be addressed without uploading a new version of the patch. (Feel free to change it back if I've mis-understood something).

          Show
          dyret Dyre Tjeldvoll added a comment - Removing 'patch available' since it would appear that the latest comments cannot be addressed without uploading a new version of the patch. (Feel free to change it back if I've mis-understood something).
          Hide
          kmarsden Kathey Marsden added a comment -

          No activity in over a year, so unassigning this issue. Ramin, please reassign yourself if you are still interested in pursuing this issue.

          Show
          kmarsden Kathey Marsden added a comment - No activity in over a year, so unassigning this issue. Ramin, please reassign yourself if you are still interested in pursuing this issue.
          Hide
          kmarsden Kathey Marsden added a comment -

          It has become apparent to me that having sysinfo in the derby.log, especially in combination with DERBY-4441 would improve supportability significantly.

          In complex systems it has been difficult to gather the important version details because there may be many different distributions of java and derby on the problematic machine. There is no guarantee that sysinfo run from the comand line will match up with the environment causing the problem.

          It would be so useful, in fact, that I think sysinfo should print with the boot message by default and we should just provide an option to turn it off. It could eliminate many round trips with instructions to set properties and gather information. It would however, increase the size of the boot message significantly. Are there objections to implementing the sysinfo dump to the log on boot by default?

          Show
          kmarsden Kathey Marsden added a comment - It has become apparent to me that having sysinfo in the derby.log, especially in combination with DERBY-4441 would improve supportability significantly. In complex systems it has been difficult to gather the important version details because there may be many different distributions of java and derby on the problematic machine. There is no guarantee that sysinfo run from the comand line will match up with the environment causing the problem. It would be so useful, in fact, that I think sysinfo should print with the boot message by default and we should just provide an option to turn it off. It could eliminate many round trips with instructions to set properties and gather information. It would however, increase the size of the boot message significantly. Are there objections to implementing the sysinfo dump to the log on boot by default?
          Hide
          myrna Myrna van Lunteren added a comment -

          I can understand how valuable it will be in a Tech Support situation of a product that embeds another product that embeds another product that embeds Derby to have sysinfo - with additional jvm data - show up in derby.log without having to figure out where to set a property.

          But I do think if someone has already set derby.infolog.append=true, and is used to doing a lot of starting and shutting down, the derby.log could now grow quite large quickly. So I worry about doing this by default...
          Did you intend to backport such a change?

          I was thinking perhaps sysinfo output could go to a separate log file, to show up wherever derby.log lives...?
          But likely I over-estimate the growth of derby.log; and I agree something more than what we get currently will be useful.

          Show
          myrna Myrna van Lunteren added a comment - I can understand how valuable it will be in a Tech Support situation of a product that embeds another product that embeds another product that embeds Derby to have sysinfo - with additional jvm data - show up in derby.log without having to figure out where to set a property. But I do think if someone has already set derby.infolog.append=true, and is used to doing a lot of starting and shutting down, the derby.log could now grow quite large quickly. So I worry about doing this by default... Did you intend to backport such a change? I was thinking perhaps sysinfo output could go to a separate log file, to show up wherever derby.log lives...? But likely I over-estimate the growth of derby.log; and I agree something more than what we get currently will be useful.
          Hide
          kmarsden Kathey Marsden added a comment -

          I have been thinking about this issue, perhaps the full sysinfo is just overkill for derby.log, especially considering all the extra permissions that are required. The critical information that is routinely needed in derby.log that is not there already is the jvm version and if possible the derby.jar location (not sure how to do this). Maybe we should try to print just this information compactly to derby.log and not go for the full sysinfo.

          Show
          kmarsden Kathey Marsden added a comment - I have been thinking about this issue, perhaps the full sysinfo is just overkill for derby.log, especially considering all the extra permissions that are required. The critical information that is routinely needed in derby.log that is not there already is the jvm version and if possible the derby.jar location (not sure how to do this). Maybe we should try to print just this information compactly to derby.log and not go for the full sysinfo.
          Hide
          kmarsden Kathey Marsden added a comment -

          I think now what is needed from sysinfo is now logged to derby.log by default with the diagnostics added in various other issues. We have

          • The full derby version for derby.jar
          • The class loader that loads derby.
          • The location from which derby.jar was loaded.
          • The full java version
          • The user.dir and derby.system.home locations.
          • The log location if it has been redirected.

          The only things that are missing from sysinfo are the full classpath, the exact version of other derby jar files and the OS information .

          I don't think that the non-derby classpath entries are usually relevant for embedded derby support when looking at the derby.log and actually having the full classpath might be information users don't wish to share with the list. Regarding the versions of the other derby.jar files, I could see that in rare cases it might be relevant if versions are mixed but in those cases, the client or tools or whatever would typically have a separate running environment where sysinfo output would be more relevant. Also adding these things would add bulk to the boot message.

          I do think the OS information would be useful to have, e.g,
          OS name: Windows XP
          OS architecture: x86
          OS version: 5.1 build 2600 Service Pack 3

          So if nobody objects. I would like to open an issue to add the OS info to the boot message and close this issue.

          Show
          kmarsden Kathey Marsden added a comment - I think now what is needed from sysinfo is now logged to derby.log by default with the diagnostics added in various other issues. We have The full derby version for derby.jar The class loader that loads derby. The location from which derby.jar was loaded. The full java version The user.dir and derby.system.home locations. The log location if it has been redirected. The only things that are missing from sysinfo are the full classpath, the exact version of other derby jar files and the OS information . I don't think that the non-derby classpath entries are usually relevant for embedded derby support when looking at the derby.log and actually having the full classpath might be information users don't wish to share with the list. Regarding the versions of the other derby.jar files, I could see that in rare cases it might be relevant if versions are mixed but in those cases, the client or tools or whatever would typically have a separate running environment where sysinfo output would be more relevant. Also adding these things would add bulk to the boot message. I do think the OS information would be useful to have, e.g, OS name: Windows XP OS architecture: x86 OS version: 5.1 build 2600 Service Pack 3 So if nobody objects. I would like to open an issue to add the OS info to the boot message and close this issue.
          Hide
          kmarsden Kathey Marsden added a comment -

          Linking to DERBY-5340 which is for logging operating system information

          Show
          kmarsden Kathey Marsden added a comment - Linking to DERBY-5340 which is for logging operating system information
          Hide
          kmarsden Kathey Marsden added a comment -

          The solution of logging this information directly in derby.log without going through the sysinfo tools code and without any special properties seems preferable..
          Functionality has been implemented except fro DERBY-5240 which is pending.

          Show
          kmarsden Kathey Marsden added a comment - The solution of logging this information directly in derby.log without going through the sysinfo tools code and without any special properties seems preferable.. Functionality has been implemented except fro DERBY-5240 which is pending.
          Hide
          knutanders Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          knutanders Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.

            People

            • Assignee:
              Unassigned
              Reporter:
              kmarsden Kathey Marsden
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development