On Fri, 17 Aug 2001, Rodney Waldhoff wrote:
> (As an aside, what kind of an environment are you working in in which you
> can't trust/control the code executing in the same VM? Even applets are
> sandboxed from one another, right?)
Sandbox doesn't help if you have the logger in classpath or equivalent.
Any applet ( or servlet ) would be able to do whatever it wants and mess
with logs from components and other applets.
Of course, this wouldn't matter - but what if you use the logger for
access logs ? Or maybe you have a server and you don't want customer A to
know what problems some B has.
And you must install the logger in classpath ( or equivalent ) if your
application runs in a sandbox - or you have to give write or
network permissions to the entire application.
> >2. (major)Using system properties to create the logger... What if you're in
> >a sandbox ? How many system properties do we need ? ( IMHO system
> >properties are over abused, they are nice but using them as the only
> >mechanism is not that good ).
>
> It's only if you want to use a different logging implemenation that you'll
> need to add a *single* property indicating the name of the Log
> implementation you'd like to use, and if we wanted to make the defaults a
> little more clever, e.g., if log4j, then if logkit, then if merlin or
> whatever, we could do that.
And log4j needs a single property, and so on. Every package needs a single
property, and this is not the best way - just a quick solution.
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.
But it'll work fine in standalone applications, if the user is willing to
type few -D ( or edit some scripts, etc ).
Ok, enough time on logging - I have a lot of work to do.
Costin
