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 Scott Farquhar <s....@student.unsw.edu.au> on 2002/03/07 02:07:29 UTC
Default Repository Selectors / Orion Repository Selector - REPOST
I posted this a week ago, and I didn't receive any response, so I am
reposting in the hope that someone will have any opinion, or whether I
should just post a patch.
My suggestion is to have another argument, which defines the default
repository selector to use. The reason is that unless your application
server supports startup classes, there is no way to set the repository
selector before application classes start logging.
Please read below and let me know your opinions (if you have any). I am
eager to release my code, but it would require releasing a patched
version of log4j to get this to work.
Cheers,
Scott
-------- Original Message --------
Subject: Default Repository Selectors / Orion Repository Selector
Date: Thu, 28 Feb 2002 11:48:20 +1100
From: Scott Farquhar <sc...@atlassian.com>
Reply-To: "Log4J Developers List" <lo...@jakarta.apache.org>
To: Log4J Developers List <lo...@jakarta.apache.org>
I have successfully completed a repository selector for the orion
application server, which looks up the log4j.properties / xml files from
the bottom up, loading those in the most specific classloader, before
loading from parents.
Whilst the ability to configure a repository selector with
LogManager.setRepositorySelector(..)
is useful, unless you control the server, you cannot guarantee that your
repository selector will be loaded first.
My feature request is to be able to pass the classname of a default
repository selector as a system property. eg.
-Dlog4j.repositorySelector=org.apache.log4j.spi.OrionRepositorySelector
In LogManager, in the static{} initalisation, you can then load the class.
I have attached my suggested changes. Note that it needs refactoring,
but for the moment it is all in the one code block (for easy reading).
Any thoughts? Anyone else planning (or written) repository selectors?
If anyone is interested in helping me test the Orion selector, please
send me an email.
Cheers,
Scott
--
Scott Farquhar :: scott@atlassian.com
Atlassian :: http://www.atlassian.com
Supporting YOUR J2EE World
--
Scott Farquhar
E :: s.farquhar@student.unsw.edu.au
M :: +61 414 884 583
W :: http://www.atlassian.com
Re: Default Repository Selectors / Orion Repository Selector
Posted by Scott Farquhar <sc...@atlassian.com>.
I have attached the Orion Repository Selector.
Cheers,
Scott
Scott Farquhar wrote:
> Ceki,
>
> Thanks for answering - I know that you must be busy.
>
> The problem with not allowing a default repository selector is that
> unless you have access to the server code, then you cannot set it. You
> may be able to hack around with startup classes, but I'm still not sure
> if you can guarantee that one startup class loads before another.
>
> The reason that I want a repository selector for Orion is classloaders.
> If you have multiple properties files, then the current way that
> classloaders work is that it would find the property file in the highest
> classloader (in this case - orion/lib).
>
> This always caused problems if you had a log4j.properties file loaded in
> a classloader above you - you would never be able to specify your own.
> Eg - in a web component you want to use your own properties file, but a
> 3rd party ejb component already includes one. Currently there is
> nothing you can do regarding this.
>
> Other long term options are loading multiple property files, so that for
> development you can specify default properties in orion/lib & then more
> specific properties in other locations.
>
> I hope you can see that "searching for property files" is fairly
> important in an area with multiple classloaders. Isn't this a subset of
> what the JBoss selector will be doing?
>
> I will post the respository selector code when I get to work later. It
> simply runs down the classloaders, and gets the last file loaded & uses
> that. (as opposed to the first file loaded, which is the current case).
>
> Cheers,
> Scott
>
>
>
> Ceki G�lc� wrote:
>
>>
>> Hello Scott,
>>
>> Sorry for not responding earlier. My working assumption is that the
>> repository selector is set by
>> the application server code. This makes very much sense in the case of
>> JBoss which uses
>> log4j for its own logging. Allowing the end user to set the repository
>> selector is a dangerous
>> operation. So I am not keen on letting it happen. I have to think
>> about it some more.
>>
>> I did not really understand the aim of the OrionRepositorySelector.
>> What does it
>> do? It seems like overkill to write a repository selector for just
>> searching for
>> property files. What am I missing. By the way, the code for
>> OrionRepositorySelector
>> was not included in your previous message. Regards, Ceki
>>
>>
>>
>> At 12:07 07.03.2002 +1100, Scott Farquhar wrote:
>>
>>> I posted this a week ago, and I didn't receive any response, so I am
>>> reposting in the hope that someone will have any opinion, or whether
>>> I should just post a patch.
>>>
>>> My suggestion is to have another argument, which defines the default
>>> repository selector to use. The reason is that unless your
>>> application server supports startup classes, there is no way to set
>>> the repository selector before application classes start logging.
>>>
>>> Please read below and let me know your opinions (if you have any). I
>>> am eager to release my code, but it would require releasing a patched
>>> version of log4j to get this to work.
>>>
>>> Cheers,
>>> Scott
>>>
>>> -------- Original Message --------
>>> Subject: Default Repository Selectors / Orion Repository Selector
>>> Date: Thu, 28 Feb 2002 11:48:20 +1100
>>> From: Scott Farquhar <sc...@atlassian.com>
>>> Reply-To: "Log4J Developers List" <lo...@jakarta.apache.org>
>>> To: Log4J Developers List <lo...@jakarta.apache.org>
>>>
>>> I have successfully completed a repository selector for the orion
>>> application server, which looks up the log4j.properties / xml files from
>>> the bottom up, loading those in the most specific classloader, before
>>> loading from parents.
>>>
>>> Whilst the ability to configure a repository selector with
>>>
>>> LogManager.setRepositorySelector(..)
>>>
>>> is useful, unless you control the server, you cannot guarantee that your
>>> repository selector will be loaded first.
>>>
>>> My feature request is to be able to pass the classname of a default
>>> repository selector as a system property. eg.
>>>
>>>
>>> -Dlog4j.repositorySelector=org.apache.log4j.spi.OrionRepositorySelector
>>>
>>> In LogManager, in the static{} initalisation, you can then load the
>>> class.
>>>
>>> I have attached my suggested changes. Note that it needs refactoring,
>>> but for the moment it is all in the one code block (for easy reading).
>>>
>>> Any thoughts? Anyone else planning (or written) repository selectors?
>>>
>>> If anyone is interested in helping me test the Orion selector, please
>>> send me an email.
>>>
>>> Cheers,
>>> Scott
>>>
>>>
>>> --
>>> Scott Farquhar :: scott@atlassian.com
>>>
>>> Atlassian :: http://www.atlassian.com
>>> Supporting YOUR J2EE World
>>>
>>>
>>>
>>> --
>>> Scott Farquhar
>>> E :: s.farquhar@student.unsw.edu.au
>>> M :: +61 414 884 583
>>> W :: http://www.atlassian.com
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>>
>>> --
>>> To unsubscribe, e-mail:
>>> <ma...@jakarta.apache.org>
>>> For additional commands, e-mail:
>>> <ma...@jakarta.apache.org>
>>
>>
>>
>> --
>> Ceki G�lc�
>>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>>
>
>
--
Scott Farquhar :: scott@atlassian.com
Atlassian :: http://www.atlassian.com
Supporting YOUR J2EE World
Re: Default Repository Selectors / Orion Repository Selector
Posted by Scott Farquhar <sc...@atlassian.com>.
Ceki,
Thanks for answering - I know that you must be busy.
The problem with not allowing a default repository selector is that
unless you have access to the server code, then you cannot set it. You
may be able to hack around with startup classes, but I'm still not sure
if you can guarantee that one startup class loads before another.
The reason that I want a repository selector for Orion is classloaders.
If you have multiple properties files, then the current way that
classloaders work is that it would find the property file in the highest
classloader (in this case - orion/lib).
This always caused problems if you had a log4j.properties file loaded in
a classloader above you - you would never be able to specify your own.
Eg - in a web component you want to use your own properties file, but a
3rd party ejb component already includes one. Currently there is
nothing you can do regarding this.
Other long term options are loading multiple property files, so that for
development you can specify default properties in orion/lib & then more
specific properties in other locations.
I hope you can see that "searching for property files" is fairly
important in an area with multiple classloaders. Isn't this a subset of
what the JBoss selector will be doing?
I will post the respository selector code when I get to work later. It
simply runs down the classloaders, and gets the last file loaded & uses
that. (as opposed to the first file loaded, which is the current case).
Cheers,
Scott
Ceki Gülcü wrote:
>
> Hello Scott,
>
> Sorry for not responding earlier. My working assumption is that the
> repository selector is set by
> the application server code. This makes very much sense in the case of
> JBoss which uses
> log4j for its own logging. Allowing the end user to set the repository
> selector is a dangerous
> operation. So I am not keen on letting it happen. I have to think about
> it some more.
>
> I did not really understand the aim of the OrionRepositorySelector. What
> does it
> do? It seems like overkill to write a repository selector for just
> searching for
> property files. What am I missing. By the way, the code for
> OrionRepositorySelector
> was not included in your previous message. Regards, Ceki
>
>
>
> At 12:07 07.03.2002 +1100, Scott Farquhar wrote:
>
>> I posted this a week ago, and I didn't receive any response, so I am
>> reposting in the hope that someone will have any opinion, or whether I
>> should just post a patch.
>>
>> My suggestion is to have another argument, which defines the default
>> repository selector to use. The reason is that unless your
>> application server supports startup classes, there is no way to set
>> the repository selector before application classes start logging.
>>
>> Please read below and let me know your opinions (if you have any). I
>> am eager to release my code, but it would require releasing a patched
>> version of log4j to get this to work.
>>
>> Cheers,
>> Scott
>>
>> -------- Original Message --------
>> Subject: Default Repository Selectors / Orion Repository Selector
>> Date: Thu, 28 Feb 2002 11:48:20 +1100
>> From: Scott Farquhar <sc...@atlassian.com>
>> Reply-To: "Log4J Developers List" <lo...@jakarta.apache.org>
>> To: Log4J Developers List <lo...@jakarta.apache.org>
>>
>> I have successfully completed a repository selector for the orion
>> application server, which looks up the log4j.properties / xml files from
>> the bottom up, loading those in the most specific classloader, before
>> loading from parents.
>>
>> Whilst the ability to configure a repository selector with
>>
>> LogManager.setRepositorySelector(..)
>>
>> is useful, unless you control the server, you cannot guarantee that your
>> repository selector will be loaded first.
>>
>> My feature request is to be able to pass the classname of a default
>> repository selector as a system property. eg.
>>
>>
>> -Dlog4j.repositorySelector=org.apache.log4j.spi.OrionRepositorySelector
>>
>> In LogManager, in the static{} initalisation, you can then load the
>> class.
>>
>> I have attached my suggested changes. Note that it needs refactoring,
>> but for the moment it is all in the one code block (for easy reading).
>>
>> Any thoughts? Anyone else planning (or written) repository selectors?
>>
>> If anyone is interested in helping me test the Orion selector, please
>> send me an email.
>>
>> Cheers,
>> Scott
>>
>>
>> --
>> Scott Farquhar :: scott@atlassian.com
>>
>> Atlassian :: http://www.atlassian.com
>> Supporting YOUR J2EE World
>>
>>
>>
>> --
>> Scott Farquhar
>> E :: s.farquhar@student.unsw.edu.au
>> M :: +61 414 884 583
>> W :: http://www.atlassian.com
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>>
>> --
>> To unsubscribe, e-mail:
>> <ma...@jakarta.apache.org>
>> For additional commands, e-mail:
>> <ma...@jakarta.apache.org>
>
>
> --
> Ceki Gülcü
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
Scott Farquhar :: scott@atlassian.com
Atlassian :: http://www.atlassian.com
Supporting YOUR J2EE World
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Default Repository Selectors / Orion Repository Selector -
REPOST
Posted by Ceki Gülcü <ce...@qos.ch>.
Hello Scott,
Sorry for not responding earlier. My working assumption is that the
repository selector is set by
the application server code. This makes very much sense in the case of
JBoss which uses
log4j for its own logging. Allowing the end user to set the repository
selector is a dangerous
operation. So I am not keen on letting it happen. I have to think about it
some more.
I did not really understand the aim of the OrionRepositorySelector. What
does it
do? It seems like overkill to write a repository selector for just
searching for
property files. What am I missing. By the way, the code for
OrionRepositorySelector
was not included in your previous message. Regards, Ceki
At 12:07 07.03.2002 +1100, Scott Farquhar wrote:
>I posted this a week ago, and I didn't receive any response, so I am
>reposting in the hope that someone will have any opinion, or whether I
>should just post a patch.
>
>My suggestion is to have another argument, which defines the default
>repository selector to use. The reason is that unless your application
>server supports startup classes, there is no way to set the repository
>selector before application classes start logging.
>
>Please read below and let me know your opinions (if you have any). I am
>eager to release my code, but it would require releasing a patched version
>of log4j to get this to work.
>
>Cheers,
>Scott
>
>-------- Original Message --------
>Subject: Default Repository Selectors / Orion Repository Selector
>Date: Thu, 28 Feb 2002 11:48:20 +1100
>From: Scott Farquhar <sc...@atlassian.com>
>Reply-To: "Log4J Developers List" <lo...@jakarta.apache.org>
>To: Log4J Developers List <lo...@jakarta.apache.org>
>
>I have successfully completed a repository selector for the orion
>application server, which looks up the log4j.properties / xml files from
>the bottom up, loading those in the most specific classloader, before
>loading from parents.
>
>Whilst the ability to configure a repository selector with
>
> LogManager.setRepositorySelector(..)
>
>is useful, unless you control the server, you cannot guarantee that your
>repository selector will be loaded first.
>
>My feature request is to be able to pass the classname of a default
>repository selector as a system property. eg.
>
> -Dlog4j.repositorySelector=org.apache.log4j.spi.OrionRepositorySelector
>
>In LogManager, in the static{} initalisation, you can then load the class.
>
>I have attached my suggested changes. Note that it needs refactoring,
>but for the moment it is all in the one code block (for easy reading).
>
>Any thoughts? Anyone else planning (or written) repository selectors?
>
>If anyone is interested in helping me test the Orion selector, please
>send me an email.
>
>Cheers,
>Scott
>
>
>--
>Scott Farquhar :: scott@atlassian.com
>
>Atlassian :: http://www.atlassian.com
> Supporting YOUR J2EE World
>
>
>
>--
>Scott Farquhar
>E :: s.farquhar@student.unsw.edu.au
>M :: +61 414 884 583
>W :: http://www.atlassian.com
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Ceki Gülcü
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>