commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: commons-logging auto-detection
Date Sat, 08 Jan 2005 14:01:36 GMT

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.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message