When tracing the sample application Alfresco, I got an exception like below.

Caused by: com.sun.xml.bind.v2.runtime.IllegalAnnotationsException: 1 counts of IllegalAnnotationExceptions
javax.xml.bind.JAXBElement does not have a no-arg default constructor.
this problem is related to the following location:
at javax.xml.bind.JAXBElement
at static final javax.xml.bind.JAXBElement org.alfresco.repo.audit.model._3.ObjectFactory.createAudit_aroundBody
at org.alfresco.repo.audit.model._3.ObjectFactory

This kind of exceptions arise when we are trying to trace class files generated at runtime (jaxb, cglib, etc.). The quick fix is to exclude the problem causing class from the aop.xml file as below. This FAQ explains the location of aop.xml and how to edit it.

<exclude within=”org.alfresco.repo.audit.model._3.ObjectFactory”/>

A few other exceptions that could be resolved using the same approach are below:

29-Nov-2011 17:47:45 org.aspectj.weaver.tools.Jdk14Trace error
SEVERE: xxx/xxx/XXXDaoImpl$$EnhancerByCGLIB$$dd2b8471
java.lang.NullPointerException
at org.aspectj.weaver.bcel.LazyMethodGen.remap(LazyMethodGen.java:1415)

Caused by: java.lang.VerifyError: (class: xxx/xxx/XXXFactory$$EnhancerByCGLIB$$43dfa63e, method: init$_aroundBody2 signature: (XXXFactory$$EnhancerByCGLIB$$43dfa63e;Lorg/aspectj/lang/JoinPoint;)V) Unable to pop operand off an empty stack

–Choudary Kothapalli.

I answered a question on Stackoverflow, related to the UML diagrams. I am reproducing it here with some changes.

Only a few high-level UML  diagrams survive the life cycle of the application

We need models to represent the software design. But even in large projects of about 500 man-months, I observed that only 3-4 sequence diagrams really matter and have a chance of surviving the entire life cycle of the application. Those 3-4 sequence diagrams (and class diagrams that represent their static time relationships), usually represent the high level design of the application.

Or, look at it this way:

Any decent enterprise application will not have 20 generic call flows. There will be one or two generic (or abstract) call flows, which all the concrete use cases implement. Let us take a simple Struts / EJB application. The generic flow will be something like - an action class calling a validator and then calling a stateless session bean, which in turn calls a domain class, which will call a DAO. All the use cases of the application just implement this flow with concrete classes that are specific to that use case.

Do you agree?

If you do not, I would like to hear about applications that have 20 different generic call flows and survived for 5 years after the first release.

If you agree with me, we are boiling down to 3-4 class and sequence diagrams even for large enterprise applications comprising several thousand classes.

It is hard to find good UML documentation that is kept in sync with the evolving code

You might say that in addition to the few high-level diagrams, you want to document all the use cases of the system for training or documentation purposes. During my last 14 years of experience in the real enterprise software world, I don’t remember seeing well ‘maintained’ UML documentation. First of all, good documents are difficult to produce and are not found that often. Secondly, they are out of sync with the code most of the time. Most of my experience is with large banks, insurance companies, Auto companies, etc. Those environments are just too hectic and their resources are limited (really? Are we talking banks? Yes, difficult to believe, but true) for ‘maintaining’ good documentation.

So am I suggesting that we get rid of UML?

No. We need visual models to represent complex systems. Human brains seem to be at their best when processing visuals. The visual cortex, which is responsible for processing the visual images, is the largest system in the human brain.

So what is a reasonable solution to easily produce and maintain UML models?

1. Probably we are better off using the current crop of UML tools to draw those 3-4 high-level UML diagrams. If you hate using them, check option 3 below.
2. For the diagrams at the next level of abstraction (any useful models should have different levels of abstraction), generate the UML from source code. You can generate both class and sequence diagrams.
3. In this age of agile methodologies, why not just write the shell classes and generate those 3-4 high-level UML class and sequence diagrams as well? This way there won’t be any UML to maintain at all.

The source code is the truth - generate the UML from the code

Can you argue against the statement that the code is the truth? If you do not, why not generate the models from the source code itself? I am not suggesting the round-trip engineering, by the way. I am just suggesting a one way trip - from code to models.

Problems with the generated UML

There are 2 main problems however with the generated UML.

1. When we hand draw a class diagram, we show the relations between the classes involved in a scenario. Most existing class diagram generating tools allow the user to drop the Java classes (the source code) into the tool and the tool automatically shows the relations between the classes. The problem with this approach is, how does one know about the classes involved in a scenario to begin with?
2. The second problem is the verboseness of the generated diagrams. There are tools available to generate runtime sequence and class diagrams for a scenario. But the diagrams are often very verbose and defeat the purpose of models, which is to highlight the important aspects and filter out unimportant details.

How does MaintainJ address the above problems?

1. MaintainJ generates diagrams for a single use case. So the MaintainJ generated class and sequence diagrams are for a single scenario.
2. MaintainJ offers various options to filter out unimportant details from the diagrams.  A powerful relevant feature in MaintainJ is to ‘exclude’ a class. When we hand draw the diagrams, we could leave out the facade like classes and show a direct call from a Controller class in the web tier to the DAO in the business tier for the sake of clarity, though in reality the call flows through a ‘front controller’ or ‘Session facade’, etc. The ‘Exclude class’ feature of MaintainJ allows one to do exactly the same in the  generated UML diagrams.

–Choudary Kothapalli

So what is

• ‘Runtime Impact Analysis’ or
• ‘Runtime Dependency Analysis’ or
• ‘Dynamic Change Impact Analysis’?

Why is it necessary to begin with? Aren’t we fine with what we have now?

I cannot answer these questions better than Ben Rowland did on his blog titled Runtime Dependency Analysis. Please check that blog to appreciate the power of this new feature in MaintainJ.

My explanation of how MaintainJ addresses this problem is here. I will add screenshots of this feature on the screenshots page of the web site.

This release also adds the ability to see the class fields and methods in a class diagram. Showing all the fields and methods in each class will make the diagram very cumbersome and difficult to read. The chosen solution is to show them in the tool tip when the mouse is hovered over a class.

–Choudary Kothapalli.

Here is a document with detailed instructions to apply MaintainJ on a Tomcat application. The steps in this document should work for other application servers as well.

This document is produced by Chris Velado at Periscope Holdings Inc. Thanks a lot, Chris!

Chris is using MaintainJ on a J2EE application that contains around 4000 classes. The application is based on Struts and uses SQL Server, Oracle 10 and 11g databases.

Choudary Kothapalli.

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 this feels like lot of changes, contact us and we would be happy to help.

Choudary  Kothapalli.

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.