[tfennelly]

"tfennelly" wrote:

Tom, the change to the SPI supersedes Heiko's proposal AFAICS. Injecting your own JAXBHandler on the Endpoint should allow you to create, cache, etc the JAXBContext any way you want

Ah OK, thanks Thomas. I'll have a look at that so. I assume it's in the 2.0.x codebase.

Will this then require users of this ESB feature to have to go making low level mods to the container bean configurations? We we re hoping to avoid imposing that kind of requirement!

[tfennelly]

Hi Guys.

So Thomas, I had a look at the new additions around the JAXBHandler interface and I think this will work for JBossESB.

I was afraid that it might require the ESB user to get down and dirty with the JBossWS bean configs, but I see that the handler can be set on the Endpoint - for some reason I missed that in your earlier post - sorry :-)

I'll be back if I run into any issues. Thanks for sorting this out for us guys :-)

[tfennelly]

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.

[heiko.braun]

OK Tom, both Thomas and I did agree that the API quickshot was a mess. I did a revamp the API, but the concepts we talked about did remain the same.

The SPI now contains

Endpoint.addBindingCustomization (BindingCustomization)

BindingCustomization offers Map like access and will become a generic extension point for binding implementations and is not specific to any stack or binding framework.

The native stack implements JAXB binding customization:

/**
 * Supported JAXB 2.1 customizations.
 */
public class JAXBBindingCustomization extends BindingCustomization {

 // Use an alternative RuntimeAnnotationReader implementation
 public final static String ANNOTATION_READER = JAXBRIContext.ANNOTATION_READER;

 // Reassign the default namespace URI to something else at the runtime
 public final static String DEFAULT_NAMESPACE_REMAP = JAXBRIContext.DEFAULT_NAMESPACE_REMAP;

 // Enable the c14n marshalling support in the JAXBContext.
 public final static String CANONICALIZATION_SUPPORT = JAXBRIContext.CANONICALIZATION_SUPPORT;

}

It is recognized by the JAXBContextFactory, when set on the SPI Endpoint.

This allows you to supply JAXB customizations at deploy time through an ESB specific deployment aspect (in JBossWS terms spi.deployment.Deployer).
This particular deployment aspect should recognize ESB deployments and customize the JAXB marshalling for those endpoints only.

I think this SPI change will stand the test of time and allows us to model future ESB requirements (i.e. programmatic deployment) as well.

[heiko.braun]

Just to complete the picture:

There is a default API to create JAXBContext's now:

JAXBContextFactory.newInstance().createContext()

The default factory implementation is the one that works with BindingCustomizations:

CustomizableJAXBContextFactory.java