Hi,
I used castor-1.3.1 to generate Java classes from the XACML 2.0 xsd, and
then attempted to load the published XACML 2.0 conformance test Policy xml
instances into Java objects that are instances of the generated classes.
Apart from one example (II004Policy.xml) which has a deliberate syntax
error, the remaining 387 cases are valid XML (tested with xmllint).
Of the 387 valid xml files, 72 loaded OK. Each of the remaining 315 cases
had one of two validation problems.
Problem 1: Validation failed because of missing abstract element in xml
instances
---------------------------------------------------------------------------------
The most common problem was reported like:
While validating field: _condition of class: policy.Rule: The field
'_expression' (whose xml name is 'Expression') is a required field of
class 'policy.Condition'
The difficulty is that Expression does not appear in any of the Rule
elements of the problematic xml files, yet is treated as mandatory by the
castor xml parser. Note that the Expression element is abstract - see the
following fragment of the XACML 2.0 policy XSD:
<xs:element name="Expression" type="xacml:ExpressionType"
abstract="true"/>
<xs:complexType name="ExpressionType" abstract="true"/>
and is used to define other elements of the substitutionGroup. For example:
<xs:element name="VariableReference" type="xacml:VariableReferenceType"
substitutionGroup="xacml:Expression"/>
<xs:complexType name="VariableReferenceType">
<xs:complexContent>
<xs:extension base="xacml:ExpressionType">
<xs:attribute name="VariableId"
type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
I would expect Expression to map to an abstract class in Java, to be
extended by concrete classes in that substitution group like
VariableReference, etc.
I found some archived email correspondence relating to substitution groups
saying that they should be supported, with some changes to the
castorbuilder.properties file.
Problem 2: XACML main element can be either Policy or PolicySet element
-----------------------------------------------------------------------
The XACML 2.0 specification allows either a Policy or PolicySet element to
be the main element in a valid xml instance. Typically, a PolicySet
element is a container for Policy elements. The complication is that you
may need kludgy code like
policySet = (policy.PolicySet)
Unmarshaller.unmarshal(policy.PolicySet.class, reader); // for xml files
containing PolicySet elements
// or
policy = (policy.Policy) Unmarshaller.unmarshal(policy.Policy.class,
reader); // for xml files NOT containing PolicySet elements
possibly by applying grep to the file to determine whether it contains a
PolicySet element or not.
Is there a castor-XML pattern/better workaround for this?
More generally, I wish to understand the class model for the generated
Java classes. I notice that the descriptor classes generally contain the
attributes; the plain classes, such as Policy.java, contain more of the
scaffolding code, such as marshalling methods. Obviously, the main driver
for the class model is the xsd specification, but it would be useful to be
able to "read" the generated classes better. Do you have user-level
documents to assist with understanding the generated class models?
** Also see the comment below about generating mapping files **
Configuration
-------------
O/S: Ubuntu 9.10. JVM: Sun JavaSE 1.6.0_16-b01. Castor version: 1.3.1
(binary jars and compiled from source (where I could find the source -
easier for debugging in eclipse 3.5))
No binding/mapping file is used. Introspection mode is used to upload xml
instances.
A typical command line used to generate the Java classes is
java -cp $castorCP $castorMainProgram -i $xacmlPolicySchema -package
policy -dest ~/tools/xacmlGenerated -gen-mapping
~/tools/xacmlGenerated/polMapping -generateImportedSchemas
** Even though I ask for a mapping file - to see what Castor XML is doing
- the file is never created. **
I generally use the default settings of castor properties. However, the
following non-defaults are used
org.exolab.castor.builder.javaclassmapping=type # this was mentioned in an
archived email - needed to support substitutionGroups
org.exolab.castor.builder.automaticConflictResolution=true # this was
mentioned in an archived email - needed to support substitutionGroups
org.exolab.castor.builder.javaVersion=5.0 # annotations might ease
understanding; better fit with my JVM
org.exolab.castor.builder.extraCollectionMethods=true # preparing for
castor JDO :-)
org.exolab.castor.regexp=org.exolab.castor.util.JakartaOroEvaluator #
essential: match conditions in XML files are implemented by regexes
org.exolab.castor.parser.namespaces=true # should make generated XML
easier to read for debugging, etc.
org.exolab.castor.indent=true # should make generated XML easier to read
for debugging, etc.
External resources are:
OASIS XACML2.0 xsd: Available from
http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-policy-schema-os.xsd
OASIS XACML2.0 conformance tests: Available from
http://www.oasis-open.org/committees/download.php/14846/xacml2.0-ct-v.0.4.zip
containing:
IIA001Policy.xml validates/uploads OK (policy-based; no condition
element/substitution group)
IIA008Policy.xml does not validate/upload OK (policy-based; has condition
element/substitution group)
IID005Policy.xml does not validate/upload OK (policySet-based; has
condition element/substitution group)
Any help would be greatly appreciated,
Bernard Butler
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
