I had a look at the use of the JaxwsInterceptorRemover in the RM system
test. For starters this interceptor (at least at some point) only removd
one JAXWS specific interceptor - the SOAPHandlerInterceptor. This was
necessary before I switched over to the callback based approach to
logging outbound message. It is not required any more.
In the meantime however, the Holder[In|Out]Interceptors were added, and
these caused problems for some RM protocol messages (e.g. CreateSequence
operation). So the JaxwsInterceptorRemover was extended to remove the
HolderOutInterceptor also.
The ClassCastException seen when the HolderOutInterceptor is on the
chain can be avoided by checking if outObjects.get(idx) actually IS a
Holder object.
Before making this change however I'd like to know a little bit more
about this interceptor:
Is is possible for example to first check if the part is an INOUT
parameter and only then attempt the cast and store the holder for later?
Why do we need to store holders for other parameters?
BTW there is one more piece in RM code where interceptors get removed
from the chain for RM protocol messages: This is in the RMInInterceptor,
which removes the (JAXWS frontend specific) WrapperClassInInterceptor
from the chain. I am looking into what needs to be done to avoid this
(hence my attempts to generate code from the the wsrm.wsdl - I want to
compare the resulting service model with the one that is built up
manually in RMEndpoint.java).
Andrea.
