[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12465845
]
Mamta A. Satoor commented on DERBY-1275:
----------------------------------------
I have attached a small review package(DERBY1275EnableClientTracingDiffV1.txt)
for this Jira entry. I have taken Kathey's suggested way of approaching the
issue which is to introduce 2 system properties, derby.client.traceLevel and
derby.client.traceDirectory. These 2 properties will enable a customer to start
client tracing without having to change the actual client application. The
discussion on the Jira has talked about keeping these properties as unsupported
and putting them on a wiki page rather than the official documentation. If we
agree on that, then I can go ahead and put something on a wiki page. Do we
already have a wiki page for unsupported Derby stuff? If yes, then I can go
ahead and use that same wiki page. I will mention on that page that traceLevel
and traceDirectory values specified through JVM system property will overwrite
what is passed through the jdbc url.
Now to go over the changes that went into 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 hext numbers.
Specifying non-int value will result in following exception
ERROR XJ213: The traceLevel connection property does not have a valid format
for a number.
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
3)The junit test framework requires that I put these 2 new properties in
functionTests/util/derby_tests.policy so that properties can be read without
running SecurityException.
4)I manually tested my changes but don't know how to add a test in the test
suite so I can pass these new system properties. Would appreciate if anyone has
some info on this.
> 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,
> DERBY1275EnableClientTracingStatV1.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.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
