Data binding from XML to Java code three from text to byte code

The third part of this data binding series demonstrates how to convert XML elements and attributes to Java objects by using the method specified in JSR-031: Data binding, Sun data binding specification request. This section is mainly about moving from XML representations of data to Java instances that are easy to use for application code. The third part is about the use of new tools by canceling the nesting elements in XML documents into Java objects, testing, and using some practical examples.

The goal of this series is to demonstrate how to convert XML elements into Java objects, and then use the Java language accessor and mutator methods to work directly with XML data. The first part compares the data binding and other methods of processing XML data in the Java application, analyzes the design decision, and defines the XML schema of the sample WEB service configuration document. The second section explains how to generate interfaces and implementations from XML schemas so that XML documents that conform to XML schemas can be converted into instances of these build classes.

In the third part (a total of four parts), the basics are explained, and how the code is carefully designed to perform ungroup, and ungroup completes the process of translating XML into Java objects. After you perform a ungroup, you can use the test class, which is included, to check that all parts are grouped together correctly. Each part of this series is based on other parts, so if you haven't seen the first and second parts, you may not be able to read some of the descriptions in this article. If you want to review a specific glossary, see the term interpretation sidebar.

Using the XML Schema defined for Webserviceconfiguration in the first section (see newer version) and the interfaces in part two, you are about to create an XML document that provides data for a specific instance of the configuration data. Any XML document that conforms to the schema can be made into a Java object. These objects should be instances of classes that are generated using the Schemamapper class. The end result, of course, is data binding.

Making an XML instance document

Creating an XML document that conforms to schemas--often called XML instances--is simple. The document must provide only data values that match the constraints defined in the pattern, as shown in Listing 1.

Listing 1. XML instance documents that conform to the sample XML Schema

<?xml version="1.0"?>
<webServiceConfiguration xmlns="http://www.enhydra.org"
牋牋牋牋牋牋牋牋牋牋牋牋 xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance"
牋牋牋牋牋牋牋牋牋牋牋牋 xsi:schemaLocation="http://www.enhydra.org
牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋牋 configuration.xsd"
牋牋牋牋牋牋牋牋牋牋牋牋 version="1.1"
牋牋牋牋牋牋牋牋牋牋牋牋 name="Unsecured Web Listener"
>
_<port number="80"
牋牋牋_protocol="http"
牋牋牋_protectedPort="false"
_/>
_<document root="/usr/local/enhydra/html"
牋牋牋牋牋_index="*.html,*.xml"
牋牋牋牋牋_error="error.html"
_/>
</webServiceConfiguration>

The example in Listing 1 shows a complete example of webserviceconfiguration. The instance document includes two namespace declarations. The first is the default namespace declaration, please refer to http://www.enhydra.org. This means that all elements without a prefix are assigned to this namespace. Although there is no need to declare the default namespace in this example, it also gives some identity to the document. This default namespace helps differentiate the document from other XML documents that have similar or equivalent element names.

Another namespace that is defined is assigned to the XSI prefix, so all elements with that prefix are assigned to this namespace. It (http://www.w3.org/1999/XMLSchema/instance) references the URI of the XML Schema instance specification. The specification, in turn, defines how the XML document refers to the XML schema that the document conforms to. Finally, the schemalocation attribute references the XML schema. The first variable of this property is the constrained namespace (the sample default namespace, which includes each element in the document). The second variable, separated by a space from the first variable, refers to the actual location of the XML schema. In this case, the schema configuration.xsd is a local file that is in the same directory as the document. You can also refer to a pattern anywhere on the network by using a URL.

In the default namespace, the attached properties (because they do not have a prefix) define the version (1.1) and the name (unsecured Web Listener).

It then declares the Port object in the pattern and defines its data: The port number is 80, and the protocol is HTTP. The document becomes an instance of the Webserviceconfigurationimpl class after the correct cancellation of the compilation of the Java code. Java code can then use the interface webserviceconfiguration designed in part two of this series to work with the data in the underlying XML document. (Note that you might perform validation in your application, as outlined in the schema Validation sidebar.) ）