Hi Remko and Ralph,
Thank you for your inputs.
I tried adding the context.updateLoggers() after initializing the context and
it worked.
I do agree that it would make better sense to have properties within log4j
configuration to tailor for each application.
I will try that in the next
Remko, since he is using Configurator he shouldn’t have to call updateLoggers.
However, he is calling System.setProperty to set the LoggerContext
implementation to use AFTER the static Logger is created. There is no hope that
could ever work. The best way to fix that would be to add the setting
The first line: private static final Logger LOGGER =
LogManager.getLogger(TestLog.class);
is executed before the code in main(). This means that Log4j will initialize to
the default configuration (since it cannot find a configuration file).
After that, your code in main() kicks in.
It is
Hi Mikael,
The product I am working on holds about 15 odd configurations which are
specific to different process that run as part of the application. It is a core
java app.
So, every time a process starts the configuration is loaded on the fly.
We store configurations in a properties file with
On Wed, Nov 30, 2016 at 9:41 AM, Mikael Ståldal
wrote:
> Any particular reason for not using a configuration file?
Do you have reason to believe, that this would change the behaviour?
--
The next time you hear: "Don't reinvent the wheel!"
Any particular reason for not using a configuration file?
On Wed, Nov 30, 2016 at 5:31 AM, Tarun Sharma
wrote:
> Hi,
>
>
>
> While upgrading from 1.2.17 to 2.5, I have come across a major
> difference. Please see following code snippets.
>
>
>
> Log4j1.2.17
>
>
Hi,
While upgrading from 1.2.17 to 2.5, I have come across a major difference.
Please see following code snippets.
Log4j1.2.17
private static final Logger LOGGER = Logger.getLogger(TestLog.class);
public static void main(String args[])
{
Properties p = new Properties();