When working with enterprise integration you will quite often deal with legacy systems integration.

I recently had the case where integration of webservices was requested, and much to my surprise there are huge issues when attempting to integrate old webservices (as in pre axis2 and pre jax-ws).

These webservices use outdated or unsupported methods, such as rpc-style/encoded communication, or even worce, outdated elements in the XML messages, for instance <multiref>’s. Having to integrate such services does of course imply that you cannot change anything on the server side, and thus such an outdated format must still be consumed.
This is a huge problem, since current WS implementations, such as the popular axis2 framework, do simply not support these formats.

What surprised me the most about this is that webservices are designed to make systems independent by defining a common communication and data format, which is the exact opposite of what is going on here – and these formats are not that old, we are probably talking 4-5 years.

Developers facing these problems are taking rather desperate measures to work around these problems, such as using on-the-fly XSLT transformation to convert incoming and outgoing WS messages. However, this binds your application even stronger to the outdated format and specific service data.

In my case I wanted to use Spring-remoting. Since the service was RPC-style, I wanted to use the JaxRpcPortProxyFactoryBean to create an on-the-fly proxy implementing the service interface. What I did not want to do is having to write any additional code to consume the service. Furthermore, I wanted the complex objects transferred by the services to be represented by standard JAVA beans, and not be generated using the wsdl2java axis1 tools. Here is how I got this to work.

Using Spring-remoting’s jax-rpc support with axis 1

Required maven dependencies

First, I was willing to make the compromise of having axis1 on my classpath. This might not be the way to go for everyone, unless you are using an OSGI framework, which was not an option in my case. Using jax-rpc with axis1 from spring requires the following dependencies (I am using maven’s dependency management for the sake of simplicity):

<dependency>
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>commons-discovery</groupId>
  <artifactId>commons-discovery</artifactId>
  <version>0.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis-jaxrpc</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>org.apache.axis</groupId>
  <artifactId>axis-saaj</artifactId>
  <version>1.4</version>
</dependency>
<dependency>
  <groupId>wsdl4j</groupId>
  <artifactId>wsdl4j</artifactId>
  <version>1.6.2</version>
</dependency>
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-aop</artifactId>
  <version>2.5.6</version>
</dependency>
<dependency>
  <groupId>org.springframework</groupId>
  <artifactId>spring-web</artifactId>
  <version>2.5.6</version>
</dependency>
<dependency>
  <groupId>cglib</groupId>
  <artifactId>cglib-nodep</artifactId>
  <version>2.2</version>
</dependency>

Note that this setup is for JDK 1.5. JDK 1.6 ships with quite a lot of jax-ws libraries, so you might want to check whether all of these dependencies are still required when using 1.6, but I fear they might.

Configuring the service using the port proxy factory bean

First, I downloaded the WSDL’s from the services and placed them within my src/main/resources folder to use them offline. This is not required, but I do recommend it. Next step was to set up the factory beans for jax-rpc to generate implementations of my service interfaces:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

  <bean id="myWebService" class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean">
    <property name="serviceInterface" value="my.package.MYServiceInterface" />
    <property name="wsdlDocumentUrl" value="classpath:path/to/my/wsdl.swdl" />
    <property name="namespaceUri" value="namespace/as/defined/in/wsdl" />
    <property name="serviceName" value="ServiceNameFromWsdl" />
    <property name="portName" value="PortNameFromWsdl" />
    <property name="servicePostProcessors">
      <list>
        <!--
          This is for mapping your POJO's to the complex service objects (if you are using any).
          You can use an arbitrary number of mapping <bean> configurations for every model
          namespace of your WSDL.
        -->
        <bean
          class="org.springframework.remoting.jaxrpc.support.AxisBeanMappingServicePostProcessor">
	  <!-- encoding style as in WSDL, in my case the outdated soap/encoding -->
          <property name="encodingStyleUri" value="http://schemas.xmlsoap.org/soap/encoding/" />
          <property name="typeNamespaceUri" value="namespace/for/models/as/defined/in/wsdl" />
          <property name="beanMappings">
            <props>
              <prop key="my.package.MyPojo">ModelNameInWsdl</prop>
            </props>
          </property>
        </bean>
      </list>
    </property>
  </bean>
