AppDynamics Agent Instrumentation for Java 6 Applications

AppDynamics Agent can monitor Java 6 applications. However, modern applications does not supporting TLS version older than TLS 1.2. So, the SaaS controller does not support using TLS 1.1, TLS 1.0, and SSH 3. On the other hand, being an 2006 technology, Java 6 does not support TLS 1.2 out-of-the-box.

Upgrading the JVM seems to be an obvious solution. However, it might not be possible as it would involve a lot of effort to re-test. Some library might not even compatible with newer JVM.

Fortunately, we can make use of Java's pluggable cryptography extension (JCE) and Java Secure Socket Extension (JSSE). Bouncy Castle is one of the library to provider of the security feature [ref: stackoverflow.com].

The following Dockerfile demonstrate the following:

1. Use yannart/jboss-5.1.0.ga-jdk6 as the base image
2. Copy the content of AppServerAgent to /opt/appdynamics
• Java agent is separately downloaded
• controller-info.xml shall be configured 
3. Download and install jurisdiction policy files for "unlimited strength" cryptography
4. Download and install Bouncy Castle 1.66
5. Copy the java.security file
6. Configure Java agent instrumentation via environment variable

The changes of the java.security is as follows:

1. Set the priority of Bouncy Castle as the first provider of JCE and JSSE
2. Set the default SocketFactory

For what it's worth, here is the full java.security file:

Screwing up HTTP Session for Servlet/JSP

Prerequisites:
1. Browsers under Mozilla project (e.g. Firefox, SeaMonkey)
2. Enable cookies
3. Tomcat (probably all Java web containers)

