Jason, the caching is not adding value IMO.
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.
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:
- Modify ParameterMetaData to detect that its cached javaType is invalid by comparing the UMD classloader to javaType.getClassLoader()
- Modify ParameterMetaData to not cache the java type
- 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
I vote for 3