[JBoss AS7 Development] - Modular Serialization
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene] modified the document:
"Modular Serialization"
To view the document, visit: http://community.jboss.org/docs/DOC-17244
--------------------------------------------------------------
h2. Understanding Class-loading Issues
When an object is serialized using Java serialization, the format consists of a "class reference" and the field data of every field in all inherited classes. The class reference is simply a class name. *+The assumption is that the receiving party has all of the sender's class definitions readily accessible to the thread's current context class loader.+* This means very different semantics than those commonly expected in a normal in-vm invocation across class loader boundaries. In a modularized environment, it is not only common, but considered good practice to only share public API types and yet still pass internal implementation classes that back the API types across module boundaries. These "opaque" structures don't cause the VM a problem because the same physical, already constructed, object instance is being passed around.
However, with serialization there is no object instance. All fields of all types that make up an object need to be accessed to recreate the instance. Also since fields themselves may be references to other custom types, it is quite common for a large graph referencing numerous types to be on the wire, and thus have a need for visibility.
h2. Problem A - Subclass Visibility
In this example a common super class is shared between a sender and a receiver, but an extended subclass used by the sender's implementation is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-18-170... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-18...
h2. Problem B - Reference / Aggregation Visibility
In this example a common class is shared between a sender and a receiver, but it contains a field which references a sender class that is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-18-170... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-18...
h2. Problem C - Transitive Modular Dependencies
This complex example shows how the isolation properties of a module can reflect its ability to load its own serialized data. It's considered good practice (and actually the default in JBoss Modules, as well as other module systems) to not import a transitive dependency. This allows for an application to use independent versions of a module that will never conflict with a library used by one of the application's dependencies. In this example we have an application that is using a framework of some sort which controls the lifecycle of a class in the application (think IoC container, ejb, web container etc). As part of constructing the instance of the application's class Foo, it associates some internal class with the instance that it uses from a thirdparty framework that is of no interest to the application (it's just an implementation detail of the framework).
The application then serializes the instance the framework constructed BUT it will not be able to deserialize it. This is because the framework's dependencies (which are transitive to the application) are not visible to the application.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-18-170... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-18...
h2. Solution 1 - Require Components To Share All Needed Classes
This may require altering the application / component code to always use common shared classes in the serialization stream. A negative side effect of this is that it puts a larger burden on the application / component developer. A positive benefit is that the wire format is compatible standard serialization.
Possible approaches to use this solution with the above problems would be:
Problem A:
1. Create a FooData class in shared.jar.
2. Add a FooImpl.toFooData().
3. Write the FooData instance.
Problem B:
1. Move Bar to shared.jar
Problem C (Option 1)
1. Create a copy constructor on Foo
2. Create a local data version of whatever interface Bar implements
3. Have the copy constructor copy Bar's interface properties to the data version
Problem C (Option 2)
1. Import thirdparty.jar, or change framework.jar to export thirdparty.jar
h2. Solution 2 - JBoss Marshalling - Modular Serialization
This solution is currently available using the ModularClassResolver like so:
RiverMarshallerFactory factory = new RiverMarshallerFactory();
MarshallingConfiguration configuration = new MarshallingConfiguration();
// Enable Modular Serialization!
configuration.setClassResolver(ModularClassResolver.getInstance(moduleLoader));
// Create a marshaller on some stream we have
Marshaller marshaller = factory.createMarshaller(configuration);
marshaller.start(new OutputStreamByteOutput(fileOutputStream));
// Write lots of stuff
marshaller.writeObject(fooObject);
// Done
marshaller.finish();
This changes the format of the stream such that the owning module identifier is written in addition to the name of any class referenced in the stream. This allows jboss marshalling to easily locate the "correct" class loader for deserializing the class. The advantage of this approach is that application/component code need not be changed, and that the same practices used in local invocation also apply with remote serialization. The drawback is that the serialization format must be altered potentially introducing compatibility problems with older clients. In addition non-modular clients, if they need to be supported, will not understand the format. Solution 3 is the recommended approach when compatibility is a concern.
Note that JBoss Marshalling has some other benefits including +*double the performance of Java serialization*+. For general information on JBoss Marshalling check out http://www.jboss.org/jbossmarshalling its project page.
Also note this solution is only applicable to JBoss Modules. Although, you could add your own resolver that works with the modular framework of your choice (OSGi for example).
h2. Solution 3 - Support both Modular and Standard Serialization
This is the same approach as 2 but adds the ability to handle both styles of streaming. This is achieved by either having the client ignore the information, or having some kind of negotiation process (protocol version etc).
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17244]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
[JBoss AS7 Development] - Modular Serialization
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene] modified the document:
"Modular Serialization"
To view the document, visit: http://community.jboss.org/docs/DOC-17244
--------------------------------------------------------------
h2. Understanding Class-loading Issues
When an object is serialized using Java serialization, the format consists of a "class reference" and the field data of every field in all inheriting classes. The class reference is simply a class name. *+The assumption is that the receiving party has all of the sender's class definitions readily accessible to the thread's current context class loader.+* This means very different semantics than those commonly expected in a normal in-vm invocation across class loader boundaries. In a modularized environment, it is not only common, but considered good practice to only share public API types and yet still pass internal implementation classes that back the API types across module boundaries. These "opaque" structures don't cause the VM a problem because the same physical, already constructed, object instance is being passed around.
However, with serialization there is no object instance. All fields of all types that make up an object need to be accessed to recreate the instance. Also since fields themselves may be references to other custom types, it is quite common for a large graph referencing numerous types to be on the wire, and thus have a need for visibility.
h2. Problem A - Subclass Visibility
In this example a common super class is shared between a sender and a receiver, but an extended subclass used by the sender's implementation is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-17-170... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-17...
h2. Problem B - Reference / Aggregation Visibility
In this example a common class is shared between a sender and a receiver, but it contains a field which references a sender class that is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-17-170... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-17...
h2. Problem C - Transitive Modular Dependencies
This complex example shows how the isolation properties of a module can reflect its ability to load its own serialized data. It's considered good practice (and actually the default in JBoss Modules, as well as other module systems) to not import a transitive dependency. This allows for an application to use independent versions of a module that will never conflict with a library used by one of the application's dependencies. In this example we have an application that is using a framework of some sort which controls the lifecycle of a class in the application (think IoC container, ejb, web container etc). As part of constructing the instance of the application's class Foo, it associates some internal class with the instance that it uses from a thirdparty framework that is of no interest to the application (it's just an implementation detail of the framework).
The application then serializes the instance the framework constructed BUT it will not be able to deserialize it. This is because the framework's dependencies (which are transitive to the application) are not visible to the application.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-17-170... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-17...
h2. Solution 1 - Require Components To Share All Needed Classes
This may require altering the application / component code to always use common shared classes in the serialization stream. A negative side effect of this is that it puts a larger burden on the application / component developer. A positive benefit is that the wire format is compatible standard serialization.
Possible approaches to use this solution with the above problems would be:
Problem A:
1. Create a FooData class in shared.jar.
2. Add a FooImpl.toFooData().
3. Write the FooData instance.
Problem B:
1. Move Bar to shared.jar
Problem C (Option 1)
1. Create a copy constructor on Foo
2. Create a local data version of whatever interface Bar implements
3. Have the copy constructor copy Bar's interface properties to the data version
Problem C (Option 2)
1. Import thirdparty.jar, or change framework.jar to export thirdparty.jar
h2. Solution 2 - JBoss Marshalling - Modular Serialization
This solution is currently available using the ModularClassResolver like so:
RiverMarshallerFactory factory = new RiverMarshallerFactory();
MarshallingConfiguration configuration = new MarshallingConfiguration();
// Enable Modular Serialization!
configuration.setClassResolver(ModularClassResolver.getInstance(moduleLoader));
// Create a marshaller on some stream we have
Marshaller marshaller = factory.createMarshaller(configuration);
marshaller.start(new OutputStreamByteOutput(fileOutputStream));
// Write lots of stuff
marshaller.writeObject(fooObject);
// Done
marshaller.finish();
This changes the format of the stream such that the owning module identifier is written in addition to the name of any class referenced in the stream. This allows jboss marshalling to easily locate the "correct" class loader for deserializing the class. The advantage of this approach is that application/component code need not be changed, and that the same practices used in local invocation also apply with remote serialization. The drawback is that the serialization format must be altered potentially introducing compatibility problems with older clients. In addition non-modular clients, if they need to be supported, will not understand the format. Solution 3 is the recommended approach when compatibility is a concern.
Note that JBoss Marshalling has some other benefits including +*double the performance of Java serialization*+. For general information on JBoss Marshalling check out http://www.jboss.org/jbossmarshalling its project page.
Also note this solution is only applicable to JBoss Modules. Although, you could add your own resolver that works with the modular framework of your choice (OSGi for example).
h2. Solution 3 - Support both Modular and Standard Serialization
This is the same approach as 2 but adds the ability to handle both styles of streaming. This is achieved by either having the client ignore the information, or having some kind of negotiation process (protocol version etc).
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17244]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
[JBoss AS7 Development] - Modular Serialization
by Carlo de Wolf
Carlo de Wolf [http://community.jboss.org/people/wolfc] modified the document:
"Modular Serialization"
To view the document, visit: http://community.jboss.org/docs/DOC-17244
--------------------------------------------------------------
h2. Understanding Class-loading Issues
When an object is serialized using Java serialization, the format consists of a "class reference" and the field data of every field in all inheriting classes. The class reference is simply a class name. *+The assumption is that the receiving party has all of the sender's class definitions readily accessible to the thread's current context class loader.+* This means very different semantics than those commonly expected in a normal in-vm invocation across class loader boundaries. In a modularized environment, it is not only common, but considered good practice to only share public API types and yet still pass internal implementation classes that back the API types across module boundaries. These "opaque" structures don't cause the VM a problem because the same physical, already constructed, object instance is being passed around.
However, with serialization there is no object instance. All fields of all types that make up an object need to be accessed to recreate the instance. Also since fields themselves may be references to other custom types, it is quite common for a large graph referencing numerous types to be on the wire, and thus have a need for visibility.
h2. Problem A - Subclass Visibility
In this example a common super class is shared between a sender and a receiver, but an extended subclass used by the sender's implementation is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-9-1706... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-9-...
h2. Problem B - Reference / Aggregation Visibility
In this example a common class is shared between a sender and a receiver, but it contains a field which references a sender class that is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-9-1706... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-9-...
h2. Solution 1 - Require Components To Share All Needed Classes
This may require altering the application / component code to always use common shared classes in the serialization stream. A negative side effect of this is that it puts a larger burden on the application / component developer. A positive benefit is that the wire format is compatible standard serialization.
h2. Solution 2 - JBoss Marshaling - Modular Serialization
This solution is currently available using the ModularClassResolver like so:
RiverMarshallerFactory factory = new RiverMarshallerFactory();
MarshallingConfiguration configuration = new MarshallingConfiguration();
configuration.setClassResolver(ModularClassResolver.getInstance(moduleLoader));
This changes the format of the stream such that the owning module identifier is written in addition to the name of any class referenced in the stream. This allows jboss marshalling to easily locate the "correct" class loader for deserializing the class. The advantage of this approach is that application/component code need not be changed, and that the same practices used in local invocation also apply with remote serialization. The drawback is that the serialization format must be altered potentially introducing compatibility problems with older clients. In addition non-modular clients, if they need to be supported, will not understand the format. Solution 3 is the recommended approach when compatibility is a concern
h2. Solution 3 - Support both Modular and Standard Serialization
This is the same approach as 2 but adds the ability to handle both styles of streaming. This is achieved by either having the client ignore the information, or having some kind of negotiation process (protocol version etc).
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17244]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
Re: [jboss-dev-forums] [JBoss AS7 Development] - AS7 XML Parser Validation [Proposed Idea]
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] commented on the document
"AS7 XML Parser Validation [Proposed Idea]"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-17243#comment-7722
--------------------------------------------------
Turning on JAXP validation would however do nothing to validate our parser implementations match the schema. At runtime the schemas are as good as non-existent, it does not matter if the XML does or does not match the schema if the parser does not match the schema.
This proposed change firstly allows the error reporting to be centralised allowing the current error reporting code in the parsers to be removed, secondly the change in calls allows us to provide a test framework that validates the calls made by the parser do match the definition in the schema.
--------------------------------------------------
14 years
[JBoss AS7 Development] - Modular Serialization
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene] modified the document:
"Modular Serialization"
To view the document, visit: http://community.jboss.org/docs/DOC-17244
--------------------------------------------------------------
h2. Understanding Class-loading Issues
When an object is serialized using Java serialization, the format consists of a "class reference" and the field data of every field in all inheriting classes. The class reference is simply a class name. *+The assumption is that the recieving party has all of the sender's class definitions readily accessable to the thread's current context class loader.+* This means very different semantics than those commonly expected in a normal in-vm invocation accross class loader boundaries. In a modularized environment, it is not only common, but considered good practice to only share public API types and yet still pass internal implementation classes that back the API types across module boundaries. These "opaque" structures don't cause the VM a problem because the same phsysical, already constructed, object instance is being passed around.
However, with serialization there is no object instance. All fields of all types that make up an object need to be accessed to recreate the instance. Also since fields themesleves may be references to other custom types, it is quite common for a large graph referencing numerous types to be on the wire, and thus have a need for visibility.
h2. Problem A - Subclass Visibility
In this example a common super class is shared between a sender and a receiver, but an extened subclass used by the sender's implementation is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-7-1706... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-7-...
h2. Problem B - Reference / Aggregation Visibility
In this example a common class is shared between a sender and a receiver, but it contains a field which references a sender class that is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-7-1706... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-7-...
h2. Solution 1 - Require Components To Share All Needed Classes
This may require altering the application / component code to always use common shared classes in the serialization stream. A negative side effect of this is that it puts a larger burdeon on the application / component developer. A positive benefit is that the wire format is compatible standard serialization.
h2. Solution 2 - JBoss Marshaling - Modular Serialization
This solution is currently available using the ModularClassResolver like so:
RiverMarshallerFactory factory = new RiverMarshallerFactory();
MarshallingConfiguration configuration = new MarshallingConfiguration();
configuration.setClassResolver(ModularClassResolver.getInstance(moduleLoader));
This changes the format of the stream such that the owning module identifier is written in addition to the name of any class referenced in the stream. This allows jboss marshalling to easily locate the "correct" class loader for deserializing the class. The advantage of this approach is that application/component code need not be changed, and that the same practices used in local invocation also apply with remote serialization. The drawback is that the serialization format must be alteredm potentially introducing compatiblity problems with older clients. In addition non-modular clients, if they need to be supported, will not understand the format. Solution 3 is the recommended approach when compatibility is a concern
h2. Solution 3 - Support both Modular and Standard Serialization
This is the same approach as 2 but adds the ability to handle both styles of streaming. This is achieved by either having the client ignore the information, or having some kind of negotiation process (protocol version etc).
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17244]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
[JBoss AS7 Development] - Modular Serialization
by Jason Greene
Jason Greene [http://community.jboss.org/people/jason.greene] modified the document:
"Modular Serialization"
To view the document, visit: http://community.jboss.org/docs/DOC-17244
--------------------------------------------------------------
h2. Understanding Class-loading Issues
When an object is serialized using Java serialization, the format consists of a "class reference" and the field data of every field in all inheriting classes. The class reference is simply a class name. *+The assumption is that the recieving party has a all of the sender's class definitions readily accessable to the thread's current context class loader.+* This means very different semantics than those commonly expected in a normal in-vm invocation accross class loader boundaries. In a modularized environment, it is not only common, but considered good practice to only share public API types and yet still pass internal implementation classes that back the API types across module boundaries. These "opaque" structures don't cause the VM a problem because the same phsysical, already constructed, object instance is being passed around.
However, with serialization there is no object instance. All fields of all types that make up an object need to be accessed to recreate the instance. Also since fields themesleves may be references to other custom types, it is quite common for a large graph referencing numerous types to be on the wire, and thus have a need for visibility.
h2. Problem A - Subclass Visibility
In this example a common super class is shared between a sender and a receiver, but an extened subclass used by the sender's implementation is mistakenly not shared. This case works just fine wiht local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-4-1706... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-4-...
h2. Problem B - Reference / Aggregation Visibility
In this example a common class is shared between a sender and a receiver, but it contains a field which references a sender class that is mistakenly not shared. This case works just fine with local IN-VM invocations, but will fail once serialization is involved.
http://community.jboss.org/servlet/JiveServlet/showImage/102-17244-4-1706... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-17244-4-...
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17244]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
[JBoss AS7 Development] - AS7 XML Parser Validation [Proposed Idea]
by Darran Lofthouse
Darran Lofthouse [http://community.jboss.org/people/dlofthouse] modified the document:
"AS7 XML Parser Validation [Proposed Idea]"
To view the document, visit: http://community.jboss.org/docs/DOC-17243
--------------------------------------------------------------
Within JBoss AS7 all of the configuration that can be written for standalone and domain server is described by making use of XML schemas, the XML is then parsed using parsers making StAX calls.
This approach has started to lead to possible issues in a couple of areas: -
* Error checking / reporting is duplicated across all of the parsers.
* No automated validation realistically possible that the parser implementation matches the schema definition.
This article is to propose a possible wrapper around the existing XMLElementReader that at server runtime takes over the error reporting during parsing, this in turn will open up possibilites within the testsuite to validate that the calls the parser makes to the new wrapper match the definition of the schema.
The change to the wrapper would potentially be intrusive as code making calls to the XMLElementReader API and performing validation would need to change to make calls to the new wrapper and remove the validation - having said that the wrapper is after all a wrapper, this means that integration could be gradual e.g. it could be introduced on a subsystem by subsystem basis as a subsystem moves to a new namespace version.
h2. Runtime
The proposal is that a wrapper around the XMLElementReader that implements the following interface will be provided: -
public interface ValidatingXmlReader {
/**
* Identify if the next element is the element specified by 'name'
*
* @param name - the name to compare with the name of the next element.
* @param optional - is the next element optional.
* @throws UnexpectedAttributeException - if there are still attributes that have not been read.
* @throws UnexpectedElementException - if optional is false and the next
* element does not match the name supplied.
* @throws UnexpectedContent - if the wrapping element had content that has not been read.
* @throws MissingElementException - if optional is false and the end element is encountered.
*
* @return true if the name of the next element matches the name supplied, otherwise false.
*/
boolean nextElement(String name, boolean optional);
/**
* Return the content of the element.
*
* @param optional is content optional on the current element.
* @throws UnexpectedAttributeException - if there are still attributes that have not been read.
*
* @return the content of the element or null if it is optional and not specified.
*/
String readElementContent(boolean optional);
/**
* Return the value of the specified attribute.
*
* @param name - the name of the attribute to read.
* @param optional - is this an optional attribute?
* @throws MissingAttributeException - if the element is not optional and it is not specified.
* @return the value of the attribute or null if it is optional and not specified.
*/
String readAttribute(String name, boolean optional);
/**
* Verifies that an end element has been reached.
*
* @throws UnexpectedAttributeException - if there are still attributes that have not been read.
* @throws UnexpectedElementException - if optional is false and the next
* element does not match the name supplied.
* @throws UnexpectedContent - if the element had content that has not been read.
*/
void endElement();
}
The following (modified) complex type definition is for the host element in the host.xml configuration file: -
<xs:element name='host'>
<xs:complexType>
<xs:sequence>
<xs:element name='system-properties' type='properties-with-boottime' minOccurs='0'/>
<xs:element name='paths' type='specified-pathsType' minOccurs='0' maxOccurs='1' />
<xs:element name='management' type='managementType' minOccurs='0' maxOccurs='1'/>
<xs:element name='domain-controller' type='domain-controllerType'/>
<xs:element name='interfaces' type='specified-interfacesType' minOccurs='0' maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='name' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
Using the new wrapper to read an XML document containing this type would be as: -
private void readHostElement(final ValidatingXmlReader reader, final ModelNode address, final List list) {
String name = reader.readAttribute("name", true);
if (reader.nextElement("system-properties", true)) {
readSystemProperties(reader, address, list);
}
if (reader.nextElement("paths", true)) {
readPaths(reader, address, list);
}
if (reader.nextElement("management", true)) {
readManagement(reader, address, list);
}
if (reader.nextElement("domain-controller", false)) {
readDomainController(reader, address, list);
}
while (reader.nextElement("interfaces", true)) {
readInterfaces(reader, address, list);
}
reader.endElement();
}
So the call structure still follows the same structure we are already using, the main difference is that apart from the call to end element to signify that we have reached the end there is now no element / attribute checking or error handling - the wrapper handles all of that now by keeping up with the calls from the parser.
Here are a few possible errors that could have been reported here: -
* If an additional attribute was provided an exception would have been thrown from the call to nextElement for "system-properties"
* If an additional "paths" element was supplied an exception would have been called from the call to nextElement for "domain-controller"
* If the "domain-controller" element was missing the call to nextElement for "domain-controller" would thrown an exception.
* If an additional "domain-controler" element was provided the call to endElement would throw an exception.
h2. Testsuite
+*Note:* The testsuite enhancement introduces schema validation, this is an overhead however it only applies during specific tests - everything else will just be using the wrapper with no notion of the underlying schema.+
As the change requires the parsers to specify the elements and attributes expected and identify if the requested items are optional when running within the testsuite it would also be potentially possible to verify those calls against the schema definition, this would allow the following scenarios to be detected within the testsuite: -
* Missed calls for seldom used optional elements / attributes.
* Calls for elements / attributes not specified in the schema.
* Missed calls for subsequent instances of elements where more than one can be supplied.
* Calls for additional instances of elements beyond the limits specified in the schema.
For testing within the testsuite the first pre-requisit to resolve will be obtaining a representation of the schema at least to the point of fully modelling the structure of the schema.
For test cases the idea would be to perform the validated testing in issolation within the testsuite, the test would be to load configuration (or configuration extracts for subsystems) that uses all of the possible XML structure - the resulting operations will not be executed against a server so the test is just that the entire schema is supported and results in ModelNode operations.
Similar to code coverage tools the validating wrapper can monitor how much of the schema is actually visited during testing, a report could be generated of areas not visited and even a pre-determined threshold set for how much of schema to cover automatically failing the test if the threshold is not met - this could provide a smoke test that automatically fails if a new XML element is added but not visited during testing.
h4. Limitations
There are a couple of limitations in testing: -
* Where there is an XML choice in a schema multiple XML representations will be needed to ensure all choices are tested.
* Where an element is unbounded the wrapper can validate that there was at lease one optional call for the element after the last instance encountered, however it can not validate how long the parser would keep looping for true unbounded.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-17243]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
14 years