</beans>

If the service specifies an operation such as ComplexResponseVO getResults(ComplexRequestVO), you would thus define an interface like so:

public interface MyService {
     MyResponsePojo getResults(MyRequestPojo);
}

And map the MyResponsePojo and MyRequestPojo using the AxisBeanMappingServicePostProcessor in the above spring configuration. Spring will serialize and deserialize the pojos using standard getter and setter methods to obtain the values, thus you do not have to care for serialization or marshalling. In fact, your pojos do not even have to be Serializable.

Once you have this stuff up and running, you can inject the MyService implementation into any other spring bean and use it like any other bean. Spring will convert the usually annoying and unrecoverable RemoteExceptions into unchecked remote exceptions, thus if you want to handle these, catching remote access exceptions is recommended.

Using an interface as the service representation has the additional advantage that it is pretty easy to fake or mock the service for integration testing.

Handling uppercase data type attributes

Now it’s getting really ugly: Legacy services sometimes violate the JAVA standards of good coding and specify uppercase attribute names for their data types. This is like writing

public class MyService {
     private SomeType MyFieldName;
     ...
}

And thus pretty ugly. When using spring’s JaxRpcPortProxyFactoryBean things are getting a lot worce: the BeanDeserializer will look for a getter/setter pair (property) starting with an uppercase letter – and will never find it, since they must start with a lowercase letter. This is a known issue in Axis 1.x, and there is no fix released for it (and most likely there will never be one).

I solved the problem by providing a subclass of the org.apache.axis.encoding.ser.BeanDeserializer to the JaxRpcPortProxyFactoryBean using a subclassed AxisBeanMappingServicePostProcessor and a customized BeanDeserializerFactory:

<bean id="myWebService" class="org.springframework.remoting.jaxrpc.JaxRpcPortProxyFactoryBean">
...
  <property name="servicePostProcessors">
    <list>
      <bean class="my.package.MyServicePostProcessor">
      ....

Here is the sourcecode for this post processor, the deserializer factory and deserializer:

The post processor:

package my.package;

import javax.xml.namespace.QName;
import javax.xml.rpc.encoding.TypeMapping;

import org.apache.axis.encoding.ser.BeanSerializerFactory;
import org.springframework.remoting.jaxrpc.support.AxisBeanMappingServicePostProcessor;

/**
 * This {@link AxisBeanMappingServicePostProcessor} registers a
 * {@link MyBeanDeserializerFactory} during
 * {@link #registerBeanMapping(TypeMapping, Class, QName) mapping registration}.
 *
 * @author Olaf Otto
 */
public class MyServicePostProcessor extends AxisBeanMappingServicePostProcessor {

  /**
   * Registers the {@link MyBeanDeserializer} for the given mapping.
   */
  @Override
  @SuppressWarnings("unchecked")
  protected void registerBeanMapping(TypeMapping mapping, Class javaType, QName wsdlType) {
    mapping.register(javaType, wsdlType, new BeanSerializerFactory(javaType, wsdlType), new MyBeanDeserializerFactory(javaType, wsdlType));
  }
}

The deserializer factory:

package my.package;

import javax.xml.namespace.QName;

import org.apache.axis.encoding.Deserializer;
import org.apache.axis.encoding.ser.BeanDeserializerFactory;
import org.apache.axis.encoding.ser.EnumDeserializer;

/**
 * This {@link BeanDeserializerFactory} provides a {@link #getGeneralPurpose(String) general-purpose}
 * deserializer {@link MyBeanDeserializer capable of handling local names not conforming to the java beans spec}.
 *
 * @author Olaf Otto
 */
public class MyBeanDeserializerFactory extends BeanDeserializerFactory {
  private static final long serialVersionUID = -8880103201020594221L;

  @SuppressWarnings("unchecked")
  public MyBeanDeserializerFactory(Class javaType, QName xmlType) {
    super(javaType, xmlType);
  }

