Over the past few weeks we worked on migrating the SOAPProcessor (formerly known as "JBossWSAdapter") up to the JBossWS 2.0.x codebase. This was important for us because we wanted to get away from our dependency on a non-public JBossWS 1.x API. JBossWS has introduced a new SPI into the 2.x codebase. Changing the JBossESB SOAPProcessor action component to depend on this public SPI was a no-brainer.
However, the native SOAP stack in JBossWS 2.x depends on JAXB for SOAP<->Java binding. This raised an issue for us because JAXB is 100% driven by annotations on the Java binding classes. If your Webservice Java bindings are not JAXB annotated, JAXB will not marshal/unmarshal SOAP<->Java properly (see JAXB forum post).
A classic JBossESB usecase is one where the ESB is used to expose a Webservice interface for an existing Java based Service that doesn't already expose a Webservice interface. In this situation, you can use the ESB to define a "wrapper webservice" that maps calls to the target Service (we'll be automating this in a future release). In this situation you'll also want to use the Java types that define the target Service, when defining the "wrapper webservice" e.g. use an EJB's remote interface, without modification, to define a JSR 181 wrapper service.
So, in the usecase outlined above, the Java types that define the target Service are obviously not going to be JAXB annotated (or at least they typically will not be). At this point, using JAXB (and therefore JBossWS 2.x) is no longer an option, since JAXB will not work against an unannotated interface.
The JAXB RI API supports setting a RuntimeInlineAnnotationReader during JAXBContext creation. We've used this feature to support "Introduction" of the JAXB annotations, from an XML configuration, for interfaces that are not JAXB annotated. It works by creating dynamic proxies for the annotations as they are requested by JAXB RI, with the dynamic proxies being fed via an XML configuration. See "JAXB Annotation Introductions" for more details.
Having done this, and having talked with the JBossWS guys, it would appear as though users of JAXB are not the only ones that run into trouble as a result of not having an alternative to a purely annotation driven configuration model (JSR 181 being another example that Thomas Diesler and Hieko Braun have pointed out). Is there room for a general purpose mechanism that can be used to manually "Introduce" annotations in situations like this? Obviously you could suggest that implementations should just support 2 configuration models - internal (annotations) and external (something else - fed by XML, or whatever). But surely a single underlying configuration/metadata "access" mechanism (the Annotations API) is preferable.
The Annotation Reader approach (ala JAXB Introductions) seems to offer something along these lines, but it would be nice if it could be done without requiring the annotation reader i.e. it would be nice if we could introduce annotations directly on the Annotations API (AOP style).