ParameterMetaData caching & Annotated Classloading

[jason.greene]

During the deploy process of a JSR181 endpoint the UMD uses a different classloader, the annotation classloader, since the web classloader is not yet available. After deployment the classloader is switched, which introduces a classloader problem with caching. Since tools needs to analyze the java type of a parameter, it calls getJavaType() on ParameterMetaData. The class object is then cached. After the first request, the classloader is then switched to the thread context classloader, leaving a cached class object from the old classloader. A type mapping is then built from these cached javatype classes. This cause the type lookups from the binding layer to finally fail because the lookup is using the correct class objects that are in the classloading context of the service endpoint.

The workaround I am currently using is to verify the classloader of the cached class values matches the UMD classloader. If it doesn't we then reload the class.

The other possible solution is to throw out caching altogether.

Any thoughts on this one?

-Jason

[anil.saldhana]

Jason, the caching is not adding value IMO.

[thomas.diesler]

During the proccess of meta data building it should not be neccesary to load and cache types other than for introspection.

For the exact same reason the loading of types is done lazily in ServiceDesc.getTypeMapping() which does not happen before the first message exchange.

IMHO, its a bug in the tools layer.

[jason.greene]

Tools isn't caching it, it is only used ifor introspection when producing the proper schema for complex types that correspond to SEI parameters. Tools just calls ParameterMetaData->getJavaType(). which caches the value internally.

This causes the type mapping returned from ServiceDesc->getTypeMapping() to contain the cached classes (since it in turn calls ParameterMetaData->getJavaType()).

So IMO we have 3 options:

1. 
   
2. Modify ParameterMetaData to detect that its cached javaType is invalid by comparing the UMD classloader to javaType.getClassLoader()
   
   
3. Modify ParameterMetaData to not cache the java type
   
   
4. Change the contract such that PMD.getJavaType() should only be called after the first request. In this scenario tools would then instead call PMD.getJavaTypeName(), and load the class itself
   
   
   -Jason

[thomas.diesler]

I vote for 3