* 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: *
* SPEC REQUIREMENT: the provider must supply an implementation * class containing the following method signatures: *
* 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
*
* * 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. *
* SPEC REQUIREMENT: 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 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.) *
* Once the provider factory class is discovered, its * public static JAXBContext createContext(String,ClassLoader,Map) method * (see {@link #newInstance(String, ClassLoader, Map)} for the parameter semantics.) * or public static JAXBContext createContet(Class[],Map) method * (see {@link #newInstance(Class[], Map)} for the parameter semantics) are invoked * to create a {@link JAXBContext}. * @author
* Obtain 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 *
* Obtain a new instance of a JAXBContext class. *
* The client application must supply a context path which is a list of * colon (':', \u003A) 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 * <jaxb:globalBindings valueClass="false">, * the JAXB provider will ensure that each package on the context path * has a jaxb.properties file which contains a value for the * javax.xml.bind.context.factory property and that all values * resolve to the same provider. This requirement does not apply to * JAXB annotated classes. *
* 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 *
* Obtain 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 *
* Obtain 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. Always non-null valid object. * @throws JAXBException * if an error was encountered while creating the * JAXBContext, such as (but not limited to): *
* Obtain 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. Always non-null valid object. * @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
*/
// @ts-ignore
public abstract createValidator(): javax.xml.bind.Validator
/**
* 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 JAXB2.0
*/
// @ts-ignore
public createBinder