Cloners :
|
|
Relates :
|
JAX-B defines a Plugability Layer that specifies how it will locate an implementation or service provider. In the Java API documentation, the Plugability Layer is described in javax.xml.bind.JAXBContext: Discovery of JAXB implementation When one of the newInstance methods is called, a JAXB implementation is discovered by the following steps. 1. For each package/class explicitly passed in to the newInstance(java.lang.String) method, in the order they are specified, jaxb.properties file is looked up in its package, by using the associated classloader ��� this is the owner class loader for a Class argument, and for a package the specified ClassLoader. If such a file is discovered, it is loaded as a property file, and the value of the JAXB_CONTEXT_FACTORY key will be assumed to be the provider factory class. This class is then loaded by the associated classloader discussed above. This phase of the look up allows some packages to force the use of a certain JAXB implementation. (For example, perhaps the schema compiler has generated some vendor extension in the code.) 2. If the system property JAXB_CONTEXT_FACTORY exists, then its value is assumed to be the provider factory class. This phase of the look up enables per-JVM override of the JAXB implementation. 3. Look for /META-INF/services/javax.xml.bind.JAXBContext file in the associated classloader. This file follows the standard service descriptor convention, and if such a file exists, its content is assumed to be the provider factory class. This phase of the look up is for automatic discovery. It allows users to just put a JAXB implementation in a classpath and use it without any furhter configuration. 4. Finally, if all the steps above fail, then the rest of the look up is unspecified. That said, the recommended behavior is to simply look for some hard-coded platform default JAXB implementation. This phase of the look up is so that JavaSE can have its own JAXB implementation as the last resort. Once the provider factory class is discovered, its public static JAXBContext createContext(String,ClassLoader,Map) method (see newInstance(String, ClassLoader, Map) for the parameter semantics.) or public static JAXBContext createContet(Class[],Map) method (see newInstance(Class[], Map) for the parameter semantics) are invoked to create a JAXBContext. The problem is in points 3. and 4.: 3. Although there is java.util.ServiceLoader like functionality, the implementation is proprietary and can't be switched to JDK's one. 4. There is no provider interface/abstract class to be searched for. The resource defined by SPEC /META-INF/services/javax.xml.bind.JAXBContext points to ContextFactory which doesn't implement any interface and must have specific static methods (also defined by SPEC).