  /**
   * Returns either:
   * <ol>
   *       <li>
   *           The super types general-purpose deserializer if the target type or
   *           the XML type is <code>null</code> or the pre-defined deserializer class
   *           is an {@link EnumDeserializer}
   *      </li>

   *      <li>A {@link MyBeanDeserializer} otherwise (standard case)</li>
   * </ol>
   *
   *  @return never <code>null</code>, rather throws a {@link RuntimeException}.
   */
  @Override
  protected Deserializer getGeneralPurpose(String mechanismType) {
    Deserializer deserializer;
    if (javaType == null || xmlType == null || deserClass == org.apache.axis.encoding.ser.EnumDeserializer.class) {
      deserializer = super.getGeneralPurpose(mechanismType);
    } else {
      deserializer = new MyBeanDeserializer(javaType, xmlType, typeDesc, propertyMap);
    }
    return deserializer;
  }
}

The deserializer:

package my.package;

import static org.springframework.util.Assert.hasText;

import java.util.Map;

import javax.xml.namespace.QName;

import org.apache.axis.description.TypeDesc;
import org.apache.axis.encoding.DeserializationContext;
import org.apache.axis.encoding.ser.BeanDeserializer;
import org.apache.axis.message.SOAPHandler;
import org.xml.sax.Attributes;
import org.xml.sax.SAXException;

/**
 * This {@link BeanDeserializer} takes care of non-normal local names,
 * i.e. local names starting with an uppercase character.<br />
 * Such a local name, usually derived from a WSDL description, will
 * lead to a property lookup for a getter/setter pair on the target bean of the deserialization
 * with an uppercase name start. However, all property names start with a lowercase character
 * according to the java beans spec, thus a property with an upper case name start
 * is never found, causing the deserialization to fail.<br />
 *
 * @author Olaf Otto
 */
public class MyBeanDeserializer extends BeanDeserializer {
  private static final long serialVersionUID = 1183255594948119370L;

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType, TypeDesc typeDesc, Map propertyMap) {
    super(javaType, xmlType, typeDesc, propertyMap);
  }

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType, TypeDesc typeDesc) {
    super(javaType, xmlType, typeDesc);
  }

  @SuppressWarnings("unchecked")
  public MyBeanDeserializer(Class javaType, QName xmlType) {
    super(javaType, xmlType);
  }

  /**
   * {@link #normalizeLocalName(String) normalizes} the localName and invokes
   * {@link BeanDeserializer#onStartChild(String, String, String, Attributes, DeserializationContext)}.
   */
  @Override
  public SOAPHandler onStartChild(String namespace, String localName, String prefix, Attributes attributes1, DeserializationContext deserializationcontext) throws SAXException {
    String normalizedLocalName = normalizeLocalName(localName);
    return super.onStartChild(namespace, normalizedLocalName, prefix, attributes1, deserializationcontext);
  }

  /**
   * Converts the first character of the local name to
   * {@link Character#toLowerCase(char) lower case}, if it is
   * {@link Character#isUpperCase(char) upper case}.
   *
   * @param localName must not be <code>null</code> and not empty.
   * @return The normalized local name, never <code>null</code>.
   */
  public String normalizeLocalName(String localName) {
    hasText(localName, "The local name must not be null or empty.");
    char localNameStart  = localName.charAt(0);
    String normalizedLocalName = localName;
    if (Character.isUpperCase(localNameStart)) {
      StringBuilder builder = new StringBuilder(32)
                    .append(Character.toLowerCase(localNameStart))
                    .append(localName.substring(1));
      normalizedLocalName = builder.toString();
    }
    return normalizedLocalName;
  }
}

You might also write you own Serializer if you have the problem “in the opposite direction” which, luckily, I didn’t.

Let’s hope the current WS standards are not deprecated this fast…

I would even go as far as saying that there was no object orientation before programming crosscutting concerns and using dependency injection became established mechanisms.
Think about it: The original goal of OO is not to use inheritance, encapsulation, identity and polymorphism, but to express the real world of things – our reality – using an abstract world of things, while preserving most of the properties and relationships we observe in reality.

Before AOP, before being able to separate the description of things from creating, configurating and connecting concrete instances through dependency injection frameworks, this goal was hard to achieve.

