db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Paging Kathey and Dan: sysinfo for mixed versions
Date Tue, 01 Nov 2005 23:57:01 GMT

Daniel John Debrunner wrote:
> David W. Van Couvering wrote:
>>Hi, Kathey and Dan.  During our discussions on shared code, you had both
>>felt some helpful diagnostic information around mixed versions of Derby
>>would be important.
>>I want to make sure I understand these, so I have quoted them below with
>>questions.   Once I understand them better I can log JIRA items on them.
>>I also would like to know whether these need to be part of the initial
>>submission of shared code or whether they can be subsequent incremental
> Incremental developement is always good, there is no requirement for any
> contribution to completely solve a problem. If a contribution makes any
> progress towards some goal then that's great.

OK.  I was worried that any contribution of shared code without this 
would be considered "broken."

>>1) Kathey's suggestion, with Dan's +1: "Print warnings to the log file
>>when jars are mixed"
>>I am assuming this is done at system bootup time?  What about when the
>>network client driver is first loaded, should I do it then too, for
>>environments where there say multiple network client apps running in the
>>same VM?
>>2) Kathey's suggestion, with Dan's +1: "Provide a way to print sysinfo
>>to the log when classes have been loaded with classloaders"
>>I have to say I don't fully understand this one, can you explain?
> The issue is that currently sysinfo just works against the classpath,
> however its classpath based output may be totally unrelated to the
> environment running Derby, e.g. in an app server environment. This is an
> enhancement to provide some mechanism to dump info similar to the
> current sysinfo output from a running derby system.

OK.  It sounds like this is related to Bryan's bug, DERBY-668, where if 
a jar is loaded by the system classloader we don't report the location 

>>3) Dan's suggestion, in response to (2) above: "some stored procedure
>>version of sysinfo would be good, maybe even one that doesn't require a
>>database, e.g. a sysinfo ping to the network server"
>>It sounds like you want the network client to get the sysinfo for the
>>server, say at startup?  How is this related to (2) above?
> It's a possible (vague) mechanism for 2).

Hm, I don't see how this solves things if the network server is not 
gettings its classes from the classpath...

> Dan.

View raw message