You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Ceki Gülcü <cg...@qos.ch> on 2001/06/27 20:26:39 UTC
Re: modifying config file loading code so it can handle custom
URL types with 'ref' section
Colin,
Thanks for the info. A slightly different solution is to have OptionConverter.selectAndConfigure leave the reference part alone of it contains slashes instead of dots. Your patch is most welcome. Ceki
At 17:54 27.06.2001 +0000, Colin Sampaleanu wrote:
>I would like to suggest that the code which is reponsible for the loading of
>a property file (or XML configuration file) be modified somewhat, since
>presently it can not handle custom URL types.
>Right now, the static init method in Category establishes a URL for the
>property file, either from a value explicitly set in a "log4j.configuration"
>system variable, or by asking the classloader to find the the
>"log4j.properties" file. Once it has the URL, it then calls
>OptionConverter.selectAndConfigure(url, defaultHierarchy);
>OptionConverter then takes a look at the URL, and if it has a 'ref' portion,
>assumes that that is the classname of a custom configurator class, and tries
>to instantiate that class to handle the config file.
>The problem with this scheme is that it can't handle URLs in which the 'ref'
>portion is actually relevant to accessing the file.
>If I have a Servlet Web App in a .WAR file and deploy it to WebLogic 6,
>WebLogic will never actually expand out the log4j.properties file that is in
>the /WEB-INF/classes dir inside the .WAR file. It has a custom classloader
>and zip url handler that knows how to load files from within the war file.
>So when the classloader is asked for the URL of log4j.properties, it returns
>something like:
>zip:D:/dev/bea/wlserver6.0/config/mydomain/applications/.wl_temp_do_not_dele
>te/wl_local_comp7017.war#WEB-INF/classes/log4j.properties
>OptionConverter then blows up on this since it assumes there is a custom
>configurator class called 'WEB-INF/classes/log4j.properties', and blows up
>when it can't load it.
>It would be pretty simple to fix this, by checking the URL returned from the
>classloader, and if it has a 'ref' section, then calling OptionConverter
>with an option saying to not treat the 'ref' as a configurator class.
>If people are in agreement with this, I am willing to make changes and post
>them as patches...
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: PATCH: modify config file loading to allow custom URL types
Posted by Colin Sampaleanu <co...@exis.com>.
Ceki,
Your code works fine on my machine. A few comments:
- I would take out the reference to WebLogic and make it say something like
"...assuming custom URL", given the fact that it is perfectly legal to
define custom URLs and associated handlers, in a running envrionment.
- 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.
-
----- Original Message -----
From: "Ceki Gülcü" <cg...@qos.ch>
To: "LOG4J Developers Mailing List" <lo...@jakarta.apache.org>
Sent: Thursday, July 05, 2001 12:54 PM
Subject: Re: PATCH: modify config file loading to allow custom URL types
Colin,
I modified OptionConverter.java as follows:
static
public
void selectAndConfigure(URL url, Hierarchy hierarchy) {
String clazz = url.getRef();
if (clazz.indexOf('.') == -1 || clazz.indexOf('/') != -1 ||
clazz.indexOf('\\') != -1) {
LogLog.warn("Suspicious reference part in URL ["+url+
"] will ignore refence part assuming BEA Weblogic
environment.");
clazz = null;
}
Configurator configurator = null;
if(clazz != null) {
LogLog.debug("Preferred configurator class: " + clazz);
....
}
Category.java remains unchanged. Can you please double check that my
simplified patch works.
You can get the latest code from our CVS repository. Best regards, Ceki
At 14:20 29.06.2001 +0000, you wrote:
>(same patch as before, but diffed using -u option...)
>
>>As per my previous email with Ceki, this patch modifies the configuration
file loading code so that while still allowing a 'ref' or anchor portion of
a URL to specify a class name for a custom configurator, it can also work
with custom URL schemes such as used in WebLogic to specify a file within an
archive, e.g.
>>zip:/part1/part2/whatever.war#WEB-INF/classes/log4j.properties
>>With the new code, for the ref portion of a URL to be considered a
classname, it must consist of at least one package element and one classname
element (e.g. mypackage.Myclass), and must not have the file separator
character in it. Also, when the URL comes from a classloader as opposed to a
system properly, the code will never consider the ref to be a classname,
since that wouldn't make sense (e.g. in this case the ref will always be
part of a custom URL).
>
>Index: Category.java
>===================================================================
>RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/Category.java,v
>retrieving revision 1.35
>diff -w -u -r1.35 Category.java
>--- Category.java 2001/06/26 19:40:05 1.35
>+++ Category.java 2001/06/29 14:12:44
>@@ -131,12 +131,16 @@
>
>DEFAULT_CONFIGURATION_KEY,
>
DEFAULT_CONFIGURATION_FILE);
> URL url = null;
>+ boolean urlRefMayBeConfigurator = true;
> try {
>- // so, resource is not a URL:
>- // attempt to get the resource from the class path
> url = new URL(resource);
> } catch (MalformedURLException ex) {
>+ // if resource is not a URL then
>+ // attempt to get the resource from the class path
> url = Loader.getResource(resource, Category.class);
>+ // any ref portion in URL returned by classload is specific to
that URL,
>+ // not a Configurator class name
>+ urlRefMayBeConfigurator = false;
> }
>
> // If we have a non-null url, then delegate the rest of the
>@@ -144,7 +148,7 @@
> // method.
> if(url != null) {
> LogLog.debug("Using URL ["+url+"] for automatic log4j
configuration.");
>- OptionConverter.selectAndConfigure(url, defaultHierarchy);
>+ OptionConverter.selectAndConfigure(url, urlRefMayBeConfigurator,
defaultHierarchy);
> } else {
> LogLog.debug("Could not find resource: ["+resource+"].");
> }
>Index: helpers/OptionConverter.java
>===================================================================
>RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/helpers/OptionConver
ter.java,v
>retrieving revision 1.17
>diff -w -u -r1.17 OptionConverter.java
>--- helpers/OptionConverter.java 2001/06/20 07:59:46 1.17
>+++ helpers/OptionConverter.java 2001/06/29 14:12:45
>@@ -399,9 +399,16 @@
> /**
> Configure log4j given a URL.
>- <p>The URL format is important. Its <em>reference</em> part is
>- taken as the class name of the configurator. For example, if you
>- invoke your application using the command line
>+ <p>The URL format is important. If the
<em>urlRefMayBeConfigurator</em>
>+ param is true, then its <em>reference</em> part (if any) is
potentially
>+ considered to be the class name of the configurator. Since the ref
part
>+ may also be used by some custom URL types (e.g. to qualify a specific
file
>+ within another archive file), for the ref string to be considered a
class
>+ name, it must be a fully qualified class name including at least one
>+ package, and must not contain any file separator characters such as
'/' or
>+ '\' since those would never be part of a valid class name, and are a
strong
>+ indication of a custom URL type. For example, if you invoke your
>+ application using the command line
> <pre>
java -Dlog4j.configuration=file:/temp/myconfig.xyz#com.myCompany.myConfigura
tor
> </pre>
>@@ -412,8 +419,8 @@
> configurator you specify <em>must</em> implement the {@link
> Configurator} interface.
>- <p>If the URL has no reference part, then the {@link
>- PropertyConfigurator} will parse the URL. However, if the URL
>+ <p>If no configurator is specified via a URL reference part, then the
>+ {@link PropertyConfigurator} will parse the URL. However, if the URL
> ends with a ".xml" extension, then the {@link DOMConfigurator}
> will be used to parse the URL.
>@@ -425,12 +432,29 @@
> @since 1.0 */
> static
> public
>- void selectAndConfigure(URL url, Hierarchy hierarchy) {
>- String clazz = url.getRef();
>+ void selectAndConfigure(URL url, boolean urlRefMayBeConfigurator,
>+ Hierarchy hierarchy) {
>+
>+ // assume a 'ref' portion of a URL may be Configurator class
>+ String clazz = null;
>+ if (urlRefMayBeConfigurator) {
>+ clazz = url.getRef();
>+ if (clazz != null) {
>+ String fileSep = "/";
>+ try { fileSep = System.getProperty("file.separator"); }
catch(Exception e) {}
>+ // it's only a class name if it has a period somewhere in it, and
it's
>+ // not a class name if it has a file separator (explicitly check
both
>+ // unix and windows versions since Java itself will always allow
them
>+ // regardless of actual platform)
>+ if (clazz.indexOf('.') == -1 || clazz.indexOf(fileSep) != -1 ||
>+ clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1)
>+ clazz = null;
>+ }
>+ }
> Configurator configurator = null;
>- if(clazz != null) {
>+ if (clazz != null && clazz.length() > 0) {
> LogLog.debug("Preferred configurator class: " + clazz);
> configurator = (Configurator) instantiateByClassName(clazz,
>
Configurator.class,
>@@ -440,6 +464,11 @@
> return;
> }
> } else {
>+ // hmm, this test is actually no longer valid if we have a custom
URL type
>+ // such as:
>+ // 'zip:/a/b/c/d.war#e/f/log4j.properties'
>+ // which is what a custom classloader like WebLogic's may return as
a URL
>+ // reference to a file inside of an archive
> String filename = url.getFile();
> if(filename != null && filename.endsWith(".xml")) {
> try {
>@@ -455,4 +484,16 @@
> configurator.doConfigure(url, hierarchy);
> }
>+
>+
>+ /**
>+ Configure log4j given a URL.
>+ This method signature maintained for compatibility
>+ */
>+ static
>+ public
>+ void selectAndConfigure(URL url, Hierarchy hierarchy) {
>+ selectAndConfigure(url, true, hierarchy);
>+ }
>+
>}
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: e-mail Appender?
Posted by Jesse Kuhnert <jk...@ekosystems.com>.
Damn...Oops...Just discovered that someone already did it(SMTPAppender).
( Oh well, sorry for the post, and please ignore previous comments.
Jesse
----- Original Message -----
From: "Jesse Kuhnert" <jk...@ekosystems.com>
To: "LOG4J Developers Mailing List" <lo...@jakarta.apache.org>
Sent: Saturday, July 07, 2001 8:11 PM
Subject: e-mail Appender?
> I've created a little e-mail appender that sends e-mail out to a
> specific/series of e-mail addresses depending on the log-level. (We get
all
> error/fatal). I'm not sure if anyone is interested in something like this,
> because in most cases it would probably be more like spam than help. :) We
> have to maintain our product after we release it, so this just makes it
much
> easier than asking a DFU what is going on.
>
> The code is a little dirty, but I can clean it all up if you guys want it.
> (I think maybe the SendMail methods don't need to be synchronized, only
the
> init...) It uses Sun's JavaMail api as the underlying mechanism for
sending
> the mail. Not sure where I should post the files, I'll attach the two Java
> files, and post the log4j xml config used below.
>
> btw, Log4j kicks ass! (Although more/any appender creation documentation
> would've been helpful...I can create a small one if you guys think it's
> helpful, although my ~wordy~ skills are not quite up to par with my
coding.
> :).
>
> Jesse
>
> ============================================
> Sample log4j xml file configuration(the one we use)
> ============================================
>
> <?xml version="1.0" encoding="UTF-8" ?>
> <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
>
> <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
>
> <appender name="ASYNC" class="org.apache.log4j.AsyncAppender">
> <appender-ref ref="MAIL"/>
> </appender>
>
> <appender name="MAIL" class="com.frontiers.server.mail.MailAppender">
> <param name="Threshold" value="ERROR" />
>
> <param name="To" value="jkuhnert@ekosystems.com ,
> someonelse@ekosystems.com, etcc@etc.com" />
> <param name="Subject" value="Error from CaseServer!!" />
> <param name="From" value="caseserver@xxx.com" />
> <param name="Location" value="CaseServer at X company. I.P. address:
> 10.1.1.44" />
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d{ISO8601}
%-5p
> %c{1} - %m%n"/>
> </layout>
> </appender>
>
> <appender name="A1"
> class="org.apache.log4j.DailyRollingFileAppender">
> <param name="File" value="./log/appserver.log" />
> <param name="Append" value="true" />
> <param name="DatePattern" value="'.'dd" />
>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d{ISO8601} %-5p
> %c{1} - %m%n"/>
> </layout>
>
> <filter class="org.apache.log4j.varia.PriorityRangeFilter">
> <param name="PriorityMin" value="DEBUG" />
> <param name="PriorityMax" value="WARN" />
> <param name="AcceptOnMatch" value="true" />
> </filter>
> </appender>
>
> <appender name="A2"
> class="org.apache.log4j.DailyRollingFileAppender">
> <param name="File" value="./log/error.log" />
> <param name="Append" value="true" />
> <param name="DatePattern" value="'.'dd" />
> <param name="Threshold" value="ERROR" />
>
> <layout class="org.apache.log4j.PatternLayout">
> <param name="ConversionPattern" value="%d{ISO8601}
%-5p
> %c{1} - %m%n"/>
> </layout>
> </appender>
>
> <root>
> <priority value ="debug" />
> <appender-ref ref="A1" />
> <appender-ref ref="A2" />
> <appender-ref ref="ASYNC"/>
> </root>
> </log4j:configuration>
>
>
----------------------------------------------------------------------------
----
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
e-mail Appender?
Posted by Jesse Kuhnert <jk...@ekosystems.com>.
I've created a little e-mail appender that sends e-mail out to a
specific/series of e-mail addresses depending on the log-level. (We get all
error/fatal). I'm not sure if anyone is interested in something like this,
because in most cases it would probably be more like spam than help. :) We
have to maintain our product after we release it, so this just makes it much
easier than asking a DFU what is going on.
The code is a little dirty, but I can clean it all up if you guys want it.
(I think maybe the SendMail methods don't need to be synchronized, only the
init...) It uses Sun's JavaMail api as the underlying mechanism for sending
the mail. Not sure where I should post the files, I'll attach the two Java
files, and post the log4j xml config used below.
btw, Log4j kicks ass! (Although more/any appender creation documentation
would've been helpful...I can create a small one if you guys think it's
helpful, although my ~wordy~ skills are not quite up to par with my coding.
:).
Jesse
============================================
Sample log4j xml file configuration(the one we use)
============================================
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/">
<appender name="ASYNC" class="org.apache.log4j.AsyncAppender">
<appender-ref ref="MAIL"/>
</appender>
<appender name="MAIL" class="com.frontiers.server.mail.MailAppender">
<param name="Threshold" value="ERROR" />
<param name="To" value="jkuhnert@ekosystems.com ,
someonelse@ekosystems.com, etcc@etc.com" />
<param name="Subject" value="Error from CaseServer!!" />
<param name="From" value="caseserver@xxx.com" />
<param name="Location" value="CaseServer at X company. I.P. address:
10.1.1.44" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-5p
%c{1} - %m%n"/>
</layout>
</appender>
<appender name="A1"
class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="./log/appserver.log" />
<param name="Append" value="true" />
<param name="DatePattern" value="'.'dd" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-5p
%c{1} - %m%n"/>
</layout>
<filter class="org.apache.log4j.varia.PriorityRangeFilter">
<param name="PriorityMin" value="DEBUG" />
<param name="PriorityMax" value="WARN" />
<param name="AcceptOnMatch" value="true" />
</filter>
</appender>
<appender name="A2"
class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="./log/error.log" />
<param name="Append" value="true" />
<param name="DatePattern" value="'.'dd" />
<param name="Threshold" value="ERROR" />
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d{ISO8601} %-5p
%c{1} - %m%n"/>
</layout>
</appender>
<root>
<priority value ="debug" />
<appender-ref ref="A1" />
<appender-ref ref="A2" />
<appender-ref ref="ASYNC"/>
</root>
</log4j:configuration>
RE: PATCH: modify config file loading to allow custom URL types
Posted by Ceki Gülcü <cg...@qos.ch>.
At 19:55 06.07.2001 -0400, Colin Sampaleanu wrote:
>> -----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.
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: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
RE: PATCH: modify config file loading to allow custom URL types
Posted by Colin Sampaleanu <co...@exis.com>.
> -----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
Re: PATCH: modify config file loading to allow custom URL types
Posted by Ceki Gülcü <cg...@qos.ch>.
At 14:49 06.07.2001 -0400, you wrote:
>Ceki,
>
>Your version of the code works fine on my machine. A few comments:
>- I would take out the reference to WebLogic and make it say something like
>"...assuming custom URL", given the fact that it is perfectly legal to
>define custom URLs and associated handlers, in a running envrionment.
OK.
>- 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.
>- 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
>----- Original Message -----
>From: "Ceki Gülcü" <cg...@qos.ch>
>To: "LOG4J Developers Mailing List" <lo...@jakarta.apache.org>
>Sent: Thursday, July 05, 2001 12:54 PM
>Subject: Re: PATCH: modify config file loading to allow custom URL types
>
>
>Colin,
>
>I modified OptionConverter.java as follows:
>
> static
> public
> void selectAndConfigure(URL url, Hierarchy hierarchy) {
> String clazz = url.getRef();
>
> if (clazz.indexOf('.') == -1 || clazz.indexOf('/') != -1 ||
>clazz.indexOf('\\') != -1) {
> LogLog.warn("Suspicious reference part in URL ["+url+
> "] will ignore refence part assuming BEA Weblogic
>environment.");
> clazz = null;
> }
>
>
> Configurator configurator = null;
>
> if(clazz != null) {
> LogLog.debug("Preferred configurator class: " + clazz);
> ....
>
> }
>
>Category.java remains unchanged. Can you please double check that my
>simplified patch works.
>You can get the latest code from our CVS repository. Best regards, Ceki
>
>At 14:20 29.06.2001 +0000, you wrote:
>>(same patch as before, but diffed using -u option...)
>>
>>>As per my previous email with Ceki, this patch modifies the configuration
>file loading code so that while still allowing a 'ref' or anchor portion of
>a URL to specify a class name for a custom configurator, it can also work
>with custom URL schemes such as used in WebLogic to specify a file within an
>archive, e.g.
>>>zip:/part1/part2/whatever.war#WEB-INF/classes/log4j.properties
>>>With the new code, for the ref portion of a URL to be considered a
>classname, it must consist of at least one package element and one classname
>element (e.g. mypackage.Myclass), and must not have the file separator
>character in it. Also, when the URL comes from a classloader as opposed to a
>system properly, the code will never consider the ref to be a classname,
>since that wouldn't make sense (e.g. in this case the ref will always be
>part of a custom URL).
>>
>>Index: Category.java
>>===================================================================
>>RCS file:
>/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/Category.java,v
>>retrieving revision 1.35
>>diff -w -u -r1.35 Category.java
>>--- Category.java 2001/06/26 19:40:05 1.35
>>+++ Category.java 2001/06/29 14:12:44
>>@@ -131,12 +131,16 @@
>>
>>DEFAULT_CONFIGURATION_KEY,
>>
>DEFAULT_CONFIGURATION_FILE);
>> URL url = null;
>>+ boolean urlRefMayBeConfigurator = true;
>> try {
>>- // so, resource is not a URL:
>>- // attempt to get the resource from the class path
>> url = new URL(resource);
>> } catch (MalformedURLException ex) {
>>+ // if resource is not a URL then
>>+ // attempt to get the resource from the class path
>> url = Loader.getResource(resource, Category.class);
>>+ // any ref portion in URL returned by classload is specific to
>that URL,
>>+ // not a Configurator class name
>>+ urlRefMayBeConfigurator = false;
>> }
>>
>> // If we have a non-null url, then delegate the rest of the
>>@@ -144,7 +148,7 @@
>> // method.
>> if(url != null) {
>> LogLog.debug("Using URL ["+url+"] for automatic log4j
>configuration.");
>>- OptionConverter.selectAndConfigure(url, defaultHierarchy);
>>+ OptionConverter.selectAndConfigure(url, urlRefMayBeConfigurator,
>defaultHierarchy);
>> } else {
>> LogLog.debug("Could not find resource: ["+resource+"].");
>> }
>>Index: helpers/OptionConverter.java
>>===================================================================
>>RCS file:
>/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/helpers/OptionConver
>ter.java,v
>>retrieving revision 1.17
>>diff -w -u -r1.17 OptionConverter.java
>>--- helpers/OptionConverter.java 2001/06/20 07:59:46 1.17
>>+++ helpers/OptionConverter.java 2001/06/29 14:12:45
>>@@ -399,9 +399,16 @@
>> /**
>> Configure log4j given a URL.
>>- <p>The URL format is important. Its <em>reference</em> part is
>>- taken as the class name of the configurator. For example, if you
>>- invoke your application using the command line
>>+ <p>The URL format is important. If the
><em>urlRefMayBeConfigurator</em>
>>+ param is true, then its <em>reference</em> part (if any) is
>potentially
>>+ considered to be the class name of the configurator. Since the ref
>part
>>+ may also be used by some custom URL types (e.g. to qualify a specific
>file
>>+ within another archive file), for the ref string to be considered a
>class
>>+ name, it must be a fully qualified class name including at least one
>>+ package, and must not contain any file separator characters such as
>'/' or
>>+ '\' since those would never be part of a valid class name, and are a
>strong
>>+ indication of a custom URL type. For example, if you invoke your
>>+ application using the command line
>> <pre>
>java -Dlog4j.configuration=file:/temp/myconfig.xyz#com.myCompany.myConfigura
>tor
>> </pre>
>>@@ -412,8 +419,8 @@
>> configurator you specify <em>must</em> implement the {@link
>> Configurator} interface.
>>- <p>If the URL has no reference part, then the {@link
>>- PropertyConfigurator} will parse the URL. However, if the URL
>>+ <p>If no configurator is specified via a URL reference part, then the
>>+ {@link PropertyConfigurator} will parse the URL. However, if the URL
>> ends with a ".xml" extension, then the {@link DOMConfigurator}
>> will be used to parse the URL.
>>@@ -425,12 +432,29 @@
>> @since 1.0 */
>> static
>> public
>>- void selectAndConfigure(URL url, Hierarchy hierarchy) {
>>- String clazz = url.getRef();
>>+ void selectAndConfigure(URL url, boolean urlRefMayBeConfigurator,
>>+ Hierarchy hierarchy) {
>>+
>>+ // assume a 'ref' portion of a URL may be Configurator class
>>+ String clazz = null;
>>+ if (urlRefMayBeConfigurator) {
>>+ clazz = url.getRef();
>>+ if (clazz != null) {
>>+ String fileSep = "/";
>>+ try { fileSep = System.getProperty("file.separator"); }
>catch(Exception e) {}
>>+ // it's only a class name if it has a period somewhere in it, and
>it's
>>+ // not a class name if it has a file separator (explicitly check
>both
>>+ // unix and windows versions since Java itself will always allow
>them
>>+ // regardless of actual platform)
>>+ if (clazz.indexOf('.') == -1 || clazz.indexOf(fileSep) != -1 ||
>>+ clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1)
>>+ clazz = null;
>>+ }
>>+ }
>> Configurator configurator = null;
>>- if(clazz != null) {
>>+ if (clazz != null && clazz.length() > 0) {
>> LogLog.debug("Preferred configurator class: " + clazz);
>> configurator = (Configurator) instantiateByClassName(clazz,
>>
>Configurator.class,
>>@@ -440,6 +464,11 @@
>> return;
>> }
>> } else {
>>+ // hmm, this test is actually no longer valid if we have a custom
>URL type
>>+ // such as:
>>+ // 'zip:/a/b/c/d.war#e/f/log4j.properties'
>>+ // which is what a custom classloader like WebLogic's may return as
>a URL
>>+ // reference to a file inside of an archive
>> String filename = url.getFile();
>> if(filename != null && filename.endsWith(".xml")) {
>> try {
>>@@ -455,4 +484,16 @@
>> configurator.doConfigure(url, hierarchy);
>> }
>>+
>>+
>>+ /**
>>+ Configure log4j given a URL.
>>+ This method signature maintained for compatibility
>>+ */
>>+ static
>>+ public
>>+ void selectAndConfigure(URL url, Hierarchy hierarchy) {
>>+ selectAndConfigure(url, true, hierarchy);
>>+ }
>>+
>>}
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>>
>
>--
>Ceki Gülcü
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: PATCH: modify config file loading to allow custom URL types
Posted by Colin Sampaleanu <co...@exis.com>.
Hi,
Unfortunately I have to take back my comment about this code being ok. My
original patch worked both in and outside of WebLogic. I only tried your
patch inside WL (with a prop file in a .WAR archive, which forces the custom
URL to be used), where it worked fine. Unfortunately your code will get a
null pointer exception outside. You need to check the return value from
getRef() for a null, as my original code did...
Regards,
Colin
----- Original Message -----
From: "Ceki Gülcü" <cg...@qos.ch>
To: "LOG4J Developers Mailing List" <lo...@jakarta.apache.org>
Sent: Thursday, July 05, 2001 12:54 PM
Subject: Re: PATCH: modify config file loading to allow custom URL types
Colin,
I modified OptionConverter.java as follows:
static
public
void selectAndConfigure(URL url, Hierarchy hierarchy) {
String clazz = url.getRef();
if (clazz.indexOf('.') == -1 || clazz.indexOf('/') != -1 ||
clazz.indexOf('\\') != -1) {
LogLog.warn("Suspicious reference part in URL ["+url+
"] will ignore refence part assuming BEA Weblogic
environment.");
clazz = null;
}
Configurator configurator = null;
if(clazz != null) {
LogLog.debug("Preferred configurator class: " + clazz);
....
}
Category.java remains unchanged. Can you please double check that my
simplified patch works.
You can get the latest code from our CVS repository. Best regards, Ceki
At 14:20 29.06.2001 +0000, you wrote:
>(same patch as before, but diffed using -u option...)
>
>>As per my previous email with Ceki, this patch modifies the configuration
file loading code so that while still allowing a 'ref' or anchor portion of
a URL to specify a class name for a custom configurator, it can also work
with custom URL schemes such as used in WebLogic to specify a file within an
archive, e.g.
>>zip:/part1/part2/whatever.war#WEB-INF/classes/log4j.properties
>>With the new code, for the ref portion of a URL to be considered a
classname, it must consist of at least one package element and one classname
element (e.g. mypackage.Myclass), and must not have the file separator
character in it. Also, when the URL comes from a classloader as opposed to a
system properly, the code will never consider the ref to be a classname,
since that wouldn't make sense (e.g. in this case the ref will always be
part of a custom URL).
>
>Index: Category.java
>===================================================================
>RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/Category.java,v
>retrieving revision 1.35
>diff -w -u -r1.35 Category.java
>--- Category.java 2001/06/26 19:40:05 1.35
>+++ Category.java 2001/06/29 14:12:44
>@@ -131,12 +131,16 @@
>
>DEFAULT_CONFIGURATION_KEY,
>
DEFAULT_CONFIGURATION_FILE);
> URL url = null;
>+ boolean urlRefMayBeConfigurator = true;
> try {
>- // so, resource is not a URL:
>- // attempt to get the resource from the class path
> url = new URL(resource);
> } catch (MalformedURLException ex) {
>+ // if resource is not a URL then
>+ // attempt to get the resource from the class path
> url = Loader.getResource(resource, Category.class);
>+ // any ref portion in URL returned by classload is specific to
that URL,
>+ // not a Configurator class name
>+ urlRefMayBeConfigurator = false;
> }
>
> // If we have a non-null url, then delegate the rest of the
>@@ -144,7 +148,7 @@
> // method.
> if(url != null) {
> LogLog.debug("Using URL ["+url+"] for automatic log4j
configuration.");
>- OptionConverter.selectAndConfigure(url, defaultHierarchy);
>+ OptionConverter.selectAndConfigure(url, urlRefMayBeConfigurator,
defaultHierarchy);
> } else {
> LogLog.debug("Could not find resource: ["+resource+"].");
> }
>Index: helpers/OptionConverter.java
>===================================================================
>RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/helpers/OptionConver
ter.java,v
>retrieving revision 1.17
>diff -w -u -r1.17 OptionConverter.java
>--- helpers/OptionConverter.java 2001/06/20 07:59:46 1.17
>+++ helpers/OptionConverter.java 2001/06/29 14:12:45
>@@ -399,9 +399,16 @@
> /**
> Configure log4j given a URL.
>- <p>The URL format is important. Its <em>reference</em> part is
>- taken as the class name of the configurator. For example, if you
>- invoke your application using the command line
>+ <p>The URL format is important. If the
<em>urlRefMayBeConfigurator</em>
>+ param is true, then its <em>reference</em> part (if any) is
potentially
>+ considered to be the class name of the configurator. Since the ref
part
>+ may also be used by some custom URL types (e.g. to qualify a specific
file
>+ within another archive file), for the ref string to be considered a
class
>+ name, it must be a fully qualified class name including at least one
>+ package, and must not contain any file separator characters such as
'/' or
>+ '\' since those would never be part of a valid class name, and are a
strong
>+ indication of a custom URL type. For example, if you invoke your
>+ application using the command line
> <pre>
java -Dlog4j.configuration=file:/temp/myconfig.xyz#com.myCompany.myConfigura
tor
> </pre>
>@@ -412,8 +419,8 @@
> configurator you specify <em>must</em> implement the {@link
> Configurator} interface.
>- <p>If the URL has no reference part, then the {@link
>- PropertyConfigurator} will parse the URL. However, if the URL
>+ <p>If no configurator is specified via a URL reference part, then the
>+ {@link PropertyConfigurator} will parse the URL. However, if the URL
> ends with a ".xml" extension, then the {@link DOMConfigurator}
> will be used to parse the URL.
>@@ -425,12 +432,29 @@
> @since 1.0 */
> static
> public
>- void selectAndConfigure(URL url, Hierarchy hierarchy) {
>- String clazz = url.getRef();
>+ void selectAndConfigure(URL url, boolean urlRefMayBeConfigurator,
>+ Hierarchy hierarchy) {
>+
>+ // assume a 'ref' portion of a URL may be Configurator class
>+ String clazz = null;
>+ if (urlRefMayBeConfigurator) {
>+ clazz = url.getRef();
>+ if (clazz != null) {
>+ String fileSep = "/";
>+ try { fileSep = System.getProperty("file.separator"); }
catch(Exception e) {}
>+ // it's only a class name if it has a period somewhere in it, and
it's
>+ // not a class name if it has a file separator (explicitly check
both
>+ // unix and windows versions since Java itself will always allow
them
>+ // regardless of actual platform)
>+ if (clazz.indexOf('.') == -1 || clazz.indexOf(fileSep) != -1 ||
>+ clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1)
>+ clazz = null;
>+ }
>+ }
> Configurator configurator = null;
>- if(clazz != null) {
>+ if (clazz != null && clazz.length() > 0) {
> LogLog.debug("Preferred configurator class: " + clazz);
> configurator = (Configurator) instantiateByClassName(clazz,
>
Configurator.class,
>@@ -440,6 +464,11 @@
> return;
> }
> } else {
>+ // hmm, this test is actually no longer valid if we have a custom
URL type
>+ // such as:
>+ // 'zip:/a/b/c/d.war#e/f/log4j.properties'
>+ // which is what a custom classloader like WebLogic's may return as
a URL
>+ // reference to a file inside of an archive
> String filename = url.getFile();
> if(filename != null && filename.endsWith(".xml")) {
> try {
>@@ -455,4 +484,16 @@
> configurator.doConfigure(url, hierarchy);
> }
>+
>+
>+ /**
>+ Configure log4j given a URL.
>+ This method signature maintained for compatibility
>+ */
>+ static
>+ public
>+ void selectAndConfigure(URL url, Hierarchy hierarchy) {
>+ selectAndConfigure(url, true, hierarchy);
>+ }
>+
>}
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: PATCH: modify config file loading to allow custom URL types
Posted by Colin Sampaleanu <co...@exis.com>.
Ceki,
Your version of the code works fine on my machine. A few comments:
- I would take out the reference to WebLogic and make it say something like
"...assuming custom URL", given the fact that it is perfectly legal to
define custom URLs and associated handlers, in a running envrionment.
- 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.
- 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.
----- Original Message -----
From: "Ceki Gülcü" <cg...@qos.ch>
To: "LOG4J Developers Mailing List" <lo...@jakarta.apache.org>
Sent: Thursday, July 05, 2001 12:54 PM
Subject: Re: PATCH: modify config file loading to allow custom URL types
Colin,
I modified OptionConverter.java as follows:
static
public
void selectAndConfigure(URL url, Hierarchy hierarchy) {
String clazz = url.getRef();
if (clazz.indexOf('.') == -1 || clazz.indexOf('/') != -1 ||
clazz.indexOf('\\') != -1) {
LogLog.warn("Suspicious reference part in URL ["+url+
"] will ignore refence part assuming BEA Weblogic
environment.");
clazz = null;
}
Configurator configurator = null;
if(clazz != null) {
LogLog.debug("Preferred configurator class: " + clazz);
....
}
Category.java remains unchanged. Can you please double check that my
simplified patch works.
You can get the latest code from our CVS repository. Best regards, Ceki
At 14:20 29.06.2001 +0000, you wrote:
>(same patch as before, but diffed using -u option...)
>
>>As per my previous email with Ceki, this patch modifies the configuration
file loading code so that while still allowing a 'ref' or anchor portion of
a URL to specify a class name for a custom configurator, it can also work
with custom URL schemes such as used in WebLogic to specify a file within an
archive, e.g.
>>zip:/part1/part2/whatever.war#WEB-INF/classes/log4j.properties
>>With the new code, for the ref portion of a URL to be considered a
classname, it must consist of at least one package element and one classname
element (e.g. mypackage.Myclass), and must not have the file separator
character in it. Also, when the URL comes from a classloader as opposed to a
system properly, the code will never consider the ref to be a classname,
since that wouldn't make sense (e.g. in this case the ref will always be
part of a custom URL).
>
>Index: Category.java
>===================================================================
>RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/Category.java,v
>retrieving revision 1.35
>diff -w -u -r1.35 Category.java
>--- Category.java 2001/06/26 19:40:05 1.35
>+++ Category.java 2001/06/29 14:12:44
>@@ -131,12 +131,16 @@
>
>DEFAULT_CONFIGURATION_KEY,
>
DEFAULT_CONFIGURATION_FILE);
> URL url = null;
>+ boolean urlRefMayBeConfigurator = true;
> try {
>- // so, resource is not a URL:
>- // attempt to get the resource from the class path
> url = new URL(resource);
> } catch (MalformedURLException ex) {
>+ // if resource is not a URL then
>+ // attempt to get the resource from the class path
> url = Loader.getResource(resource, Category.class);
>+ // any ref portion in URL returned by classload is specific to
that URL,
>+ // not a Configurator class name
>+ urlRefMayBeConfigurator = false;
> }
>
> // If we have a non-null url, then delegate the rest of the
>@@ -144,7 +148,7 @@
> // method.
> if(url != null) {
> LogLog.debug("Using URL ["+url+"] for automatic log4j
configuration.");
>- OptionConverter.selectAndConfigure(url, defaultHierarchy);
>+ OptionConverter.selectAndConfigure(url, urlRefMayBeConfigurator,
defaultHierarchy);
> } else {
> LogLog.debug("Could not find resource: ["+resource+"].");
> }
>Index: helpers/OptionConverter.java
>===================================================================
>RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/helpers/OptionConver
ter.java,v
>retrieving revision 1.17
>diff -w -u -r1.17 OptionConverter.java
>--- helpers/OptionConverter.java 2001/06/20 07:59:46 1.17
>+++ helpers/OptionConverter.java 2001/06/29 14:12:45
>@@ -399,9 +399,16 @@
> /**
> Configure log4j given a URL.
>- <p>The URL format is important. Its <em>reference</em> part is
>- taken as the class name of the configurator. For example, if you
>- invoke your application using the command line
>+ <p>The URL format is important. If the
<em>urlRefMayBeConfigurator</em>
>+ param is true, then its <em>reference</em> part (if any) is
potentially
>+ considered to be the class name of the configurator. Since the ref
part
>+ may also be used by some custom URL types (e.g. to qualify a specific
file
>+ within another archive file), for the ref string to be considered a
class
>+ name, it must be a fully qualified class name including at least one
>+ package, and must not contain any file separator characters such as
'/' or
>+ '\' since those would never be part of a valid class name, and are a
strong
>+ indication of a custom URL type. For example, if you invoke your
>+ application using the command line
> <pre>
java -Dlog4j.configuration=file:/temp/myconfig.xyz#com.myCompany.myConfigura
tor
> </pre>
>@@ -412,8 +419,8 @@
> configurator you specify <em>must</em> implement the {@link
> Configurator} interface.
>- <p>If the URL has no reference part, then the {@link
>- PropertyConfigurator} will parse the URL. However, if the URL
>+ <p>If no configurator is specified via a URL reference part, then the
>+ {@link PropertyConfigurator} will parse the URL. However, if the URL
> ends with a ".xml" extension, then the {@link DOMConfigurator}
> will be used to parse the URL.
>@@ -425,12 +432,29 @@
> @since 1.0 */
> static
> public
>- void selectAndConfigure(URL url, Hierarchy hierarchy) {
>- String clazz = url.getRef();
>+ void selectAndConfigure(URL url, boolean urlRefMayBeConfigurator,
>+ Hierarchy hierarchy) {
>+
>+ // assume a 'ref' portion of a URL may be Configurator class
>+ String clazz = null;
>+ if (urlRefMayBeConfigurator) {
>+ clazz = url.getRef();
>+ if (clazz != null) {
>+ String fileSep = "/";
>+ try { fileSep = System.getProperty("file.separator"); }
catch(Exception e) {}
>+ // it's only a class name if it has a period somewhere in it, and
it's
>+ // not a class name if it has a file separator (explicitly check
both
>+ // unix and windows versions since Java itself will always allow
them
>+ // regardless of actual platform)
>+ if (clazz.indexOf('.') == -1 || clazz.indexOf(fileSep) != -1 ||
>+ clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1)
>+ clazz = null;
>+ }
>+ }
> Configurator configurator = null;
>- if(clazz != null) {
>+ if (clazz != null && clazz.length() > 0) {
> LogLog.debug("Preferred configurator class: " + clazz);
> configurator = (Configurator) instantiateByClassName(clazz,
>
Configurator.class,
>@@ -440,6 +464,11 @@
> return;
> }
> } else {
>+ // hmm, this test is actually no longer valid if we have a custom
URL type
>+ // such as:
>+ // 'zip:/a/b/c/d.war#e/f/log4j.properties'
>+ // which is what a custom classloader like WebLogic's may return as
a URL
>+ // reference to a file inside of an archive
> String filename = url.getFile();
> if(filename != null && filename.endsWith(".xml")) {
> try {
>@@ -455,4 +484,16 @@
> configurator.doConfigure(url, hierarchy);
> }
>+
>+
>+ /**
>+ Configure log4j given a URL.
>+ This method signature maintained for compatibility
>+ */
>+ static
>+ public
>+ void selectAndConfigure(URL url, Hierarchy hierarchy) {
>+ selectAndConfigure(url, true, hierarchy);
>+ }
>+
>}
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: PATCH: modify config file loading to allow custom URL types
Posted by Ceki Gülcü <cg...@qos.ch>.
Colin,
I modified OptionConverter.java as follows:
static
public
void selectAndConfigure(URL url, Hierarchy hierarchy) {
String clazz = url.getRef();
if (clazz.indexOf('.') == -1 || clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1) {
LogLog.warn("Suspicious reference part in URL ["+url+
"] will ignore refence part assuming BEA Weblogic environment.");
clazz = null;
}
Configurator configurator = null;
if(clazz != null) {
LogLog.debug("Preferred configurator class: " + clazz);
....
}
Category.java remains unchanged. Can you please double check that my simplified patch works.
You can get the latest code from our CVS repository. Best regards, Ceki
At 14:20 29.06.2001 +0000, you wrote:
>(same patch as before, but diffed using -u option...)
>
>>As per my previous email with Ceki, this patch modifies the configuration file loading code so that while still allowing a 'ref' or anchor portion of a URL to specify a class name for a custom configurator, it can also work with custom URL schemes such as used in WebLogic to specify a file within an archive, e.g.
>>zip:/part1/part2/whatever.war#WEB-INF/classes/log4j.properties
>>With the new code, for the ref portion of a URL to be considered a classname, it must consist of at least one package element and one classname element (e.g. mypackage.Myclass), and must not have the file separator character in it. Also, when the URL comes from a classloader as opposed to a system properly, the code will never consider the ref to be a classname, since that wouldn't make sense (e.g. in this case the ref will always be part of a custom URL).
>
>Index: Category.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/Category.java,v
>retrieving revision 1.35
>diff -w -u -r1.35 Category.java
>--- Category.java 2001/06/26 19:40:05 1.35
>+++ Category.java 2001/06/29 14:12:44
>@@ -131,12 +131,16 @@
>
>DEFAULT_CONFIGURATION_KEY,
> DEFAULT_CONFIGURATION_FILE);
> URL url = null;
>+ boolean urlRefMayBeConfigurator = true;
> try {
>- // so, resource is not a URL:
>- // attempt to get the resource from the class path
> url = new URL(resource);
> } catch (MalformedURLException ex) {
>+ // if resource is not a URL then
>+ // attempt to get the resource from the class path
> url = Loader.getResource(resource, Category.class);
>+ // any ref portion in URL returned by classload is specific to that URL,
>+ // not a Configurator class name
>+ urlRefMayBeConfigurator = false;
> }
>
> // If we have a non-null url, then delegate the rest of the
>@@ -144,7 +148,7 @@
> // method.
> if(url != null) {
> LogLog.debug("Using URL ["+url+"] for automatic log4j configuration.");
>- OptionConverter.selectAndConfigure(url, defaultHierarchy);
>+ OptionConverter.selectAndConfigure(url, urlRefMayBeConfigurator, defaultHierarchy);
> } else {
> LogLog.debug("Could not find resource: ["+resource+"].");
> }
>Index: helpers/OptionConverter.java
>===================================================================
>RCS file: /home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/helpers/OptionConver ter.java,v
>retrieving revision 1.17
>diff -w -u -r1.17 OptionConverter.java
>--- helpers/OptionConverter.java 2001/06/20 07:59:46 1.17
>+++ helpers/OptionConverter.java 2001/06/29 14:12:45
>@@ -399,9 +399,16 @@
> /**
> Configure log4j given a URL.
>- <p>The URL format is important. Its <em>reference</em> part is
>- taken as the class name of the configurator. For example, if you
>- invoke your application using the command line
>+ <p>The URL format is important. If the <em>urlRefMayBeConfigurator</em>
>+ param is true, then its <em>reference</em> part (if any) is potentially
>+ considered to be the class name of the configurator. Since the ref part
>+ may also be used by some custom URL types (e.g. to qualify a specific file
>+ within another archive file), for the ref string to be considered a class
>+ name, it must be a fully qualified class name including at least one
>+ package, and must not contain any file separator characters such as '/' or
>+ '\' since those would never be part of a valid class name, and are a strong
>+ indication of a custom URL type. For example, if you invoke your
>+ application using the command line
> <pre> java -Dlog4j.configuration=file:/temp/myconfig.xyz#com.myCompany.myConfigurator
> </pre>
>@@ -412,8 +419,8 @@
> configurator you specify <em>must</em> implement the {@link
> Configurator} interface.
>- <p>If the URL has no reference part, then the {@link
>- PropertyConfigurator} will parse the URL. However, if the URL
>+ <p>If no configurator is specified via a URL reference part, then the
>+ {@link PropertyConfigurator} will parse the URL. However, if the URL
> ends with a ".xml" extension, then the {@link DOMConfigurator}
> will be used to parse the URL.
>@@ -425,12 +432,29 @@
> @since 1.0 */
> static
> public
>- void selectAndConfigure(URL url, Hierarchy hierarchy) {
>- String clazz = url.getRef();
>+ void selectAndConfigure(URL url, boolean urlRefMayBeConfigurator,
>+ Hierarchy hierarchy) {
>+
>+ // assume a 'ref' portion of a URL may be Configurator class
>+ String clazz = null;
>+ if (urlRefMayBeConfigurator) {
>+ clazz = url.getRef();
>+ if (clazz != null) {
>+ String fileSep = "/";
>+ try { fileSep = System.getProperty("file.separator"); } catch(Exception e) {}
>+ // it's only a class name if it has a period somewhere in it, and it's
>+ // not a class name if it has a file separator (explicitly check both
>+ // unix and windows versions since Java itself will always allow them
>+ // regardless of actual platform)
>+ if (clazz.indexOf('.') == -1 || clazz.indexOf(fileSep) != -1 ||
>+ clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1)
>+ clazz = null;
>+ }
>+ }
> Configurator configurator = null;
>- if(clazz != null) {
>+ if (clazz != null && clazz.length() > 0) {
> LogLog.debug("Preferred configurator class: " + clazz);
> configurator = (Configurator) instantiateByClassName(clazz,
> Configurator.class,
>@@ -440,6 +464,11 @@
> return;
> }
> } else {
>+ // hmm, this test is actually no longer valid if we have a custom URL type
>+ // such as:
>+ // 'zip:/a/b/c/d.war#e/f/log4j.properties'
>+ // which is what a custom classloader like WebLogic's may return as a URL
>+ // reference to a file inside of an archive
> String filename = url.getFile();
> if(filename != null && filename.endsWith(".xml")) {
> try {
>@@ -455,4 +484,16 @@
> configurator.doConfigure(url, hierarchy);
> }
>+
>+
>+ /**
>+ Configure log4j given a URL.
>+ This method signature maintained for compatibility
>+ */
>+ static
>+ public
>+ void selectAndConfigure(URL url, Hierarchy hierarchy) {
>+ selectAndConfigure(url, true, hierarchy);
>+ }
>+
>}
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
--
Ceki Gülcü
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
PATCH: modify config file loading to allow custom URL types
Posted by Colin Sampaleanu <co...@exis.com>.
(same patch as before, but diffed using -u option...)
> As per my previous email with Ceki, this patch modifies the configuration
> file loading code so that while still allowing a 'ref' or anchor portion
> of a URL to specify a class name for a custom configurator, it can also
> work with custom URL schemes such as used in WebLogic to specify a file
> within an archive, e.g.
> zip:/part1/part2/whatever.war#WEB-INF/classes/log4j.properties
>
> With the new code, for the ref portion of a URL to be considered a
> classname, it must consist of at least one package element and one
> classname element (e.g. mypackage.Myclass), and must not have the file
> separator character in it. Also, when the URL comes from a classloader as
> opposed to a system properly, the code will never consider the ref to be a
> classname, since that wouldn't make sense (e.g. in this case the ref will
> always be part of a custom URL).
Index: Category.java
===================================================================
RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/Category.java,v
retrieving revision 1.35
diff -w -u -r1.35 Category.java
--- Category.java 2001/06/26 19:40:05 1.35
+++ Category.java 2001/06/29 14:12:44
@@ -131,12 +131,16 @@
DEFAULT_CONFIGURATION_KEY,
DEFAULT_CONFIGURATION_FILE);
URL url = null;
+ boolean urlRefMayBeConfigurator = true;
try {
- // so, resource is not a URL:
- // attempt to get the resource from the class path
url = new URL(resource);
} catch (MalformedURLException ex) {
+ // if resource is not a URL then
+ // attempt to get the resource from the class path
url = Loader.getResource(resource, Category.class);
+ // any ref portion in URL returned by classload is specific to that
URL,
+ // not a Configurator class name
+ urlRefMayBeConfigurator = false;
}
// If we have a non-null url, then delegate the rest of the
@@ -144,7 +148,7 @@
// method.
if(url != null) {
LogLog.debug("Using URL ["+url+"] for automatic log4j configuration.");
- OptionConverter.selectAndConfigure(url, defaultHierarchy);
+ OptionConverter.selectAndConfigure(url, urlRefMayBeConfigurator,
defaultHierarchy);
} else {
LogLog.debug("Could not find resource: ["+resource+"].");
}
Index: helpers/OptionConverter.java
===================================================================
RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/helpers/OptionConver
ter.java,v
retrieving revision 1.17
diff -w -u -r1.17 OptionConverter.java
--- helpers/OptionConverter.java 2001/06/20 07:59:46 1.17
+++ helpers/OptionConverter.java 2001/06/29 14:12:45
@@ -399,9 +399,16 @@
/**
Configure log4j given a URL.
- <p>The URL format is important. Its <em>reference</em> part is
- taken as the class name of the configurator. For example, if you
- invoke your application using the command line
+ <p>The URL format is important. If the
<em>urlRefMayBeConfigurator</em>
+ param is true, then its <em>reference</em> part (if any) is
potentially
+ considered to be the class name of the configurator. Since the ref
part
+ may also be used by some custom URL types (e.g. to qualify a specific
file
+ within another archive file), for the ref string to be considered a
class
+ name, it must be a fully qualified class name including at least one
+ package, and must not contain any file separator characters such as
'/' or
+ '\' since those would never be part of a valid class name, and are a
strong
+ indication of a custom URL type. For example, if you invoke your
+ application using the command line
<pre> java
-Dlog4j.configuration=file:/temp/myconfig.xyz#com.myCompany.myConfigurator
</pre>
@@ -412,8 +419,8 @@
configurator you specify <em>must</em> implement the {@link
Configurator} interface.
- <p>If the URL has no reference part, then the {@link
- PropertyConfigurator} will parse the URL. However, if the URL
+ <p>If no configurator is specified via a URL reference part, then the
+ {@link PropertyConfigurator} will parse the URL. However, if the URL
ends with a ".xml" extension, then the {@link DOMConfigurator}
will be used to parse the URL.
@@ -425,12 +432,29 @@
@since 1.0 */
static
public
- void selectAndConfigure(URL url, Hierarchy hierarchy) {
- String clazz = url.getRef();
+ void selectAndConfigure(URL url, boolean urlRefMayBeConfigurator,
+ Hierarchy hierarchy) {
+
+ // assume a 'ref' portion of a URL may be Configurator class
+ String clazz = null;
+ if (urlRefMayBeConfigurator) {
+ clazz = url.getRef();
+ if (clazz != null) {
+ String fileSep = "/";
+ try { fileSep = System.getProperty("file.separator"); }
catch(Exception e) {}
+ // it's only a class name if it has a period somewhere in it, and
it's
+ // not a class name if it has a file separator (explicitly check
both
+ // unix and windows versions since Java itself will always allow
them
+ // regardless of actual platform)
+ if (clazz.indexOf('.') == -1 || clazz.indexOf(fileSep) != -1 ||
+ clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1)
+ clazz = null;
+ }
+ }
Configurator configurator = null;
- if(clazz != null) {
+ if (clazz != null && clazz.length() > 0) {
LogLog.debug("Preferred configurator class: " + clazz);
configurator = (Configurator) instantiateByClassName(clazz,
Configurator.class,
@@ -440,6 +464,11 @@
return;
}
} else {
+ // hmm, this test is actually no longer valid if we have a custom URL
type
+ // such as:
+ // 'zip:/a/b/c/d.war#e/f/log4j.properties'
+ // which is what a custom classloader like WebLogic's may return as a
URL
+ // reference to a file inside of an archive
String filename = url.getFile();
if(filename != null && filename.endsWith(".xml")) {
try {
@@ -455,4 +484,16 @@
configurator.doConfigure(url, hierarchy);
}
+
+
+ /**
+ Configure log4j given a URL.
+ This method signature maintained for compatibility
+ */
+ static
+ public
+ void selectAndConfigure(URL url, Hierarchy hierarchy) {
+ selectAndConfigure(url, true, hierarchy);
+ }
+
}
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
PATCH: modify config file loading to allow custom URL types
Posted by Colin Sampaleanu <co...@exis.com>.
As per my previous email with Ceki, this patch modifies the configuration
file loading code so that while still allowing a 'ref' or anchor portion of
a URL to specify a class name for a custom configurator, it can also work
with custom URL schemes such as used in WebLogic to specify a file within an
archive, e.g.
zip:/part1/part2/whatever.war#WEB-INF/classes/log4j.properties
With the new code, for the ref portion of a URL to be considered a
classname, it must consist of at least one package element and one classname
element (e.g. mypackage.Myclass), and must not have the file separator
character in it. Also, when the URL comes from a classloader as opposed to a
system properly, the code will never consider the ref to be a classname,
since that wouldn't make sense (e.g. in this case the ref will always be
part of a custom URL).
----
Index: Category.java
===================================================================
RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/Category.java,v
retrieving revision 1.35
diff -w -r1.35 Category.java
133a134
> boolean urlRefMayBeConfigurator = true;
135,136d135
< // so, resource is not a URL:
< // attempt to get the resource from the class path
138a138,139
> // if resource is not a URL then
> // attempt to get the resource from the class path
139a141,143
> // any ref portion in URL returned by classload is specific to that URL,
> // not a Configurator class name
> urlRefMayBeConfigurator = false;
147c151
< OptionConverter.selectAndConfigure(url, defaultHierarchy);
---
> OptionConverter.selectAndConfigure(url, urlRefMayBeConfigurator, defaultHierarchy);
Index: helpers/OptionConverter.java
===================================================================
RCS file:
/home/cvspublic/jakarta-log4j/src/java/org/apache/log4j/helpers/OptionConver
ter.java,v
retrieving revision 1.17
diff -w -r1.17 OptionConverter.java
402,404c402,411
< <p>The URL format is important. Its <em>reference</em> part is
< taken as the class name of the configurator. For example, if you
< invoke your application using the command line
---
> <p>The URL format is important. If the <em>urlRefMayBeConfigurator</em>
> param is true, then its <em>reference</em> part (if any) is potentially
> considered to be the class name of the configurator. Since the ref part
> may also be used by some custom URL types (e.g. to qualify a specific file
> within another archive file), for the ref string to be considered a class
> name, it must be a fully qualified class name including at least one
> package, and must not contain any file separator characters such as '/' or
> '\' since those would never be part of a valid class name, and are a strong
> indication of a custom URL type. For example, if you invoke your
> application using the command line
415,416c422,423
< <p>If the URL has no reference part, then the {@link
< PropertyConfigurator} will parse the URL. However, if the URL
---
> <p>If no configurator is specified via a URL reference part, then the
> {@link PropertyConfigurator} will parse the URL. However, if the URL
428,429c435,450
< void selectAndConfigure(URL url, Hierarchy hierarchy) {
< String clazz = url.getRef();
---
> void selectAndConfigure(URL url, boolean urlRefMayBeConfigurator,
> Hierarchy hierarchy) {
>
> // assume a 'ref' portion of a URL may be Configurator class
> String clazz = null;
> if (urlRefMayBeConfigurator) {
> clazz = url.getRef();
> if (clazz != null) {
> String fileSep = "/";
> try { fileSep = System.getProperty("file.separator"); } catch(Exception e) {}
> // java support non-platform normal file separators, so we should too
> if (clazz.indexOf('.') == -1 || clazz.indexOf(fileSep) != -1 ||
> clazz.indexOf('/') != -1 || clazz.indexOf('\\') != -1)
> clazz = null;
> }
> }
433c454
< if(clazz != null) {
---
> if (clazz != null && clazz.length() > 0) {
442a464,468
> // hmm, this test is actually no longer valid if we have a custom URL type
> // such as:
> // 'zip:/a/b/c/d.war#e/f/log4j.properties'
> // which is what a custom classloader like WebLogic's may return as a URL
> // reference to a file inside of an archive
457a484,495
>
>
> /**
> Configure log4j given a URL.
> This method signature maintained for compatibility
> */
> static
> public
> void selectAndConfigure(URL url, Hierarchy hierarchy) {
> selectAndConfigure(url, true, hierarchy);
> }
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org