At 19:55 06.07.2001 -0400, Colin Sampaleanu wrote:
>> -----Original Message-----
>> From: Ceki Gülcü [mailto:[EMAIL PROTECTED]]
>> >- 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.
Very good point.
>> >- 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...
No, no, you are right. I was missing the whole point. Here is how I
understand the problem now.
Case 1)
The user passes a URL as a system property when launching the
application. This is the only case where the reference part of the URL
can be the fully qualified name of a configurator.
Case 2)
The URL is loaded by a classloader. In this case, the reference part
can specify the properties file as a resource contained in a zip file
or on the network or where have you. In this case, the reference part
is never the fully qualified name of a custom configurator.
Thanks for your explanations. Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
