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 [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); >>>> >>>> } >>>> >>>> >>>> } >>>> >>> >
