MaintainJ Blog

November 28, 2011

Problem when tracing applications using JAXB or cglib

Filed under: Uncategorized — maintainj @ 4:13 pm

1. 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”/>

2. Some 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

Use the exclude like below to exclude all the CGLIB generated classes from scope. The sample below assumes that the top level package is org.alfresco.

<exclude within=”org.alfresco..*CGLIB*”/>

–Choudary Kothapalli.

November 2, 2011

Are UML drawing tools relevant today?

Filed under: Uncategorized — maintainj @ 4:24 pm

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

Powered by WordPress