Kathey Marsden wrote:
> > I wonder the best way to get this information from customers if sysinfo > is just meant to be a quick classpath check and not a definiitive > answer to the age old question: "what derby jars am I using?" I think Bryan raised this earlier, what exactly is sysinfo for? In its current form it does a fairly good job as a stand alone utility of reporting: - what derby elements are on the user's class path - what jvm the user executed sysinfo with - what the operating system is But more typically Derby is running in a J2EE server or embedded in another app. In that case the user's classpath or the jvm used to execute sysinfo probably has little to do with the instance of Derby that is running. I think people want to know the version of Derby running to: - determine it's the version the expected to run (Bryan's example of jars in ext folders) - determine what version is running to aid support or debugging an issue. The better approach is to ask Derby itself what version it is running, some possibilities are: SYSINFO command in ij. SYSINFO procedure in the database engine dumping SYSINFO type information to derby.log from engine and network server (as Kathey said) remote SYSINFO command to the network server, maybe this exists already? not sure about a client solution? Now in the case that an application is running Derby, say Apache James, then it's probably near impossible to get a user to call a SYSINFO procedure on the active database. In that case it seems logging the information to derby.log is better. Maybe the information in derby.log doesn't need to as complete as the current sysinfo, the user name and home directory may not be desirable in derby.log. Dan.
