On 7 Jan 2005, at 08:43, Paul Libbrecht wrote:
Le 6 janv. 05, à 22:46, robert burrell donkin a écrit :
given the extra layer proposed, the discovery/configuration mechanism that should be employed for the JVM would be set by a system property
Careful to offer one alternative to system properties... (maybe like a LoggingProperties class which does not load any other class): System properties are often not readable and not writable in some environments and commons-logging has been quite much sandbox-friendly thus far...
i haven't been able to think of any general mechanism for JVM level configuration that would work well in strongly sandboxed environments. it's critical that the base API classes are very portable and small. i'd be glad to hear of any suitable alternatives...
at the moment, if the system property cannot be read, it will be ignored. this behaviour would be retained. it would then default to trying to load LogFactory (for backwards compatibility) and use that for discovery (thus defaulting to the current behaviour). if LogFactory cannot be loaded, it would fall back on a very simple logging implementation (which would probably print ERROR and FATAL to System.err).
IIRC in these kinds of environments the JCL currently has many issues. i've proposed that the general solution for heavily secured environments (such as untrusted applets) would be to dope the application (using byte code engineering) so that all references to JCL are rewired to a logger appropriate to that environment (one which would, for example, just print ERROR and FATAL level messages to System.err). i believe that this would allow JCL to be used successfully in a much wider variety of environments.
We use JCL in both untrusted and signed applets. There used to be issues with the sandbox before, but with the release of 1.0.4 these issues are gone.
-- Dennis Lundberg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
