You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <de...@db.apache.org> on 2006/06/22 21:00:30 UTC
[jira] Commented: (DERBY-1275) Provide a way to enable client
tracing without changing the application
[ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417349 ]
Kathey Marsden commented on DERBY-1275:
---------------------------------------
I was wondering if anyone had any thoughts on how to implement this improvement to
provide a way to enable client tracing without changing the application
Not being able to turn on tracing in a deployed application without application code changes is a serious supportability issue because unless the application has a mechanism to configure settings like traceDirectory and traceLevel, the application itself my have to be rebuilt to enable client tracing. Even when such a mechanism is provided it takes someone with knowledge of the application to turn it on, again a supportability issue.
All I can think of is supporting System properties like derby.client.traceLevel. We also could mimic our server side mechanism and have a System property derby.client.home that points to a directory where a file derby.client.properties can live and the trace files can go by default. The System property mechanism raises a red flag for me because of class loader issues like we have for derby.system.home. But maybe it is ok because of the diagnostic nature.
I ask this question because I find myself in need to put this into a debug build to send to a user and figure I might as well head down the correct path toward an ultimate solution.
Thoughts?
> 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
> Type: Improvement
> Components: Network Client
> Versions: 10.2.0.0, 10.1.2.3
> Reporter: Kathey Marsden
> Priority: Minor
>
> 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
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client
tracing without changing the application
Posted by David Van Couvering <Da...@Sun.COM>.
IMHO, this is exactly the kind of thing JMX is suited for.
David
Kathey Marsden wrote:
> Sanket Sharma wrote:
>
>> This sounds like a perfect case for JMX soultion and can be added to
>> list of requirements on derby Wiki. Tracing options (enable/disable)
>
> The requirement for this is that we have something that can be turned on
> quickly by the user when talking to tech support so we can easily get
> the traces produced and back for analysis without the need to download
> any additional software or libraries.
> I am sure it would be much more helpful if I knew something about JMX,
> but given those requirements, would JMX work for this?
>
> Kathey
>
>
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client
tracing without changing the application
Posted by Kathey Marsden <km...@sbcglobal.net>.
Sanket Sharma wrote:
> This sounds like a perfect case for JMX soultion and can be added to
> list of requirements on derby Wiki. Tracing options (enable/disable)
The requirement for this is that we have something that can be turned on
quickly by the user when talking to tech support so we can easily get
the traces produced and back for analysis without the need to download
any additional software or libraries.
I am sure it would be much more helpful if I knew something about JMX,
but given those requirements, would JMX work for this?
Kathey
Re: [jira] Commented: (DERBY-1275) Provide a way to enable client tracing without changing the application
Posted by Sanket Sharma <sa...@gmail.com>.
This sounds like a perfect case for JMX soultion and can be added to
list of requirements on derby Wiki. Tracing options (enable/disable)
and perhaps the file name can be exposed as JMX operations. While
debugging the application the developers can start derby in JMX mode
and enable/disable tracing via JConsole.
Comments welcome.
Regards,
Sanket
On 6/23/06, Kathey Marsden (JIRA) <de...@db.apache.org> wrote:
> [ http://issues.apache.org/jira/browse/DERBY-1275?page=comments#action_12417349 ]
>
> Kathey Marsden commented on DERBY-1275:
> ---------------------------------------
>
> I was wondering if anyone had any thoughts on how to implement this improvement to
> provide a way to enable client tracing without changing the application
>
> Not being able to turn on tracing in a deployed application without application code changes is a serious supportability issue because unless the application has a mechanism to configure settings like traceDirectory and traceLevel, the application itself my have to be rebuilt to enable client tracing. Even when such a mechanism is provided it takes someone with knowledge of the application to turn it on, again a supportability issue.
>
> All I can think of is supporting System properties like derby.client.traceLevel. We also could mimic our server side mechanism and have a System property derby.client.home that points to a directory where a file derby.client.properties can live and the trace files can go by default. The System property mechanism raises a red flag for me because of class loader issues like we have for derby.system.home. But maybe it is ok because of the diagnostic nature.
>
> I ask this question because I find myself in need to put this into a debug build to send to a user and figure I might as well head down the correct path toward an ultimate solution.
>
> Thoughts?
>
>
> > 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
> > Type: Improvement
>
> > Components: Network Client
> > Versions: 10.2.0.0, 10.1.2.3
> > Reporter: Kathey Marsden
> > Priority: Minor
>
> >
> > 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
>
>