[ 
https://issues.apache.org/jira/browse/DERBY-6620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14104383#comment-14104383
 ] 

Dag H. Wanvik commented on DERBY-6620:
--------------------------------------

This is the wiki explanation:
{quote}
Client side tracing under Network Server

Currently, the client tracing can be enabled by setting jdbc url attributes or 
through setXXX methods on the DataSource or by calling 
DriverManager.setLogWriter method (More information on these options can be 
found in the Server and Administration Guide). All these options require 
changing the client code which may not be a feasible option for a deployed 
client application. To get around this, in Derby 10.3, 2 new JVM 
properties(DERBY-1275) have been added. They are namely, 
derby.client.traceLevel and derby.client.traceDirectory. When the client 
application is started, the users can include these 2 JVM properties to start 
the client side tracing. eg java -Dderby.client.traceDirectory=./traceDir 
-Dderby.client.traceLevel=64 clientApplication

When running under security manager, read permission for these properties is 
required. If permission to read the properties is not allowed, the properties 
will be ignored and tracing will not be affected. 
{quote}
I am tempted to resolve this issue as "won't fix" in the light of this 
information. Rick?


> Network client DataSources silently swallow SecurityExceptions when trying to 
> read the tracing properties
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6620
>                 URL: https://issues.apache.org/jira/browse/DERBY-6620
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.11.1.1
>            Reporter: Rick Hillegas
>            Assignee: Dag H. Wanvik
>
> The swallowing occurs here:
> {noformat}
> org.apache.derby.jdbc.ClientBaseDataSourceRoot run Catch 
> java.lang.SecurityException 1 line 457
> {noformat}
> Maybe a warning could be raised to alert the user to the problem and 
> encourage them to correct their security policy.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Reply via email to