MaintainJ Blog

September 27, 2011

Support for MS SQL Server

Filed under: Uncategorized — maintainj @ 10:27 am

MaintainJ currently does not support Microsoft SQL Server out-of-the-box.

This is because MaintainJ needs to instrument the JDBC driver classes to capture the runtime SQL statements and Microsoft disallows instrumenting their JDBC driver. Below are the two steps required to trace the applications using MS SQL Server.

1. To avoid the problems with instrumentation, I unjar’ed the Microsoft JDBC driver jar file, removed the signing logic under the META-INF folder and jar’ed up the files again. You can download the changed jar from here. Please replace the original sqljdbc4.jar file with the downloaded jar file while tracing the application with MaintainJ. You may notice that there are no changes at all to the class files in the new jar.

2. Next, you need to change the aop.xml file. Below is a sample aop.xml (for a J2SE app) to use while tracing MS SQL Server applications. The relevant parts are highlighted. The default generated aop.xml needs to be edited and this FAQ explains the location of aop.xml and how to edit it.

<aspectj>
<aspects>
<concrete-aspect name=”com.maintainj.inst.J2SEAspect” extends=”com.maintainj.aspect.J2SEExecutionDataAspect”>
<pointcut name=”anyExecution” expression=”execution(public  * *.*(..)) || execution(public  *.new(..))”/>
<pointcut name=”beforeMain” expression=”execution(public static void com.db.test.TestDBManager.main(String[]))”/>
<pointcut name=”excludedPointcut” expression=”execution(* com.microsoft.sqlserver.jdbc..*.*(..)) || execution(com.microsoft.sqlserver.jdbc..*.new(..))”/>
</concrete-aspect>
</aspects>
<weaver options=”-proceedOnError -nowarn -XaddSerialVersionUID -showWeaveInfo -verbose”>
<include within=”com.db..*”/>
<include within=”com.microsoft.sqlserver.jdbc..*”/>
<include within=”com.db.test.TestDBManager”/>
<exclude within=”com.maintainj..*”/>
</weaver>
</aspectj>

If you are using jTDS Driver: If you happen to be using jTDS driver to access the MS SQL Server, simply replace com.microsoft.sqlserver.jdbc with net.sourceforge.jtds.jdbc everywhere in the above aop.xml.

If this feels like lot of changes, contact us and we would be happy to help.

Choudary  Kothapalli.

September 22, 2011

The 3 Types of Maintenance

Filed under: Uncategorized — maintainj @ 11:55 am

This post deals with maintenance of enterprise Java applications. There are many types of maintenance, but here I am going to talk about the bug fixing and enhancements related maintenance, which consumes most of the maintenance budgets.

Enterprise Java application maintenance can be divided into three broad categories. Most of the maintenance will either be one or a combination of these three types.

Type 1 – Localized changes

A bug fix or enhancement requires a local change in a JSP, Java class, Javascript, HTML, resource bundle or XML file. The first task would be to identify the component to change. Usually the impact for this type of change is local and thereby minimal. So fixing and regression testing this would be quick.

Type 2 – New features

This can be like adding a new field to a database table or adding a new screen to the application.

To add a new database field, first we need to identify the current components in the flow – the Action/Controller class, DAO, VO, Servlet, JSP, etc. Then we analyze the impact, which is usually limited as we are only adding new components and are not changing the existing components (at least not in a major way).

A new screen being added will usually be similar to many of those already present in the application. Very rarely do we need to build a new screen that is completely different from the other screens in the application. The information shown on the screen will be different, but the screen structure, the flow to the screen will be similar to some other screens in the application. So we just need to identify a similar screen and replicate its design.

Because of this, the development effort for Type 2 maintenance is minimal even though it takes more effort than Type 1 maintenance.

The regression testing effort is also minimal unless we modify some existing code while adding a new feature.

Type 3 – Global changes

This can either be fixing defects or adding new features but the distinguishing feature is the global impact of the change on the application. Some examples of this type are:

a) Changing the base data model on which most of the application depends. This will require changes to the object model on which many parts of the application depends.
b) Because of a business change, multiple changes to many parts of the application may be required.
c) A change or fix is required in a shared JSP, which is included in most of the JSP’s in the application. If the shared JSP does not get the data it displays from a single source, it will be very difficult to assess the impact.

This kind of maintenance takes the most effort during development and regression testing.

Summary

Most of the time the maintenance activities fall under one or a combination of these categories.

Careful observation suggests that about 50% of the maintenance falls under the first two types, in which most of the effort goes into identifying the code to fix or enhance. MaintainJ can be used to drastically reduce the effort required to identify the source of a defect or to identify the components used in a use case, and thereby reducing the overall maintenance effort.

