Derby
  1. Derby
  2. DERBY-3211

Convert derbynet/NSinSameJVM.java to junit

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.4.1.3
    • Component/s: Test
    • Labels:
      None
    1. DERBY_3211_diff_12_19.txt
      6 kB
      Manjula Kutty
    2. DERBY_3211_stat_12_19.txt
      0.2 kB
      Manjula Kutty
    3. DERBY_3211_diff_12_14.txt
      54 kB
      Manjula Kutty
    4. DERBY_3211_stat_12_14.txt
      0.2 kB
      Manjula Kutty
    5. DERBY-3211_diff_11_19_ver2.txt
      6 kB
      Manjula Kutty
    6. DERBY-3211_stat_11_19_ver2.txt
      0.2 kB
      Manjula Kutty
    7. DERBY-3211_diff_11_19.txt
      20 kB
      Manjula Kutty
    8. DERBY-3211_stat_11_19.txt
      0.3 kB
      Manjula Kutty
    9. DERBY-3211_diff_11_16.txt
      19 kB
      Manjula Kutty
    10. DERBY-3211_stat_11_16.txt
      0.3 kB
      Manjula Kutty

      Issue Links

        Activity

        Hide
        Manjula Kutty added a comment -

        Please review this patch and if looks good please commit. I didn't delete the NSinSameJVM.java from derbyall. Will do that once this patch gets commited.

        Show
        Manjula Kutty added a comment - Please review this patch and if looks good please commit. I didn't delete the NSinSameJVM.java from derbyall. Will do that once this patch gets commited.
        Hide
        Daniel John Debrunner added a comment -
        • Are there comments as to why a different security policy file is needed? It didn't jump out at me what was different about these policy files.
        • Instead of code like this you can use the utility method: JDBC.assertDrainResults()
          + while (rs.next()) { + rs.getString(1); + }

          + rs.close();

        • In a test fixture (e.g. testStartAndShutdown) there's no need to catch Exception like this:
          + } catch (Exception e) { + System.out.print("FAIL: Unexpected exception" + e.getMessage()); + e.printStackTrace(); + }

        Junit will report a failure if an exception is thrown from a fixture.

        • In testStartAndShutdown() any idea what this comment means? Since the fixture finishes there is no test code making sure of anything so
          I wonder what it's trying to sat?

        + // Leave the connection open before shutdown to make
        + // sure the thread closes down.

        testStartAndShutdown() doesn't actually start the network server, that's handled by the decorator, right? If so the description and name of the fixture is misleading.

        Show
        Daniel John Debrunner added a comment - Are there comments as to why a different security policy file is needed? It didn't jump out at me what was different about these policy files. Instead of code like this you can use the utility method: JDBC.assertDrainResults() + while (rs.next()) { + rs.getString(1); + } + rs.close(); In a test fixture (e.g. testStartAndShutdown) there's no need to catch Exception like this: + } catch (Exception e) { + System.out.print("FAIL: Unexpected exception" + e.getMessage()); + e.printStackTrace(); + } Junit will report a failure if an exception is thrown from a fixture. In testStartAndShutdown() any idea what this comment means? Since the fixture finishes there is no test code making sure of anything so I wonder what it's trying to sat? + // Leave the connection open before shutdown to make + // sure the thread closes down. testStartAndShutdown() doesn't actually start the network server, that's handled by the decorator, right? If so the description and name of the fixture is misleading.
        Hide
        Manjula Kutty added a comment -

        Thank you for your comments Dan. Here are my thoughts regrding your questions. If I'm wrong in any context please correct me.

        I created a different policy file since the network server is started on a different port other than 1527.

        I will look in to the JDBC.assertDrainResults() and will change my code accordingly. Will submit a patch soon with this change

        Actually the test is not doing any explicit connecction.close(). Instead, it just shuts down the server and make sure no exceptions are thrown.

        Yes. I agree that the server is started using the decorator. Will change the function name.

        Show
        Manjula Kutty added a comment - Thank you for your comments Dan. Here are my thoughts regrding your questions. If I'm wrong in any context please correct me. I created a different policy file since the network server is started on a different port other than 1527. I will look in to the JDBC.assertDrainResults() and will change my code accordingly. Will submit a patch soon with this change Actually the test is not doing any explicit connecction.close(). Instead, it just shuts down the server and make sure no exceptions are thrown. Yes. I agree that the server is started using the decorator. Will change the function name.
        Hide
        Manjula Kutty added a comment -

        Submitting new patch which takes care of Dan's comments. Please review and if looks good please commit

        Show
        Manjula Kutty added a comment - Submitting new patch which takes care of Dan's comments. Please review and if looks good please commit
        Hide
        Daniel John Debrunner added a comment -

        Manjula> I created a different policy file since the network server is started on a different port other than 1527.

        Is it required, I don't see anything in the policy file that refers to port 1527?

        Show
        Daniel John Debrunner added a comment - Manjula> I created a different policy file since the network server is started on a different port other than 1527. Is it required, I don't see anything in the policy file that refers to port 1527?
        Hide
        Manjula Kutty added a comment -

        If I don't give a seperate policy file for the port 20000 (which I used in this test) the test fails with the following exception.

        $ java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.derby
        net.NSinSameJVMTest
        .java.security.AccessControlException: access denied (java.net.SocketPermission
        0.0.0.0:20000 connect,resolve)
        at java.security.AccessControlContext.checkPermission(AccessControlConte
        xt.java:264)
        at java.security.AccessController.checkPermission(AccessController.java:
        427)
        at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
        at java.lang.SecurityManager.checkConnect(SecurityManager.java:1034)
        at java.net.Socket.connect(Socket.java:513)
        at java.net.Socket.connect(Socket.java:469)
        at java.net.Socket.<init>(Socket.java:366)
        at java.net.Socket.<init>(Socket.java:208)
        at javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:202)
        at org.apache.derby.impl.drda.NetworkServerControlImpl$6.run(NetworkServ
        erControlImpl.java:2358)
        at java.security.AccessController.doPrivileged(Native Method)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.setUpSocket(Netwo
        rkServerControlImpl.java:2329)
        at org.apache.derby.impl.drda.NetworkServerControlImpl.shutdown(NetworkS
        erverControlImpl.java:927)
        at org.apache.derby.drda.NetworkServerControl.shutdown(NetworkServerCont
        rol.java:348)
        at org.apache.derbyTesting.functionTests.tests.derbynet.NSinSameJVMTest.
        testShutdown(NSinSameJVMTest.java:70)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
        java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
        sorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
        95)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
        at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        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.framework.TestResult.runProtected(TestResult.java:124)
        at junit.extensions.TestSetup.run(TestSetup.java:23)
        at junit.textui.TestRunner.doRun(TestRunner.java:116)
        at junit.textui.TestRunner.start(TestRunner.java:172)
        at junit.textui.TestRunner.main(TestRunner.java:138)

        So I thought the default hostname and ipaddress defaults to the default port of 1527. Should the policy file accept all the ports, without explicitly giving them in the policy file? If so then this will be a bug, else I need a seperate policy file just for the different port.

        Show
        Manjula Kutty added a comment - If I don't give a seperate policy file for the port 20000 (which I used in this test) the test fails with the following exception. $ java junit.textui.TestRunner org.apache.derbyTesting.functionTests.tests.derby net.NSinSameJVMTest .java.security.AccessControlException: access denied (java.net.SocketPermission 0.0.0.0:20000 connect,resolve) at java.security.AccessControlContext.checkPermission(AccessControlConte xt.java:264) at java.security.AccessController.checkPermission(AccessController.java: 427) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.SecurityManager.checkConnect(SecurityManager.java:1034) at java.net.Socket.connect(Socket.java:513) at java.net.Socket.connect(Socket.java:469) at java.net.Socket.<init>(Socket.java:366) at java.net.Socket.<init>(Socket.java:208) at javax.net.DefaultSocketFactory.createSocket(SocketFactory.java:202) at org.apache.derby.impl.drda.NetworkServerControlImpl$6.run(NetworkServ erControlImpl.java:2358) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derby.impl.drda.NetworkServerControlImpl.setUpSocket(Netwo rkServerControlImpl.java:2329) at org.apache.derby.impl.drda.NetworkServerControlImpl.shutdown(NetworkS erverControlImpl.java:927) at org.apache.derby.drda.NetworkServerControl.shutdown(NetworkServerCont rol.java:348) at org.apache.derbyTesting.functionTests.tests.derbynet.NSinSameJVMTest. testShutdown(NSinSameJVMTest.java:70) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 95) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.framework.TestResult.runProtected(TestResult.java:124) 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.framework.TestResult.runProtected(TestResult.java:124) at junit.extensions.TestSetup.run(TestSetup.java:23) at junit.textui.TestRunner.doRun(TestRunner.java:116) at junit.textui.TestRunner.start(TestRunner.java:172) at junit.textui.TestRunner.main(TestRunner.java:138) So I thought the default hostname and ipaddress defaults to the default port of 1527. Should the policy file accept all the ports, without explicitly giving them in the policy file? If so then this will be a bug, else I need a seperate policy file just for the different port.
        Hide
        Daniel John Debrunner added a comment -

        This is because your test and policy file is using a different host (0.0.0.0), not because it's using a different port number.

        The policy file already handles a settable host file using derbyTesting.serverhost, I wonder though if this test should just use the default host (a different port number is fine) and not specifically 0.0.0.0. In special testing of 0.0.0.0 is needed then it probably should be set at a test configuration level and not hard-coded within a test.

        Show
        Daniel John Debrunner added a comment - This is because your test and policy file is using a different host (0.0.0.0), not because it's using a different port number. The policy file already handles a settable host file using derbyTesting.serverhost, I wonder though if this test should just use the default host (a different port number is fine) and not specifically 0.0.0.0. In special testing of 0.0.0.0 is needed then it probably should be set at a test configuration level and not hard-coded within a test.
        Hide
        Manjula Kutty added a comment -

        Yes, I agree with you Dan. And I think it is OK to use the localhost instead of 0.0.0.0. So I made the changes accordingly and now there is no seperate policy file for this test. Please review this latest patch.

        Show
        Manjula Kutty added a comment - Yes, I agree with you Dan. And I think it is OK to use the localhost instead of 0.0.0.0. So I made the changes accordingly and now there is no seperate policy file for this test. Please review this latest patch.
        Hide
        Myrna van Lunteren added a comment -

        I thought the latest patch looked good, and as there were no further comments, I committed it to trunk with revision 597456, and removed the old test and masters etc. with revision 597466.

        I intend to backport this to 10.3 - tomorrow.

        Show
        Myrna van Lunteren added a comment - I thought the latest patch looked good, and as there were no further comments, I committed it to trunk with revision 597456, and removed the old test and masters etc. with revision 597466. I intend to backport this to 10.3 - tomorrow.
        Hide
        Myrna van Lunteren added a comment -

        backported to 10.3 with revision 597751.

        Show
        Myrna van Lunteren added a comment - backported to 10.3 with revision 597751.
        Hide
        Knut Anders Hatlen added a comment -

        Reopening the issue since there are some remaining problems:

        1) Dan's comment about try/catch/println is not addressed. As the test is written now, JUnit won't ever notice if the test fails, since all exceptions are swallowed.

        2) I don't think the port number and host name should be hard coded in the test. Instead of "localhost", TestConfiguration.getHostName() should be used. Also, I think we need to add a method to TestConfiguration called getAlternativePort() or something, instead of hard coding the port number 20000 in the test. The point of centralizing the allocation of port numbers in TestConfiguration, is to enable people to run multiple JUnit tests in parallel on the same machine without conflicting with each other (there was an effort some time ago to achieve this, I don't remember how far they got). If we start hard-coding port numbers in the tests, this becomes much more difficult.

        I also think the new decorator methods in TestConfiguration should not take port number as an argument, as that will encourage more tests to use arbitrary port numbers. Instead we should name them differently (e.g., defaultServerDecoratorWithAlternativePort), remove the port parameter, and let them use getAlternativePort() internally.

        3) Class header for NSinSameJVMTest header says DRDAProtocolTest.

        4) testShutdown() has a comment which says "Just connect, do something and close the connection", but there is no code to close the connection (or the statement) as far as I can see.

        5) NSinSameJVMTest.java contains a mixture of tabs/spaces, which I think should be avoided in new files.

        6) The new method TestConfiguration.defaultServerDecorator(Test,int) has a comment which says "This looks bogus to me." That doesn't sound very comforting...

        7) Why does the test need to sleep for five seconds before it finishes? It would be good to document this in a comment.

        Show
        Knut Anders Hatlen added a comment - Reopening the issue since there are some remaining problems: 1) Dan's comment about try/catch/println is not addressed. As the test is written now, JUnit won't ever notice if the test fails, since all exceptions are swallowed. 2) I don't think the port number and host name should be hard coded in the test. Instead of "localhost", TestConfiguration.getHostName() should be used. Also, I think we need to add a method to TestConfiguration called getAlternativePort() or something, instead of hard coding the port number 20000 in the test. The point of centralizing the allocation of port numbers in TestConfiguration, is to enable people to run multiple JUnit tests in parallel on the same machine without conflicting with each other (there was an effort some time ago to achieve this, I don't remember how far they got). If we start hard-coding port numbers in the tests, this becomes much more difficult. I also think the new decorator methods in TestConfiguration should not take port number as an argument, as that will encourage more tests to use arbitrary port numbers. Instead we should name them differently (e.g., defaultServerDecoratorWithAlternativePort), remove the port parameter, and let them use getAlternativePort() internally. 3) Class header for NSinSameJVMTest header says DRDAProtocolTest. 4) testShutdown() has a comment which says "Just connect, do something and close the connection", but there is no code to close the connection (or the statement) as far as I can see. 5) NSinSameJVMTest.java contains a mixture of tabs/spaces, which I think should be avoided in new files. 6) The new method TestConfiguration.defaultServerDecorator(Test,int) has a comment which says "This looks bogus to me." That doesn't sound very comforting... 7) Why does the test need to sleep for five seconds before it finishes? It would be good to document this in a comment.
        Hide
        Myrna van Lunteren added a comment -

        Coincidentally, I wrote a silly getAlternatePort() method for the TestConfiguration class.

        Maybe some review of the method will be useful here - it'll take a bit longer before I have the test I'm working on (testProperties.java) converted. This is what I have so far:

        public int getAlternativePort() throws SQLException {

        Exception failException = null;
        // start with the default port + 1
        // there may be a smarter way to get the starting point...
        int possiblePort = getPort();
        if (!(possiblePort > 0))
        possiblePort = 1528;
        else
        possiblePort = getPort() + 1;
        try {
        boolean portOK = false;
        while (!portOK) {
        // check for first one in use
        NetworkServerControl networkServer =
        new NetworkServerControl(InetAddress.getByName("localhost"), possiblePort);
        // Ping and wait for the network server to reply
        boolean started = false;

        try

        { networkServer.ping(); // If ping throws no exception the server is running started = true; }

        catch(Exception e)

        { failException = e; }

        // Check if we got a reply on ping
        if (!started)

        { // we'll assume we can use this port. // If there was some other problem with the pinging, it'll // become clear when someone attempts to use the port portOK = true; }

        else

        { // this port's in use. possiblePort = possiblePort + 1; }

        }
        } catch (Exception e)

        { SQLException se = new SQLException("Error pinging network server"); se.initCause(failException); throw se; }


        return possiblePort;
        }

        Show
        Myrna van Lunteren added a comment - Coincidentally, I wrote a silly getAlternatePort() method for the TestConfiguration class. Maybe some review of the method will be useful here - it'll take a bit longer before I have the test I'm working on (testProperties.java) converted. This is what I have so far: public int getAlternativePort() throws SQLException { Exception failException = null; // start with the default port + 1 // there may be a smarter way to get the starting point... int possiblePort = getPort(); if (!(possiblePort > 0)) possiblePort = 1528; else possiblePort = getPort() + 1; try { boolean portOK = false; while (!portOK) { // check for first one in use NetworkServerControl networkServer = new NetworkServerControl(InetAddress.getByName("localhost"), possiblePort); // Ping and wait for the network server to reply boolean started = false; try { networkServer.ping(); // If ping throws no exception the server is running started = true; } catch(Exception e) { failException = e; } // Check if we got a reply on ping if (!started) { // we'll assume we can use this port. // If there was some other problem with the pinging, it'll // become clear when someone attempts to use the port portOK = true; } else { // this port's in use. possiblePort = possiblePort + 1; } } } catch (Exception e) { SQLException se = new SQLException("Error pinging network server"); se.initCause(failException); throw se; } return possiblePort; }
        Hide
        Knut Anders Hatlen added a comment -

        Hi Myrna,

        I think this getAlternativePort() method attempts to do too much. I would expect it just to return a port number, and that two subsequent calls would return the same number. Starting the server in a getter method also feels a little strange. I liked Manjula's approach with using NetworkServerTestSetup to start and stop the server better, if only the port number was defined in TestConfiguration instead of in the test itself.

        If the alternative port is not available, I think it is OK that the test fails, since that would be a problem with the environment, the same way as if the default port was not available or the hard disk was full.

        Show
        Knut Anders Hatlen added a comment - Hi Myrna, I think this getAlternativePort() method attempts to do too much. I would expect it just to return a port number, and that two subsequent calls would return the same number. Starting the server in a getter method also feels a little strange. I liked Manjula's approach with using NetworkServerTestSetup to start and stop the server better, if only the port number was defined in TestConfiguration instead of in the test itself. If the alternative port is not available, I think it is OK that the test fails, since that would be a problem with the environment, the same way as if the default port was not available or the hard disk was full.
        Hide
        Myrna van Lunteren added a comment -

        I see your point, the method is very specific to something I don't see how to accomplish with decorators/setups in converting testProperties.

        Show
        Myrna van Lunteren added a comment - I see your point, the method is very specific to something I don't see how to accomplish with decorators/setups in converting testProperties.
        Hide
        Myrna van Lunteren added a comment -

        On that note...
        This test originally did something unique in the old test harness, which always kicked off a separate process for networkserver.
        Now, in the junit framework, we're always starting networkserver within the same jvm, so what is the use of this test?

        Show
        Myrna van Lunteren added a comment - On that note... This test originally did something unique in the old test harness, which always kicked off a separate process for networkserver. Now, in the junit framework, we're always starting networkserver within the same jvm, so what is the use of this test?
        Hide
        Manjula Kutty added a comment -

        I had the same question and found out that, now the test is used to test starting the server and shutdown with a different port and also shutting down with one open connection, and also felt it is good to have such a test.

        Show
        Manjula Kutty added a comment - I had the same question and found out that, now the test is used to test starting the server and shutdown with a different port and also shutting down with one open connection, and also felt it is good to have such a test.
        Hide
        Daniel John Debrunner added a comment -

        The end of the fixture (testShutdown) has this line:

        Thread.sleep(5000)

        Any idea why? It would be good to comment why this test is sleeping for 5 seconds at the end, if it's not required it should be removed.

        Show
        Daniel John Debrunner added a comment - The end of the fixture (testShutdown) has this line: Thread.sleep(5000) Any idea why? It would be good to comment why this test is sleeping for 5 seconds at the end, if it's not required it should be removed.
        Hide
        Manjula Kutty added a comment -

        Attaching my latest patch. Please review and if looks good please commit

        Show
        Manjula Kutty added a comment - Attaching my latest patch. Please review and if looks good please commit
        Hide
        Knut Anders Hatlen added a comment -

        Hi Manjula, I think your approach basically looks good. Please see my comments below.

        1) I think this code

        + NetworkServerControl serverControl = null;
        + int port = TestConfiguration.getCurrent().getPort();
        + String hostName = TestConfiguration.getCurrent().getHostName();
        + serverControl = new NetworkServerControl(InetAddress
        + .getByName(hostName), port);// initialized for the shutdown.

        could be replaced by a call to NetworkServerTestSetup.getNetworkServerControl()

        2)
        + try

        { + serverControl.shutdown(); + }

        catch (Exception e)

        { + fail("Unexpected exception" + e.getMessage()); + e.printStackTrace(); + }

        e.printStackTrace() won't ever be called, since it's placed right after a call to fail(). Anyway, I think it is better just to remove the try/catch/fail and let JUnit handle the exception itself.

        3) I can't see that getNewPort() is used, so it's probably best to remove it.

        4) It looks like most of the changes in TestConfiguration.java are reformatting/white-space changes. If you could post a new patch which only contained what's actually changed, it would be easier to review those changes.

        Show
        Knut Anders Hatlen added a comment - Hi Manjula, I think your approach basically looks good. Please see my comments below. 1) I think this code + NetworkServerControl serverControl = null; + int port = TestConfiguration.getCurrent().getPort(); + String hostName = TestConfiguration.getCurrent().getHostName(); + serverControl = new NetworkServerControl(InetAddress + .getByName(hostName), port);// initialized for the shutdown. could be replaced by a call to NetworkServerTestSetup.getNetworkServerControl() 2) + try { + serverControl.shutdown(); + } catch (Exception e) { + fail("Unexpected exception" + e.getMessage()); + e.printStackTrace(); + } e.printStackTrace() won't ever be called, since it's placed right after a call to fail(). Anyway, I think it is better just to remove the try/catch/fail and let JUnit handle the exception itself. 3) I can't see that getNewPort() is used, so it's probably best to remove it. 4) It looks like most of the changes in TestConfiguration.java are reformatting/white-space changes. If you could post a new patch which only contained what's actually changed, it would be easier to review those changes.
        Hide
        Manjula Kutty added a comment -

        Thanks Knut for your input. Please find the attached patch with the recommended changes. If it looks good, please commit

        Show
        Manjula Kutty added a comment - Thanks Knut for your input. Please find the attached patch with the recommended changes. If it looks good, please commit
        Hide
        Knut Anders Hatlen added a comment -

        Thanks, Manjula! Committed revision 605719.

        Show
        Knut Anders Hatlen added a comment - Thanks, Manjula! Committed revision 605719.
        Hide
        Manjula Kutty added a comment -

        Thanks Knut for committing this one

        Show
        Manjula Kutty added a comment - Thanks Knut for committing this one

          People

          • Assignee:
            Manjula Kutty
            Reporter:
            Manjula Kutty
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development