Hi Bernard,
On 09.02.2010 11:54, Bernard Butler wrote:
Hi,
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
specification.
I believe my problem was caused by a rogue original
castorbuilder.properties on the class path, which masked the
castorbuilder.properties 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.
For those users not (completely) acquainted with the problem at hand, I
am just repeating the properties required to get this going:
org.exolab.castor.builder.javaclassmapping=type
org.exolab.castor.builder.automaticConflictResolution=true
What surprises me, though, is that you seem to have found the solution
through the mailing list archives. Afair, there's a detailed chapter on
this very subject in the reference guide at
http://www.castor.org/reference/html/xml.code.generator.html#d0e5140, and
http://www.castor.org/reference/html/xml.code.generator.html#d0e5239
If you happen to think that it still needs more (and more precise)
documentation, please let us know, and supply us with one or more patches.
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.
I am still curious to know what you have on your mind in this context.
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) {
return;
}
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.
Well, feel free to raise a few feature requests ovr at Jira. And even
better, attach a few patches that showcase what you have on your mind.
Regards,
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
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
