You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Jinhong Lu <lu...@gmail.com> on 2015/08/14 07:08:25 UTC
java.lang.NoSuchFieldError: errorHandler
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);
}
}
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Douglas Wegscheid <do...@whirlpool.com>.
> So you are saying that you would simply add a log4j1 to log4j2 bridge
> right. And those libraries that use the old version then automatically use
> the bridge. And everything runs agains the new version then regardless.
>
yep. they designed it to do that, and it works as advertised. I used to
bridge j.u.l and JCL to slf4j feeding log4j1, and now am doing it with JUL,
JCL, and slf4j feeding log4j2.
>
> I believe slf4j is also meant for that right? I don't like its deployment
> but it's super easy of course. So you would bridge log4j1 to log4j2 for
> example (for older libraries/systems) and meanwhile you write your own code
> against slf4j so that it is portable to another framework if required.
>
precisely. that's why I use the slf4j bindings in my own stuff.
>
> I would personally still be tempted to move to log4j2 if it's a better
> product. But mostly I believe the Java progression version requirement is
> what would hold me back. Java 1.6 is probably not so bad. Knowing that if I
> jumped to log4j2 I would need to be very conservative and not jump on the
> 1.7 and 1.8 bandwagon, would ... reduce the attractiveness of the upgrade.
> From my perception (and I must say I am *very* perceptive, people regularly
> tell me if I get the chance, how right on the mark I am) the biggest
> benefit of log4j2 from an upgrade perspective is to be right where the
> money is. The biggest downside is higher java version requirements. I don't
> think (If I am allowed to voice a sentiment that may not be warranted here)
> the new API thing is absolute perfection but that would not hold me back,
> because progress is possible and progress is what happens in the future,
> not the past.
>
I hadn't been keeping track of the Java version dependencies, and I agree
that future versions depending on Java 7 will probably cause some people
not to switch. But as observed, log4j2 2.3 is available.
how big of an issue is a Java 7 dependency? One problem is having an
environment that absolutely cannot be upgraded (some web environments and
old OSes come to mind), but how big is that space?
I can't recall any old code I've seen that won't run on a newer JVM that it
was designed for.
--
*NOTICE: Whirlpool Corporation e-mail is for the designated recipient only
and may contain proprietary or otherwise confidential information. If you
have received this e-mail in error, please notify the sender immediately
and delete the original. Any other use or disclosure of the e-mail by you
is unauthorized.*
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
So you are saying that you would simply add a log4j1 to log4j2 bridge
right. And those libraries that use the old version then automatically
use the bridge. And everything runs agains the new version then regardless.
I believe slf4j is also meant for that right? I don't like its
deployment but it's super easy of course. So you would bridge log4j1 to
log4j2 for example (for older libraries/systems) and meanwhile you write
your own code against slf4j so that it is portable to another framework
if required.
I would personally still be tempted to move to log4j2 if it's a better
product. But mostly I believe the Java progression version requirement
is what would hold me back. Java 1.6 is probably not so bad. Knowing
that if I jumped to log4j2 I would need to be very conservative and not
jump on the 1.7 and 1.8 bandwagon, would ... reduce the attractiveness
of the upgrade. From my perception (and I must say I am *very*
perceptive, people regularly tell me if I get the chance, how right on
the mark I am) the biggest benefit of log4j2 from an upgrade perspective
is to be right where the money is. The biggest downside is higher java
version requirements. I don't think (If I am allowed to voice a
sentiment that may not be warranted here) the new API thing is absolute
perfection but that would not hold me back, because progress is possible
and progress is what happens in the future, not the past.
I think that holds true for many people. "Don't fix it if it ain't
broke" has not ever really been a thing that people agree with in their
actual choices ;-). Haha.
Op 14-8-2015 om 18:43 schreef Douglas Wegscheid:
> which is the reason that projects aren't 'complying'?
>
> - v2 is not better than v1
> - the upgrade path and bridge jars mean the upgrading is really not
> necessary.
>
> I suspect it's the 2nd: why put a bunch of work into reworking all the
> logging in my library (and forcing my users to change their logging
> framework, which may not support other dependencies my project has) when I
> can spend that effort into making my library do what it does better?
>
> with the way things are, I can use old libraries that use j.u.l, log4j1,
> slf4j, or jcl with log4j2 (or slf4j), just need to use the bridge
> utilities. I'm to the point when I start a new project that I always start
> with a slf4j or log4j2 configuration (and I still write my stuff against
> the slf4j APIs), write a method to set up any bridging, and call that
> method first thing....
>
>
> *■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
> (269) 923-5278 // Douglas_E_Wegscheid@whirlpool.com
>
> "A wrong note played hesitatingly is a wrong note. A wrong note played with
> conviction is interpretation."
>
> On Fri, Aug 14, 2015 at 12:15 PM, Xen <xe...@dds.nl> wrote:
>
>> Then why do you need to persuade people? Why are they unwilling? Obviously
>> they stand to lose something or they would 'comply' of their own.
>>
>> ;-). Seriously, that's just the case. Your personal opinion doesn't matter
>> much it is about what it does to people.
>>
>> Op 14-8-2015 om 16:19 schreef Mikael Ståldal:
>>
>> I don't agree with you that Log4j 2 is worse than Log4j 1. Log4j 2 is a
>>> huge improvement.
>>>
>>> On Fri, Aug 14, 2015 at 4:05 PM, Xen <xe...@dds.nl> wrote:
>>>
>>> That is precisely the sort of stuff you get when your application or newer
>>>> version is actually worse than your older version, and now you need to do
>>>> effort to "persuade" others in joining you when you have not really
>>>> improved things ;-).
>>>>
>>>> I was writing some longer email I guess, I will send it later, I guess.
>>>>
>>>> Bye.
>>>>
>>>> Op 14-8-2015 om 10:27 schreef Mikael Ståldal:
>>>>
>>>> Perhaps the Log4j developers should spend some time to persuade other
>>>>
>>>>> Apache projects to start using Log4j 2.
>>>>>
>>>>> On Fri, Aug 14, 2015 at 8:05 AM, Jinhong Lu <lu...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> 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 <ra...@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 <lu...@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);
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>>
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Douglas Wegscheid <do...@whirlpool.com>.
which is the reason that projects aren't 'complying'?
- v2 is not better than v1
- the upgrade path and bridge jars mean the upgrading is really not
necessary.
I suspect it's the 2nd: why put a bunch of work into reworking all the
logging in my library (and forcing my users to change their logging
framework, which may not support other dependencies my project has) when I
can spend that effort into making my library do what it does better?
with the way things are, I can use old libraries that use j.u.l, log4j1,
slf4j, or jcl with log4j2 (or slf4j), just need to use the bridge
utilities. I'm to the point when I start a new project that I always start
with a slf4j or log4j2 configuration (and I still write my stuff against
the slf4j APIs), write a method to set up any bridging, and call that
method first thing....
*■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
(269) 923-5278 // Douglas_E_Wegscheid@whirlpool.com
"A wrong note played hesitatingly is a wrong note. A wrong note played with
conviction is interpretation."
On Fri, Aug 14, 2015 at 12:15 PM, Xen <xe...@dds.nl> wrote:
> Then why do you need to persuade people? Why are they unwilling? Obviously
> they stand to lose something or they would 'comply' of their own.
>
> ;-). Seriously, that's just the case. Your personal opinion doesn't matter
> much it is about what it does to people.
>
> Op 14-8-2015 om 16:19 schreef Mikael Ståldal:
>
> I don't agree with you that Log4j 2 is worse than Log4j 1. Log4j 2 is a
>> huge improvement.
>>
>> On Fri, Aug 14, 2015 at 4:05 PM, Xen <xe...@dds.nl> wrote:
>>
>> That is precisely the sort of stuff you get when your application or newer
>>> version is actually worse than your older version, and now you need to do
>>> effort to "persuade" others in joining you when you have not really
>>> improved things ;-).
>>>
>>> I was writing some longer email I guess, I will send it later, I guess.
>>>
>>> Bye.
>>>
>>> Op 14-8-2015 om 10:27 schreef Mikael Ståldal:
>>>
>>> Perhaps the Log4j developers should spend some time to persuade other
>>>
>>>> Apache projects to start using Log4j 2.
>>>>
>>>> On Fri, Aug 14, 2015 at 8:05 AM, Jinhong Lu <lu...@gmail.com>
>>>> wrote:
>>>>
>>>> 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 <ra...@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 <lu...@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);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
*NOTICE: Whirlpool Corporation e-mail is for the designated recipient only
and may contain proprietary or otherwise confidential information. If you
have received this e-mail in error, please notify the sender immediately
and delete the original. Any other use or disclosure of the e-mail by you
is unauthorized.*
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Jinhong Lu <lu...@gmail.com>.
OK, I sent my mail not to argue about which is better, and I resolve my
problem myself.
I have a jar of log4j-over-slf4j.jar in my classpath.
That's all. Thanks everyone.
2015-08-15 0:15 GMT+08:00 Xen <xe...@dds.nl>:
> Then why do you need to persuade people? Why are they unwilling? Obviously
> they stand to lose something or they would 'comply' of their own.
>
> ;-). Seriously, that's just the case. Your personal opinion doesn't matter
> much it is about what it does to people.
>
> Op 14-8-2015 om 16:19 schreef Mikael Ståldal:
>
> I don't agree with you that Log4j 2 is worse than Log4j 1. Log4j 2 is a
>> huge improvement.
>>
>> On Fri, Aug 14, 2015 at 4:05 PM, Xen <xe...@dds.nl> wrote:
>>
>> That is precisely the sort of stuff you get when your application or newer
>>> version is actually worse than your older version, and now you need to do
>>> effort to "persuade" others in joining you when you have not really
>>> improved things ;-).
>>>
>>> I was writing some longer email I guess, I will send it later, I guess.
>>>
>>> Bye.
>>>
>>> Op 14-8-2015 om 10:27 schreef Mikael Ståldal:
>>>
>>> Perhaps the Log4j developers should spend some time to persuade other
>>>
>>>> Apache projects to start using Log4j 2.
>>>>
>>>> On Fri, Aug 14, 2015 at 8:05 AM, Jinhong Lu <lu...@gmail.com>
>>>> wrote:
>>>>
>>>> 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 <ra...@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 <lu...@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);
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
Then why do you need to persuade people? Why are they unwilling?
Obviously they stand to lose something or they would 'comply' of their own.
;-). Seriously, that's just the case. Your personal opinion doesn't
matter much it is about what it does to people.
Op 14-8-2015 om 16:19 schreef Mikael Ståldal:
> I don't agree with you that Log4j 2 is worse than Log4j 1. Log4j 2 is a
> huge improvement.
>
> On Fri, Aug 14, 2015 at 4:05 PM, Xen <xe...@dds.nl> wrote:
>
>> That is precisely the sort of stuff you get when your application or newer
>> version is actually worse than your older version, and now you need to do
>> effort to "persuade" others in joining you when you have not really
>> improved things ;-).
>>
>> I was writing some longer email I guess, I will send it later, I guess.
>>
>> Bye.
>>
>> Op 14-8-2015 om 10:27 schreef Mikael Ståldal:
>>
>> Perhaps the Log4j developers should spend some time to persuade other
>>> Apache projects to start using Log4j 2.
>>>
>>> On Fri, Aug 14, 2015 at 8:05 AM, Jinhong Lu <lu...@gmail.com> wrote:
>>>
>>> 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 <ra...@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 <lu...@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);
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Mikael Ståldal <mi...@magine.com>.
I don't agree with you that Log4j 2 is worse than Log4j 1. Log4j 2 is a
huge improvement.
On Fri, Aug 14, 2015 at 4:05 PM, Xen <xe...@dds.nl> wrote:
> That is precisely the sort of stuff you get when your application or newer
> version is actually worse than your older version, and now you need to do
> effort to "persuade" others in joining you when you have not really
> improved things ;-).
>
> I was writing some longer email I guess, I will send it later, I guess.
>
> Bye.
>
> Op 14-8-2015 om 10:27 schreef Mikael Ståldal:
>
> Perhaps the Log4j developers should spend some time to persuade other
>> Apache projects to start using Log4j 2.
>>
>> On Fri, Aug 14, 2015 at 8:05 AM, Jinhong Lu <lu...@gmail.com> wrote:
>>
>> 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 <ra...@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 <lu...@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);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> }
>>>>>
>>>>
>>>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior backend developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
That is precisely the sort of stuff you get when your application or
newer version is actually worse than your older version, and now you
need to do effort to "persuade" others in joining you when you have not
really improved things ;-).
I was writing some longer email I guess, I will send it later, I guess.
Bye.
Op 14-8-2015 om 10:27 schreef Mikael Ståldal:
> Perhaps the Log4j developers should spend some time to persuade other
> Apache projects to start using Log4j 2.
>
> On Fri, Aug 14, 2015 at 8:05 AM, Jinhong Lu <lu...@gmail.com> wrote:
>
>> 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 <ra...@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 <lu...@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);
>>>>
>>>> }
>>>>
>>>>
>>>> }
>>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Mikael Ståldal <mi...@magine.com>.
Perhaps the Log4j developers should spend some time to persuade other
Apache projects to start using Log4j 2.
On Fri, Aug 14, 2015 at 8:05 AM, Jinhong Lu <lu...@gmail.com> wrote:
> 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 <ra...@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 <lu...@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);
> > >
> > > }
> > >
> > >
> > > }
> >
> >
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior backend developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
It's hard to argue with that. Maybe there is a flaw in my mind ;-). I
just take the long-term perspective. I couldn't for the life of me write
differently because it would F with my Mind.
I have trouble as it is staying sane. Doing exactly what I want to do
seems to be the best way to avoid that. Also, I have things / feelings /
thoughts to express. I have to deal with that. So it's just not
non-negotiable to me, if I have to say anything like that again, from a
functional point of view towards my communication (there would really be
no point in writing if I can't follow my own stream of consciousness, as
it always leads me to my goal and my mark) but also the fact that doing
anything else will quickly render me....
Well. Let's say incapable of reasonable confident expression.
Let's just say that being confident about what I do is the only thing I
*can* do. A form of programmed or agreed-upon or 'polite' or 'civilized'
not-trusting-myself doesn't really work out, I don't think it would or
even does work out for anyone.
Let's say that /I/ believe I have a valid point, and I'm writing to make
you see it ;-).
Anyway, enough with that.
Op 14-8-2015 om 21:01 schreef Eric Schwarzenbach:
> I have to agree with Remko. My ratio of lines-of-your-messages-read to
> being-convinced-you-have-a-valid-point is exceedingly high. Also,
> truly perceptive people judge the effectiveness of their
> communications based on the feedback of others.
>
> Cheers,
>
> Eric
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Eric Schwarzenbach <su...@blackbrook.org>.
I have to agree with Remko. My ratio of lines-of-your-messages-read to
being-convinced-you-have-a-valid-point is exceedingly high. Also, truly
perceptive people judge the effectiveness of their communications based
on the feedback of others.
Cheers,
Eric
On 08/14/2015 02:19 PM, Xen wrote:
> Well actually that is non-negotiable to me. I can't make my emails (or
> whatever, I don't /NEED/ to be emailing here, that's not really the
> point I am making...) shorter because then they'd miss the point and
> have no effect. My emails are perfectly to the point, it is just that
> the point needs more explaining ;-).
>
> But if you think I should not write any emails at all, you'd be
> welcome, then I would go spend my time on something else again.
>
> The time spent on 'making them shorter' (even when it destroys the
> purpose of the emails) would probably also vastly outweight the time
> saved by those who would read them, etc ;-). You'd be rewriting your
> email and losing all the juice and all the good stuff and in the end
> nobody cares about it anyway.
>
> Because you've sacrificed your own feeling of what is right and lost
> your happiness and joy in doing it, and that doesn't inspire anyway in
> the least. Anyway.
>
>> 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.
>
> I'd say that given current conditions you have no choice but to go on,
> but that's why I am writing the emails; to change current conditions ;-).
>
> Regards ;-).
>
>
>
> Op 14-8-2015 om 20:07 schreef Remko Popma:
>> 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 <xe...@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<ra...@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<lu...@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);
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
Well actually that is non-negotiable to me. I can't make my emails (or
whatever, I don't /NEED/ to be emailing here, that's not really the
point I am making...) shorter because then they'd miss the point and
have no effect. My emails are perfectly to the point, it is just that
the point needs more explaining ;-).
But if you think I should not write any emails at all, you'd be welcome,
then I would go spend my time on something else again.
The time spent on 'making them shorter' (even when it destroys the
purpose of the emails) would probably also vastly outweight the time
saved by those who would read them, etc ;-). You'd be rewriting your
email and losing all the juice and all the good stuff and in the end
nobody cares about it anyway.
Because you've sacrificed your own feeling of what is right and lost
your happiness and joy in doing it, and that doesn't inspire anyway in
the least. Anyway.
> 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.
I'd say that given current conditions you have no choice but to go on,
but that's why I am writing the emails; to change current conditions ;-).
Regards ;-).
Op 14-8-2015 om 20:07 schreef Remko Popma:
> 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 <xe...@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<ra...@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<lu...@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);
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> }
>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Remko Popma <re...@gmail.com>.
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 <xe...@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<ra...@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<lu...@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);
>>>>
>>>> }
>>>>
>>>>
>>>> }
>>>>
>>>
>
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Gary Gregory <ga...@gmail.com>.
When I first read "cheap places" I thought of services like AWS ;-)
G
On Fri, Aug 14, 2015 at 1:00 PM, Xen <xe...@dds.nl> wrote:
> No I meant my thing might need to run on older platforms. E.g. I might
> want to run it on shell hosts or general cheap places, or interest other
> people in running it.
>
> People are sometimes... idiosynchratic. I had (and have) a Debian based
> shell host that ran Java 1.5 after which they got rid of Java altogether.
> When I was looking for these things it was really a rare occasion that any
> did offer Java. I've had a friend I asked to run a Java program I'd written
> and he wouldn't do it because he thought it would compromise his machine
> (being Java).
>
> Silly stuff but you can't choose for other people... I wonder how it is
> going to work out ;-).
>
> Regards.
>
>
> Op 14-8-2015 om 21:35 schreef Douglas Wegscheid:
>
>>
>>> Of course I can do that but not if my logging library requires greater.
>>> Right? Or should I (be able to) write against slf4j and then run on older
>>> systems by binding to an older version of Log4j?.
>>>
>>> Write Java 5 style code, usel log4j2 2.4, compile it with Java 7, run it
>> on
>> Java 7. You can ignore all the stuff you hate about Java 6 and later.
>>
>> *■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
>> (269) 923-5278 // Douglas_E_Wegscheid@whirlpool.com
>>
>> "A wrong note played hesitatingly is a wrong note. A wrong note played
>> with
>> conviction is interpretation."
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
Thank you, it seems everything is so flexible that in the end it might
not even matter?
As long as you are willing to use the slf4j bridge / abstraction for
example ?.
?. Right.
Op 14-8-2015 om 22:06 schreef Douglas Wegscheid:
>> No I meant my thing might need to run on older platforms. E.g. I might
>> want to run it on shell hosts or general cheap places, or interest other
>> people in running it.
>>
> yes, if you are constrained to running on a JDK 5 platform, then finding a
> suitable version of slf4j is one way to get it done. logback may be helpful
> here, too...
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Douglas Wegscheid <do...@whirlpool.com>.
> No I meant my thing might need to run on older platforms. E.g. I might
> want to run it on shell hosts or general cheap places, or interest other
> people in running it.
>
yes, if you are constrained to running on a JDK 5 platform, then finding a
suitable version of slf4j is one way to get it done. logback may be helpful
here, too...
--
*NOTICE: Whirlpool Corporation e-mail is for the designated recipient only
and may contain proprietary or otherwise confidential information. If you
have received this e-mail in error, please notify the sender immediately
and delete the original. Any other use or disclosure of the e-mail by you
is unauthorized.*
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
No I meant my thing might need to run on older platforms. E.g. I might
want to run it on shell hosts or general cheap places, or interest other
people in running it.
People are sometimes... idiosynchratic. I had (and have) a Debian based
shell host that ran Java 1.5 after which they got rid of Java
altogether. When I was looking for these things it was really a rare
occasion that any did offer Java. I've had a friend I asked to run a
Java program I'd written and he wouldn't do it because he thought it
would compromise his machine (being Java).
Silly stuff but you can't choose for other people... I wonder how it is
going to work out ;-).
Regards.
Op 14-8-2015 om 21:35 schreef Douglas Wegscheid:
>>
>> Of course I can do that but not if my logging library requires greater.
>> Right? Or should I (be able to) write against slf4j and then run on older
>> systems by binding to an older version of Log4j?.
>>
> Write Java 5 style code, usel log4j2 2.4, compile it with Java 7, run it on
> Java 7. You can ignore all the stuff you hate about Java 6 and later.
>
> *■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
> (269) 923-5278 // Douglas_E_Wegscheid@whirlpool.com
>
> "A wrong note played hesitatingly is a wrong note. A wrong note played with
> conviction is interpretation."
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Douglas Wegscheid <do...@whirlpool.com>.
>
>
> Of course I can do that but not if my logging library requires greater.
> Right? Or should I (be able to) write against slf4j and then run on older
> systems by binding to an older version of Log4j?.
>
Write Java 5 style code, usel log4j2 2.4, compile it with Java 7, run it on
Java 7. You can ignore all the stuff you hate about Java 6 and later.
*■ DOUGLAS E. WEGSCHEID* // Lead Analyst, Directories
(269) 923-5278 // Douglas_E_Wegscheid@whirlpool.com
"A wrong note played hesitatingly is a wrong note. A wrong note played with
conviction is interpretation."
--
*NOTICE: Whirlpool Corporation e-mail is for the designated recipient only
and may contain proprietary or otherwise confidential information. If you
have received this e-mail in error, please notify the sender immediately
and delete the original. Any other use or disclosure of the e-mail by you
is unauthorized.*
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Gary Gregory <ga...@gmail.com>.
I appreciate the passion. I wish it can be put to constructive use for
log4j 2 :-)
You might find it of interest that there is a recent mail thread to discuss
having Log4j 2 process properties-based configurations, as we did in 1.2.
Maybe the 1.2 compatibility module is an area that would be of interest to
you.
WRT Java versions, Java 6 has been EOL for a while. Java 7 has some good
incremental changes. Java 8 has lambdas, finally.
Gary
On Fri, Aug 14, 2015 at 12:26 PM, Xen <xe...@dds.nl> wrote:
> Op 14-8-2015 om 19:10 schreef Douglas Wegscheid:
>
>> 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
>>>
>>> easy there. that's pretty harsh treatment of other list participants, and
>> presumptuous to state you know what someone else is thinking/feeling.
>>
>
> I would say that that is the biggest lie ;-). Knowing how another is
> feeling is a perfect skill and essence and even requirement of many
> branches of sports. It forms the basis of seduction (of women) but also of
> knowing what to say and when to say it. It forms the basis of persuasion,
> and really of any sort of dealing with people who might have goals of
> whatever sort and are manouvring against you or with you. Knowing how
> another is feeling is the requirement of knowing how to help the person,
> and listening, being quiet and silent and observing, perceiving, is the
> essence of knowing how another is feeling.
>
> It is rather the thought that you /can't /know how another is feeling that
> is a false belief that is perpetrated and perpetuated amongst certain
> classes of professions, mostly, particularly those that deal with mental
> health care, to say not the least.
>
> Any person that runs a professional business of some sophistication
> (helping clients with their needs) definitely requires knowing how another
> is feeling, because otherwise you can't know the person and cannot create
> or offer something that the person will really like. You have to be in tune
> with another, otherwise you might just as well quit.
>
> It requires to listen and to look, something at which obviously women are
> usually better, but anyone can do it really. It requires to wait and not
> jump to a conclusion immediately, but also to trust your instincts and
> intuitions and go with them.
>
>
>
>> keeping an employer happy is not an ulterior motive. People like to be
>> able
>> to pay their bills.
>>
>
> It is ulterior to the project if the project is an open source project
> with stated community goals. If then your actual motives are dictated by
> your current employer, -- not necessarily saying they are here, THAT would
> be presumptuous -- instead of by the community's needs (or the desire of
> the product itself to evolve in whatever direction) -- the creative impetus
> -- then you could say design choices and commitments are being made that
> fly in the face of what everyone else needs, but which may not be obvious
> to the casual bystander, who is left to wonder "why?".
>
> Often in life, when people do things that seem to be outrageously
> incomprehensible or from the surface look if it, downright stupid, or
> destructive, you may not be in the knowing as to what their true goals
> really are. This happens often in politics I believe. You do not know why a
> politician is making a certain move. And because he is not telling you the
> truth about it, it seems incomprehensible to you that he would still do
> that thing given the reasons he cites, because /they are not his real
> reasons/. Were you to know his real reasons, everything becomes logical
> again.
>
> In this case I also feel that there are personal reasons here for the
> version push. That I don't understand really from my position and lack of
> knowledge about this all. So what I am saying is that there is a "why?"
> that I do not understand really. I can feel that it is there, and I can
> feel that there are probably some (?)important people who /really want it
> to happen/ but I don't know who they are and where they are hiding ;-) so
> to speak, to say it a bit belligerently. (Seriously, I know English words
> that I never remember having ever seen).
>
> When Kubuntu had released version 15.04 Jonathan Riddell, the guy who got
> so in the dispute with the Ubuntu Community Council (if I may be allowed to
> say anything about it as a bystander) ...--- immediately without pause went
> to planning for version 15.10. Not a moment to waste, straight ahead, no
> reflection, no looking back. I told him to pause, he said it was not
> constructive to say that.
>
> What he didn't say and what I didn't know, but what another member told me
> ; -) was that he is a full time employee on Kubuntu so given the nature of
> his work he would have to perhaps /take days off/ in order to take a break.
> He had to stop working his dayjob in order to sit back and relax and look
> back! That was the missing piece of information that explained his
> behaviour for about 40-60%.
>
> ;-).
>
>
> agreed. but let's be objective about what life is like in the "obsolete
>> server" space: you aren't typically deploying radically new code there
>> that
>> introduces new logging dependencies, either! log4j2 requires java 6, I
>> have
>> a few boxes that don't support that, but very few.
>>
>
> Okay, right. Still I feel the version push is too fast. I don't know what
> the reasons are for it. Supposing I wanted to run on older systems, I might
> then need to drop Log4j 2 and go with v1 just for a few of those systems.
> It's not that I have these outrageous demands on what my logging needs to
> do, far from it, probably. It's just that I happen to be using the newest
> version, not for its features, but for its advancement in the API, for
> example. I would then be given the choice to either stick completely to
> e.g. 2.3, which is rotten, being stuck in a mid-way version is just silly.
> My own improvements would then be insensible, what reason would there be to
> do anything for it?.
>
> Of course its'the same with Kubuntu and Plasma 4 /5 . Developing for KDE 4
> gets kinda ....deadening when you are the only one doing it (for instance).
> So there'd be another choice:
>
> fork the project and strip away all the higher language versions.
> Featuronality. I don't even know what the new version is going to use that
> requires java 7?.
>
> I only really saw two things of interest in my quick/non-quick perousal.
> One was mult-threaded class loaders, and the other is the diamond notation
> for generics. I don't know what else?.
>
> Why is it going to need Java 7?
>
> It is written that Java 7 has already reached EOL back in April. But still
> on a general Linux system it is the only thing you can install, at least on
> a conservative system like Debian. The Ubuntus probably have Java 8, for
> example.
>
> I see a lot of stuff in Java 7 and 8 that I don't understand (yet), but
>> that doesn't make me say "java 8 is a step backward"; usually I have (and
>> exercise) the option to ignore changes that I don't yet see the value of.
>> I
>> could keep writing what I've always written, and appreciate the fact that
>> I
>> am getting security updates.
>>
>
> Of course yeah, agreed, same. I do believe the Java 8 JDK has become a
> much (?) larger download than Java 7. On bad links I am tempted to search
> for Java 7 just so my download size is smaller.
>
> Most of the stuff that's been added over time has increased my productivity
>> immensely once I've invested the time to master it (this is from the
>> standpoint of someone making a living writing Java since v1.1). For most
>> of
>> the stuff I do, my customer is happier if I stamp the stuff out quickly,
>> rather than agonize over every decision from a performance standpoint (for
>> a lot of stuff, machines are cheaper than programming time). I realize
>> that
>> is not the case, especially on very large systems; adding more hardware
>> there gets expen$ive.
>>
>
> That's cool. I would love to learn more about it as well. Currently I 'm
> doing the max of what I can digest though and it is not fun. Configuring a
> Linux VPS and and all that.
>
> go ahead and just write Java 5 code, compile and run it with 7 or 8, and be
>> happy!
>>
>>
> Of course I can do that but not if my logging library requires greater.
> Right? Or should I (be able to) write against slf4j and then run on older
> systems by binding to an older version of Log4j?.
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
Op 14-8-2015 om 19:10 schreef Douglas Wegscheid:
>> 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
>>
> easy there. that's pretty harsh treatment of other list participants, and
> presumptuous to state you know what someone else is thinking/feeling.
I would say that that is the biggest lie ;-). Knowing how another is
feeling is a perfect skill and essence and even requirement of many
branches of sports. It forms the basis of seduction (of women) but also
of knowing what to say and when to say it. It forms the basis of
persuasion, and really of any sort of dealing with people who might have
goals of whatever sort and are manouvring against you or with you.
Knowing how another is feeling is the requirement of knowing how to help
the person, and listening, being quiet and silent and observing,
perceiving, is the essence of knowing how another is feeling.
It is rather the thought that you /can't /know how another is feeling
that is a false belief that is perpetrated and perpetuated amongst
certain classes of professions, mostly, particularly those that deal
with mental health care, to say not the least.
Any person that runs a professional business of some sophistication
(helping clients with their needs) definitely requires knowing how
another is feeling, because otherwise you can't know the person and
cannot create or offer something that the person will really like. You
have to be in tune with another, otherwise you might just as well quit.
It requires to listen and to look, something at which obviously women
are usually better, but anyone can do it really. It requires to wait and
not jump to a conclusion immediately, but also to trust your instincts
and intuitions and go with them.
>
> keeping an employer happy is not an ulterior motive. People like to be able
> to pay their bills.
It is ulterior to the project if the project is an open source project
with stated community goals. If then your actual motives are dictated by
your current employer, -- not necessarily saying they are here, THAT
would be presumptuous -- instead of by the community's needs (or the
desire of the product itself to evolve in whatever direction) -- the
creative impetus -- then you could say design choices and commitments
are being made that fly in the face of what everyone else needs, but
which may not be obvious to the casual bystander, who is left to wonder
"why?".
Often in life, when people do things that seem to be outrageously
incomprehensible or from the surface look if it, downright stupid, or
destructive, you may not be in the knowing as to what their true goals
really are. This happens often in politics I believe. You do not know
why a politician is making a certain move. And because he is not telling
you the truth about it, it seems incomprehensible to you that he would
still do that thing given the reasons he cites, because /they are not
his real reasons/. Were you to know his real reasons, everything becomes
logical again.
In this case I also feel that there are personal reasons here for the
version push. That I don't understand really from my position and lack
of knowledge about this all. So what I am saying is that there is a
"why?" that I do not understand really. I can feel that it is there, and
I can feel that there are probably some (?)important people who /really
want it to happen/ but I don't know who they are and where they are
hiding ;-) so to speak, to say it a bit belligerently. (Seriously, I
know English words that I never remember having ever seen).
When Kubuntu had released version 15.04 Jonathan Riddell, the guy who
got so in the dispute with the Ubuntu Community Council (if I may be
allowed to say anything about it as a bystander) ...--- immediately
without pause went to planning for version 15.10. Not a moment to waste,
straight ahead, no reflection, no looking back. I told him to pause, he
said it was not constructive to say that.
What he didn't say and what I didn't know, but what another member told
me ; -) was that he is a full time employee on Kubuntu so given the
nature of his work he would have to perhaps /take days off/ in order to
take a break. He had to stop working his dayjob in order to sit back and
relax and look back! That was the missing piece of information that
explained his behaviour for about 40-60%.
;-).
> agreed. but let's be objective about what life is like in the "obsolete
> server" space: you aren't typically deploying radically new code there that
> introduces new logging dependencies, either! log4j2 requires java 6, I have
> a few boxes that don't support that, but very few.
Okay, right. Still I feel the version push is too fast. I don't know
what the reasons are for it. Supposing I wanted to run on older systems,
I might then need to drop Log4j 2 and go with v1 just for a few of those
systems. It's not that I have these outrageous demands on what my
logging needs to do, far from it, probably. It's just that I happen to
be using the newest version, not for its features, but for its
advancement in the API, for example. I would then be given the choice to
either stick completely to e.g. 2.3, which is rotten, being stuck in a
mid-way version is just silly. My own improvements would then be
insensible, what reason would there be to do anything for it?.
Of course its'the same with Kubuntu and Plasma 4 /5 . Developing for KDE
4 gets kinda ....deadening when you are the only one doing it (for
instance). So there'd be another choice:
fork the project and strip away all the higher language versions.
Featuronality. I don't even know what the new version is going to use
that requires java 7?.
I only really saw two things of interest in my quick/non-quick perousal.
One was mult-threaded class loaders, and the other is the diamond
notation for generics. I don't know what else?.
Why is it going to need Java 7?
It is written that Java 7 has already reached EOL back in April. But
still on a general Linux system it is the only thing you can install, at
least on a conservative system like Debian. The Ubuntus probably have
Java 8, for example.
> I see a lot of stuff in Java 7 and 8 that I don't understand (yet), but
> that doesn't make me say "java 8 is a step backward"; usually I have (and
> exercise) the option to ignore changes that I don't yet see the value of. I
> could keep writing what I've always written, and appreciate the fact that I
> am getting security updates.
Of course yeah, agreed, same. I do believe the Java 8 JDK has become a
much (?) larger download than Java 7. On bad links I am tempted to
search for Java 7 just so my download size is smaller.
> Most of the stuff that's been added over time has increased my productivity
> immensely once I've invested the time to master it (this is from the
> standpoint of someone making a living writing Java since v1.1). For most of
> the stuff I do, my customer is happier if I stamp the stuff out quickly,
> rather than agonize over every decision from a performance standpoint (for
> a lot of stuff, machines are cheaper than programming time). I realize that
> is not the case, especially on very large systems; adding more hardware
> there gets expen$ive.
That's cool. I would love to learn more about it as well. Currently I 'm
doing the max of what I can digest though and it is not fun. Configuring
a Linux VPS and and all that.
> go ahead and just write Java 5 code, compile and run it with 7 or 8, and be
> happy!
>
Of course I can do that but not if my logging library requires greater.
Right? Or should I (be able to) write against slf4j and then run on
older systems by binding to an older version of Log4j?.
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Douglas Wegscheid <do...@whirlpool.com>.
>
>
> 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
>
easy there. that's pretty harsh treatment of other list participants, and
presumptuous to state you know what someone else is thinking/feeling.
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.
keeping an employer happy is not an ulterior motive. People like to be able
to pay their bills.
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.
>
agreed. but let's be objective about what life is like in the "obsolete
server" space: you aren't typically deploying radically new code there that
introduces new logging dependencies, either! log4j2 requires java 6, I have
a few boxes that don't support that, but very few.
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.
>
I see a lot of stuff in Java 7 and 8 that I don't understand (yet), but
that doesn't make me say "java 8 is a step backward"; usually I have (and
exercise) the option to ignore changes that I don't yet see the value of. I
could keep writing what I've always written, and appreciate the fact that I
am getting security updates.
>
> 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.
>
Most of the stuff that's been added over time has increased my productivity
immensely once I've invested the time to master it (this is from the
standpoint of someone making a living writing Java since v1.1). For most of
the stuff I do, my customer is happier if I stamp the stuff out quickly,
rather than agonize over every decision from a performance standpoint (for
a lot of stuff, machines are cheaper than programming time). I realize that
is not the case, especially on very large systems; adding more hardware
there gets expen$ive.
> 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.
>
go ahead and just write Java 5 code, compile and run it with 7 or 8, and be
happy!
--
*NOTICE: Whirlpool Corporation e-mail is for the designated recipient only
and may contain proprietary or otherwise confidential information. If you
have received this e-mail in error, please notify the sender immediately
and delete the original. Any other use or disclosure of the e-mail by you
is unauthorized.*
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Xen <xe...@dds.nl>.
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<ra...@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<lu...@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);
>>>
>>> }
>>>
>>>
>>> }
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Jinhong Lu <lu...@gmail.com>.
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 <ra...@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 <lu...@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);
> >
> > }
> >
> >
> > }
>
>
Re: java.lang.NoSuchFieldError: errorHandler
Posted by Ralph Goers <ra...@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 <lu...@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);
>
> }
>
>
> }