I'm attempting a migration from int-http:inbound-gateway version MVC to int-webflux:inbound-gateway version webflux. I'm stuck on the equivalent of the attribute message-converters in the MVC version for webflux. I have converters that are invoked in the MVC side for the return body from the inbound-gateway. Is there no body conversion for inbound-gateway in webflux?
The codec-configurer is some level of equivalent:
<xsd:attribute name="codec-configurer" type="xsd:string">
<xsd:annotation>
<xsd:appinfo>
<tool:annotation kind="ref">
<tool:expected-type type="org.springframework.http.codec.ServerCodecConfigurer"/>
</tool:annotation>
</xsd:appinfo>
<xsd:documentation>
A 'ServerCodecConfigurer' for the request readers and response writers.
By default the 'ServerCodecConfigurer#create()' factory is used.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
The WebFlux does not use a HttpMessageConverter abstraction, rather it uses an HttpMessageReader and HttpMessageWriter pairs.
See more in docs: https://docs.spring.io/spring-integration/docs/current/reference/html/webflux.html#webflux-inbound
You can configure the WebFluxInboundEndpoint with a custom ServerCodecConfigurer, a RequestedContentTypeResolver, and even a ReactiveAdapterRegistry.
Related
i have XML structure as below (just part of large XML)
<Person>
<firstName>
<lastName>
<Partner>
<firstName>
...
</Person>
i need to keep additional metadata with each field for example to indicate if its updatable or not
i c two approaches
1) add the metadata at each FIELD level. i feel this overly complicates the XSD as each element is now an OBJECT
<Person>
<firstName updatable="true" ... />
...
</Person>
2) separate out the metadata as below
BUt how do i link the metadata to the data? via a uniquie name? can someone consuming the XML easily link it?
Is there a better way? Thanks!
<data>
<Person>one
<firstName>
<lastName>
<Partner>
<firstName>
...
</Person>
<Person>two
<firstName>
<lastName>
<Partner>
<firstName>
...
</Person>
</data>
<metadata>
<field name="firstName" updateble="false"/>
....
</metadata>
i think this is similar to
Add metadata to an XSD definition
but it does not have any answer
My (maybe rhetoric) question would be why would someone want to see this metadata with each XML if it is static in relationship to the model?
I'll show you a UBL XSD snippet (XML namespaces elided as irrelevant):
<xsd:element ref="cbc:UBLVersionID" minOccurs="0" maxOccurs="1">
<xsd:annotation>
<xsd:documentation>
<ccts:Component>
<ccts:ComponentType>BBIE</ccts:ComponentType>
<ccts:DictionaryEntryName>Application Response. UBL Version Identifier. Identifier</ccts:DictionaryEntryName>
<ccts:Definition>The earliest version of the UBL 2 schema for this document type that defines all of the elements that might be encountered in the current instance.</ccts:Definition>
<ccts:Cardinality>0..1</ccts:Cardinality>
<ccts:ObjectClass>Application Response</ccts:ObjectClass>
<ccts:PropertyTerm>UBL Version Identifier</ccts:PropertyTerm>
<ccts:RepresentationTerm>Identifier</ccts:RepresentationTerm>
<ccts:DataType>Identifier. Type</ccts:DataType>
<ccts:Examples>2.0.5</ccts:Examples>
</ccts:Component>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
You could see here that there's a lot of structured data which could easily pass as something related to your question. Fundamentally though, this is a mechanism that uses the XSD annotations mechanism, to achieve things in relationship to the XSD. Another one is that used by JAXB custom binding mechanism:
<xsd:simpleType name="ZipCodeType">
<xsd:annotation>
<xsd:appinfo>
<jxb:javaType name="int" parseMethod="javax.xml.bind.DatatypeConverter.parseInt" printMethod="javax.xml.bind.DatatypeConverter.printInt"/>
</xsd:appinfo>
</xsd:annotation>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="10000"/>
<xsd:maxInclusive value="99999"/>
</xsd:restriction>
</xsd:simpleType>
While this is different than the UBL example, (documentation vs. appinfo), both are using the XSD annotation mechanism.
JAXB's custom bindings also supports a model where the custom bindings are separate from the XSD (in their own separate XML file). The correlation between the custom binding file (the metadata in your case) and the XSD (the XML in your case) is done through XPath matches.
This brings about another clarification: what is the processing model you have in mind? Dynamic (i.e. the metamodel is static, but can be applied to arbitrary XSDs)? Platform? Below is a solution that could work for what you need, in a dynamic fashion, if it happens to match your platform.
.NET:
Build an XSD the way I've referred to above (i.e. annotations of some sort).
At runtime, validate your XML against this XSD. Each node will then have the SchemaInfo property filled in. Using classes in System.Xml.Schema you could easily process the SchemaElement or SchemaAttribute in your SchemaInfo property as an XmlSchemaAnnotated class, which is what both are.
The above is basically PSVI applied to your XML. The same exists for Java (on this Xerces page search for How do I retrieve PSVI from the DOM?)...
I could picture solutions for XSLT as well, or not involving XSD at all... the above though should be sufficient to get you started.
I'm trying to convert an XSD I have no control over to Java classes using JAXB. The errors I'm getting are :
[ERROR] cvc-pattern-valid: Value 'true' is not facet-valid with respect to pattern '0|1' for type 'BooleanType'.
line 139 of http://neon/meaweb/schema/common/meta/MXMeta.xsd
[ERROR] a-props-correct.2: Invalid value constraint value '1' in attribute 'mxencrypted'.
line 139 of http://neon/meaweb/schema/common/meta/MXMeta.xsd
The code in the XSD that contains the error is in:
<xsd:complexType name="MXCryptoType">
<xsd:simpleContent>
<xsd:extension base="xsd:base64Binary">
<xsd:attribute name="changed" type="ChangeIndicatorType" use="optional" />
<xsd:attribute name="mxencrypted" type="BooleanType" use="optional" default="1" />
</xsd:extension>
</xsd:simpleContent>
Specifically it's the attribute mxencrypted using the BooleanType. BooleanType is defined as
<xsd:simpleType name="BooleanType">
<xsd:restriction base="xsd:boolean">
<xsd:pattern value="0|1" />
</xsd:restriction>
</xsd:simpleType>
From searching around this seems to be a somewhat common case. From what I can tell the default in the mxencrypted line shouldn't be a 1? When I load the XSD into Liquid XML, the schema doesn't report errors. Validating the XSD here (http://www.utilities-online.info/xsdvalidation/#.UV3zkL_EW0s) reports the same errors as JAXB.
Is there a way to tell JAXB to ignore this problem and just generate the class ignoring the default?
Your question is similar to this one (and I've just updated it with relevant information). I am not aware of a way to tell JAXB to ignore it, since this error happens in the XSD schema processor (before JAXB's xjc starts to do its work actually).
The only way may be to filter out the default attributes; however, in this case it is obvious that the XSD designer intended to have a default value of true, which would not be the case with your generated code (Java defaults to false).
This could yield unwanted fracas, my recommendation would be to work with the XSD provider to get it fixed.
Maybe a sidebar, but I personally consider the use of defaults in XSDs as an interoperability monster : any XML processor that is not relying on the XSD would behave differently than one that does.
SDL Tridion uses XML schema definitions to define content stored in Tridion components. XSD can use restrictions/facets or indicators to restrict what's valid for XML nodes.
Chris Summers found some of these accidentally in training, specifically that we can set minOccurs and maxOccurs indicators in SDL Tridion 2011 as in:
<xsd:element name="someField" minOccurs="2" maxOccurs="5" type="xsd:normalizedString">
Andrey Marchuk mentions additional options in the same post:
Indicators
MaxValue
MinValue
Restrictions
FractionDigits
MaxLength
MinLength
Pattern
TotalDigits
Btw, are these XSD-specific?
IsMaxValueExclusive
IsMinValueExclusive
How would I get the *restrictions into the following sample Tridion schema (source)?*
<xsd:schema xmlns="http://createandbreak.net/schema/example" xmlns:tcmi="http://www.tridion.com/ContentManager/5.0/Instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://createandbreak.net/schema/example">
<xsd:import namespace="http://www.tridion.com/ContentManager/5.0/Instance"></xsd:import>
<xsd:annotation>
<xsd:appinfo>
<tcm:Labels xmlns:tcm="http://www.tridion.com/ContentManager/5.0">
<tcm:Label ElementName="someField" Metadata="false">someField</tcm:Label>
</tcm:Labels>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="Content">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="someField" minOccurs="2" maxOccurs="5" type="xsd:normalizedString">
<xsd:annotation>
<xsd:appinfo>
<tcm:ExtensionXml xmlns:tcm="http://www.tridion.com/ContentManager/5.0"></tcm:ExtensionXml>
</xsd:appinfo>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
To take an example from W3Schools, this would be a non-Tridion XSD restricting a field to 5 digits using a regular expression:
<xs:element name="prodid">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:pattern value="[0-9][0-9][0-9][0-9][0-9]"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
I tried changing the xs namespace to xsd but I'm not sure where XSD restrictions would go in the (Tridion) schema.
I believe the XS and XSD is somewhat irrelevant here. Both are actually namespace prefixes which refer to the same namespace. This is described in this post.
If you look at a sample from the site you quoted (http://www.w3schools.com/schema/default.asp) you will see that the xs namespace prefix refers to http://www.w3.org/2001/XMLSchema which is the same as xsd in the Tridion schema.
E.g.
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
therefore xsd is the same as xs.
Or am I completely missing your point?
If you are just looking on how to apply restrictions, this comes from the SDL Tridion docs (here but requires password):
<xsd:element name="NumberFieldWithMultipleFacets">
<xsd:simpleType>
<xsd:restriction base="xsd:decimal">
<xsd:totalDigits value="4"/>
<xsd:fractionDigits value="2"/>
<xsd:minInclusive value="10"/>
<xsd:maxInclusive value="20"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>
If you are looking for a list of the possible facets in Xml Schema, then you need to look here. Perhaps then it's a simple matter to check which of these are respected/supported by Tridion
I still miss xsd:ID for example, works in WebForms (yes, from version 1.0), but not in the latest SDL Tridion GUI (except 2013, not tested).
I would like all valid xsd's to work in the Tridion GUI.
And for example, that content editors will see a counter when you limit a text field to be min="30" max="70" characters.
Would be a very nice GUI update.
Because it would make WebForms possible in the normal(!) Tridion GUI.
Creating new fields will then be possible by content management.
Creating new HTML5 webforms (tested!) takes then less then 2 minutes.
So please update the GUI to full xsd support.
Hi all i am an XML Schema where i have the following
<xsd:element name="Check" type="CheckboxType">
<xsd:annotation>
<xsd:documentation>
<Description>Check</Description>
<LineNumber>12</LineNumber>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
While assigning the value or inner text for this field it is taking only X. What's the other value that i can pass other than X. I think X is assigned when i checked a check box, but what's the other value that i can assign to that Node when check box was not checked
There are multiple ways to specify an absence of a value. Below two are two generic ways.
Option 1
Do not add the element in the XML instance. If this is the right option or not is dependent upon the context and hard to tell without knowing more information
Option 2
Use xsi:nil="true" attribute in the XML instance. You can read more about the usage on zvon.org. To use this change your element definition as below
<xsd:element name="Check" type="CheckboxType" nillable="true">
<xsd:annotation>
<xsd:documentation>
<Description>Check</Description>
<LineNumber>12</LineNumber>
</xsd:documentation>
</xsd:annotation>
</xsd:element>
You can then have the XML instance as below
<Check xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" />
Lets say I have one schema that defines a complex type named "MyType" in the namespace "general"
Then in another schema, that complex type is used.
For instance:
<xsd:schema targetNamespace="http://www.example.com/otherschema"
xmlns:general="http://www.example.com/genschema">
<xsd:import namespace="http://www.example.com/genschema" schemaLocation="general.xsd" />
<xsd:element ref="general:Mytype" />
<xsd:element name="myName" type="general:MyType" />
Should the namespace on the XML element in the XML document that conforms to this schema use the targetNamespace of otherschema or genschema.
<general:MyType />
or
<targetNamespacePrefix:Mytype />
I am asking this question because I used Axis2 to generate the java code to interact with a web service. The Axis2 code has checks against the namespace and in the example above it would check that the namespace was the general one and throw an exception if it wasn't. Of course the web service response xml used the targetNamespace instead of the general namespace so it breaks every time. I have much more faith in the Axis2 developers than the developers of the web service, but I want to make sure I am write before filing a bug report.
Your use of MyType in the "other" schema is correct: declare the namespace, use import and use the declared prefix (general).
<xsd:schema targetNamespace="http://www.example.com/otherschema"
xmlns:general="http://www.example.com/genschema">
<xsd:import namespace="http://www.example.com/genschema" schemaLocation="general.xsd" />
<xsd:element name="myName" type="general:MyType" />
</xsd>
Notice that I made your http://... items explicit to be clear which ones are typically different in the situation you describe.
If you're asking about the schema where MyType is defined, use an unprefixed name for the definition in that schema:
<xsd:schema targetNamespace="http://www.example.com/genschema"
<xsd:complexType name="MyType"> ... </xsd:complexType>
</xsd:schema>
Update based on your edit:
In the XML instance document, use of myName would have a namespace of the "otherschema" which is targetNamespace above. Use of MyType would use the "genschema" namespace.
I removed the <xsd:element ref="general:MyType"/> which only makes sense if MyType is a element (not a type) and if it's inside a type definition. Suppose "otherschema" contains:
<xsd:complexType name="otherType>
...
<xsd:element ref="general:MyElement"/>
</xsd:complexType>
In that case, MyElement would still use the "genschema" namespace in the XML instance document.
Bottom line: importing items does not change their namespace. Including them, however, does change the namespace (that is, using <xsd:include>.