[
https://issues.apache.org/jira/browse/DERBY-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468323
]
Daniel John Debrunner commented on DERBY-1275:
----------------------------------------------
privilege block comments:
1) Use of classes for privilege blocks is ok but the typical use is anonymous
classes, see BaseTestCase.getSystemProperty for an example.
2) The exception handling for the privilege blocks is incorrect:
- System.getProperty() in SystemPropertyReadPrivledgeBlock cannot thrown
IOException or any checked exception so only a PrivilegedAction is needed and
no need to catch java.security.PrivilegedActionException.
- The java.security.PrivilegedActionException only catches checked exceptions
which are not RuntimeExceptions so this code is incorrect:
+ } catch (java.security.PrivilegedActionException pae) {
+ throw (RuntimeException) pae.getException();
For example opening a file in a privilge block can thrown IOException which
will be wrapped in PrivilegedActionException but a SecurityException will not.
- The error handling for FilePrivilegeBlock is broken. The run() method can
throw IOException but if it does the cast to RuntimeException will cause
another exception. Previously the exception would be wrapped in a SqlException.
Typically the run() methods of a privilege action should be simple, so in this
case the run() method should not be catching IOException and wrapping it in a
SqlException, instead the wrapping should happen outside the doPrivileged()
call.
3) Any reason for the run() methods to be synchronized?
> 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.