Procedure:
1. Write a page that use back-slashes as the directory seperator (e.g. http://www.abc.com\app\page.jsp)
2. Include this page with absolute path in all pages

Why:
1. The browser encode back-slashes as %5C. So, http://www.abc.com\app\page.jsp will be encoded as http://www.abc.com%5Capp%5Cpage.jsp
2. The browser tries to look up the cookies for the domain. However, the browser think that the domain name is www.abc.com%5Capp%5Cpage.jsp instead of www.abc.com
3. The browser cannot find the cookies for the domain. So, it does not send the cookies to the browser.
4. When cookies is enabled, Java Servlet and JSP uses it to store the session ID
5. Since the cookies was not found in the request header, the web container creates a new session and send to session ID with Set-Cookie header.
6. The browser uses the new session ID for the next request.
7. As a result, the web container creates new session for each browser request and the sessions are screwed up.

What about other browsers? I think IE is smart enough to replace all back-slashes to slashes before it does further processing. I don't know about others though...

You may want to ask why you would use back-slash. My answer is "No, you may not but your staff or your outsource partner may." In a workflow engine we are studying, we found the following JavaScript:
document.write("<iframe src='<%=request.getContextPath()%>\\app\\page.jsp'>")

My colleague asked for help about why the session does not work in Firefox. Since the code was written by different parties, we know nothing about the workflow engine. I alone used 6 man-hours to fix the BUG. I think I know fairly well on HTTP and Java Servlet. I tried many possible solutions like finding the HttpSession.invalidate(), session.removeAttribute(), appending the jsessionid, etc. Finally, I used a packet sniffer to dig out the pattern that changes the jsessionid cookie and recognize the weired %5C URL in a GET command.

Adobe Flex Push

There are ready to go assemblers in FDS samples application provided for you to develop your own Flex application with FDS. It is quite impressive that when a client update a piece of data, the FDS can synchronize the data to other Flex client without extra coding. However, what if you only want to push some changes to the client?

Calling update in assembler may be a good option. Using the DataServiceTransaction could be better:

DataServiceTransaction tx = DataServiceTransaction.begin(false);
Rate rate = ... // get the rate from some streaming data source

// do any necessary calculation
tx.updateItem("fds.rate", rate, null, null);
tx.commit();

This snippet should get the job done on the server side. On the client side, you need to handle the FDS message:

 <mx:script>
public function handleMessage(event):void {
  if (rate.id == event.message.body[2].id) {
    rate = event.message.body[2];
  }
}
</mx:script>
<mx:label text="{rate.value}"/>
<mx:dataservice id="dsRate" destination="fds.rate" message="handleMessage(event)" />

Base64, MHTML, and IE

In HTML 4.0, binary objects (e.g. image) can be inlined with Base64 encoding. However, Internet Explorer totally ignores the standard. Even in IE7, base64 image is still not supported.

Two solutions proposed by Dean Edwards and Luiz Angelo De Luca are trying to solve the problem. Both of them are implemented in PHP. Base64Html is a Java implementation of Luiz Angelo De Luca's solution: convert the HTML into MHTML (HTML Mail format).

Luiz Angelo De Luca's solution can be genernalize to the following steps:

1. Buffer the output and add a function callback
2. If the browser is IE, set the HTTP header to MHTML
3. Convert the HTML to MHTML
   

Luiz Angelo De Luca has implemented it in a single PHP. In Java, we make use of HttpServletResponseWrapper (for #1), Serlvet Filter (for #2), and Apache Jakarta Commons Email API (for MHTML construction). Source code and example web app are available at: http://www.shaneng.net/Main/Base64Html

Building a Source Code Generator II

Last article described the basic infrastructure of writing a source code generator. The design is now implemented in Codejen Framework and available in SourceForge.net.

Building a Source Code Generator I

Recall the following components to build a source code generator:

1. A model that describe your application - you don't need to define it yourself, you can use XMI or XML schema as the reference model. The only problem is how you parse them to the object model.
   
2. A template engine - Velocity or Freemaker are good template engines in Java.
   
3. Templates that corresponding to the model - Generate code Java, PHP, C#, etc.
   
4. A configuration of templates - There would be configurations for desktop app, web app, RIA, or web services, etc.
   
5. A parser that parse the configuration - If the configuration is an XML file, Apache's commons-digester library can help.
6. A driver to glue up everthing.
7. Optionally, a validator for the template is good - JavaCC or ANTRL for syntax validation. For the extreme, use a compiler to verify the correctness of the generated code.
   

The diagram on the left included the classes designed for #4 to #7.

• CodeGenerator - the parser of the configuration file and the driver gluing up everything.
  
• TemplateConfiguration - an list of template that can stores the properties specified in the XML file.
• Template - a class representing the state of a template.
• TemplateProcessor - processor that may perform validation or beautification of the generated code.

With this general source code generator, it can be adapted to use with other CASE tools (e.g. Visual-Paradigm).

Example configuration XML:

<profile>
<property key="asdf" value="1" />
<property key="templateDir" value="x ${asdf}" />
<template class="org.sf.codejen.test.TestTemplate" a="${templateDir}">
 <postProcessorFactory class="org.sf.codejen.test.TestProcessorFactory" b="jkl;" />
</template>
</profile>

The required attributes are

• profile/property - key and value
• profile/template - class
• profile/template/postProcessorFactory - class

All other attributes are optional depends on the class design.
Also, if you are familiar with ANT, you can use ${propKey} style to access the property value.

How to build a source code generator

1. A model that describe your application - you don't need to define it yourself, you can use XMI or XML schema as the reference model. The only problem is how you parse them to the object model.
   
2. A template engine - Velocity or Freemaker are good template engines in Java.
   
3. Templates that corresponding to the model - Generate code Java, PHP, C#, etc.
   
4. A configuration of templates - There would be configurations for desktop app, web app, RIA, or web services, etc.
   
5. A parser that parse the configuration - If the configuration is an XML file, Apache's commons-digester library can help.
   
6. A driver to glue up everthing.
7. Optionally, a validator for the template is good - JavaCC or ANTRL for syntax validation. For the extreme, use a compiler to verify the correctness of the generated code.