Modules larger than classes with OSGI

Now however, we are about to reach a new stage in development of object orientation in JAVA: Developing modules that are larger than classes, modules which can, once properly identified, be developed independently using all the wonderful technology described beforehand. The technology used to achieve this has a name: OSGI. This technology has quite a long history of development, but a certain lack of elegance and light-weightiness barred this component model from becoming a real hit in the worldwide development community. This is about to change.

Impact of OSGI on the development process

Let me stress out here how important it is to be able to develop, manage and deploy such modules. The larger your system, the more developers your project involves, the longer you maintain it – you will always face the same problem: Developers concurrently working with party of the system that are directly or transitively connected will run into conflicts. You will have different parts of your system requiring different versions of the same library on the same class path. Changing one part of the system will always affect other parts of the system, most of the times in an unplanned fashion.

Test driven developments helps a lot along the way, but you still have a responsibility problem if there’s one team changing something and this causes a problem in a different part of the system, and dependency issues can be a real mess.

This is where OSGI can play out it’s strengths. Not only does it offer you complete, classloader-based module isolation. I believe the greatest benefit lies in the development process: Concurrent development is a lot easier with OSGI bundles than with a huge pile of tightly interconnected classes. You can have a lot of changes in the bundle, while exposing a relatively stable interface through which other components access your bundle’s services. Separation into OSGI bundles can bring the power of the SOA-Idea into “stand-alone” applications, without the massive overhead of connecting systems or components through, for example web services.

Of course, this concept has quite an impact on your way of thinking, since you will start to add a new level of decomposition: Which classes form tightly coupled components that could be isolated from other components and used as a service through a well-defined, slim and easy-to-use interface?

OSGI about to “break through”

Now, why am i so convinced that OSGI is about to finally become as common as using AOP or dependency injection? Because all the popular technologies are just about to embrace OSGI:

• Craig walls (Spring framework) has just finished his book an modular JAVA with the spring framework, featuring OSGI and Spring, a very powerful combination.
• Doug Clarke and Shaun Smith will hold a presentation on persistence and OSGI with eclipselink (the reference implementation of the JAVA persistence API (JPA)), thus suitable persistence mechanisms for this level of modularization are likely to be close at hand.

And if you look at the schedule for the JAX, Europe’s most important software & development conference, there have never been more OSGI topics featured – at least I would doubt that.

In other words: OSGI will soon be so smoothly integrated with you favorite frameworks, IDE’s and API’s that using it will be a breeze – and a must, if you want to take the quality of your development process and software to the next level.

Finding useful information about open source software projects can be tedious – especially when trying to find facts that your customers understand.
ohloh.net provides excellent, comparable meta information for open source projects and should be on every decision-makers favorites list.

Why this software and not another?

I often find the need to justify the use of a specific open source software. Why is is better than another, competing open source software? How much better is the community support? How many supporters does it have? How active is the project and how much effort was spend on it’s development? How about metrics for the code, and how do you compare software in general?
Those are about the most important questions i have to answer.

Obtaining information about open source projects

Most of the above questions are not so easy to answer. When it comes to usage statistics and community support, one might be lucky to find the number of committers and the number of downloads, the number of mailings on the project mailing list or a more or less qualified article in a software mag. All of this information can usually be googled up or located on the projects site.
Unfortunately, many of the above facts are only loosely related to a project’s code quality.
To compare code, i am usually downloading the software and run QA tools on it, such as findbugs and JAVANCSS. But code metrics are something that developers understand, but customers usually do not. They want to know how many happy users a software has and whether or not community support might last long enough to justify investments.

Best practice: ohloh.net

ohloh.net: Money spend on developing hibernate, calculation based on the COCOMO model.

Looking for such Information, i found ohloh.net’s project information site for hibernate.
To my surprise, it had most of the things i was looking for. Code metrics. Information on who is involved in the projects development. Usage statistics. Ratings. Reviews. Journal links. An executive summary and statements on the code quality and project state, based on facts.

To sum it up i wish that more projects would publish information to the same extend ohloh does. ohloh.net’s project meta-information should be an example and a blue print for other big open source sites. Sourceforge, for example, is already publishing some useful project information (see for example findbugs sf project page) but does not deliver the same amount and quality of information that ohloh has to offer.