Choudary Kothapalli.

September 21, 2011

Integrating MaintainJ with Selenium, JUnit or such testing tools

Filed under: Uncategorized — maintainj @ 5:49 pm

Below are the options to integrate MaintainJ with Selenium, JUnit or with such test automation tools.

1. Web Apps – On the browser end

You can automate the process of manually clicking the ‘Start’ and ‘Stop Tracing’ buttons. You will have to use the tool specific API to switch between your application window and MaintainJ tracing window. Using the tool specific API, provide the use case name for every use case, before generating the trace files.

2. Web Apps – On the server side

You can also follow this approach instead, which will automatically generate trace files for every server hit. This approach needs a bit of customization to MaintainJAspect.jar. You could pass a test case specific identifier with every request, which can be used to generate the trace file name. Contact us and we will be happy to work with you to do the necessary customization.

3. For JUnit

If you are using JUnit, you are in luck. MaintainJ already integrates with JUnit and you can generate the trace file for each test case. This is a very neat feature as you will have documentation for each test case you run. If a test case fails, you can use the sequence diagram to find out where and why it failed and fix the problem.

4. For all other applications

If your test automation tool supports Java, then you can use the MaintainJ API to start and stop tracing and to generate the trace files.

Choudary Kothapalli.

So you hate clicking ‘Start’ and ‘Stop Tracing’ buttons

Filed under: Uncategorized — maintainj @ 4:24 pm

If you are generating trace files for lot of use cases, clicking the ‘Start Tracing’ and ‘Stop Tracing’ buttons can be tedious.

You don’t need to keep clicking

You do not really need to do it as documented in an earlier blog. Contact us if you need any further help and we will be glad to work with you to customize it for your application.

The problem with generating a trace file for every server hit

The main problem with this approach is that the name of the generated trace files does not indicate the use case for which it is generated. The trace file name is auto-generated and is like ‘traceFileXX_threadName.ser, where XX is the trace file count starting from 1.

When you click the ‘Stop Tracing’ button, you provide the use case name, which becomes the trace file name. When you are not clicking buttons, you are not giving the use case name.

How do we solve this problem?

The solution has to be application specific. If you are dealing with a web application, there is probably a unique identifier with every request to the server in the url or in the parameters passed. This unique identifier can be used to make the trace file name more meaningful.

For now, contact us if you need to do this. We will give you an updated MaintainJAspect.jar file with the logic to produce the trace files with meaningful names. In future releases we will provide a way for you to implement this logic yourself.

Choudary Kothapalli.

September 16, 2011

About the new MaintainJ V3.2 video demo on Alfresco

Filed under: Uncategorized — maintainj @ 6:08 pm

The MaintainJ V3.2 captures the the actual runtime SQL calls sent to the database irrespective of the JDBC framework used. It also shows the interactions between the JSPs. So I was looking for a suitable sample application with the following qualities to demonstrate these capabilities.

  1. A large application – I do not want to demonstrate MaintainJ on a ‘Hello World’ kind of application. I wanted a  large, enterprise scale, real-world application that uses the popular Java frameworks.
  2. An application that uses database so that I can showcase the runtime SQL statements.
  3. An open source application so that I would not be reverse engineering some proprietary code.

Alfresco satisfies all the criteria to perfection. It’s a large open source software with:

  • 8000+ Java classes
  • 600+ XML configuration files that include Spring, Hibernate and I don’t know what else
  • 260+ JSP’s
  • A J2EE application running on Tomcat and MySQL.

I had few problems in running the Alfresco Document Management product. I just had to create a database in my local MySQL server and Alfresco created the required tables.
When I tried MaintainJ on Alfresco, it was surprisingly smooth. I faced two familiar issues that were resolved quickly.

  1. The OutOfMemoryError:PermGen issue that was resolved by increasing the max PermGen to 256MB. This line is added to the Tomcat setenv.bat – set JAVA_OPTS=-XX:MaxPermSize=256m %JAVA_OPTS%
  2. There were 2 classes that were causing problems with instrumenting the code. I excluded both those classes from the instrumentation scope.

That’s it! I chose the Login use case because it has all the elements to demonstrate the capabilities of MaintainJ.

This demo proved that:

  1. MaintainJ indeed helps developers to quickly understand the runtime interactions for a use case in a large application.
  2. That the actual runtime SQL statements are captured with parameters populated regardless of the JDBC framework used (Hibernate being the framework here)

Choudary Kothapalli.

Powered by WordPress