logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Sampaleanu" <colin...@exis.com>
Subject RE: PATCH: modify config file loading to allow custom URL types
Date Fri, 06 Jul 2001 23:55:00 GMT
> -----Original Message-----
> From: Ceki Gülcü [mailto:cgu@qos.ch]
> >- I think (but have no way to verify) your code will actually not work
> >properly on a Mac, since the file separator there is ':' from what I
know,
> >not / or \. This is why my code did a
> >'System.getProperty("file.separator");' to get the file
> separator and look
> >for that. Thinking about it though, my code was also not correct
> for a Mac.
> >It would look for a file separator ':', but a URL will always
> have a ':' as
> >part of the protocol portion, so that instance would have to be ignored.
>
> I don't think many people are running Application Servers on Macs
> but that's just my impression.

Actaully, there will be a lot more people running servers on the Mac, now
that OS X is out. It is quite good. Now to be honest, I don't know if OS X,
being based on BSD, usees '/' as file separators, or the old Mac OS ':'. In
any case, given that System.getProperty("file.separator") exists and is easy
to use, it somehow just doesn't feel right to put out code I know will fail,
even if only a smaller portion of the user base is affected.

> >- The reason I added the other extra code in Category.java was
> to not even
> >consider the ref as a possible class name in the case of the URL
> coming back
> >from a classloader. In this case we know _for sure_ the ref (if
> it exists at
> >all) is not a classname, so we will get in less trouble if we don't even
> >look at it and possibly mistake it for one. Given the fact that it is
> >perfectly legal for other classloaders to return customs URLs with other
> >special handling of the ref field (and our adding the classname there is
> >somewhat of a hack), I thought it was a bit safer to add this extra code.
>
> Err.. you mean in the case the url came from the system
> properties not from the classpath. If I understand correctly, one
> can assume that the reference part must be the fully qualified
> name of a configurator class in case the URL came from the environment.
>
> IMHO, in practice the extra defensive code does not hurt but does
> not really help either. So for the sake of simplicity I think
> it's better to leave it out. Regards, Ceki

Actually you can never _assume_ that the ref portion of a url is a
classname, even if the url came from the environment, given that custom urls
are always legal (unless you want to start differentiating between standard
and custom urls), and Weblogic for example does use them. Running under
Weblogic, it is perfectly ok for me to refer to any file (log4j.properties,
or whatever) via 'zip:whatever', whether I pass that in through the
environment, or as a setting in a config file, or as a value that I get back
from a classloader 'getResource' call. In fact, the only assumption you can
make is that when you do get back a url from a classloader, it will _not_
contain a log4j configurator classname in the ref portion, so that's why my
original code in that case didn't even try to figure out if it was a
classname, to avoid any possible complications with other, unknown url
types... Anyways, hopefully not that big a deal...

Regards,


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


Mime
View raw message