[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mamta A. Satoor updated DERBY-1275:
-----------------------------------
Attachment: DERBY1275EnableClientTracingStatV2.txt
DERBY1275EnableClientTracingDiffV2.txt
I have attached an updated review package
DERBY1275EnableClientTracingDiffV1.txt As mentioned with the earlier patch, I
am adding 2 client-side system properties, derby.client.traceLevel and
derby.client.traceDirectory. This 2 properties will allow a user to start
client tracing without having to change the actual client application.
Summary of the patch
1)Added an attribute for the client property prefix in Attribute.java This
prefix and traceLevel or traceDirectory will define the 2 new system property
names. Rather than introducing 2 new attributes with derby.client.traceLevel
and derby.client.traceDirectory, I thought it will be better to just intorduce
a prefix which can be used with the existing attributes for traceLevel and
traceDirectory.
2)At this point, the system property derby.client.traceLevel will only accept
int values. The existing documentation at
http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html
talks about symbolic values or the hex values but the new system property
derby.client.traceLevel will not accept any of these 2 documented ways.
Instead, the user will need to use the base 10 equivalent of the hex numbers.
This behavior is same as what happens inside ij. More info can be found at
http://www.nabble.com/Specifying-the-traceLevel-property-through-ij-tf3021545.html#a8391955
Specifying non-int value will result in following exception
ERROR XJ213: The traceLevel connection property does not have a valid format
for a number.
3)I added a new junit test, ClientSideSystemProperties under tests/derbynet
directory. This class relies on the decorator SystemPropertyTestSetup to set up
the trace related jvm properties(derby.client.traceLevel and
derby.client.traceDirectory). This property setting code happens in the suite()
method. Once these properties are set, the test establishes a database
connection. At the time of the test tear down, in tearDown() method, the test
needs to look in the trace directory specified by derby.client.traceDirectory
to see if any new files were created. If yes, then that means that the jvm
properties were correctly picked by the test and tracing happened correctly.
The tearDown() method then deletes the trace files and deletes the
traceDirectory so that the test environment is clean.
Now, since this test runs under security manager, the directory access part
needs to happen in a privileged block. I wanted to have
ClientSideSystemProperties implement java.security.PrivilegedExceptionAction
and include the public synchronized final Object run() throws IOException
method in ClientSideSystemProperties to write the privilege code but I kept
getting compile error. The compiler was getting confused with the run() method
in java.security.PrivilegedExceptionAction and the run() method in
junit.framework.TestCase.
[javac]
C:\p4clients\maintest3\opensource\java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\ClientSideSystemProperties.java:57:
run() in
org.apache.derbyTesting.functionTests.tests.derbynet.ClientSideSystemProperties
cannot override run() in junit.framework.TestCase; attempting to use
incompatible return type
[javac] found : java.lang.Object
[javac] required: junit.framework.TestResult
[javac] public synchronized final Object run() throws IOException {
[javac] ^
[javac] 1 error
[javac] Compile failed; see the compiler error output for details.
To work around this compile time error, I decided to create a new class,
DirReadAndDeletePrivledgeBlock, which extends
java.security.PrivilegedExceptionAction and this new class has the directory
lookup, cleanup code. An object of this class is then used by the tearDown
method in , as shown below ClientSideSystemProperties
java.security.AccessController.doPrivileged(new
DirReadAndDeletePrivledgeBlock(traceDirectory));
4)Changes in ClientBaseDataSource.java
I have changed getTraceDirectory method to first check for the jvm properties
derby.client.traceDirectory. If not found, then look for traceDirectory in the
jdbc url. Similar change has been made for method getTraceLevel. Since these 2
methods now require looking at system properties, part of their code needs to
be inside a privileged block. But since the methods getTraceLevel and
getTraceDirectory are
static, I can't pass an instance of their class to
java.security.AccessController.doPrivileged call. To get around this, I
introduced a
new class which just implements java.security.PrivilegedExceptionAction and
it's run method does the job of looking at the system properties.
In addition, I took out some unused imports from ClientBaseDataSource.java
5)Changes in LogWriter.java
I had to change the PrintWriter related code in this file to run inside a
privileged block. The existing code for PrintWrite is in the static method
getPrintWriter. For the reasons similar to #4 above (for
ClientBaseDataSource.java), I had to create a new class to do the PrintWriter
code and have the LogWriter.getPrintWriter use an instance of the new class in
it's java.security.AccessController.doPrivileged call.
May be there is a better way to accomplish #4 and #5 above w/o introducing the
new classes. If anyone has any ideas, please let me know. I could have created
a new instance of the current class even when inside the static method but the
classes LogWriter and ClientBaseDataSource are pretty big. I thought it would
be better to have smaller welldefined classes to do the privileged code rather
than instantiating objects of large classes.
Items to do
1)Since these 2 properties won't be documented in the official Derby
ocumentation, I will add a wiki page for them so we don't loose track of these
undocumented properties. I will mention on the page that system properties will
override the same properties provided through JDBC url. I will also add that at
this point, onlt int values can be specified for the system property
derby.client.traceLevel.
The existing documentation at
http://db.apache.org/derby/docs/10.2/adminguide/cadminappsclienttracing.html
talks about symbolic values or the hex values but the new system property
derby.client.traceLevel will not accept any of these 2 documented ways.
Instead, the
user will need to use the base 10 equivalent of the hext numbers.
Disclaimer: A user can use these properties but since they are not in the
official documentation, they can be changed at any point without providing any
backward compatibility.
svn stat -q is attached as DERBY1275EnableClientTracingStatV2.txt
I have finished running the junit test suite and there were no new failures
caused by this patch. The run of derbyall shows NSinSameJVM failure but from
the actual diff, it doesn't look like it is related to my changes.
Any feedback on the patch will be much appreciated.
> Provide a way to enable client tracing without changing the application
> -----------------------------------------------------------------------
>
> Key: DERBY-1275
> URL: https://issues.apache.org/jira/browse/DERBY-1275
> Project: Derby
> Issue Type: Improvement
> Components: Network Client
> Affects Versions: 10.1.3.1, 10.2.1.6
> Reporter: Kathey Marsden
> Assigned To: Mamta A. Satoor
> Priority: Minor
> Fix For: 10.2.3.0
>
> Attachments: DERBY1275EnableClientTracingDiffV1.txt,
> DERBY1275EnableClientTracingDiffV2.txt,
> DERBY1275EnableClientTracingStatV1.txt, DERBY1275EnableClientTracingStatV2.txt
>
>
> Currently the client tracing can be enabled by setting attributes on the
> client url, setXXX methods on the DataSource or calling
> DriverManager.setLogWriter(), but it often cannot be enabled in a deployed
> client application because all of these API's require modification of the
> application or its configuration files.
> It would be good to have a global way to turn on client tracing. A system
> property pointing to a property file is one possibility but probably not
> ideal because of the impact in class loader contexts. I am not sure what
> the other possiblities are,
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
