I'm getting this error when I run "mvn clean install"
Thrown by JAXB:
[ERROR] Thrown by JAXB: 'ArrayOfstring' is already defined
[ERROR]
[ERROR] Thrown by JAXB: (related to above error) the first definition appears here
[ERROR]
[ERROR] Thrown by JAXB: 'ArrayOfstring' is already defined
ArrayOfString appears multiple times in multiple XSD files using the same namespace.
wsdl0:
<xsd:schema elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
<xsd:complexType name="ArrayOfstring">
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="unbounded" name="string" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="ArrayOfstring" nillable="true" type="tns:ArrayOfstring"/>
</xsd:schema>
wsdl1:
<xsd:schema elementFormDefault="qualified" targetNamespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays">
<xsd:complexType name="ArrayOfstring">
<xsd:sequence>
<xsd:element minOccurs="0" maxOccurs="unbounded" name="string" nillable="true" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element name="ArrayOfstring" nillable="true" type="tns:ArrayOfstring"/>
</xsd:schema>
</wsdl:types>
How would I resolve this? I'm assuming I would have to use an external bindings file...Thanks!
Sam
I would generate for each wsdl the classes in a different package and then you will not have any clashes. This can be achieved using binding files:
https://github.com/highsource/maven-jaxb2-plugin/wiki/Configure-Target-Packages-in-Binding-Files as you assumed.
Related
I'm using the AzureBlobStorage adapter in BizTalk 2020 and to receive blobs from Azure Blob Storage. The blobs have metadata which I want to use within my orchestration. So I created and deployed a schema containing the metadata keys as elements.
Within the receive location I entered the "Namespace for blob metadata" with the namespace of my schema and checked the checkbox "Promote metadata properties"
Unfortunately I'm getting the following error: "Loading property information by list by namespace failed or property not found in the list. Verify that the schema is deployed properly."
Schema:
<?xml version="1.0" encoding="utf-16"?>
<xs:schema xmlns="http://POC.Test.AzBlobMetadata.AzLaParameters" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://POC.Test.AzBlobMetadata.AzLaParameters" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:annotation>
<xs:appinfo>
<b:schemaInfo schema_type="AzLaParameters" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" />
</xs:appinfo>
</xs:annotation>
<xs:element name="MetaData">
<xs:complexType>
<xs:sequence>
<xs:element name="la_name" type="xs:string" />
<xs:element name="la_runid" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Receive Location / Adapter configuration:
I am creating a soap service by consuming one wsdl and multiple xsd files. The xsd files are included in my wsdl. I have tried with jaxws and cxf plugins using maven. Both the plugins are throwing error/exception while parsing the wsdl.
below is the error from jaxws:
[ERROR] Invalid wsdl:operation "insertSubscriber": its a document-literal operation, message part must refer to a schema element declaration
CXF dies without throwing any error description.
The jxc framework creates the classes from xsd files but they are of no use because I have to create endpoints manually and the linking of the classes is already defined in my wsdl.
I have also C++ gsoap client which uses the same wsdl and xsds using which I can create my soap service, But I want to migrate my service to a java application. How do I fix the above problem?
wsdl snippet:
<wsdl:import namespace="MyDomain/mytypes" location="MyTypes1.xsd"/>
<xsd:complexType name="insertSubscriberRequest">
<xsd:sequence>
<xsd:element name="insertAddressList" type="mytypes:InsertAddressList"/>
</xsd:sequence>
</xsd:complexType>
<wsdl:message name="insertSubscriberRequest">
<wsdl:part name="insertSubscriberRequest" type="tns:insertSubscriberRequest"/>
</wsdl:message>
<!--wsdl operation-->
<wsdl:portType name="myService">
<wsdl:operation name="insertSubscriber">
<wsdl:input message="tns:insertSubscriberRequest"/>
<wsdl:output message="tns:insertSubscriberResponse"/>
</wsdl:operation>
</wsdl:portType>
<!--soap operation-->
<wsdl:operation name="insertSubscriber">
<soap:operation soapAction="MyDomain/mytypes/insertSubscriber"/>
<wsdl:input>
<soap:body use="literal" namespace="MyDomain/mytypes"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal" namespace="MyDomain/mytypes"/>
</wsdl:output>
</wsdl:operation>
snippet from MyTypes1.xsd:
<xs:complexType name="InsertAddressList">
<xs:annotation>
<xs:documentation>Definition of a list of Account IDs for Insert operation</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="accountId" type="MyType2:sdsAccountId" minOccurs="10" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
snippet from MyTypes2.xsd
<xs:simpleType name="sdsAccountId">
<xs:annotation>
<xs:documentation>Definition of Account ID parameter</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:minLength value="1"/>
<xs:maxLength value="26"/>
<xs:pattern value="([0..9]){1,26}"/>
</xs:restriction>
</xs:simpleType>
I verified the WSDL file and there was an import error. Actually, It was importing the xsds two times once in the wsdl:definitions and once in the xsd:schema. removing the import from the wsdl:definitions worked for me,
With wsimport I am facing the same issue, but it is working with cxf.
I am trying to deploy a shared library in IIB v10 toolkit integration server which has 1 WSDL created through New->Message Model -> using existing WSDL. It internally imported referencing schema files.B ut while trying to deploy Shared lib project into integration server in toolkit, it's failing with below error:
BIP4395E: Java exception: 'com.ibm.xml.xlxp.compiler.CompilerError';
thrown from class name: 'com.ibm.broker.schemamgr.MbXLXPCompiler',
method name: 'compileSchemas', file: 'MbXLXPCompiler.java', line: '211'
Is it a problem with relative path in wsdl referencing XSD schema files?
<xsd:import namespace="http://test.com/ebo/Basic" schemaLocation="../../mds/ebo/Bsc.xsd"/>
<xsd:import namespace="http://test.com/ebo/header" schemaLocation="../../mds/ebo/header.xsd"/>
<xsd:import namespace="http://test.com/ebo/cpr" schemaLocation="../../mds/ebo/cpr.xsd"/>
Could anyone you please suggest any solution?
Complete error details:
Begin running task [Deploying [TEST1SHARED] to integration server [DEVSERVER]]
BIP2087E: Integration node 'TESTNODE_USER' was unable to process the internal configuration message.
The entire internal configuration message failed to be processed successfully.
Use the messages following this message to determine the reasons for the failure. If the problem cannot be resolved after reviewing these messages, contact your IBM Support center. Enabling service trace may help determine the cause of the failure.
BIP4041E: Integration server 'DEVSERVER' received an administration request that encountered an exception.
While attempting to process an administration request, an exception was encountered. No updates have been made to the configuration of the integration server.
Review related error messages to determine why the administration request failed.
BIP5049E: A failure occurred when the integration server was preparing XML and DFDL schema files for use as part of the deployment of a library.
A failure occurred when the integration server was preparing XML and DFDL schema files for use as part of the deployment of a library. The deployment of the library has failed, and the deployment will be rolled back.
Review previous messages to find out why the error occurred. Be aware that DFDL schema files must also be valid XML Schema files, and that all DFDL schema files are prepared for use by the XMLNSC domain before being prepared for use by the DFDL domain.
BIP4395E: Java exception: 'com.ibm.xml.xlxp.compiler.CompilerError'; thrown from class name: 'com.ibm.broker.schemamgr.MbXLXPCompiler', method name: 'compileSchemas', file: 'MbXLXPCompiler.java', line: '211'
The message contains that data associated with a Java exception.
No user action required.
The task was unsuccessful: The deployment was unsuccessful. Check error messages above for explanation.
Below are my files:
1)Plant_1.0.wsdl
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
name="Plant" targetNamespace="http://test.com/ivs/Plant"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://test.com/ivs/Plant"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<wsdl:documentation>
Version 1.0
<wsdl:appinfo source="WMQI_APPINFO">
<MRWSDLAppInfo imported="true">
<binding hasEncoding="false" imported="true"
name="Plant.Binding"
originalBindingStyle="document" />
</MRWSDLAppInfo>
</wsdl:appinfo>
</wsdl:documentation>
<wsdl:types>
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<import namespace="http://test.com/ivs/Plant"
schemaLocation="Plant_1.0_wsdl.xsd" />
</schema>
</wsdl:types>
<wsdl:message name="getData">
<wsdl:part element="tns:getData" name="payload" />
</wsdl:message>
<wsdl:message name="getDataResponse">
<wsdl:part element="tns:getDataResponse" name="payload" />
</wsdl:message>
<wsdl:portType name="Plant">
<wsdl:operation name="getData">
<wsdl:input message="tns:getData" />
<wsdl:output message="tns:getDataResponse" />
</wsdl:operation>
</wsdl:portType>
<wsdl:binding name="Plant.Binding" type="tns:Plant">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />
<wsdl:operation name="getData">
<soap:operation soapAction="getData" style="document" />
<wsdl:input>
<soap:body use="literal" />
</wsdl:input>
<wsdl:output>
<soap:body use="literal" />
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
</wsdl:definitions>
Plant_1.0_wsdl.xsd(auto generated xsd)
<?xml version="1.0" encoding="UTF-8"?><xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://test.com/ivs/Plant"
xmlns:tns="http://test.com/ivs/Plant">
<xsd:include schemaLocation="Plant_1.0.xsd"/>
</xsd:schema>
Plant_1.0.xsd:
<?xml version="1.0" encoding="UTF-8"?><xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" targetNamespace="http://test.com/ivs/Plant" version="1.0" xmlns="http://test.com/ivs/Plant" xmlns:ibmSchExtn="http://www.ibm.com/schema/extensions">
<xsd:element ibmSchExtn:docRoot="true" name="getData" type="GetDataType"/>
<xsd:element ibmSchExtn:docRoot="true" name="getDataResponse" type="GetDataResponseType"/>
<xsd:complexType name="GetDataType">
<xsd:sequence>
<xsd:element name="body">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="subDataType" type="xsd:string"/>
<xsd:element name="fromDateTime" type="xsd:dateTime"/>
<xsd:element name="toDateTime" type="xsd:dateTime"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<xsd:complexType name="GetDataResponseType">
<xsd:sequence>
<xsd:element name="body">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="result" type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
Thanks
IIB have a specific way to handle WSDL / XSD : usually, a WSDL contains a XSD, but IIB consider it should be in two different files (that's what it does when you import an existing WSDL, it split it into different files)
You can do what you are trying to achieve in a different way : your XSD import should be done in the .xsd generated while importing the WSDL, instead of being done in the .wsdl directly.
A small extract from one of my WSDL / XSD referencing another XSD :
XXX.wsdl :
[...]
<wsdl:types>
<xsd:schema
targetNamespace="http://toto.org/XXXX">
<xsd:include schemaLocation="XXXX_InlineSchema1.xsd" />
</xsd:schema>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import
namespace="http://toto.org/XXXX"
schemaLocation="XXXX_InlineSchema1.xsd">
</xsd:import>
</xsd:schema>
</wsdl:types>
[...]
XXXX_InlineSchema1.xsd :
[...]
<xsd:import namespace="http://test.com/ebo/Basic" schemaLocation="../../mds/ebo/Bsc.xsd"/>
<xsd:import namespace="http://test.com/ebo/header" schemaLocation="../../mds/ebo/header.xsd"/>
<xsd:import namespace="http://test.com/ebo/cpr" schemaLocation="../../mds/ebo/cpr.xsd"/>
[...]
This issue is best demonstrated by example. Consider the following:
In the first example, my <Permissions/> element is placed immediately after the <FormSettings/> block:
<?xml version="1.0" encoding="UTF-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0" xmlns:mailappor="http://schemas.microsoft.com/office/mailappversionoverrides/1.0" xsi:type="MailApp">
<Id>464672b2-35a8-44a1-8c06-3ad07ed893a7</Id>
<Version>1.0.0.0</Version>
<ProviderName>Example</ProviderName>
<DefaultLocale>en-US</DefaultLocale>
<DisplayName DefaultValue="Example A"/>
<Description DefaultValue="This is an example add-in."/>
<IconUrl DefaultValue="https://placehold.it/64x64"/>
<HighResolutionIconUrl DefaultValue="https://placehold.it/64x64"/>
<SupportUrl DefaultValue="https://example.com/"/>
<Hosts>
<Host Name="Mailbox"/>
</Hosts>
<Requirements>
<Sets>
<Set Name="MailBox" MinVersion="1.1"/>
</Sets>
</Requirements>
<FormSettings>
<Form xsi:type="ItemEdit">
<DesktopSettings>
<SourceLocation DefaultValue="https://example.com"/>
</DesktopSettings>
</Form>
</FormSettings>
<Permissions>ReadWriteMailbox</Permissions>
<Rule xsi:type="RuleCollection" Mode="And">
<Rule xsi:type="ItemIs" ItemType="Message" FormType="Edit"/>
</Rule>
</OfficeApp>
I am able to successfully add this manifest to my Exchange Admin Center's organization add-ins list.
However, if I move the <Permissions/> element anywhere else in the manifest, the manifest fails validation when attempting to add it:
<?xml version="1.0" encoding="UTF-8"?>
<OfficeApp xmlns="http://schemas.microsoft.com/office/appforoffice/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:bt="http://schemas.microsoft.com/office/officeappbasictypes/1.0" xmlns:mailappor="http://schemas.microsoft.com/office/mailappversionoverrides/1.0" xsi:type="MailApp">
<Id>464672b2-35a8-44a1-8c06-3ad07ed893a7</Id>
<Version>1.0.0.0</Version>
<ProviderName>Example</ProviderName>
<DefaultLocale>en-US</DefaultLocale>
<DisplayName DefaultValue="Example A"/>
<Description DefaultValue="This is an example add-in."/>
<IconUrl DefaultValue="https://placehold.it/64x64"/>
<HighResolutionIconUrl DefaultValue="https://placehold.it/64x64"/>
<SupportUrl DefaultValue="https://example.com/"/>
<Hosts>
<Host Name="Mailbox"/>
</Hosts>
<Requirements>
<Sets>
<Set Name="MailBox" MinVersion="1.1"/>
</Sets>
</Requirements>
<FormSettings>
<Form xsi:type="ItemEdit">
<DesktopSettings>
<SourceLocation DefaultValue="https://example.com"/>
</DesktopSettings>
</Form>
</FormSettings>
<Rule xsi:type="RuleCollection" Mode="And">
<Rule xsi:type="ItemIs" ItemType="Message" FormType="Edit"/>
</Rule>
<Permissions>ReadWriteMailbox</Permissions>
</OfficeApp>
Attempting to add this manifest to my Exchange Admin Center's organization add-ins list produces the following error:
This app can't be installed. The manifest file doesn't conform to the schema definition. The element 'OfficeApp' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1' has invalid child element 'Permissions' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1'. List of possible elements expected: 'DisableEntityHighlighting' in namespace 'http://schemas.microsoft.com/office/appforoffice/1.1' as well as 'VersionOverrides' in namespace 'http://schemas.microsoft.com/office/mailappversionoverrides' as well as any element in namespace 'http://www.w3.org/2000/09/xmldsig#'...
It is only through trial and error were we able to find the root cause of this validation failure.
My question: Why does ordering matter? Why can the <Permissions/> element not appear anywhere within the same nesting level in the manifest?
Context
This validation failure occurs in hosted Exchange (Office 365), and also when attempting to submit an add-in to the Office Store, at the step where a manifest is requested.
Why does ordering matter?
Order of the tags defined by schema file. In your case you have included in the manifest http://schemas.microsoft.com/office/appforoffice/1.1 Schema. Try to find in the schema <Permissions/> element and you will see the following definition ...
<xs:complexType name="MailApp">
<xs:complexContent>
<xs:extension base="OfficeApp">
<xs:sequence>
<xs:element name="Requirements" type="MailAppRequirements" minOccurs="1" maxOccurs="1"/>
<xs:element name="FormSettings" type="FormSettings" minOccurs="1" maxOccurs="1"/>
<xs:element name="Permissions" minOccurs="0" maxOccurs="1" type="ST_Permissions2"/>
<xs:element name="Rule" type="Rule" minOccurs="1" maxOccurs="1"/>
<xs:element name="DisableEntityHighlighting" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
<xs:element ref="mailor:VersionOverrides" minOccurs="0" maxOccurs="1"/>
<xs:any id="MailAppSignature" minOccurs="0" maxOccurs="1" namespace="http://www.w3.org/2000/09/xmldsig#" processContents="lax"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
Element <Permissions/> is in the <sequence/> which means it must be in order defined by this element and it's right after <FormSettings/> and nowhere elese.
Order of the tags defined by schema file. Unfortunately this is not well documented and we are working to improve this documentation. Order matters when defining a manifest for Outlook web add-ins because of the way we validate the schema for installation. We realize this can be a hassle especially since it's not well documented but the main reason we require a specific order is because it allows us to validate the manifest content quickly and increase performance of the service.
Thank you for providing this feedback on our documentation.
I have a problem with c# XDocument XSD validation.
The following file is validated well by Xml Spy, but not by .Net (c#)
<Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="Simple.xsd">
<Var Name="$Toto"/>
</Root>
Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="Var">
<xs:complexType>
<xs:attribute name="Name" type="ST_VariableIdentifier" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="ST_VariableIdentifier">
<xs:restriction base="xs:string">
<xs:pattern value="$[a-z,A-Z]*"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
An idea?
This should work!
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element name="Var">
<xs:complexType>
<xs:attribute name="Name" type="ST_VariableIdentifier" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="ST_VariableIdentifier">
<xs:restriction base="xs:string">
<xs:pattern value="[$][a-z,A-Z]*"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Just to add to the existing answer. This is actually a known 'bug' in the .Net implementation of the W3C specs (acknowledged here on Connect, but Won't fix).
MSDN provides more information (here), together with the workaround mentioned above.
The System.Xml implementation of the World Wide Web Consortium (W3C)
Recommendations for XML Schemas uses the RegEx class to perform
pattern matching of regular expressions. In some cases, the behavior
recommended by W3C differs from the RegEx class behavior. The
following are the known cases where the System.Xml implementation of
pattern matching differs from the W3C specification:
According to the W3C for XML Schema specification, the dollar sign ($)
should be treated as a regular character. However, the System.Xml
validation interprets a dollar sign in the xs:pattern as an
end-of-line anchor. The possible workaround is to replace $ with [$].
If your pattern is already in brackets, such as [abc$], it is not
necessary to make any changes.