OK, so after looking this a bit more, I still think we're good. Haven't made it all the way yet - have other issues. I just wanted to give ye a heads up Vs waiting until tomorrow. Some feedback on the SPI changes, specifically being able to reset the JAXBHandler via the Endpoint instance.... If I were you guys, I'd be a little scared of allowing something like the ESB (JBossWSAdapter) to do this. It's true that in many cases the JBossWSAdapter will only be doing this for endpoints that are "under it's control" from a deployment perspective. However, it's not impossible to use the JBossWSAdapter to access a webservice endpoint not under it's control (from a deployment perspective). In a situation like this, isn't it a bit dodgy to be allowing the JBossWSAdapter screw with details of an endpoint not "under its control". Perhaps it'd be better to only allow programmatic "overriding" of the installed JAXBHandler via the InvocationContext i.e. only on a per request basis. That's just something for you guys to decide on. I think I have it working for the ESB so I'm happy enough from that perspective, although I did have to implement a bit of a hack in an effort to avoid the above scenario (more below). This is just general API feedback. I'm trying to avoid the type scenario I outlined above by using the old reliable ThreadLocal (Grrrr) | private static class JBossESBJBossWSJAXBHandler implements JAXBHandler { | private static ThreadLocal<JAXBHandler> handlerTL = | new ThreadLocal<JAXBHandler>(); | private JAXBHandler installedJaxbHandler; | private JBossWSAdapter adapter; | | private JBossESBJBossWSJAXBHandler( | JAXBHandler installedJaxbHandler, JBossWSAdapter adapter) { | this.installedJaxbHandler = installedJaxbHandler; | this.adapter = adapter; | handlerTL.set(installedJaxbHandler); | } | | public JAXBContext getJAXBContext(Class[] classes) throws JAXBException { | return handlerTL.get().getJAXBContext(classes); | } | | /** | * This method helps ensure that only threads executing out of the | * JBossWSAdapter are supplied with JAXBContext instances from the | * JBossWSAdapter. We don't like the idea of not using the installed | * JAXBHandler for non ESB initiated JBossWS requests after the | * JBossWSAdapter has changed the JAXBHandler for the endpoint. | */ | private void useAdapterAsHandler() { | handlerTL.set(adapter); | } | | private void useInstalledHandler() { | handlerTL.set(installedJaxbHandler); | } | } | So the JBossWSAdapter is my real JAXBHandler and the class outlined above is just a way of toggling between the installed JAXBHandler and the JBossWSAdapter JAXBHandler via the useInstalledHandler and useAdapterAsHandler methods respectively. The JBossWSAdapter turns itself on as the handler for the current thread and when done turns itself off and switches the thread back to the installed handler. None of this poop would be required if I were setting the JBossWSAdapter as the JAXBHandler for the request only via the InvocationContext (or some other request scope object). Unless of course (I just thought of this), the CommonMessageContext only has a copy of the Endpoint, in which case we're OK and I don't need to worry about any of the above issue. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058380#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...