31Jul 2012 by codercowboy

Stopping Axis2 in unix

Java, Unix
If you're having trouble killing axis2 via a init.d script or otherwise on unix, just do this: AXIS2_CHILD_PID=`ps aux | egrep "axis2server.sh|SimpleAxis2Server" | grep -v "egrep" | awk '{print $2;}'` echo "Killing stubborn AXIS2 child process that won't die with parent.. pid is ${AXIS2_CHILD_PID}" kill ${AXIS2_CHILD_PID} >/dev/null 2>&1 && echo OK || echo "failed, what now?" That works for axis 1.5.1, at least. The odd thing about axis2 is, there isn't any documentation mentioning axis2 daemonizing. The axis2server.sh script certainly does not appear to daemonize, and the axis2.xml config file doesnt seem to make any mention of a deamonizing configuration item. Yet, when you run axis2server.sh in a terminal, it's interactive, ctrl-c, and the the script and the child axis2 will be dead. Run axis2server.sh as a background process, like…
Read More
25Jul 2012 by codercowboy

Maven build automatically removing a jar?

Java
If you have a maven build mysteriously deleting the jar it's building, double check your POM hierarchy to make sure you dont have some non-sense such as this in there: org.apache.maven.plugins maven-clean-plugin 2.1 auto-clean validate clean In my case this was in a copy/pasted reactor pom, lingering at the bottom of my plugins list. When I added a maven-source-plugin directive to generate sources, the original jar would be deleted by that unintended maven-clean-plugin directive earlier in the pom. Thanks to Jason Duke for figuring this out.
Read More
06Jul 2012 by codercowboy

Getting LogBack to log to console with TestNG and IntelliJ

Java
If you're having problems with a TestNG test using Logback not logging anything to the console inside IntelliJ, assuming you're in a maven project, do the following: create the file src/test/resources/logback-test.xml Put this in it: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %m%n And whatever you do, pay no mind at all to the highlighted rule in the configuration manual: "Let us begin by discussing the initialization steps that logback follows to try to configure itself: Logback tries to find a file called logback.groovy in the classpath. If no such file is found, logback tries to find a file called logback-test.xml in the classpath. If no such file is found, it checks for the file logback.xml in the classpath.. If neither file is found, logback configures itself automatically using the BasicConfigurator which…
Read More