GenericSignatureFormatError while deploying SOAP web services

This ticket will present some problem that I encountered using  JAXB.

Environment

  • OS: Windows 7
  • Servlet container : Tomcat 7.X
  • JRE: Sun Java 1.6.0_11
  • JAXB version: 2.2.1

Stack trace

Trying to deploy a web application containing (SOAP) web services  failed with the following stack trace:

WSSERVLET11: failed to parse runtime descriptor: 
java.lang.reflect.GenericSignatureFormatError
at sun.reflect.generics.parser.SignatureParser.error(SignatureParser.java:103)
at sun.reflect.generics.parser.SignatureParser.parseSimpleClassTypeSignature(SignatureParser.java:262)
at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignatureSuffix(SignatureParser.java:270)
at sun.reflect.generics.parser.SignatureParser.parseClassTypeSignature(SignatureParser.java:244)
...
 at com.sun.xml.ws.transport.http.DeploymentDescriptorParser.parse(DeploymentDescriptorParser.java:147)
 at com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized(WSServletContextListener.java:124)
...

Cause of the exception

One of the web services had as return value a list of enums. The enum was defined something like :

public enum Season { WINTER, SPRING, SUMMER, FALL }

(no default constructor).

In order to fix the problem it must add a no parameter contructor; something like:

public enum Season { 
WINTER, SPRING, SUMMER, FALL 
 Season() {}
}

A strange NullPointerException inside Beehive

This entry is a small analysis of a stange NullPointerException that we had on our production servers when the server started and the first client tried to connect. I have no idea what provoked this exception but maybe someone will have a hint.

Environment

Code biopsy

This is the stack trace:

java.lang.NullPointerException
at org.apache.beehive.netui.pageflow.AutoRegisterActionServlet.process(AutoRegisterActionServlet.java:622)
at org.apache.beehive.netui.pageflow.PageFlowActionServlet.process(PageFlowActionServlet.java:158)
at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:292)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42)
...

The code of the AutoRegisterActionServlet.java around the line 622 is:
//
// Try to select the appropriate Struts module and delegate to its RequestProcessor.
//
ModuleConfig moduleConfig = InternalUtils.selectModule( modulePath, request, servletContext );
// If this module came from an abstract page flow controller class, send an error.
ControllerConfig cc = moduleConfig.getControllerConfig();//622 line
if (cc instanceof PageFlowControllerConfig && ((PageFlowControllerConfig) cc).isAbstract()) {
InternalUtils.sendDevTimeError( "PageFlow_AbstractPageFlow", null, HttpServletResponse.SC_NOT_FOUND,
request, response, servletContext,
new Object[]{ modulePath } );
return;
}

The most logical conclusion is that the moduleConfig variable is null and moduleConfig.getControllerConfig will throw the NullPointerException.
Now, let’s take a look at how the moduleConfig variable is computed; the code of the InternalUtils#selectModule is:

/**
* Set the given Struts module in the request, and expose its set of MessageResources as request attributes.
*
* @param prefix the prefix of the desired module.
* @param request the current HttpServletRequest.
* @param servletContext the current ServletContext.
* @return the selected ModuleConfig, or
null if there is none for the given module prefix.
*/
public static ModuleConfig selectModule( String prefix, HttpServletRequest request, ServletContext servletContext )
{
ModuleConfig moduleConfig = getModuleConfig( prefix, servletContext );
if ( moduleConfig == null )
{
request.removeAttribute( Globals.MODULE_KEY );
return null;
}
// If this module came from an abstract page flow controller class, don’t select it.
ControllerConfig cc = moduleConfig.getControllerConfig();
if (cc instanceof PageFlowControllerConfig && ((PageFlowControllerConfig) cc).isAbstract()) {
return moduleConfig;
}
// Just return it if it’s already registered.
if ( request.getAttribute( Globals.MODULE_KEY ) == moduleConfig ) return moduleConfig;
request.setAttribute( Globals.MODULE_KEY, moduleConfig );
MessageResourcesConfig[] mrConfig = moduleConfig.findMessageResourcesConfigs();
Object formBean = unwrapFormBean( getCurrentActionForm( request ) );
for ( int i = 0; i < mrConfig.length; i++ )
{
String key = mrConfig[i].getKey();
MessageResources resources = ( MessageResources ) servletContext.getAttribute( key + prefix );
if ( resources != null )
{
if ( ! ( resources instanceof ExpressionAwareMessageResources ) )
{
resources = new ExpressionAwareMessageResources( resources, formBean, request, servletContext );
}
request.setAttribute( key, resources );
}
else
{
request.removeAttribute( key );
}
}
return moduleConfig;
}

