Kathey Marsden wrote: > We need, I think, to discourage jar mixing by changing the > documentation to encourage application developers to use classloaders to > insulate their application and protect others from it,
-1 : Derby needs to be easy to use, requiring developers to use class loaders is too much. We must follow the standard JDBC driver/data source paradigm, not have any additional requirements. If it's a problem, then Derby should handle it internally. (no idea how, I just talking general principles here). > printing warnings > to the log file when jars are mixed +1 : I do think Derby should refuse to boot if the network server jar does not match the embedded jar. > or there is more than one copy or > version of derby in the classpath, -0 : hard to rely on, since class path is not the only loading mechanism. providing a way to print sysinfo to > the log when classes have been loaded with classloaders +1 - 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 could report version info. Dan.
