* The JAXBContext class provides the client's entry point to the * JAXB API. It provides an abstraction for managing the XML/Java binding * information necessary to implement the JAXB binding framework operations: * unmarshal, marshal and validate. * *
A client application normally obtains new instances of this class using * one of these two styles for newInstance methods, although there are other * specialized forms of the method available: * *
* The following JAXB 1.0 requirement is only required for schema to * java interface/implementation binding. It does not apply to JAXB annotated * classes. JAXB Providers must generate a jaxb.properties file in * each package containing schema derived classes. The property file must * contain a property named javax.xml.bind.context.factory whose * value is the name of the class that implements the createContext * APIs. * *
* The class supplied by the provider does not have to be assignable to * javax.xml.bind.JAXBContext, it simply has to provide a class that * implements the createContext APIs. * *
* In addition, the provider must call the * {@link DatatypeConverter#setDatatypeConverter(DatatypeConverterInterface) * DatatypeConverter.setDatatypeConverter} api prior to any client * invocations of the marshal and unmarshal methods. This is necessary to * configure the datatype converter that will be used during these operations. * * *
* The {@link Unmarshaller} class provides the client application the ability * to convert XML data into a tree of Java content objects. * The unmarshal method allows for * any global XML element declared in the schema to be unmarshalled as * the root of an instance document. * Additionally, the unmarshal method allows for an unrecognized root element that * has an xsi:type attribute's value that references a type definition declared in * the schema to be unmarshalled as the root of an instance document. * The JAXBContext object * allows the merging of global elements and type definitions across a set of schemas (listed * in the contextPath). Since each schema in the schema set can belong * to distinct namespaces, the unification of schemas to an unmarshalling * context should be namespace independent. This means that a client * application is able to unmarshal XML documents that are instances of * any of the schemas listed in the contextPath. For example: * *
* JAXBContext jc = JAXBContext.newInstance( "com.acme.foo:com.acme.bar" ); * Unmarshaller u = jc.createUnmarshaller(); * FooObject fooObj = (FooObject)u.unmarshal( new File( "foo.xml" ) ); // ok * BarObject barObj = (BarObject)u.unmarshal( new File( "bar.xml" ) ); // ok * BazObject bazObj = (BazObject)u.unmarshal( new File( "baz.xml" ) ); // error, "com.acme.baz" not in contextPath ** *
* The client application may also generate Java content trees explicitly rather * than unmarshalling existing XML data. For all JAXB-annotated value classes, * an application can create content using constructors. * For schema-derived interface/implementation classes and for the * creation of elements that are not bound to a JAXB-annotated * class, an application needs to have access and knowledge about each of * the schema derived ObjectFactory classes that exist in each of * java packages contained in the contextPath. For each schema * derived java class, there is a static factory method that produces objects * of that type. For example, * assume that after compiling a schema, you have a package com.acme.foo * that contains a schema derived interface named PurchaseOrder. In * order to create objects of that type, the client application would use the * factory method like this: * *
* com.acme.foo.PurchaseOrder po = * com.acme.foo.ObjectFactory.createPurchaseOrder(); ** *
* Once the client application has an instance of the the schema derived object, * it can use the mutator methods to set content on it. * *
* For more information on the generated ObjectFactory classes, see * Section 4.2 Java Package of the specification. * *
* The provider must generate a class in each * package that contains all of the necessary object factory methods for that * package named ObjectFactory as well as the static * newInstance( javaContentInterface ) method * *
* The {@link Marshaller} class provides the client application the ability * to convert a Java content tree back into XML data. There is no difference * between marshalling a content tree that is created manually using the factory * methods and marshalling a content tree that is the result an unmarshal * operation. Clients can marshal a java content tree back to XML data * to a java.io.OutputStream or a java.io.Writer. The * marshalling process can alternatively produce SAX2 event streams to a * registered ContentHandler or produce a DOM Node object. * Client applications have control over the output encoding as well as * whether or not to marshal the XML data as a complete document or * as a fragment. * *
* Here is a simple example that unmarshals an XML document and then marshals * it back out: * *
* JAXBContext jc = JAXBContext.newInstance( "com.acme.foo" ); * * // unmarshal from foo.xml * Unmarshaller u = jc.createUnmarshaller(); * FooObject fooObj = (FooObject)u.unmarshal( new File( "foo.xml" ) ); * * // marshal to System.out * Marshaller m = jc.createMarshaller(); * m.marshal( fooObj, System.out ); ** * *
* Validation has been changed significantly since JAXB 1.0. The {@link Validator} * class has been deprecated and made optional. This means that you are advised * not to use this class and, in fact, it may not even be available depending on * your JAXB provider. JAXB 1.0 client applications that rely on Validator * will still work properly when deployed with the JAXB 1.0 runtime system. * * In JAXB 2.0, the {@link Unmarshaller} has included convenince methods that expose * the JAXP 1.3 {@link javax.xml.validation} framework. Please refer to the * {@link Unmarshaller#setSchema(javax.xml.validation.Schema)} API for more * information. * * *
* The following JAXB 1.0 restriction only applies to binding schema to * interfaces/implementation classes. * Since this binding does not require a common runtime system, a JAXB * client application must not attempt to mix runtime objects (JAXBContext, * Marshaller, etc. ) from different providers. This does not * mean that the client application isn't portable, it simply means that a * client has to use a runtime system provided by the same provider that was * used to compile the schema. * * *
* When one of the newInstance methods is called, a JAXB implementation is discovered * by the following steps. * *
* If such a file is discovered, it is {@link Properties#load(InputStream) loaded} as a property file, and * the value of the {@link #JAXB_CONTEXT_FACTORY} key will be assumed to be the provider factory class. * This class is then loaded by the associated class loader 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.) * *
* * public static JAXBContext createContext( * String contextPath, * ClassLoader classLoader, * Map<String,Object> properties throws JAXBException * * public static JAXBContext createContext( * Class[] classes, * Map<String,Object> properties ) throws JAXBException ** This configuration method is deprecated. * *
* Once the provider factory class {@link javax.xml.bind.JAXBContextFactory} is discovered, one of its methods * {@link javax.xml.bind.JAXBContextFactory#createContext(String, ClassLoader, java.util.Map)} or * {@link javax.xml.bind.JAXBContextFactory#createContext(Class[], java.util.Map)} is invoked * to create a {@link JAXBContext}. * *
* * @apiNote *Service discovery method using file /META-INF/services/javax.xml.bind.JAXBContext (described in step 4) * and leveraging provider's static methods is supported only to allow backwards compatibility, but it is strongly * recommended to migrate to standard ServiceLoader mechanism (described in step 3). * * @implNote * Within the last step, if Glassfish AS environment detected, its specific service loader is used to find factory class. * * @author
* Create a new instance of a JAXBContext class. * *
* This is a convenience method to invoke the * {@link #newInstance(String,ClassLoader)} method with * the context class loader of the current thread. * * @throws JAXBException if an error was encountered while creating the * JAXBContext such as *
* Create a new instance of a JAXBContext class. * *
* The client application must supply a context path which is a list of * colon (':', \u005Cu003A) separated java package names that contain * schema-derived classes and/or fully qualified JAXB-annotated classes. * Schema-derived * code is registered with the JAXBContext by the * ObjectFactory.class generated per package. * Alternatively than being listed in the context path, programmer * annotated JAXB mapped classes can be listed in a * jaxb.index resource file, format described below. * Note that a java package can contain both schema-derived classes and * user annotated JAXB classes. Additionally, the java package may * contain JAXB package annotations that must be processed. (see JLS, * Section 7.4.1 "Named Packages"). *
* ** Every package listed on the contextPath must meet one or both of the * following conditions otherwise a JAXBException will be thrown: *
** Format for jaxb.index *
* The file contains a newline-separated list of class names. * Space and tab characters, as well as blank * lines, are ignored. The comment character * is '#' (0x23); on each line all characters following the first comment * character are ignored. The file must be encoded in UTF-8. Classes that * are reachable, as defined in {@link #newInstance(Class...)}, from the * listed classes are also registered with JAXBContext. *
* Constraints on class name occuring in a jaxb.index file are: *
* To maintain compatibility with JAXB 1.0 schema to java
* interface/implementation binding, enabled by schema customization
* {@literal
* If there are any global XML element name collisions across the various * packages listed on the contextPath, a JAXBException * will be thrown. * *
* Mixing generated interface/impl bindings from multiple JAXB Providers * in the same context path may result in a JAXBException * being thrown. * *
* The steps involved in discovering the JAXB implementation is discussed in the class javadoc. * * @param contextPath list of java package names that contain schema * derived class and/or java to schema (JAXB-annotated) * mapped classes * @param classLoader * This class loader will be used to locate the implementation * classes. * * @return a new instance of a JAXBContext * @throws JAXBException if an error was encountered while creating the * JAXBContext such as *
* Create a new instance of a JAXBContext class. * *
* This is mostly the same as {@link JAXBContext#newInstance(String, ClassLoader)}, * but this version allows you to pass in provider-specific properties to configure * the instantiation of {@link JAXBContext}. * *
* The interpretation of properties is up to implementations. Implementations should * throw JAXBException if it finds properties that it doesn't understand. * * @param contextPath list of java package names that contain schema derived classes * @param classLoader * This class loader will be used to locate the implementation classes. * @param properties * provider-specific properties. Can be null, which means the same thing as passing * in an empty map. * * @return a new instance of a JAXBContext * @throws JAXBException if an error was encountered while creating the * JAXBContext such as *
// * Create a new instance of a JAXBContext class. // * // *
// * The client application must supply a list of classes that the new // * context object needs to recognize. // * // * Not only the new context will recognize all the classes specified, // * but it will also recognize any classes that are directly/indirectly // * referenced statically from the specified classes. // * // * For example, in the following Java code, if you do // * newInstance(Foo.class), the newly created {@link JAXBContext} // * will recognize both Foo and Bar, but not Zot: // *
// * class Foo {
// * Bar b;
// * }
// * class Bar { int x; }
// * class Zot extends Bar { int y; }
// *
// *
// * Therefore, a typical client application only needs to specify the
// * top-level classes, but it needs to be careful.
// *
// * TODO: if we are to define other mechanisms, refer to them.
// *
// * @param externalBindings
// * list of external binding files. Can be null or empty if none is used.
// * when specified, those files determine how the classes are bound.
// *
// * @param classesToBeBound
// * list of java classes to be recognized by the new {@link JAXBContext}.
// * Can be empty, in which case a {@link JAXBContext} that only knows about
// * spec-defined classes will be returned.
// *
// * @return
// * A new instance of a JAXBContext.
// *
// * @throws JAXBException
// * if an error was encountered while creating the
// * JAXBContext, such as (but not limited to):
// * * Create a new instance of a JAXBContext class. * *
* The client application must supply a list of classes that the new * context object needs to recognize. * * Not only the new context will recognize all the classes specified, * but it will also recognize any classes that are directly/indirectly * referenced statically from the specified classes. Subclasses of * referenced classes nor @XmlTransient referenced classes * are not registered with JAXBContext. * * For example, in the following Java code, if you do * newInstance(Foo.class), the newly created {@link JAXBContext} * will recognize both Foo and Bar, but not Zot or FooBar: *
* class Foo {
* @XmlTransient FooBar c;
* Bar b;
* }
* class Bar { int x; }
* class Zot extends Bar { int y; }
* class FooBar { }
*
*
* Therefore, a typical client application only needs to specify the
* top-level classes, but it needs to be careful.
*
* * Note that for each java package registered with JAXBContext, * when the optional package annotations exist, they must be processed. * (see JLS, Section 7.4.1 "Named Packages"). * *
* The steps involved in discovering the JAXB implementation is discussed in the class javadoc. * * @param classesToBeBound * list of java classes to be recognized by the new {@link JAXBContext}. * Can be empty, in which case a {@link JAXBContext} that only knows about * spec-defined classes will be returned. * * @return * A new instance of a JAXBContext. * * @throws JAXBException * if an error was encountered while creating the * JAXBContext, such as (but not limited to): *
* Create a new instance of a JAXBContext class. * *
* An overloading of {@link JAXBContext#newInstance(Class...)} * to configure 'properties' for this instantiation of {@link JAXBContext}. * *
* The interpretation of properties is up to implementations. Implementations should * throw JAXBException if it finds properties that it doesn't understand. * * @param classesToBeBound * list of java classes to be recognized by the new {@link JAXBContext}. * Can be empty, in which case a {@link JAXBContext} that only knows about * spec-defined classes will be returned. * @param properties * provider-specific properties. Can be null, which means the same thing as passing * in an empty map. * * @return * A new instance of a JAXBContext. * * @throws JAXBException * if an error was encountered while creating the * JAXBContext, such as (but not limited to): *
* Create a Validator object that can be used to validate a
* java content tree against its source schema.
*
* @return a Validator object
*
* @throws JAXBException if an error was encountered while creating the
* Validator object
* @deprecated since JAXB2.0
*/
public abstract Validator createValidator() throws JAXBException;
/**
* Creates a Binder object that can be used for
* associative/in-place unmarshalling/marshalling.
*
* @param domType select the DOM API to use by passing in its DOM Node class.
*
* @return always a new valid Binder object.
*
* @throws UnsupportedOperationException
* if DOM API corresponding to domType is not supported by
* the implementation.
*
* @since 1.6, JAXB 2.0
*/
public