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 "Hitzbleck, Andreas (ext. Mitarbeiter)" <An...@KVB.de> on 2002/08/07 09:18:09 UTC

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?

Thanks in advance for help

Andreas Hitzbleck

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Multiple Log4J instances in one VM

Posted by Ceki Gülcü <ce...@qos.ch>.

No, you should not use different classloaders to solve this
problem. This problem has been discussed before search the archives.

At 08:21 07.08.2002 +0100, you wrote:


>  | -----Original Message-----
>  | From: Hitzbleck, Andreas (ext. Mitarbeiter)
>  | [mailto:Andreas.Hitzbleck@KVB.de]
>  | Sent: 07 August 2002 08:18
>  | To: 'log4j-user@jakarta.apache.org'
>  | 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...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

--
Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Multiple Log4J instances in one VM

Posted by Ceki Gülcü <ce...@qos.ch>.
Gee. How about configuring your own branch of the hierarchy? As in

log4j.logger.com.my.library=debug, F
log4j.additivity.com.my.library=false

log4j.appender.F=org.apache.log4j.FileAppender
log4j.appender.F.File=xyz.log
log4j.appender.F.layout=org.apache.log4j.PatternLayout
log4j.appender.F.layout.ConversionPattern=%r %p %t %c - %m%n


At 09:38 07.08.2002 +0100, you 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@qos.ch]
>  | 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@online.no]
>  | >  | 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@KVB.de]
>  | >  |  | Sent: 07 August 2002 08:18
>  | >  |  | To: 'log4j-user@jakarta.apache.org'
>  | >  |  | 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...@jakarta.apache.org>
>  | >For additional commands, e-mail:
><ma...@jakarta.apache.org>
> >
> >
> >
> >
> >*************************************************************************
> >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...@jakarta.apache.org>
> >For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>--
>Ceki
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>*************************************************************************
>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...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

--
Ceki


--
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>


Re: Multiple Log4J instances in one VM

Posted by sanjayrajsoni <sa...@yahoo.com>.
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: Multiple Log4J instances in one VM

Posted by Thomas Muller <tt...@online.no>.
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@qos.ch]
 | 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@online.no]
 | >  | 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@KVB.de]
 | >  |  | Sent: 07 August 2002 08:18
 | >  |  | To: 'log4j-user@jakarta.apache.org'
 | >  |  | 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...@jakarta.apache.org>
 | >For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>
>
>*************************************************************************
>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...@jakarta.apache.org>
>For additional commands, e-mail:
<ma...@jakarta.apache.org>

--
Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>




*************************************************************************
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...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Multiple Log4J instances in one VM

Posted by Ceki Gülcü <ce...@qos.ch>.
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@online.no]
>  | 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@KVB.de]
>  |  | Sent: 07 August 2002 08:18
>  |  | To: 'log4j-user@jakarta.apache.org'
>  |  | 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...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>*************************************************************************
>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...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>

--
Ceki


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Multiple Log4J instances in one VM

Posted by Thomas Muller <tt...@online.no>.
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@online.no]
 | 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@KVB.de]
 |  | Sent: 07 August 2002 08:18
 |  | To: 'log4j-user@jakarta.apache.org'
 |  | 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...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>




*************************************************************************
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...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: Multiple Log4J instances in one VM

Posted by Thomas Muller <tt...@online.no>.

 | -----Original Message-----
 | From: Hitzbleck, Andreas (ext. Mitarbeiter)
 | [mailto:Andreas.Hitzbleck@KVB.de]
 | Sent: 07 August 2002 08:18
 | To: 'log4j-user@jakarta.apache.org'
 | 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...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>