You are very friendly, thank you for that.
I take it you mean that it is not thread-safe with regards to other
threads that may already, and still, and currently be using Loggers to
do things.
So what you do instead is create the new object in safety and then
quickly install it using a form of locking such that the operation
cannot deadlock anything.
Nevertheless, I would think a (reconfiguration) API could be devised
in a better way, at least with regard to programmatic control .. but
still it is impressive how you do it in a way, I must say :).
It is just developer-unfriendly not to have that control in the first
place. And I think the way the API is devised causes a bit of a
brick-wall experience. The thing you need to do is /too difficult/ for
anyone who just wants to start with the smallest of things. The
documentation itself also causes a brick-wall but that is really the
same thing, part of the same experience. Anyone who is just a new user
cannot do what the "extending Log4j2" API suggests.
I believe it could be amended but that is not really my purpose here.
I would be happy if I found out how to do it in the first place. Maybe
then once I understand everything I may be able to offer a suggestion,
if that was accepted or welcomed.
I thank you for your humility and modesty and would like to offer my
own. I am just a new user and I have many demands but I also just want
a solution that I can agree with a little and be happy with in the
long run. I just thought Log4J should be the way to go since Logback
doesn't appeal to me and I haven't seen anything else that sparked my
interest yet. So for now I am just doing exploration on this thing.
You have helped me a great way already but I still have many
challenges to overcome. I am just going to experiment with the API and
see if I can learn the programmatic control of the Appenders and
Filters and the other things. My goals is to create the configuration
I want from scratch (or from the default config) by programmatic
changes. For my current project and my current needs that should
probably be easy. If I can then finally or eventually also achieve
reconfiguration across sets, that would be very pleasant. The goal I
have in mind at this point is also for me to create several different
configurations at the same time that I can exercise or install or
activate at will :). In this way I can have several different "modes"
or "states" for my program that I can activate easily without doing
any additional setup each time. That should probably already be
possible in a way.
If I were to suggest anything in due time (I hope so) it would
probably be mostly for closing or bridging that "brick wall"
experience that people have. What would be necessary for that would be
clear entry points and a clear and easy path of going from relevant
object to relevant object. Since your object/class structure is not
all that big and pretty easy to grasp eventually, and more likely,
when you know all the methods, I guess, probably, it should be easy to
think of something that would create a "path of unbroken success" from
start to end.
And maybe that would be helpful and maybe others could then learn of
my experience. Let's hope so ;-).
Regards, Bart.
Quoting Ralph Goers <[email protected]>:
Sorry if it appears we don’t care, but your original message seemed
to be full of sarcasm and didn’t ask for any real help.
FWIW, the goal wasn’t to make configuration harder - it was to make
configuration changes thread safe. Log4j 1 has thread safety issues
and locks in ways that can cause deadlocks. Some of the things that
you consider to be part of the Log4j 1 API are really part of the
internals of the system.
Like any other software I am sure our documentation can be improved.
If you compare the amount of documentation available for Log4j 2
against what was available for Log4j 1 I think we are miles ahead.
If you find places that it can be improved please open a Jira issue
and possibly even supply a patch.
But the manual is correct in that the safest way to perform
programmatic configuration is to implement a custom
ConfigurationFactory. I just recently added a sample to the
log4j-samples/configuration project. That hasn’t been released yet
but you can check it out from git. Some things, like adding a new
LoggerConfig, cannot be done safely to the current configuration,
and so the only way to do that is to create a new Configuration. Of
course that isn’t as simple as it was with Log4j 1, but it also
avoids a whole pile of threading issues.
Ralph
On Aug 8, 2015, at 9:51 AM, Xen <[email protected]> wrote:
Heh, it seems more like you went out of your way to close off a
configuration method on purpose that you would know would still be
in high demand by a lot of people.
The choice to have only configuration per external file would
definitely have raised a lot of eyebrows. And I bet, still does
with anyone who reads that piece of the manual.
Quoted for truth ;-):
====
Configuration of Log4j 2 can be accomplished in 1 of 4 ways:
1. Through a configuration file written in XML, JSON, or YAML.
2. Programmatically, by creating a ConfigurationFactory and
Configuration implementation.
3. Programmatically, by calling the APIs exposed in the
Configuration interface to add components
to the default configuration.
4. Programmatically, by calling methods on the internal Logger class.
(...)
Note that unlike Log4j 1.x, the public Log4j 2 API does not expose
methods to add, modify or remove appenders and filters or
manipulate the configuration in any way.
====
The manual basically hides any form of information relevant to or
pertinent with manual configuration. The information is almost
nowhere to be found?
What the manual does indicate about manual configuration is not trivial:
"Modifying the way in which logging can be configured is usually
one of the areas with the most interest. The primary method for
doing that is by implementing or extending a ConfigurationFactory.
Log4j provides two ways of adding new ConfigurationFactories. The
first is by defining the system property named
"log4j.configurationFactory" to the name of the class that should
be searched first for a configuration. The second method is by
defining the ConfigurationFactory as a Plugin."
Should a method for programmatic configuration exist and be
usable/reachable, supported and documented, many users would surely
use it or prefer it or make use of it.
So I don't think you've gone out of your way to please everyone
;-). I think you made the rational choice to displease a lot of
people. There must be thousands of people who'd give preference to
programmatic configuration when given the choice. That's just the
reality of it.
I'm sorry but uhm yeah. I still think I need to use Log4j 2 but
I'll go about experimenting with its configuration in the coming
days.
Thanks you for your help in any case :).
See ya :).
X.
Quoting Ralph Goers <[email protected]>:
I guess you can't please everybody.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
