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
[installed,automatic]
openjdk-7-jre-dcevm/stable 7u60-3 amd64
openjdk-7-jre-headless/stable,now 7u79-2.5.6-1~deb8u1 amd64
[installed,automatic]
openjdk-7-jre-lib/stable 7u79-2.5.6-1~deb8u1 all
openjdk-7-jre-zero/stable 7u79-2.5.6-1~deb8u1 amd64
openjdk-7-source/stable 7u79-2.5.6-1~deb8u1 all
That's the default installable base on debian 8. If I were to deploy my
application (any application, really) on systems that are not under my
control... it is pretty common for shell hosts for instance to not have
java or javac at all for 'security reasons'. The stupidity yeah, but it
happens. So I don't know but you can't push these limits too much.
I'm kinda wondering what kind of personal goals of interests you
have in
pushing this version evolution so much? When you see that half the
world,
so to speak, still uses version 1.x. But it's like you have an ulterior
motive, such as e.g. an employer that wants it, or a certain
subsection of
what you work with who would want that. Or some bragging rights, I
don't
know.
You see a LOT of mismatched versioning attempts these days. I mean a
newer
major version comes out, something jumps from 2 to 3 or from 1 to 2.
And in
*most* cases the new version seem to be worse than the old one.
Python 3
seems not better or more self-congruent than Python 2. SQLite 2
seems to
have a lot of adherents still, including myself perhaps. GTK 3 has
seen a
change in how you use it that is just way less attractive than GTK2, at
least for the python wrapper that existed for GTK2. PyGTK2 was
reasonably
easy to use compared to the convoluted way of calling and using the
library
that exists now.
In general I just sense that "newer versions" are done for bad
reasons. I
don't know why this seems to be such a common case. I can see
things, if I
study them, for instance in Python 3, or whatever, if I study it I
come up
with reasons for saying that the design has gone bad.
And you can sense it right away, because of how the maintainers or
developers go about it. And then when they see uptake is below what
they
want, they start to "persuade" people who don't feel like using the
thing
at all. That's what happened or is happening with Python 3. They are
trying
to "push" and to entice and give REASONS for using the thing when it
isn't
self evident. Still a lot of people use 2.7 or they use that
wrapper-bridge
thing that exists.
I just jumped on Log4J 2 because from a developing perspective it
makes no
sense to go to 1.2 when there is no interest for that anymore from the
developer point of view.
No interest, no communication, no aliveness.
Personally I would make it a goal to further develop 1.x up to a
certain
point, make it a subgoal, and one that agrees with 2.x such that you
have a
bit of a convergence; you might port something back from 2 to 1 for
instance, or whatever. Inspire the old project with the new or / and
vice
versa.
I would ensure that the old java versions still have a place. It
would be
a rotten place if some old server that can't be upgraded by you or
anyone
wouldn't be able to run Log4j and you are also closing the gap
between the
existing user base that is maybe 80-90% version 1, and the ever
widening or
departing version 2 that gets further and further away from that old
Java
1.5. And what reasons do you have to go for java 7 and 8? Probably
not all
that important except that it is a selling point of some thing for some
people. A library must be conservative.
And it's moving too fast. Maybe you like it to move fast but the
problem
exacerbates. People start to lose the connection and fall in the
gap. They
can't really leave 1.x behind. They fancy 2.x. But the further away
it gets
(from e.g. java requirements) the harder it is to tag along. For
whom are
you doing it? For yourselves only?....
Yourselfes only?.
I think it is a problem for this. You seem to focus on introducing new
features at the cost, the vast cost, of support for older systems. And
those features are not vital, just flashy. Lambda support? Come on. It
can't be essential. I've never used it and never wanted to use it
yet. I
don't even think it has a real place in Java the way it is, not that
I have
looked at it extensively. Maybe it just doesn't have a place here,
whatever.
I condider java having gone in bad directions anyway starting with 1.5.
All of the designs are ugly in my mind and to my perception and
opinion.
I love the old java but all of the new things continuously make the
code
more hideous and I believe harder to maintain. Just look at all the
annotations for the plugins and all. It is very hard to read and quite
complex or complicated the way I see it.
Generics are hard and hardly readable. @Override annotations hardly
have
any use. And become 'invalid' once the code compiles correctly the
first
times. Superfluous. I don't know much about it, much else. I just
think the
code is getting uglier and uglier that I see around.
Enums are also not that great and suffer from some serious design
flaws.
The move from arrays to Collection classes is too great and you are
often
left to choose completely between two competing paradigms in the
same code.
Do I use enums and collections? Or do I use indexes and arrays? Do I
use
enums with fields to index arrays? . How much slower is my code
going to be
if a switch statement requires a method call and an array lookup? .
Where
is the pristine quality of using bitsets or even java BitSets?. (We
still
don't have "struct" types, e.g. pascal had "record" type structures
that
caused you to accurately design a form of memory structure that
could be
instantiated). Java code is becoming and has become convoluted because
programming essentials are left behind and everything becomes
Expensive.
Because of memory alignment there is hardly any use for
non-default-bitwidth integers and the smaller types that exist have no
purpose because they are signed. And everyone must be feeling this,
all of
this. You can't program this shit for longer periods if you don't
feel what
it does to you. Where's the fun in all of this? There are not even good
(generic) binary tree or whatever tree implementations that you can
really
use to store objects in. At least in the default collections.
Oh well, just my way of seeing things I guess. I have Java 8 on the
windows machine, 7 on my new debian VPS, but I was seriously
planning to
develop and deploy for java 5.
Seeing as that, whatever. Anyway I'll go and send that email I guess.
Op 14-8-2015 om 8:05 schreef Jinhong Lu:
you mean upgrade to log4j2?
but all my projects, including spark, hadoop, kafka, they all use
log4j1.x
2015-08-14 13:25 GMT+08:00 Ralph Goers<ralph.go...@dslextreme.com>:
Please see -
https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
<
https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
.
Ralph
On Aug 13, 2015, at 10:08 PM, Jinhong Lu<lujinho...@gmail.com>
wrote:
I met this exception when using syslogappender.
my log4j version is 1.2.16.
Any idea? thanks.
java.lang.NoSuchFieldError: errorHandler
at
org.apache.log4j.net
.SyslogAppender.setSyslogHost(SyslogAppender.java:391)
~[log4j-1.2.16.jar:na]
at
com.netease.sytopology.util.MySysLogger.<init>(MySysLogger.java:39)
~[stormjar.jar:na]
at
com.netease.sytopology.util.MySysLogger.getInstance(MySysLogger.java:28)
~[stormjar.jar:na]
at
com.netease.sytopology.bolt.FilterFunction.prepare(FilterFunction.java:65)
~[stormjar.jar:na]
at
storm.trident.planner.processor.EachProcessor.prepare(EachProcessor.java:54)
~[storm-core-0.9.4.jar:0.9.4]
at
storm.trident.planner.SubtopologyBolt.prepare(SubtopologyBolt.java:121)
~[storm-core-0.9.4.jar:0.9.4]
at
storm.trident.topology.TridentBoltExecutor.prepare(TridentBoltExecutor.java:231)
~[storm-core-0.9.4.jar:0.9.4]
at
backtype.storm.daemon.executor$fn__4722$fn__4734.invoke(executor.clj:692)
~[storm-core-0.9.4.jar:0.9.4]
at
backtype.storm.util$async_loop$fn__458.invoke(util.clj:461)
~[storm-core-0.9.4.jar:0.9.4]
at clojure.lang.AFn.run(AFn.java:24) [clojure-1.5.1.jar:na]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_67]
And here is my code:
import org.apache.log4j.Level;
import org.apache.log4j.Logger;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.helpers.OnlyOnceErrorHandler;
import org.apache.log4j.net.SyslogAppender;
import org.apache.log4j.varia.FallbackErrorHandler;
public class MySysLogger {
//ä»¥ä¸‹å ‚æ•°å ‡å ¯æ ¹æ ®éœ€è¦ æ”¾åˆ°é… ç½®æ–‡ä»¶ä¸ã€‚
//默认日志级别
private static Level level = Level.INFO;
//æ—¥å¿—æŽ¥æ”¶æœ åŠ¡å™¨
private static String syslogHost = "172.16.1.18";
//设置facility
private static String facility = "local7";
private static String loggerName = "";
public static void setLoggerName(String loggerName2) {
MySysLogger.loggerName = loggerName2;
}
private static Logger LOG = null;
public static synchronized Logger getInstance() {
if (LOG == null) {
new MySysLogger(loggerName);
}
return LOG;
}
private MySysLogger(String loggerName) {
LOG = Logger.getRootLogger();
LOG.setLevel(level);
SyslogAppender appender = new SyslogAppender();
appender.setErrorHandler(new FallbackErrorHandler());
appender.setSyslogHost(syslogHost);
appender.setLayout(new PatternLayout(
"%r " + loggerName +" [%t] %-5p %C%x - %m"));
appender.setHeader(true);
appender.setFacility(facility);
LOG.addAppender(appender);
}
}
