>On Thu, 16 Aug 2001 [EMAIL PROTECTED] wrote:
> >
> > Log4j, however, allows you to use it without > setting the property.
>Back to sandboxed environments, > webapps can't set system properties
>anyway - so
>your Logger will just fail in any secure servlet > container. Or applet.
>
>I meant: with log4j you can set the behavior without using system
>properties. Logger will run in a sandbox if you add few try/catch, but you
>can't customize it.
Ok, well that's easy enough to fix. I just checked in a patch that I think
addresses the security exception concerns you're suggesting. I also added
the ability to change the underlying log implementation via method call, so
there is no need for properties, whether or not you choose to override the
default behavior.
LogSource should run fine in a sandbox as far as I can tell, *and* you can
customize it either via a propery or via method calls. If sandbox issues
get in the way, we just drop back to the NoOpLog.
>Small details - that would only matter later, after few hundred developers
>will use it.
If this is meant to be a joke, I don't get it.
All of this seems like the kind of thing that can be reasonably worked out
after the logging abstraction is commons component but before a 1.0 release.
>Costin
- Rod
PS: I also removed Iterator from the public interface for LogSource, so one
could create a Collections-free implementation easily enough. Indeed, the
public interace of Log/LogSource is now down to java.lang.* classes and
primatives (well, and locally defined classes).
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
