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<[email protected]>:
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<[email protected]> 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);
}
}
