Java Mailing List Archive

Home » user.castor »

Re: [castor-user] [xml] Validation errors uploading XACML2.0
  conformance test xml    instances

Bernard Butler


Replies: Find Java Web Hosting

Author LoginPost Reply

I am pleased to report that the main issue below has been resolved.

That is, castor 1.3.1, with appropriate property settings, *does* handle
XML substitution groups correctly, as found in the XACML 2.0 policy

I believe my problem was caused by a rogue original on the class path, which masked the that I had edited and intended for castor's code
generator to use.

The good news, for those wishing to generate Java classes to manipulate
XACML 2.0 policies, is that castor 1.3.1, with the property settings in
the message below, can generate those classes.

This is a credit to castor, because XACML 2.0's policy specification is
far from trivial.

The other issues remain but are minor
1) the unmarshaller needs to unmarshal to a concrete class. There are
creational patterns that might be more flexible here, but from what I see,
they would require edits to the generated classes. The workaround I use
is to inspect the XML file before calling the Unmarshaller with the
appropriate generated result class.

2) the generate-mapping command line option does not generate anything,
because the org.exolab.castor.builder.SourceGenerator.generateMappingFile
method contains the following code fragment:
    MappingRoot mapping = sInfo.getMapping(pkg);
    if (mapping == null) {
Unfortunately, the mapping object is null and so the remainder of that
method is not done. Better control over castor's mapping decisions would
be "nice to have" for now, but is not essential.

Bernard Butler

> 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
> 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, 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
> OASIS XACML2.0 conformance tests: Available from
> 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:

To unsubscribe from this list, please visit:

©2008 - Jax Systems, LLC, U.S.A.