rampart_1_1/xdocs/1_1/adb/adb-advanced.html - axis-axis2-java-rampart - Git at Google

 <html>
 <head>
   <meta http-equiv="content-type" content="text/html; charset=UTF-8">
   <title>Advanced Axis2 Databinding Framework Features</title>
   <link href="../../css/axis-docs.css" rel="stylesheet" type="text/css" media="all" />
 </head>

 <body lang="en">
 <h1>Advanced Axis2 Databinding Framework Features</h1>

 <p>The aim of this section is provide an insight into the newly added
 advanced features of Axis2 Databinding (ADB) Framework.</p>

 <h2>Content</h2>
 <ul>
   <li><a href="#typeSupport">xsi:type Support</a></li>
   <li><a href="#helper">Helper Mode</a></li>
   <li><a href="#more">More Stuff on ADB?</a></li>
 </ul>
 <a name="typeSupport"></a>
 <h2>xsi:type Support</h2>

 <p>This is implemented by adding a extension maping class. The code that
 calls the extension mapper is generated inside the Factory.parse method of
 the beans and gets active when the xsi:type attribute is present. The
 following code fragment shows how the generated type mapper looks like : </p>
 <pre>            public static java.lang.Object getTypeObject(java.lang.String namespaceURI,
                                 java.lang.String typeName,
                                 javax.xml.stream.XMLStreamReader reader) throws java.lang.Exception{

                   if (
                   "http://soapinterop.org/types".equals(namespaceURI) &&
                   "SOAPStruct".equals(typeName)){
                             return  com.test.SOAPStruct.Factory.parse(reader);
                   }
               throw new java.lang.RuntimeException("Unsupported type " + namespaceURI + " " + typeName);
             }</pre>

 <p>Inside every Factory.parse method, the extension mapper gets called when a
 xsi:type attribute is encountered <strong>and</strong> that type is not the
 type that is being parsed.</p>

 <p>The following code fragment shows how the ADB deserialize method calls the
 mapper class : </p>
 <pre>
 	     if (reader.getAttributeValue("http://www.w3.org/2001/XMLSchema-instance","type")!=null){
                   java.lang.String fullTypeName = reader.getAttributeValue("http://www.w3.org/2001/XMLSchema-instance",
                         "type");
                   if (fullTypeName!=null){
                     java.lang.String nsPrefix = fullTypeName.substring(0,fullTypeName.indexOf(":"));
                     nsPrefix = nsPrefix==null?"":nsPrefix;

                     java.lang.String type = fullTypeName.substring(fullTypeName.indexOf(":")+1);
                     if (!"SOAPStruct".equals(type)){
                         //find namespace for the prefix
                         java.lang.String nsUri = reader.getNamespaceContext().getNamespaceURI(nsPrefix);
                         return (SOAPStruct)org.soapinterop.types.ExtensionMapper.getTypeObject(
                              nsUri,type,reader);
                       }

                   }
 	      }</pre>

 <p>This should make the xsi:type based parsing possible and should
 result in proper xsi:type based serializations at runtime.</p>

 <p>This is automatically done but the package name for the mapper class can
 be set as an CompilerOption.</p>
 <pre>
 	CompilerOptions compilerOptions = new CompilerOptions();
         compilerOptions.setWriteOutput(true);
         <strong>compilerOptions.setMapperClassPackage("com.test");</strong>
         compilerOptions.setOutputLocation(new File("src"));
         try {
             SchemaCompiler schemaCompiler = new SchemaCompiler(compilerOptions);
             XmlSchemaCollection xmlSchemaCollection = new XmlSchemaCollection();
             XmlSchema xmlSchema =xmlSchemaCollection.read(new FileReader("schema/sample.xsd"),null);
             schemaCompiler.compile(xmlSchema);
         } catch (Exception e) {
             e.printStackTrace();
         }
 </pre>

 <p>When the mapping package is not specified it is derived from the
 targetnamespace of the first schema that is encountered.</p>

 <a name="helper"></a>
 <h2>Helper mode</h2>

 <p>Helper mode is a fairly new feature. In the helper mode, the beans are
 plain Java beans and all the deserialization/serialization code is moved to a
 helper class. For example, the simple schema mentioned in the ADB-howto
 document will yield four classes for the two that has been previously seen.</p>
 <ol>
   <li>MyElement.java</li>
   <li>MyElementHelper.java</li>
   <li>SOAPStruct.java</li>
   <li>SOAPStructHelper.java</li>
 </ol>

 <p>The helpers basically contain all the code that went into the ADBBeans.
 Hence the beans in the helper mode are pretty much readable than the rest.
 Also note that the helper mode is available only if you are in the unpacked
 mode. The code generator by default does not expand the classes.</p>

 <p>Helper mode can be switched on by using the setHelperMode method
 in CompilerOptions : </p>
 <pre><strong>compilerOptions.setHelperMode(true);</strong></pre>

 <a name="more"></a>
 <h2>More Stuff on ADB?</h2>
 <ul>
   <li><a href="adb-tweaking.html">Tweaking the ADB Code Generator</a>-
     explains available mechanisms to extend ADB and possibly adopt it to
     compile schemas to support other languages.</li>
   <li><a href="adb-codegen-integration.html">ADB and Axis2 Integration</a> -
     explains how the ADB schema compiler was attached to the Axis2
   framework</li>
 </ul>
 <hr>
 </body>
 </html>
	<html>
	<head>
	<meta http-equiv="content-type" content="text/html; charset=UTF-8">
	<title>Advanced Axis2 Databinding Framework Features</title>
	<link href="../../css/axis-docs.css" rel="stylesheet" type="text/css" media="all" />
	</head>

	<body lang="en">
	<h1>Advanced Axis2 Databinding Framework Features</h1>

	<p>The aim of this section is provide an insight into the newly added
	advanced features of Axis2 Databinding (ADB) Framework.</p>

	<h2>Content</h2>
	<ul>
	<li><a href="#typeSupport">xsi:type Support</a></li>
	<li><a href="#helper">Helper Mode</a></li>
	<li><a href="#more">More Stuff on ADB?</a></li>
	</ul>
	<a name="typeSupport"></a>
	<h2>xsi:type Support</h2>

	<p>This is implemented by adding a extension maping class. The code that
	calls the extension mapper is generated inside the Factory.parse method of
	the beans and gets active when the xsi:type attribute is present. The
	following code fragment shows how the generated type mapper looks like : </p>
	<pre> public static java.lang.Object getTypeObject(java.lang.String namespaceURI,
	java.lang.String typeName,
	javax.xml.stream.XMLStreamReader reader) throws java.lang.Exception{

	if (
	"http://soapinterop.org/types".equals(namespaceURI) &&
	"SOAPStruct".equals(typeName)){
	return com.test.SOAPStruct.Factory.parse(reader);
	}
	throw new java.lang.RuntimeException("Unsupported type " + namespaceURI + " " + typeName);
	}</pre>

	<p>Inside every Factory.parse method, the extension mapper gets called when a
	xsi:type attribute is encountered <strong>and</strong> that type is not the
	type that is being parsed.</p>

	<p>The following code fragment shows how the ADB deserialize method calls the
	mapper class : </p>
	<pre>
	if (reader.getAttributeValue("http://www.w3.org/2001/XMLSchema-instance","type")!=null){
	java.lang.String fullTypeName = reader.getAttributeValue("http://www.w3.org/2001/XMLSchema-instance",
	"type");
	if (fullTypeName!=null){
	java.lang.String nsPrefix = fullTypeName.substring(0,fullTypeName.indexOf(":"));
	nsPrefix = nsPrefix==null?"":nsPrefix;

	java.lang.String type = fullTypeName.substring(fullTypeName.indexOf(":")+1);
	if (!"SOAPStruct".equals(type)){
	//find namespace for the prefix
	java.lang.String nsUri = reader.getNamespaceContext().getNamespaceURI(nsPrefix);
	return (SOAPStruct)org.soapinterop.types.ExtensionMapper.getTypeObject(
	nsUri,type,reader);
	}

	}
	}</pre>

	<p>This should make the xsi:type based parsing possible and should
	result in proper xsi:type based serializations at runtime.</p>

	<p>This is automatically done but the package name for the mapper class can
	be set as an CompilerOption.</p>
	<pre>
	CompilerOptions compilerOptions = new CompilerOptions();
	compilerOptions.setWriteOutput(true);
	<strong>compilerOptions.setMapperClassPackage("com.test");</strong>
	compilerOptions.setOutputLocation(new File("src"));
	try {
	SchemaCompiler schemaCompiler = new SchemaCompiler(compilerOptions);
	XmlSchemaCollection xmlSchemaCollection = new XmlSchemaCollection();
	XmlSchema xmlSchema =xmlSchemaCollection.read(new FileReader("schema/sample.xsd"),null);
	schemaCompiler.compile(xmlSchema);
	} catch (Exception e) {
	e.printStackTrace();
	}
	</pre>

	<p>When the mapping package is not specified it is derived from the
	targetnamespace of the first schema that is encountered.</p>

	<a name="helper"></a>
	<h2>Helper mode</h2>

	<p>Helper mode is a fairly new feature. In the helper mode, the beans are
	plain Java beans and all the deserialization/serialization code is moved to a
	helper class. For example, the simple schema mentioned in the ADB-howto
	document will yield four classes for the two that has been previously seen.</p>
	<ol>
	<li>MyElement.java</li>
	<li>MyElementHelper.java</li>
	<li>SOAPStruct.java</li>
	<li>SOAPStructHelper.java</li>
	</ol>

	<p>The helpers basically contain all the code that went into the ADBBeans.
	Hence the beans in the helper mode are pretty much readable than the rest.
	Also note that the helper mode is available only if you are in the unpacked
	mode. The code generator by default does not expand the classes.</p>

	<p>Helper mode can be switched on by using the setHelperMode method
	in CompilerOptions : </p>
	<pre><strong>compilerOptions.setHelperMode(true);</strong></pre>

	<a name="more"></a>
	<h2>More Stuff on ADB?</h2>
	<ul>
	<li><a href="adb-tweaking.html">Tweaking the ADB Code Generator</a>-
	explains available mechanisms to extend ADB and possibly adopt it to
	compile schemas to support other languages.</li>
	<li><a href="adb-codegen-integration.html">ADB and Axis2 Integration</a> -
	explains how the ADB schema compiler was attached to the Axis2
	framework</li>
	</ul>
	<hr>
	</body>
	</html>