I've noticed that if the server has to serialize complex types (using type mappings) it seems to never be able to find the mapping. It turns out that the reason for this is that serializing the SOAP Response using the appropriate TypeMappings requires AxisEngine.getCurrentContext() to return a valid value.
This doesn't happen with the JabberTransport for two reasons: 1.) The process that calls AxisEngine.invoke(context) is not the same process that attempts to serialize the message. This means that the ThreadLocal stuff in AxisEngine for getting the current context will not work, leaving the MessageContext null, and leaving you with nothing but DefaultTypeMappingImpl. 2.) The MessageContext in AxisEngine is only valid DURING the AxisEngine.invoke(context) call. The code in invoke actually stores the previous context, then uses the passed in context, and then restores the current context. Just curious... how could AxisEngine.getCurrentContext() ever return anything but null while it is NOT in the invoke method? Anyway, my current hacked solution is to generate the full text of the SOAP response in the same method that calls invoke (this solves #1 above). And to explicitly call AxisEngine.setCurrentContext(context) from the JabberTransport, which requires a (wrong) change to the AxisEngine API to make that method public. Could someone let me know a better way to deal with this? Also, I have noticed that the JabberTransport doesn't emit entities correctly. For the moment, the only one that matters to me is '&', so I have just worked around it manually, but what is the preferred way to deal with this. Otherwise, this Jabber stuff is definitely pretty cool. I'm looking forward to further experiments in the future! :-) Thanks, Jess Sightler