2008-07-12: Comment: It is indeed a lot simpler using spring-security, as Craig Walls demonstrates in this posting in his blog “Spring-Loaded”).

In order to activate the post processing for the @Secured annotations, a spring configuration such as the following is required:

    <!-- Bean post-processor for activating any advisors -->
    <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator"/>

    <!-- The advisor that creates secured proxies for beans using security annotations such as @Secured -->
    <bean class="org.acegisecurity.intercept.method.aopalliance.MethodDefinitionSourceAdvisor">
        <constructor-arg>
            <ref bean="myMethodInterceptor"/>
        </constructor-arg>
    </bean>

Where myMethodInterceptor is a MethodSecurityInterceptor, which may be configured like this:

    <bean id="myMethodInterceptor" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
        <property name="validateConfigAttributes" value="false"/>
        <property name="authenticationManager" ref="authenticationManager"/>
        <property name="accessDecisionManager" ref="accessDecisionManager"/>
        <property name="objectDefinitionSource" ref="objectDefinitionSource"/>
    </bean>

With a suitable AuthenticationManager, AccessDescisionManager and and objectDefinitionSource of type MethodDefinitionSource.

Often it is the case that annotated bean classes must be proxied directly, rather than proxying some implemented interface.

If you get an exception such as

Failed to convert property value of type [$Proxy70] to required type ...
no matching editors or conversion strategy found


Your solution might be to force the proxying of the target class itself using:

    <!-- Bean post-processor for auto-activating all advisors -->
    <bean class="org.springframework.aop.framework.autoproxy.DefaultAdvisorAutoProxyCreator">
        <property name="proxyTargetClass" value="true" />
    </bean>


cvc-complex-type.2.4.c: The matching wildcard is strict, but no declaration can be found for element ...


Thus, it is recommended to provide the XSD’s through the applications class path and reference it accordingly in the XML file.
I did this for an activemq configuration as follows:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:amq="http://activemq.org/config/1.0"
       xmlns:jms="http://www.springframework.org/schema/jms"
       xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

           http://activemq.org/config/1.0 activemq-core-5.0.0.xsd
           http://www.springframework.org/schema/jms http://www.springframework.org/schema/jms/spring-jms-2.5.xsd">
 ...

In this example, the XML file activemq-core-5.0.0.xsd will be retreived from the classpath (residing in the default package). Putting the XSD into a subpackage on the classpath or using a classpath:// URI has not worked for me in spring 2.5.2 (and other systems). There appear to be a couple of parsers with only very basic classpath resource retreival capabilities.

@Configurable(value = "myBean")
public class MyBean {
   ...
}

Where myBean is the bean id in the spring context.

This approach can be somewhat problematic, though, when used in conjunction with aspect-oriented features.
Say, for example, you also want to use JPA and require a transactional behavior.

You would usually do the following:

@Configurable(value = "myBean")
public class MyBean {
   @Transactional
    public void foo() {
    ...
    }
}

This will not work, but lead to an exception like this:


java.lang.IllegalStateException: Post-processor tried to replace bean instance of type [my.package.MyBean] with (proxy) object of type [my.package.MyBean$$EnhancerByCGLIB$$c029ddbf] - not supported for aspect-configured classes!


The reason is that @Configurable will ask spring to configure the current bean during constructor invokation. During configuration, a number of bean post processors will be invoked on the bean, and one of them, namely the InfrastructureAdvisorAutoProxyCreator will find the @Transactional annotation – which advices the post processor to proxy the bean in order to manage the required transaction’s context.

But you cannot override the expected outcome of a class instanciation with new with a proxy object – since it is not of the same type as the expected object!

Thus, @Configurable and @Transactional – together with any other advice that leads to a proxy object – cannot coexist in your class.


...
Caused by: javax.persistence.RollbackException: Error while commiting the transaction
at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:71)
at org.springframework.orm.jpa.JpaTransactionManager.doCommit(
JpaTransactionManager.java:438)
... 55 more
Caused by: java.lang.ClassCastException: java.util.HashSet
cannot be cast to org.hibernate.collection.PersistentCollection
at org.hibernate.event.def.FlushVisitor.processCollection(FlushVisitor.java:34)
...