The first problem that we see is that the InternalUtils#selectModule method can return a null but the AutoRegisterActionServlet#process never verifies this case.
As we can see the moduleConfig variable is computed by the getModuleConfig variable and is never nullified afterward inside the method, so we go deeper into the code to see how the getModuleConfig method computes the moduleConfig variable.
The code of the InternalUtils#getModuleConfig is :

/**
* Get the Struts ModuleConfig for the given module path.
*/
public static ModuleConfig getModuleConfig( String modulePath, ServletContext context )
{
return ( ModuleConfig ) context.getAttribute( Globals.MODULE_KEY + modulePath );
}

The moduleConfig object is retrieved from the ServletContext and if no attribute exists under the name Globals.MODULE_KEY + modulePath then a null object is returned (see ServletContext#getAttribute javadoc). The full name of attribute will be org.apache.struts.action.MODULEmodulePath (to see what can be the value of the modulePath variable, go to the next section).

Struts modules and Beehive

Now, let’s take a look at the meaning of the org.apache.struts.config.ModuleConfig interface. The ModuleConfig is the API representation of a Struts-module(Beehive uses under the hood the Struts framework).
A Struts module is a Struts configuration file and a set of corresponding actions, form beans, and Web pages. A Struts application consists of one module by default but may contain more than one module.
The Beehive framework will create dynamically a Struts module for every executed page flow controller.
For example when the https://&#8230;./login url is called, the login.LoginController class will be instantiated and used to treat the request and Beehive will automatically create an instance of org.apache.struts.config.ModuleConfig and store it into the ServletContext under the name org.apache.struts.action.MODULE/login. Normally, the Struts module is created just before the first use of the page flow controller.
My supposition is that the org.apache.struts.config.ModuleConfig objects are singletons (one instance by controller) and are created and added by Beehive into the ServletContext only one time (first time when a controller is used).

Some kind of conclusion

So, the source of the NullPointerException is due to a missing Struts module (which, of course should never happen). Maybe the Beehive had a problem creating the Struts modules or maybe some “mysterious” process just removed all the objects from the ServletContext.
It is possible to monitor the ServletContext “traffic” (what objects are added/removed/updated) by implementing a ServletContextAttributeListener; the problem of this solution is his intrusiveness (a new class should be added to the web application and the application must be redeployed).

Book review: AspectJ in action – Second edition (Part 1 Understanding AOP and AspectJ)

Introduction and … conclusion

Since I’m a fan of AOP and especially of AspectJ, I participated to the MEAP (Manning Early Access Program) of the AspectJ in action – Second edition book. The review that I will done will be of the MEAP edition, so maybe the final version will be slightly different. So, my conclusion about this book is that it is the bible of AspectJ; it gives a very clear introduction to AOP and a tremendous view of the AspectJ functionalities.

Chapter 1:  Discovering AOP

The chapter explain what is AOP and how it can be integrated into the today IT systems. Then the author presents the basic ingredients of an AOP language(join point, pointcut, advice and aspect) and how an AOP language can help to improve the modularity of a complex system.

Chapter 2:  Introducing AspectJ

The chapter is a very gentle introduction to the AspectJ5 framework containing the classic “Hello world” application.For every basic block of an AOP language enumerated in the first chapter, the equivalent AspectJ5 structure is presented using some simple examples. Beside the traditional AspectJ syntax, the new syntax using the annotations is presented (this new language syntax is called @AspectJ) and a paragraph is dedicated to the integration of AspectJ with the Spring framework.

Chapter 3:  Understanding the Join Point Model

This chapter takes us in the heart of the AspectJ framework by presenting the join point model. The joint points are the parts of a Java class (and or) object that can be intercepted by the framework. The joint points exposed by AspectJ are: methods, constructors, field access (read and write access), exception processing, static initialization of classes and objects and AspectJ advices. For every joint point type the author gives very detailed explanations with many examples . For some join point types, a small comparison is made with the Spring AOP framework.

Chapter 4:  Modifying Behavior with Dynamic Crosscutting

The goal of the dynamic crosscutting is to modify the execution behavior of the program. The construct that is offered by AspectJ for dynamic crosscutting is the advice.
This chapter deeply explains the notion of advice. An advice is a structure that contains the code to be executed when a join point is intercepted. The reflection support in AspectJ also is present.The reflection support is represented by a small number of interfaces that provides access to the join point’s static and dynamic information.

Chapter 5:  Modifying Structure with Static Crosscutting

The goal of static crosscutting is to modify the static structure of the Java elements (classes, interfaces). AspectJ offers the following features:

  • Member introduction. Introduction of new fields(final and non-final) and methods to any Java class. There is no need to have the source codes of the modified classes for using member introduction.
  • Type hierarchy modifications. With AspectJ you can modify the inheritance hierarchy of existing classes to declare a superclass and interfaces of an existing class. Of course the AspectJ cannot break the rules of the Java language; cannot declare multiple inheritance or cannot declare a class being the parent of an interface.
  • Compile-time errors and warnings. This is similar to the #error and #warning preprocessor directives from the C/C++ world. A typical use of this feature will be to enforce rules, such as prohibiting calls to certain unsupported methods or issuing a warning about such calls.
  • Softening checked exception. Exception softening allows treating checked exceptions thrown by specified pointcuts as unchecked ones and thus eliminated the need to deal wit it. Well, for me this constructs is a real danger and it should never be used. Even the author, raise a warning about overusing this feature because it can lead to masking off some checked exceptions that should be handle in the normal way.

Chapter 6:  Aspect: Putting it all together

As the name of the chapter it said, all the previous elements (joinpoints and advices) are put together into a same structure that is called “aspect”. The aspects have some similarities with the Java classes:

  • can be abstract
  • have data and members
  • have access specification
  • implement or extend other types
  • be nested inside other types

The main differences with aspects and Java classes:

  • aspects cannot be explicitly created (the AspectJ framework controls the aspect initialization)
  • aspects can inherit only from abstract aspects and not concrete aspects
  • aspects can have access to the private members of the classes (using the access specifier “privileged”)

So, as it was already said, the user cannot directly instantiate the aspects but it can instruct the framework how and when to instantiate the aspects. AspectJ offers 4 kinds of aspect associations:

  • singleton (default). A single instance of an aspect is created for the entire application.
  • per object. A new aspect instance will be created when executing a join point of a matching object for the first time.
  • per control-flow. A new instance will be associated with each control flow associated with a join point
  • per type Similar as the per object association with the difference that the aspect will be associated to the class instead of objects.

The last part of the chapter explains the aspects precedence or how to control the order on which advices sharing the same joint point are executed. For aspect precedence, the AspectJ framework introduced the “precedence” keyword.

Example : declare precedence : Aspect1, Aspect2; // Aspect1 have the precedence over the Aspect2

For the case of advices from the same aspect sharing the same joint point, the lexical order is applied (the advice declared first have the precedence over the second one, etc…).

Chapter 7:  Diving into the @AspectJ Syntax

The AspectJ 5 (the last version of AspectJ) introduced support for the Java5 language features. The introductions of annotations in Java5 permitted to the AspectJ team to offer an alternative syntax to the “classical” AspectJ syntax. The newly syntax called @AspectJ offer a choice to compiling source code with a plain Java compiler because all the crosscutting information is kept in annotations on Java elements:

  • aspects are normal Java classes annotated with @Aspect annotation.
  • advices are Java methods annotated with the following annotations @Around, @After, @AfterReturning, @AfterThrowing, @Before.
  • pointcuts are Java methods annotated with the @Pointcut annotation
  • modifications of type hierarchy is done by annotating Java fields with @DeclareParents annotation.
  • error and warning declarations are done annotating Java fields with @DeclareError and @DeclareWarning annotations.

Unfortunately, not all the AspectJ feature are available using the @AspectJ syntax:

  • the member introduction; a workaround for this limitation is to use modification of type hierarchy by declaring as parent an interface using the @DeclareParents annotation with the attribute “defaultImpl” containing a class that implements the interface.
  • softening exceptions.
  • privileged aspects.

Chapter 8:  AspectJ Weaving Models

The AspectJ framework offers two types of weaving:

  • build-time weaving; the classes and aspects are weaved during the build process using the ajc compiler. The ajc compiler can take as input source files, class files and jar files each of which may contains classes and aspects.
  • load-time weaving (LTW);the aspects are weave into the classes as the classes are loaded by the classloader. The LTW uses another Java5 feature which is Java Virtual Machine Tool Interface (JVMTI). JVMTI allows a JVMTI agent to imtercept the loading of a class. The load-time weaver is a JVMTI agent that use this functionality to weave the classes as the VM loads them. If the @AspectJ syntax is used then the LTW must be used. The load-time weaver needs some additional information to decide which aspects to weave; this information should be in a XML format into the file META-INF/aop.xml (alternatives to aop.xml are also META-INF/aop-ajc.xml or org/aspectj/aop.xml file).

Basically, the aop.xml file should contains the list of aspects to weave, the list of aspects to exclude from weaving, the list of the packages of the classes to be modified by the aspects and the list of packages of classes that should not be weaved.

Chapter 9:  Integration with Spring

This chapter presents more than the integration of AspectJ into Spring framework; the chapter presents the Spring AOP framework.

Prior to Spring 2.0 version the only Spring AOP offered “schema-style” AOP support that consists into writing crosscutting information in the XML form (for more details about “schema style” aop support please see this: http://static.springframework.org/spring/docs/1.2.x/reference/aop.html). The “schema style” support is suitable for projects that use version of Spring prior to Spring 2.0 or your project don’t use Java5.
Since Spring 2.0, the Spinng AOP is capable to understand the @AspectJ syntax.
The Spring AOP is a proxy-based framework, Spring creates proxy classes for each bean that matches the criterias specified in pointcuts. The proxy classes will intercept the calls to the original object. Under the hood, Spring uses dynamic proxies mechanism for intercepting calls to a method of an interface or it uses the CGLIB-proxies if the method to intercept is not part of an interface.

Some drawbacks of the Spring AOP linked to the proxy-based nature:

  • method execution-only join points;the proxies can intercept only methods.
  • cannot intercept/advise final methods; since Java prevents overriding final methods, the dynamically created proxies cannot advise final methods.
  • bean-only crosscutting; the  proxy creation requires that Spring bean factory create the objects that needs to be advised, so Spring AOP works only on Spring beans.

Due to the proxy-based mechanism it is not possible to use the full AspectJ power; the following pointcuts are not available: call(),
initialization(), preinitialization(), staticinitialization(), get(), set(), handler(), adviceexecution(), withincode(), cflow(), cflowbelow(),
if(), @this(), @withincode().

On the other side, Spring AOP (since version 2.5)introduce a new pointcut for selecting Spring beans. The pointcut is bean(<name-pattern>) and the name-pattern follows the AspectJ matching rules for a name pattern with ‘*’ being the only allowed wildcard.

aoplib4j version 0.0.1 is out !

aoplib4j is an AOP library for Java. For instance it contains only 3 components: