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. >> >> 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. 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. 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