Das tritt dann auf, wenn man wohlmeinend die Exposition der internen Repräsentation vermeiden wollte und beispielsweise so etwas hier auf einer persistenten Collection macht:

 @Entity
 public  class foo {
       private Set<AnotherEntity> _relatedEntites = new HashSet<AnotherEntity>();

     @OneToMany(cascade = {CascadeType.ALL }, fetch = FetchType.LAZY)
     @Column(name = "RELATED_ENTITIES")
      public Set<AnotherEntity> getRelatedEntities() {
            return new HashSet<AnotherEntity>(_relatedEntites)
     }
 }

Das: new HashSet(…) ist ein Fehler, da es aus der vorher erzeugten persistenten Collection wieder eine HashMap macht, die nicht persistiertbar ist.

Um die Manipulierbarkeit der Klasse zu vermeiden kann man stattdessen die @Immutable-Annotation verwenden:

 @Entity
 public  class foo {
       private Set<AnotherEntity> _relatedEntites = new HashSet<AnotherEntity>();

     @OneToMany(cascade = {CascadeType.ALL }, fetch = FetchType.LAZY)
     @Column(name = "RELATED_ENTITIES")
     @Immutable
      public Set<AnotherEntity> getRelatedEntities() {
            return _relatedEntites;
     }
 }

Dann klappt’s auch mit Hibernate.

/**
 * Demonstrates the retrieval of a generic type parameters actual Class at runtime.
 *
 * @author Olaf Otto
 *
 * @param <T> the generic type.
 */
public abstract class AbstractDao<T extends Entity> {
    @SuppressWarnings("unchecked")
    public void foo() {
        Class<T> clazz = null;
        // Since we are targeting this class, we know it is a ParameterizedType.
        // We use getGenericSuperclass in this example since this class is abstract and the method will be invoked
        // on a directly derived class instance.
        ParameterizedType pt = (ParameterizedType) getClass().getGenericSuperclass();
        Type[] typeArguments = pt.getActualTypeArguments();
        // Since we know the maximum number of type arguments (1), this check is sufficient.
        if (typeArguments != null && typeArguments.length > 0) {
            Type arg = typeArguments[0];
            if (arg instanceof Class) {
                clazz = (Class<T>) arg;
            }
        }
        System.out.println("Resolved generic type parameter to " + clazz + ".");
    }
}

/**
 * Dummy class for demonstration purposes.
*/
public class Entity {
}

/**
 *  Dummy class for demonstration purposes.
*/
public class SomeEntity extends Entity {

}

Ruft man jetzt innerhalb einer main-Methode oder eines Unit-Tests die Methode foo() auf einer SomeEntity-Instanz auf, so erhält man folgendes Ergebnis:

Resolved generic type parameter to class my.package.name.SomeEntity.


Womit der Typparameter korrekt aufgelöst ist.

Zum Ausprobieren: die verwendete Main-Klasse.

/**
 * A main method provider for demonstration purposes.
*/
public class Main {
    public static void main(String[] args) {
        SomeEntityDao dao = new SomeEntityDao();
        dao.foo();
    }
}

Pro und contra

In einem Ähnlichen Posting zeigt Ian Robertson, wie man diese Systematik unabhängig von der Vererbungshierarchie verwenden kann.
In den Kommentaren zu seinem Posting wird diskutiert, warum man überhaupt so viel komplizierten utility-Code schreiben sollte, wenn man ebensogut einfach und sicher die Klasse des Typ-Parameters in der ableitenden Klasse bekannt machen kann – was letztendlich davon abhängt, an wie vielen unterschiedlichen Stellen im Code man die Typinformationen der Parameter benötigt.

API Dokumentationen zum Posting:

Die ParameterizedType API-Dokumentation

    <filter>
        <filter-name>springContextFilter</filter-name>
        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
    </filter>

    <filter-mapping>
        <filter-name>springContextFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

Mehr dazu gibt’s natürlich in der spring-doku!