Adding system environment properties to log4j filename

Hi, Happy Friday!

The holiday is just around corner! ¬†I feel like posting something before the holiday is really here. And it happens I do have something worth posting. ūüôā

This week we found that in a cluster environment, log4j may encounter an issue with writing log entries to FileAppender. The problem is essentially that when multiple nodes from the same cluster are trying to write to the same log file, the competing threads can cause some of the events to be dropped without being written to the file. The losing rate depends on how heavy the logging events.

We found a way to mitigate this issue by adding a hostname to the logging filename. This way, each node will be writing to its own logging file, avoiding IO contention.

How to achieve this involves two steps. First, adding a system variable in your application startup process, such as:

System.setProperty(“HostName“, InetAddress.getLocalHost().getHostName());¬†

Then reference this HostName system variable in your Log4j.xml configuration file, something like the following:

<appender name=”FileAppender” class=”org.apache.log4j.RollingFileAppender”>
¬†<param name=”file”¬†value=”/tmp/logs/app_${HostName}.log” />
¬†<param name=”MaxFileSize” value=”1024KB” />
¬†<param name=”MaxBackupIndex” value=”30″ />
¬†<param name=”Threshold” value=”DEBUG” />
¬†<layout class=”org.apache.log4j.PatternLayout”>
¬† <param name=”ConversionPattern” value=”%5p [%d] [%t] (%F:%M:%L) – %m%n” />

The application will write logging entries to the logging file with an actual host name in its filename. Another beautiful side effect of this is that one can quickly tell where the logging event is originated from, which often provides valuable information about the host in the cluster.

Of course, if you want to add more environment variables besides the HostName, it can be done in similar fashion. Also, the variables don’t need to be in the filename, it can be in the content of the logging message.

Cheers and have a happy holiday season!

-T. Y.




JAX-WS error: java.util.HashMap cannot be cast to

Happy Black Friday!

We are upgrading our JEE application from Weblogic 11g to 12c. On one of our staging servers, we got this error:

Java agent causing error: Caused by: java.lang.ClassCastException: java.util.HashMap cannot be cast to

This error, however, doesn’t happen in our development environment. We have scratched our heads for many days for this issue. From googling, this link comes up at the top:¬†¬†This apparently indicates there are some jax-ws libraries that are polluting our environment in that staging server. Following this thought, we have tuned and reconfigured many ways to let the application use the jax-ws jar we want it to, in vain.

Eventually, a server admin found out that the Introscope Wily that is installed on the staging server is the culprit that contaminated the Java Classpath for the jax-ws. When we go back to the link above, that’s of course from Wily’s vendor CA! ! The fix is easy just follow the link above to change the introscope properties to what’s described in that link.

It’s ironic that the link is from CA at the first place, and it didn’t ring the bell for me that the issue was caused by Wily in the first place.

Cheers and happy holidays!


Element Object doesn’t support property or method ‘remove’ In IE

Hi, There:

Happy Thanksgiving!  Drop a few a lines here to record an IE issue, from a version of angularJS datetime picker. The error only happens in IE:

Object doesn’t support property or method ‘remove’.¬†The Code related were something like this:


It is due to that IE doesn’t support remove() function for DOM element. ¬†But if you change to the following, things work much better!

el.parentNode && el.parentNode.removeChild(el);

Hopefully this will help anyone is scratching their heads for this IE issue that doesn’t happen in Chrome or Firefox.





Custom DataSource for DataHandler: how to get byte[] into DataHandler

Hi there:

Happy Friday!

We use javax.activation.DataHandler Routinely in SOAP Webservice invocation. However, when DataHandler constructs with DataSource, it only comes in with two types, FileDataSource, URLDataSource. A lot of times in production applications, neither is useful. For example, in memory data in byte[] or other forms cannot be used readily with these two types of DataSource. This can be easily solved by implementing your own DataSource. Here is an example that you can use


public class MyDataSource implements DataSource {

private InputStream is;
private String name, contentType;

public String getContentType() {
return contentType;
public void setContentType(String ct){
this.contentType = ct;

public InputStream getInputStream() throws IOException {
return is;

public void setInputStream(InputStream is){ = is;

public String getName() {
return name;
public void setName(String name){ = name;

public OutputStream getOutputStream() throws IOException {
// TODO Auto-generated method stub
return null;


To use the DataSource, inject byte[] into it before instantiate DataHandler with the DataSource.


MyDataSource ds = new MyDataSource ();

byte[] data = ¬†… ;

InputStream is =  new ByteArrayInputStream(data);



ds.setName(“some content¬†name”);

DataHandler dataHandler = new DataHandler(ds);


DataHandler will then fetch the data from the underlying InputStream from the Custom DataSource.




ApacheXMLDSig Signature Provider Not found

Hello, Happy Friday!  It has been a heck of week or two. Finally the dust has come down and I have enjoyed a couple of relatively quiet days of coding.

During this period, this issue bothered me for a couple of days and just found a solution to it.

I am using WSSecSignature to sign SOAP request and everything works fine in Maven tests until I deployed this to Tomcat 8 under JDK8. The error I got is always something like ApacheXMLDSig not found, no matter how I tweaked it.

javax.xml.crypto.NoSuchMechanismException: class configured for XMLSignatureFactory (provider: ApacheXMLDSig) cannot be found

I feel Tomcat is doing something funny under the hood so the default ApacheXML Digital Signer is not visible to my WSSecSignature, maybe it is due to some Classpath loader structure?

I had to eventually explicitly specify the Digital Signer as below:

System.setProperty(“jsr105Provider”, “”);

This ensures I know what Signer is to be used from the Santuario package and it works without any failures in Tomcat.


Date JsonFormat for Jackson

The default format from java.util.Date after serialized into JSON is a long number. That is not at all human readable for a Date like 07/21/2016 14:43:25.  There are many solutions to this, including pre and post formatting on the client side (AngularJS, JQuery)  as well as ObjectMapper on the Server side. But the easiest solution to me is to use com.fasterxml.jackson.annotation.JsonFormat annotation so Jackson will marshal and un-marshal the Date correctly. On the client side, only a Date picker that will restrict the user Date format will do the trick. No other coding is needed!

import com.fasterxml.jackson.annotation.JsonFormat;
import java.util.Date;

 @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "MM/dd/yyyy HH:mm:ss", timezone = "America/New_York")
  private Date update_date;


ngOptions track by to select the matched value from options

Happy Friday!

After AngularJS 1.2, you don’t need to use ng-repeat to display options for <select> element. Instead, it is recommended to use ng-options, such as this below, ¬†where items is an Array of object item.

<select ng-model=”selectedItem”¬†ng-options=”item¬†as item.label¬†for item in items”></select>

However, the above doesn’t display the selectedItem as selected if there is a match with the value of the object in the Array items.


No worries! AngularJS now has a nice expression to make that so easy to achieve, by using track by:

<select ng-model=”selectedItem”¬†ng-options=”item¬†as item.label¬†for item in items track by item.value“></select>

Now if there is a match of values between the selectedItem and one Option in the Array, that Option is selected!

AngularJS really rocks! ¬†well, most of the time ūüôā