db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-1275) Provide a way to enable client tracing without changing the application
Date Thu, 27 Jul 2006 05:37:14 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1275?page=all ]

Kathey Marsden updated DERBY-1275:

    Fix Version/s:

Adding this as a high value fix candidate to the 10.2 list so that it might be picked up for
10.2.  The original crisis that prompted me to think I might do this ended so I didn't pursue
it myself. There was a suggestion that JMX might resolve the issue but I think that would
require  additional jar distribution and also I think  won't be available for 10.2, so it
would be good to have some way to to enable tracing  at end user sites without asking the
application writers to send out a new build.  As Knut suggested it can just be mentioned on
a wiki page and not the official documentation so we don't have to stick with the quick fix
moving forward.

> Provide a way to enable client tracing without changing the application
> -----------------------------------------------------------------------
>                 Key: DERBY-1275
>                 URL: http://issues.apache.org/jira/browse/DERBY-1275
>             Project: Derby
>          Issue Type: Improvement
>          Components: Network Client
>    Affects Versions:,
>            Reporter: Kathey Marsden
>            Priority: Minor
>             Fix For:
> 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: http://issues.apache.org/jira/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message