Another interesting tidbit:
@Benchmark
public void debug1Arg_date(Blackhole blackhole) {
LOGGER.debug("Started at %s", new Date(time));
time++;
blackhole.consume(time);
}
@Benchmark
public void guardedDebug1Arg_date(Blackhole blackhole) {
if (LOGGER.isDebugEnabled()) {
LOGGER.debug("Started at %s", new Date(time));
}
time++;
blackhole.consume(time);
}
Gives the following benchmark results:
Benchmark Mode Cnt Score Error Units
Log4jBenchmark.debug1Arg_date thrpt 20 179653191.248 ± 2731044.349 ops/s
Log4jBenchmark.guardedDebug1Arg_date thrpt 20 207001790.376 ± 2074020.617 ops/s
We can also compare guarding with SLF4J over logback
One of my colleagues had a question:
Now for some context, when the Jenkins project started off, Kohsuke was working for Sun and felt it would be wrong, as a Sun employee, to use a logging framework other than that provided by the JVM as using a different logging framework could be seen as being implication that the built in Java Utils Logging framework was a steaming pile of excrement.
You asked for it.
Logback:
@Benchmark
public void debug1Arg_date(Blackhole blackhole) {
LOGGER.debug("Started at {}", new Date(time));
time++;
blackhole.consume(time);
}
@Benchmark
public void debug2Arg_date(Blackhole blackhole) {
LOGGER.debug("Started at {}", new Date(time), null);
time++;
blackhole.consume(time);
}
@Benchmark
public void debugNArg_date(Blackhole blackhole) {
LOGGER.debug("Started at {}", new Date(time), null, null);
time++;
blackhole.consume(time);
}
static {
ch.qos.logback.classic.Logger root = (ch.qos.logback.classic.Logger)LoggerFactory.getLogger(org.slf4j.Logger.ROOT_LOGGER_NAME);
root.setLevel(ch.qos.logback.classic.Level.INFO);
}
And the benchmarks
Benchmark Mode Cnt Score Error Units
LogbackBenchmark.debug1Arg_date thrpt 20 221056534.656 ± 8549233.826 ops/s
LogbackBenchmark.debug2Arg_date thrpt 20 220576341.742 ± 3778270.898 ops/s
LogbackBenchmark.debugNArg_date thrpt 20 134887126.088 ± 2973182.812 ops/s
JUL over SLF4J (same benchmark code but different dependency)
One of the headline grabbing things that people seem to be raving about over Log4J 2.0 is async loggers.
Now do not get me wrong, they are great… as long as you know what you are doing.
If you are using async loggers you had better make sure you are only passing immutable objects to your loggers, because otherwise you may end up logging the state of your objects at the time of the log record being written and not the time you called log.
I’ve been meaning to blog about getting transaction management working with OpenEjb and Jetty using jetty:run… it’s still an on-going story… but the following might get you going…First off, in your pom.xml you need to add the configuration for maven-jetty-plugin… we need to dance around the various activemq/activeio versions and ensure that we get the correct version of ant… <project xmlns=“http://maven.apache.org/POM/4.0.0" xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=“http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> 4.0.0 org.apache.openejb.examples jetty-openejb war 1.0-SNAPSHOT jetty-openejb Maven Webapp http://maven.apache.org junit junit 3.8.1 test ${project.artifactId} org.mortbay.jetty maven-jetty-plugin 6.1.22 org.apache.activemq activemq-core 4.1.1 commons-logging commons-logging commons-logging commons-logging-api org.apache.activemq activeio-core org.apache.activemq activemq-ra 4.1.1 commons-logging commons-logging commons-logging commons-logging-api org.apache.activemq activeio-core org.apache.activemq activeio-core 3.1.2 commons-logging commons-logging commons-logging commons-logging-api org.apache.openejb openejb-core 3.1.2 org.apache.activemq activemq-core org.apache.activemq activemq-ra org.apache.activemq activeio-core junit junit org.mortbay.jetty jsp-2.1-jetty 6.1.22 ant ant ${basedir}/src/main/jetty/jetty.xml Next we need to configure a src/main/jetty/jetty.xml to bind the UserTransaction instance into jetty… java.naming.factory.initial org.apache.openejb.client.LocalInitialContextFactory openejb:TransactionManager And presto-chango, now jetty has a transaction manager provided by openejb. (Note: if we don’t mind storing that in a jetty-env in /WEB-INF, you can put the same config in WEB-INF/jetty-env.xml) OK, so here are the issues:Reloading does not work (because org.apache.openejb.core.ivm.naming.IvmContext does not support the destroySubcontext(Context) methodWe are using jetty’s JNDI provider in the web-app and openejb’s JNDI provider for the EJBs… this is because When jetty binds names to JNDI (using org.mortbay.jetty.plus.naming.Resource or org.mortbay.jetty.plus.naming.Transaction) it binds the object to JNDIName and it also binds a NamingEnrtry for the object to __/JNDIName Unfortunately, openejb’s JNDI implementation seems to be somewhat strange in this regard… if we add the SystemProperties to jetty to have it use openejb’s JNDI implementation, e.g. add the following to /project/build/plugins/plugin[maven-jetty-plugin]/configuration/systemProperties java.naming.factory.initial org.apache.openejb.client.LocalInitialContextFactory Then when we bind /UserTransaction it gets bound to openejb:/UserTransaction but when we lookup /UserTransaction openejb looks up openejb:local//UserTransaction And that is just for starters… there seems to be a whole host of other JNDI strangeness between jetty’s side and openejb’s sideThe side effect of all this is that if you want resource refs to work correctly, you need to fish them out of openejb’s JNDI context and push them into jetty’s JNDI context In any case this is at least a start!
One of my co-workers has asked me to post this up. It’s rough and ready, so make of it what you want.First off, Acer recently pushed an update for better performance with the Huawei USB modems… I’m assuming that you have this update… check if the file /etc/udev/rules.d/10-Huawei-Datacard.rules exists.If that file exists then when you plug in a E169g it will be correctly autodetected without requiring poking about with usbmodeswitch… it will bind the three serial ports of the E169G to /dev/HuaweiMobile-0, /dev/HuaweiMobile-1 and /dev/HuaweiMobile-2.OK, so assuming you see these device nodes after plugging in the E169G, the next problem is getting wvdial to connect. Here’s the wvdial.conf file I use[Dialer Defaults]Init2 = ATZInit3 = ATHInit4 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0Stupid Mode = 1Modem Type = USB ModemISDN = 0Phone = *99#Modem = /dev/HuaweiMobile-0Username = usernamePassword = passwordDial Command = ATDTBaud = 460800Init5 = AT+CGDCONT=1,“IP”,“3ireland.ie"By the way, the username is actually “username”, and the password is actually “password”.That should be enough to get any self-respecting linux freak 90% of the way there. There was some stuff I had to tweak to get DHCP to populate resolve.conf from the pppd connection… and I added the following udev rule as 70-huawei-e169g-dial.rulesSUBSYSTEM==“usb” SYSFS{idProduct}==“1001”,SYSFS{idVendor}==“12d1”,RUN+="/usr/sbin/e169g_dial"And, /usr/sbin/e169g_dial is just#!/bin/shsleep 5/usr/bin/wvdial 2>&1 > /var/log/wvdial &You might be able to tune down from 5 seconds if you can be bothered… but you need at least some delay
Note to self, for later reading
http://technology.amis.nl/blog/?p=2610
Not sure why netbeans is essential on this!
I am sick of the fun that is getting JAX-WS 2.1 to work on JVM 1.6.
Oh, copy these four jars into the endorsed directory and then you can use JAX-WS 2.1… oh but sometimes it won’t work for some unknown reason and then it will work again.
How you are supposed to explain this to end users, I don’t know.
So next you need a platform specific installer to put those jars into the correct location, or a platform specific start script to tell the JVM about my alternate endorsed lib folder… or do I write a self-extracting jar file that exctracts the libs and forks a second JVM… no that won’t work for people wanting to use my library..
Working on this to add to EasyGloss.
There are a number of rules that JPA entities must obey:
equals and hashCode must only be based on the persistent fields that are @Id annotated.I want to have a JPA Entity excerciser that will check these rules for you (and can be included in your unit tests)