You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by sanjayrajsoni <sa...@yahoo.com> on 2002/12/03 20:01:35 UTC
Re: Multiple Log4J instances in one VM
We also ran into the same issue and is causing many headaches
prompting some team-members to insist that we get rid of Log4J. Log4J
being open-source is used by different teams/companies who have no
cooridnation between them. I hope in the future releases this problem
can be solved.
--- In Log4J@y..., "Thomas Muller" <tt...@o...> wrote:
> Log4j's somewhat static configuration approach strikes me as quite
> non-object-oriented since it in many ways violates encapsulation and
> instantiation; a natural requirement for a logging API is that
different
> parts of a program (running in the same VM) should be able to
configure
> their own "instances" of Log4j independent of eachother, e.g. they
should
> not need to ask eachother or the API itself whether it's configured.
>
> Everything considered, it seems like getting Log4j to work smoothly
(as is)
> in a multiple configuration environemt is a cumbersome and
unintuitive task,
> and clearly needs to be addressed in later versions.
>
> --
>
> Thomas
>
>
> | -----Original Message-----
> | From: Ceki Gulcu [mailto:ceki@q...]
> | Sent: 07 August 2002 09:17
> | To: Log4J Users List
> | Subject: RE: Multiple Log4J instances in one VM
> |
> |
> |
> | Hmm, that is not it either. I was thinking of simply checking
whether
> | log4j is already configured. If a component detects that log4j is
> | configured, it should not configure log4j.
> |
> | Here is a more elaborate explanation:
> |
> | http://marc.theaimsgroup.com/?l=log4j-user&m=102775658930710&w=2
> |
> |
> | At 09:01 07.08.2002 +0100, you wrote:
> | >As Ceki points out, there are other ways of solving this, e.g.
by using
> | >different hierarchies for the different "programs".
> | >
> | >See e.g. org.apache.log4j.net.SocketServer for an example of
> | how to obtain
> | >this.
> | >
> | >--
> | >
> | >Thomas
> | >
> | >
> | >
> | > | -----Original Message-----
> | > | From: Thomas Muller [mailto:ttm@o...]
> | > | Sent: 07 August 2002 08:22
> | > | To: Log4J Users List
> | > | Subject: RE: Multiple Log4J instances in one VM
> | > |
> | > |
> | > |
> | > |
> | > | | -----Original Message-----
> | > | | From: Hitzbleck, Andreas (ext. Mitarbeiter)
> | > | | [mailto:Andreas.Hitzbleck@K...]
> | > | | Sent: 07 August 2002 08:18
> | > | | To: 'log4j-user@j...'
> | > | | Subject: Multiple Log4J instances in one VM
> | > | |
> | > | |
> | > | | Hello list,
> | > | |
> | > | | I am developing a java program which is integrated in a
> | big content
> | > | | management system. Thus, our code runs with some other
> | java programs
> | > | | developed by other companies in one virtual mashine.
> | > | |
> | > | | Unfortunately, the Log4J initialization of one program
of another
> | > | | company overwrites our Log4J configuration or - if we
start up
> | > | | our program later - vice versa. I think that is because
of the
> | > | | statically implementation(s) of the configure() methods
in
> | > | | Property- Basic- and DOMConfigurator?
> | > | |
> | > | | Is there a way to solve this problem or to work around
it? Would
> | > | | it help to implement my own classloader and load the
> | Log4J classes
> | > | | through this loader?
> | > |
> | > | Yes - different classloaders can utilize different log4j
> | libraries and
> | > | configurations.
> | > |
> | > | --
> | > |
> | > | Thomas
> | > |
> | > |
> | > |
> | > |
> | > |
> | > |
> | > |
> |
**********************************************************************
***
> | > | Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All
rights
> | > | reserved.
> | > | The information supplied in this email should be treated in
> | confidence.
> | > | No liability whatsoever is accepted for any loss or damage
> | > | suffered as a result of accessing this message or any
attachments.
> | > |
> | > |
> |
______________________________________________________________________
__
> | > | This email has been scanned for all viruses by the
> | MessageLabs SkyScan
> | > | service. For more information on a proactive anti-virus
> | service working
> | > | around the clock, around the globe, visit
http://www.messagelabs.com
> | > |
> |
______________________________________________________________________
__
> | > |
> | > | --
> | > | To unsubscribe, e-mail:
> | ><ma...@j...>
> | >For additional commands, e-mail:
> <ma...@j...>
> >
> >
> >
> >
>
>*********************************************************************
****
> >Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All rights
reserved.
> >The information supplied in this email should be treated in
confidence.
> >No liability whatsoever is accepted for any loss or damage
> >suffered as a result of accessing this message or any attachments.
> >
>
>_____________________________________________________________________
___
> >This email has been scanned for all viruses by the MessageLabs
SkyScan
> >service. For more information on a proactive anti-virus service
working
> >around the clock, around the globe, visit
http://www.messagelabs.com
>
>_____________________________________________________________________
___
> >
> >--
> >To unsubscribe, e-mail:
> <ma...@j...>
> >For additional commands, e-mail:
> <ma...@j...>
>
> --
> Ceki
>
>
> --
> To unsubscribe, e-mail: <ma...@j...>
> For additional commands, e-mail: <ma...@j...>
>
>
>
>
>
**********************************************************************
***
> Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All rights
reserved.
> The information supplied in this email should be treated in
confidence.
> No liability whatsoever is accepted for any loss or damage
> suffered as a result of accessing this message or any attachments.
>
>
______________________________________________________________________
__
> This email has been scanned for all viruses by the MessageLabs
SkyScan
> service. For more information on a proactive anti-virus service
working
> around the clock, around the globe, visit http://www.messagelabs.com
>
______________________________________________________________________
__
>
> --
> To unsubscribe, e-mail: <ma...@j...>
> For additional commands, e-mail: <ma...@j...>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re[2]: Multiple Log4J instances in one VM
Posted by Jacob Kjome <ho...@visi.com>.
Hello sanjayrajsoni,
Logging with separate logger repositories (hierarchies) using a logger repository
selector is log4j's way of dealing with this. It works quite nicely,
if you ask me. It allows you to configure each individual logger
repository without treading on any other. See Ceki's doc here:
http://qos.ch/containers/
There he describes logger repositories keyed on classloader which
works fantastically in servers like Tomcat-4.1.xx. For other servers
such as Jboss which, apparently, uses a common classloader for the
whole server (am I right about that?), this method might not work
quite right. However, you can create a custom logger repository
selector to key on anything you want.
It would be nice if Log4j could come up with a standard repository
selector that worked in a standard way in all environments. That's
probably what people are looking for.
Jake
Tuesday, December 03, 2002, 1:01:35 PM, you wrote:
s> We also ran into the same issue and is causing many headaches
s> prompting some team-members to insist that we get rid of Log4J. Log4J
s> being open-source is used by different teams/companies who have no
s> cooridnation between them. I hope in the future releases this problem
s> can be solved.
s> --- In Log4J@y..., "Thomas Muller" <tt...@o...> wrote:
>> Log4j's somewhat static configuration approach strikes me as quite
>> non-object-oriented since it in many ways violates encapsulation and
>> instantiation; a natural requirement for a logging API is that
s> different
>> parts of a program (running in the same VM) should be able to
s> configure
>> their own "instances" of Log4j independent of eachother, e.g. they
s> should
>> not need to ask eachother or the API itself whether it's configured.
>>
>> Everything considered, it seems like getting Log4j to work smoothly
s> (as is)
>> in a multiple configuration environemt is a cumbersome and
s> unintuitive task,
>> and clearly needs to be addressed in later versions.
>>
>> --
>>
>> Thomas
>>
>>
>> | -----Original Message-----
>> | From: Ceki Gulcu [mailto:ceki@q...]
>> | Sent: 07 August 2002 09:17
>> | To: Log4J Users List
>> | Subject: RE: Multiple Log4J instances in one VM
>> |
>> |
>> |
>> | Hmm, that is not it either. I was thinking of simply checking
s> whether
>> | log4j is already configured. If a component detects that log4j is
>> | configured, it should not configure log4j.
>> |
>> | Here is a more elaborate explanation:
>> |
>> | http://marc.theaimsgroup.com/?l=log4j-user&m=102775658930710&w=2
>> |
>> |
>> | At 09:01 07.08.2002 +0100, you wrote:
>> | >As Ceki points out, there are other ways of solving this, e.g.
s> by using
>> | >different hierarchies for the different "programs".
>> | >
>> | >See e.g. org.apache.log4j.net.SocketServer for an example of
>> | how to obtain
>> | >this.
>> | >
>> | >--
>> | >
>> | >Thomas
>> | >
>> | >
>> | >
>> | > | -----Original Message-----
>> | > | From: Thomas Muller [mailto:ttm@o...]
>> | > | Sent: 07 August 2002 08:22
>> | > | To: Log4J Users List
>> | > | Subject: RE: Multiple Log4J instances in one VM
>> | > |
>> | > |
>> | > |
>> | > |
>> | > | | -----Original Message-----
>> | > | | From: Hitzbleck, Andreas (ext. Mitarbeiter)
>> | > | | [mailto:Andreas.Hitzbleck@K...]
>> | > | | Sent: 07 August 2002 08:18
>> | > | | To: 'log4j-user@j...'
>> | > | | Subject: Multiple Log4J instances in one VM
>> | > | |
>> | > | |
>> | > | | Hello list,
>> | > | |
>> | > | | I am developing a java program which is integrated in a
>> | big content
>> | > | | management system. Thus, our code runs with some other
>> | java programs
>> | > | | developed by other companies in one virtual mashine.
>> | > | |
>> | > | | Unfortunately, the Log4J initialization of one program
s> of another
>> | > | | company overwrites our Log4J configuration or - if we
s> start up
>> | > | | our program later - vice versa. I think that is because
s> of the
>> | > | | statically implementation(s) of the configure() methods
s> in
>> | > | | Property- Basic- and DOMConfigurator?
>> | > | |
>> | > | | Is there a way to solve this problem or to work around
s> it? Would
>> | > | | it help to implement my own classloader and load the
>> | Log4J classes
>> | > | | through this loader?
>> | > |
>> | > | Yes - different classloaders can utilize different log4j
>> | libraries and
>> | > | configurations.
>> | > |
>> | > | --
>> | > |
>> | > | Thomas
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> | > |
>> |
s> **********************************************************************
s> ***
>> | > | Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All
s> rights
>> | > | reserved.
>> | > | The information supplied in this email should be treated in
>> | confidence.
>> | > | No liability whatsoever is accepted for any loss or damage
>> | > | suffered as a result of accessing this message or any
s> attachments.
>> | > |
>> | > |
>> |
s> ______________________________________________________________________
s> __
>> | > | This email has been scanned for all viruses by the
>> | MessageLabs SkyScan
>> | > | service. For more information on a proactive anti-virus
>> | service working
>> | > | around the clock, around the globe, visit
s> http://www.messagelabs.com
>> | > |
>> |
s> ______________________________________________________________________
s> __
>> | > |
>> | > | --
>> | > | To unsubscribe, e-mail:
>> | ><ma...@j...>
>> | >For additional commands, e-mail:
>> <ma...@j...>
>> >
>> >
>> >
>> >
>>
>>*********************************************************************
s> ****
>> >Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All rights
s> reserved.
>> >The information supplied in this email should be treated in
s> confidence.
>> >No liability whatsoever is accepted for any loss or damage
>> >suffered as a result of accessing this message or any attachments.
>> >
>>
>>_____________________________________________________________________
s> ___
>> >This email has been scanned for all viruses by the MessageLabs
s> SkyScan
>> >service. For more information on a proactive anti-virus service
s> working
>> >around the clock, around the globe, visit
s> http://www.messagelabs.com
>>
>>_____________________________________________________________________
s> ___
>> >
>> >--
>> >To unsubscribe, e-mail:
>> <ma...@j...>
>> >For additional commands, e-mail:
>> <ma...@j...>
>>
>> --
>> Ceki
>>
>>
>> --
>> To unsubscribe, e-mail: <ma...@j...>
>> For additional commands, e-mail: <ma...@j...>
>>
>>
>>
>>
>>
s> **********************************************************************
s> ***
>> Copyright ERA Technology Ltd. 2002. (www.era.co.uk). All rights
s> reserved.
>> The information supplied in this email should be treated in
s> confidence.
>> No liability whatsoever is accepted for any loss or damage
>> suffered as a result of accessing this message or any attachments.
>>
>>
s> ______________________________________________________________________
s> __
>> This email has been scanned for all viruses by the MessageLabs
s> SkyScan
>> service. For more information on a proactive anti-virus service
s> working
>> around the clock, around the globe, visit http://www.messagelabs.com
>>
s> ______________________________________________________________________
s> __
>>
>> --
>> To unsubscribe, e-mail: <ma...@j...>
>> For additional commands, e-mail: <ma...@j...>
s> --
s> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
s> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Best regards,
Jacob mailto:hoju@visi.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>