Re: Multiple applications using GetLogger with same name
On 8/1/23 14:09, Danish Arif wrote:
The second question to this issue Is there any solution if multiple
instances of the same application which are agnostic to each other's
existence, use GetLogger("SameName"); and log into files with names in
incremental id appended dynamically. For Example App Inst1 when gets
logger, log into MyLogFile1 and when Inst2 initiates it logs into
MyLogFile2.
This might be relevant:
https://stackoverflow.com/questions/25754933/log4j2-include-pid
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Logging works fine on one machine but not on the other
I'm sure you know this but a reminder just in case this slipped by, since it's easy to not notice at a glance: the path separator character needs to be different between the Windows and Linux (; vs :) On 10/6/20 11:47 AM, Michiel Graat wrote: Hi all, I am in the process of migrating an application from Log4J 1.2.16 to Log4J 2.13.3. I am using the log4j 1.2 to 2.13.3 bridge for this purpose. I am almost done and on my own development machine everything is working perfectly. However, when I deploy the application to a test server all the logging gets send to the root logger only. The log4j2.xml configuration files on both machines are exactly the same, only the paths differ. Also: my development machine runs Windows, the test server runs Linux. I have added the one on the test server to the end of this e-mail, excuse the messy replace statement. Some extra information: the application runs on Weblogic 12.2.1.3. On my own machine I added the location of the log4j2.xml to the classpath. On the test server I have tried adding the location to the classpath as well as setting it through the log4j.configurationFile Java VM parameter. The result in both cases is the same: all the logfiles are created at startup but only the one mentioned in the root logger gets logdata send to it, the other logfiles stay empty. This tells me that at least Log4J2 is able to find and read the configuration file. I have tried switching the appender which is mentioned in the root logger. In that case logging data gets send to that file, so it does not seem to be anything filesystem related. I am completely lost here and do not know what is going wrong, hence this e-mail. Any ideas? Kind regards, Michiel - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Lohg4j2 Schema Errors
I'm not up on what the state of the log4j config schema is (though I've seen things in the past about it not being able to model what can actually be in a config, but these may have been addressed) but by looking at that xsd, it looks like it wants the Console element to appear *after* all of the other Appender elements. However even fixing that, I can't see how your config xml (or mine for that matter) would validate since that xsd doesn't define the specific appender elements like File or RollingFile*. * I could imagine these elements might be meant to be defined by other xsd files. It is possible to specify multiple xsd files in an xml file, all of which could be necessary to validate it. (This isn't very commonly done, but might be a desirable way to do it if various appenders were condered extensions that the core schema should not "know" about.) So it might be worth trying to find if there are additional xsd files... On 1/3/19 8:41 AM, Ed Zappulla wrote: I'm having trouble getting my log4j2.xml file to conform to the schema. Without the schema specification I don't have any errors but with it in place I am getting: cvc-complex-type.2.4.d: Invalid content was found starting with element 'File'. No child element is expected at this point. cvc-complex-type.2.4.d: Invalid content was found starting with element 'Logger'. No child element is expected at this point. The logging works fine without the schema but Eclipse is warning that its missing so I would like to have it in place. This is the log4j2.xml file I'm using: xmlns="http://logging.apache.org/log4j/2.0/config; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation="http://logging.apache.org/log4j/2.0/config https://raw.githubusercontent.com/apache/logging-log4j2/log4j-2.11.1/log4j-c ore/src/main/resources/Log4j-config.xsd"> Any help would be appreciated. Thank you .ed
Re: java.lang.NoSuchFieldError: errorHandler
I have to agree with Remko. My ratio of lines-of-your-messages-read to being-convinced-you-have-a-valid-point is exceedingly high. Also, truly perceptive people judge the effectiveness of their communications based on the feedback of others. Cheers, Eric On 08/14/2015 02:19 PM, Xen wrote: Well actually that is non-negotiable to me. I can't make my emails (or whatever, I don't /NEED/ to be emailing here, that's not really the point I am making...) shorter because then they'd miss the point and have no effect. My emails are perfectly to the point, it is just that the point needs more explaining ;-). But if you think I should not write any emails at all, you'd be welcome, then I would go spend my time on something else again. The time spent on 'making them shorter' (even when it destroys the purpose of the emails) would probably also vastly outweight the time saved by those who would read them, etc ;-). You'd be rewriting your email and losing all the juice and all the good stuff and in the end nobody cares about it anyway. Because you've sacrificed your own feeling of what is right and lost your happiness and joy in doing it, and that doesn't inspire anyway in the least. Anyway. I do agree with your point that it is unfortunate timing that the next release of log4j 2 requires java 7, at the same time that we announce we are not supporting log4j 1.2 any more. It means that some people who want to migrate may not be able to (or will have to use version 2.3 which was still built with java 6). I agree this is not ideal. I'd say that given current conditions you have no choice but to go on, but that's why I am writing the emails; to change current conditions ;-). Regards ;-). Op 14-8-2015 om 20:07 schreef Remko Popma: Bart, In reality we haven't been fixing issues in log4j 1.2 for a while, so the announcement doesn't really change anything. We are all volunteers working on this in our spare time, and we choose to spend our time working on log4j 2. We thought it was better for everyone if we make our intentions clear, hence the announcement. I do agree with your point that it is unfortunate timing that the next release of log4j 2 requires java 7, at the same time that we announce we are not supporting log4j 1.2 any more. It means that some people who want to migrate may not be able to (or will have to use version 2.3 which was still built with java 6). I agree this is not ideal. Best regards, Remko P.S. Some constructive criticism: your emails are a bit long. I hope you won't be offended by this, but could I ask you to spend a bit more time on making them shorter and more to the point (same functionality in fewer lines of code is better, no)? On Sat, Aug 15, 2015 at 1:17 AM, Xen x...@dds.nl wrote: In response to Jinhong Lu: but all my projects, including spark, hadoop, kafka, they all use log4j1.x I came across a project as well, it was /TeamPostgreSQL, /using 1.2 or whatever, it is the only jar on its classpath. I must say though: We are so happy with the quality and stability of Log4j 2, we are convinced it is a fantastic replacement for Log4j 1. That's clearly a lie. You wouldn't say these things if you were really happy and really convinced it'd be a replacement. That is make believe. In that case you'd say something like There's not much to be said. The thing works and it works well. I think people will be quite content with it, but there might be a few that will hold on to version 1.x. In this case you are belying the fact that many users are going to want to hold on to 1.x, and you are not acknowledging or referencing that in your words, but they are embedded within it regardless. So the lie is visible anyway; anyone who reads it can sense it. Because you know this and they know you know this. You know there are many people who are going to be discontent with such an end of support and of development, perhaps not both, perhaps not any. But you're taking the jump anyway with a bit of forcing this upon everyone, unwilling as they are cause to it.. And I guess, it's just a choice you make, in a sense it is not good or bad and not something to judge, just a personal choice I guess with its flock of repercussions. But I think you should be aware of the fact that not everyone is going to agree with it. Log4J is a pretty commonly used component and that means it should have a broad installable base. Although Java 7 is now the default on most current systems, I suspect there are still going to be many that run 1.6 (or even 1.5!!) and you're even already thinking of installing 1.8 or requiring 1.8 for your newer versions. $ apt list openjdk* Listing... Done openjdk-7-dbg/stable 7u79-2.5.6-1~deb8u1 amd64 openjdk-7-demo/stable 7u79-2.5.6-1~deb8u1 amd64 openjdk-7-doc/stable 7u79-2.5.6-1~deb8u1 all openjdk-7-jdk/stable,now 7u79-2.5.6-1~deb8u1 amd64 [installed,automatic] openjdk-7-jre/stable,now 7u79-2.5.6-1~deb8u1 amd64
Re: Any roadmap date for 2.0?
When I filter in Jira on Open (or Reopened) issues of type Bug, affecting version 2.0-beta9, it lists a couple of dozen issues, not just that one. On 12/3/2013 4:44 PM, Remko Popma wrote: I would be okay with releasing what we have now as 2.0-GA. Based on the JIRAs that have 2.0-rc1 or 2.0 in their target versions, there is one outstanding bug to do with Log4jServletContextListener (LOG4J2-359https://issues.apache.org/jira/browse/LOG4J2-359), and the rest are new feature requests. Personally, I think we can work on the OSGi stuff and the other feature requests after the 2.0-GA release. I would be okay with fixing that 359 in a subsequent release. I think we should either pick a date, or select some _absolutely must have_ JIRAs and release 2.0 when they are done. Personally I kind of favor the date approach. (Items that are not resolved before that date go into a subsequent release.) How about: Jan 31 as our target 2.0 release date? Thoughts? PS The *real* problem is... which logo do we pick? ;-) Oh well, maybe we can start worrying about that one when we've fixed a release date. On Tue, Dec 3, 2013 at 8:44 PM, Gary Gregory garydgreg...@gmail.com wrote: I would be ok with another release, rc or beta the name is debatable, sooner rather than later. I'm not sure what the other committees are doing around the holidays, but it's usually a busy time for folks in the US and elsewhere I imagine. Gary Original message From: Francesco Chicchiriccò ilgro...@apache.org Date:12/03/2013 05:49 (GMT-05:00) To: log4j-user@logging.apache.org Subject: Any roadmap date for 2.0? Hi all, is there already any planned release date for 2.0RC1? And what about 2.0? Thanks. Regards. -- Francesco Chicchiriccò Tirasa - Open Source Excellence http://www.tirasa.net/ ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/ - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Any roadmap date for 2.0?
On 12/3/2013 5:29 PM, Eric Schwarzenbach wrote: When I filter in Jira on Open (or Reopened) issues of type Bug, affecting version 2.0-beta9, it lists a couple of dozen issues, not just that one. And BTW there are even more if you do not filter on Affects Version, which brings in issues such as LOG4J2-441 which do not have an Affects Version set (though the description mentions that the issue was found in beta9)and those reported as affecting previous betas but never updated. - To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Fwd: Re: Log file named ${sys
Remko:
I've created issue LOG4J2-378 for this as you requested. I did not
include my comments about suspecting ServletContextListener
contextInitialized method ordering to be relevant since you replied that
it was string substitution issue in the FastFile appender. However you
did not reply to my question of why that would produce different
behavior on two different systems, so I'm still unclear whether
contextInitialized ordering is relevant.
Eric
On 8/26/2013 11:47 PM, Eric Schwarzenbach wrote:
On 8/26/2013 7:48 PM, Remko Popma wrote:
Looks like a string substitution issue in the FastFile appender
(renamed to
RandomAccessFile appender in the next release, btw, so you'll need to
change your config when you upgrade).
Why would that behave differently on one server vs another?
Can you file a JIRA ticket for this?
Sure.
Thanks,
Remko
On Tuesday, August 27, 2013, Eric Schwarzenbach wrote:
I'm using log4j 2.0-beta8 in a webapp, and running it under Tomcat.
I'm setting a system property in my apps ServletContextListener, and
using
that system property in my log4j2.xml file, like so:
appender type=FastFile name=File fileName=${sys:catalina.home}**
/logs/${sys:application-name}.**log
On my Windows machine, a log file named ${sys. (always 0 bytes) is
being
created instead of a log file with the application-name. The same war
deployed on one of our linux servers (also tomcat 7, though a slightly
different version) does not create a ${sys. file and instead
creates a log
file with the intended application-name.
What I think must be happening is that my app's ServletContextListener
contextInitialized method is getting called before
Log4jServletContextListener's on the server, but that they are getting
called in the opposite order on my local machine. The javadoc seems to
suggest that the intention is for it Log4jServletContextListener's to
always occur first. This raises several issues:
1) Is the fact that they get called in different orders on different
machines a failure of Tomcat to call them in the right order? Or a
failure
of the log4j code to ensure things are set up so as to guarantee this
order? Or is the order even specified and guarranteeable?
2) Is Log4jServletContextListener's contextInitialized being called
first
necessarily desirable? If Log4jServletContextListener always gets
called
before the application's context listener, how is the application to
set up
variables for use in the log4j configuration, particularly, for example
(which is what I am doing), to get the webapp's name from the servlet
context path to name the log files? Is there some better way to do
this?
(Ideally without requiring configuration to be loaded twice...which
is what
I ended up happening with logback when I tried to set it up to do
this same
thing.)
According to the servlet spec The Web container registers the listener
instances according to the interfaces they implement and the order
in which
they appear in the deployment descriptor. During Web application
execution,
listeners are invoked in the order of their registration. Since
Log4jServletContextListener doesn't appear in the web.xml, I assume it
should call them according to the interfaces they implement. I
have no
idea what that is supposed to mean, though.
--**--**-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Re: Fwd: Re: Log file named ${sys
Actually I just realized that I have 2 sys: variables and that the first
is in fact resolving. The files do appear in the directory that
sys:catalina.home should resolve to (and appear elsewhere when I don't
use sys:catalina.home).
sys:catalina.home does not depend on my app's ServletContextListener
contextInitialized method being called before
Log4jServletContextListener's but sys:application-name, I believe, does.
So I'll add my previous comments to the issue.
On 8/28/2013 12:13 PM, Eric Schwarzenbach wrote:
Remko:
I've created issue LOG4J2-378 for this as you requested. I did not
include my comments about suspecting ServletContextListener
contextInitialized method ordering to be relevant since you replied
that it was string substitution issue in the FastFile appender.
However you did not reply to my question of why that would produce
different behavior on two different systems, so I'm still unclear
whether contextInitialized ordering is relevant.
Eric
On 8/26/2013 11:47 PM, Eric Schwarzenbach wrote:
On 8/26/2013 7:48 PM, Remko Popma wrote:
Looks like a string substitution issue in the FastFile appender
(renamed to
RandomAccessFile appender in the next release, btw, so you'll need to
change your config when you upgrade).
Why would that behave differently on one server vs another?
Can you file a JIRA ticket for this?
Sure.
Thanks,
Remko
On Tuesday, August 27, 2013, Eric Schwarzenbach wrote:
I'm using log4j 2.0-beta8 in a webapp, and running it under Tomcat.
I'm setting a system property in my apps ServletContextListener,
and using
that system property in my log4j2.xml file, like so:
appender type=FastFile name=File fileName=${sys:catalina.home}**
/logs/${sys:application-name}.**log
On my Windows machine, a log file named ${sys. (always 0 bytes)
is being
created instead of a log file with the application-name. The same war
deployed on one of our linux servers (also tomcat 7, though a slightly
different version) does not create a ${sys. file and instead
creates a log
file with the intended application-name.
What I think must be happening is that my app's ServletContextListener
contextInitialized method is getting called before
Log4jServletContextListener's on the server, but that they are getting
called in the opposite order on my local machine. The javadoc seems to
suggest that the intention is for it Log4jServletContextListener's to
always occur first. This raises several issues:
1) Is the fact that they get called in different orders on different
machines a failure of Tomcat to call them in the right order? Or a
failure
of the log4j code to ensure things are set up so as to guarantee this
order? Or is the order even specified and guarranteeable?
2) Is Log4jServletContextListener's contextInitialized being called
first
necessarily desirable? If Log4jServletContextListener always gets
called
before the application's context listener, how is the application
to set up
variables for use in the log4j configuration, particularly, for
example
(which is what I am doing), to get the webapp's name from the servlet
context path to name the log files? Is there some better way to do
this?
(Ideally without requiring configuration to be loaded twice...which
is what
I ended up happening with logback when I tried to set it up to do
this same
thing.)
According to the servlet spec The Web container registers the
listener
instances according to the interfaces they implement and the order
in which
they appear in the deployment descriptor. During Web application
execution,
listeners are invoked in the order of their registration. Since
Log4jServletContextListener doesn't appear in the web.xml, I assume it
should call them according to the interfaces they implement. I
have no
idea what that is supposed to mean, though.
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Log file named ${sys
I'm using log4j 2.0-beta8 in a webapp, and running it under Tomcat.
I'm setting a system property in my apps ServletContextListener, and
using that system property in my log4j2.xml file, like so:
appender type=FastFile name=File
fileName=${sys:catalina.home}/logs/${sys:application-name}.log
On my Windows machine, a log file named ${sys. (always 0 bytes) is
being created instead of a log file with the application-name. The same
war deployed on one of our linux servers (also tomcat 7, though a
slightly different version) does not create a ${sys. file and instead
creates a log file with the intended application-name.
What I think must be happening is that my app's ServletContextListener
contextInitialized method is getting called before
Log4jServletContextListener's on the server, but that they are getting
called in the opposite order on my local machine. The javadoc seems to
suggest that the intention is for it Log4jServletContextListener's to
always occur first. This raises several issues:
1) Is the fact that they get called in different orders on different
machines a failure of Tomcat to call them in the right order? Or a
failure of the log4j code to ensure things are set up so as to guarantee
this order? Or is the order even specified and guarranteeable?
2) Is Log4jServletContextListener's contextInitialized being called
first necessarily desirable? If Log4jServletContextListener always gets
called before the application's context listener, how is the application
to set up variables for use in the log4j configuration, particularly,
for example (which is what I am doing), to get the webapp's name from
the servlet context path to name the log files? Is there some better way
to do this? (Ideally without requiring configuration to be loaded
twice...which is what I ended up happening with logback when I tried to
set it up to do this same thing.)
According to the servlet spec The Web container registers the listener
instances according to the interfaces they implement and the order in
which they appear in the deployment descriptor. During Web application
execution, listeners are invoked in the order of their registration. Since
Log4jServletContextListener doesn't appear in the web.xml, I assume it
should call them according to the interfaces they implement. I have no
idea what that is supposed to mean, though.
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
Fwd: Re: Log file named ${sys
On 8/26/2013 7:48 PM, Remko Popma wrote:
Looks like a string substitution issue in the FastFile appender (renamed to
RandomAccessFile appender in the next release, btw, so you'll need to
change your config when you upgrade).
Why would that behave differently on one server vs another?
Can you file a JIRA ticket for this?
Sure.
Thanks,
Remko
On Tuesday, August 27, 2013, Eric Schwarzenbach wrote:
I'm using log4j 2.0-beta8 in a webapp, and running it under Tomcat.
I'm setting a system property in my apps ServletContextListener, and using
that system property in my log4j2.xml file, like so:
appender type=FastFile name=File fileName=${sys:catalina.home}**
/logs/${sys:application-name}.**log
On my Windows machine, a log file named ${sys. (always 0 bytes) is being
created instead of a log file with the application-name. The same war
deployed on one of our linux servers (also tomcat 7, though a slightly
different version) does not create a ${sys. file and instead creates a log
file with the intended application-name.
What I think must be happening is that my app's ServletContextListener
contextInitialized method is getting called before
Log4jServletContextListener's on the server, but that they are getting
called in the opposite order on my local machine. The javadoc seems to
suggest that the intention is for it Log4jServletContextListener's to
always occur first. This raises several issues:
1) Is the fact that they get called in different orders on different
machines a failure of Tomcat to call them in the right order? Or a failure
of the log4j code to ensure things are set up so as to guarantee this
order? Or is the order even specified and guarranteeable?
2) Is Log4jServletContextListener's contextInitialized being called first
necessarily desirable? If Log4jServletContextListener always gets called
before the application's context listener, how is the application to set up
variables for use in the log4j configuration, particularly, for example
(which is what I am doing), to get the webapp's name from the servlet
context path to name the log files? Is there some better way to do this?
(Ideally without requiring configuration to be loaded twice...which is what
I ended up happening with logback when I tried to set it up to do this same
thing.)
According to the servlet spec The Web container registers the listener
instances according to the interfaces they implement and the order in which
they appear in the deployment descriptor. During Web application execution,
listeners are invoked in the order of their registration. Since
Log4jServletContextListener doesn't appear in the web.xml, I assume it
should call them according to the interfaces they implement. I have no
idea what that is supposed to mean, though.
--**--**-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
-
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
