On 10.02.2010 12:06, Bernard Butler wrote:
Hi Werner,
Thanks for your reply and advice.
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.
That is a good point. I read the documentation but failed to see the link
between a name clash and the problem at hand. In retrospect, I can guess
what happened and I've certainly learnt more about XML schema documents as
a result. Perhaps what is missing is more contextual information. There
are (at least) four possibilities as I see it
1) for each property setting, explain why you should choose each
alternative, relating this to xsd concepts and fragments. For example:
Use org.exolab.castor.builder.javaclassmapping=type when ...
and
org.exolab.castor.builder.javaclassmapping=element when ...
Indeed, it might be possible to define "profiles" of XML schema documents,
with linked property settings per profile, because some properties depend
on others.
2) Provide a checklist of xsd features that are not compatible with the
default property settings, with recommendations for alternative settings
if that feature is found in the xsd.
3) Automate (some of) this by performing a preliminary pass over the xsd
and infer suitable property settings *for that xsd input*, overriding the
default settings. The revised settings should be saved in a properties
file, so that the user can inspect them and, if necessary, override them
in a later invocation of the castor code generator.
4) castor provides good logging output (at Debug level) and the exception
messages are also informative. Perhaps a troubleshooting table could be
provided in the documentation providing the problem context for common
exception messages and suggesting various solutions.
I can definitely see where you are coming from, and I am more than happy
to have these points reflected in the reference guide. As such, as
already stated, please feel free to create (a) Jira issue(s) and attach
at least a patch that highlights your intentions and identifies the
locations where you think things should/could be improved. I am more
than happy to take things from there (with your help).
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.
When unmarshalling from an XML instance, the standard practice (in castor
and similar frameworks) is to cast the unmarshaller output to the
appropriate type (Java class) and store the result in an object that is an
instance of that class. This works OK when that Java class is known at
compile time. However, that is not always the case - there are XML schema
documents specifying XML instances where the main node can be one of
several different XML elements. For instance, according to the XACML 2.0
policy XSD, the main element can be either a single Policy element, or a
PolicySet containing multiple Policy elements.
I will have to investigate this a bit more (as I am not 100% sure about
the answer), but I think that this requirement can be dropped when
working with Java classes (and descriptors) generated from an XMl
schema. As already said, not 100% sure here.
As a workaround, I have Java code that inspects the XML instance file to
determine the element type and then an if statement that unmarshals to an
object with the correct type. However, this results in a lot of
duplicated/ugly Java code in my application outside the XML data binding
component.
There are OO design patterns that allow you to delay instantiating a class
at run-time until you know which variant of a class you need. However, to
use patterns such as Factory method, I believe I would need to edit the
generated classes, and that is not attractive.
Well, if the changes could be make an integral part of the code
generation, I cannot see why this should be a problem.
While this is probably not a problem in castor itself, more in how it can
be used efficiently, I was just wondering whether any castor users had met
this problem before and had advice on a solution.
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.
I will look into doing just that....
Thank you,
Bernard
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
---------------------------------------------------------------------
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
