How do I tell WCF to make use of wsdl arrayType? Like this:
<complexType name="ArrayOfString">
<complexContent>
<restriction base="soapenc:Array">
<attribute ref="soapenc:arrayType" wsdl:arrayType="string[]"/>
</restriction>
</complexContent>
</complexType>
This is what WCF is doing (The not expected)
<complexType name="ArrayOfstring">
<sequence>
<element minOccurs="0" maxOccurs="unbounded" name="string" nillable="true" type="xs:string"/>
</sequence>
<element name="ArrayOfstring" nillable="true" type="tns:ArrayOfstring"/>
</complexType>
Found the solution. I have to add this to make it work: [XmlSerializerFormat(Style = OperationFormatStyle.Rpc, Use = OperationFormatUse.Encoded)]
I think WCF doesn't support it out of the box because that is WSDL extension to standard XSD description of data type. Both XmlSerializer and DataContractSerializer should work with standard XSD in scenarios where web services are not involved at all so it uses the plain XSD approach.
If you need the first approach you can either write WSDL + XSDs yourselves or you can try to implement custom export extension - to use that for WCF client generation you will also need custom import extension.
Related
I am trying to figure out an effective way of configure the
subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0"
ActiveMQ subsystem in the standalone.xml.
I find the widlfly 10 documentation on this subsystem sufficient to get you started.
But clearly lacking when you want to further tune Active MQ behavior.
(e.g. http://activemq.apache.org/how-do-i-configure-10s-of-1000s-of-queues-in-a-single-broker-.html)
For understanding what is posisble or not with ActiveMQ, I prefer to and I try to use the active MQ as the primary source of documentation.
My expectation, in the end, is that I should be able to find a way configure the active mq features explained on their documentation in the wildfly standalone.xml configuration, somehow.
That Wildfly is acting as an interface to configure ActiveMQ, but that it does not act as a limitation to what I can configure.
This is the part I am struggling with.
Once I have read the ActiveMQ documentation and I have an idea about a feature I want to test out. I then go hunting on how to update my standalone.xml to configure the jms broker appropriately, I need to hunt for the XML elements and attributes that would allow me to do this.
So with this context in hand, here are the questions:
(a) Why is that the:
docs\schema\jboss-as-messaging_1_0.xsd to jboss-as-messaging_3_0.xsd
Are inconsistent with the configuration that must actually get written in the standalone.xml.
For example, if we look at the address-setting element.
In the Wildfly 10 official documentation and locally on my machine, this element can be configured through atrributes as illustrated next.
<address-setting name="#" slow-consumer-threshold="20" message-counter-history-day-limit="10" page-size-bytes="2097152" max-size-bytes="10485760" max-delivery-attempts="-1" expiry-address="jms.queue.ExpiryQueue" dead-letter-address="jms.queue.DLQ"/>
On the other hand, if we look at the XSD of subsytem, the address-setting type should be composed of elements not attributes.
<xs:complexType name="address-settingType">
<xs:all>
<xs:element maxOccurs="1" minOccurs="0" name="dead-letter-address" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="expiry-address" type="xs:string" />
<xs:element maxOccurs="1" minOccurs="0" name="redelivery-delay" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="max-delivery-attempts" type="xs:int" />
<xs:element maxOccurs="1" minOccurs="0" name="max-size-bytes" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="page-size-bytes" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="page-max-cache-size" type="xs:int" />
<xs:element maxOccurs="1" minOccurs="0" name="address-full-policy" type="addressFullMessagePolicyType" />
<xs:element maxOccurs="1" minOccurs="0" name="message-counter-history-day-limit" type="xs:int" />
<xs:element maxOccurs="1" minOccurs="0" name="last-value-queue" type="xs:boolean" />
<xs:element maxOccurs="1" minOccurs="0" name="redistribution-delay" type="xs:long" />
<xs:element maxOccurs="1" minOccurs="0" name="send-to-dla-on-no-route" type="xs:boolean" />
</xs:all>
<xs:attribute name="match" type="xs:string" use="required"/>
</xs:complexType>
This is a problem to me.
Because if you cannot find a documentation page for every single attribute that you can configure, then I would expect to find an XSD that has this technical level of detail in there. Then I can idependently of how up to do date or detailed the documentation is, find my way to set the features I want to enable/disable or tune.
But if the XSDs I find are not consistent with the configuration I end up writing on the stanadalone.xml and which is working, I cannot really trust the XSD as a reliable source of information for features that I can configure.
So, on the one hand, I am configuring attributes on an element. On the other hand, I have an XSD that tells me I should be using elements withing elements.
Which is it?
(b) The next question is about the scope of configuration that is posisble to do.
I want to know if our ability to configure ActiveMQ subsystem via standalone.xml is limited or if we have full capability of configuring the subsytem.
For example, If you look at the ActiveMQ page on per-destination policies.
http://activemq.apache.org/per-destination-policies.html
There are features that can be configured such as:
"optimizedDispatch"
Which is recommended by ActiveMQ if you are going to configured hundreds of queues in an active MQ broker.
Hunting the XSDs for optimizedDispatch policy, I find no mention of this configuration element in either the form of an element or attribute.
Can I actually configure this behavior on the destinations or not?
I would like to know how far I can go with the tuning of ActiveMQ via wildfly subsystem configuration?
Where are the boundaries between what ActiveMQ supports and what the wildfly stand alone xml supported configuration allows me to Tune.
Can anyone bring some light to these two questions?
Kindest regards.
WildFly comes with ActiveMQ Artemis as the messaging system, not the older and classic ActiveMQ.
These two brokers are different:
http://activemq.apache.org/how-does-activemq-compare-to-artemis.html
http://activemq.apache.org/artemis/migration/index.html
You can find the ActiveMQ Artemis documentation in the website at:
http://activemq.apache.org/artemis/
And WildFly also has some documentation at:
https://docs.jboss.org/author/display/WFLY10/Messaging+configuration
Iteration mediator works with WSo2 Tryit tool but when the same message is sent through SOAP UI the proxy it does not iterate. My proxy service is very simple it has a xslt mediator and then does the iteration. Do I need to change the content type?
Can you paster your proxy service source code.
Try it tool is a evolving tool, but you should always do your testing from SOAP UI.
This is the sample format :-
<iterate expression="//m0:getQuote/m0:request" preservePayload="true"
attachPath="//m0:getQuote"
xmlns:m0="http://services.samples">
<target>
<sequence>
<send>
<endpoint>
<address
uri="http://localhost:9000/services/SimpleStockQuoteService"/>
</endpoint>
</send>
</sequence>
</target>
I am able to deploy my web-application from IDEA without problems using annotation-based url-mappings, so why does IDEA nevertheless highlight the tag as a violation of the schema-definition here?
(using IDEA 12.1.4, Tomcat 7)
IDEA is validating your XML according to the schema and it is correctly saying that Element metadata-complete is not allowed here.
If you look at the schema web-app_3.0.xsd you'll see that it imports web-commmon_3.0.xsd. And this web-common schema has defined metadata-complete to be part of the web-common-attributes.
<xsd:attributeGroup name="web-common-attributes">
<xsd:attribute name="version"
type="javaee:web-app-versionType"
use="required"/>
<xsd:attribute name="id"
type="xsd:ID"/>
<xsd:attribute name="metadata-complete"
type="xsd:boolean">
...
In summary this means that metadata-complete is an attribute to web-app element.
Change your xml to this instead:
<?xml version=1.0 encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3.0.xsd"
version="3.0"
metadata-complete="false">
<display-name>Hello World</display-name>
</web-app>
I am wondering if there is somebody who can help me with this probelm.
I want to add a property to onet.xml of my custom webtemplate. so that if you create a site from this web template the site will contain the property.
is that possible? Thank you.
Please refer this... it contains some information about onet.xml
This is also a very useful link describing how to reference properties from your custom web part. http://aarebrot.net/blog/2008/11/loading-custom-web-parts-inside-your-onet-xml/
The link explains how v3 format looks like, if you haven't noticed it is different from using v2:
<webParts>
<webPart xmlns="http://schemas.microsoft.com/WebPart/v3">
<metaData>
<type name="Client.Publishing.Intranet.WebParts.ClientStoryRotator,Client.Publishing.Intranet.WebParts, Version=1.0.0.0, Culture=neutral, PublicKeyToken=320209e28e1f8058" />
<importErrorMessage>$Resources:cmscore,WebPartImportError;</importErrorMessage>
</metaData>
<data>
<properties>
<property name="Title" type="string">$Resources:Client.Publishing.Intranet.Lists.Articles,list_Stories_Title;</property>
<property name="Description" type="string">$Resources:Client.Publishing.Intranet.Lists.Articles,list_Stories_Description;</property>
<property name="ListName" type="string">$Resources:Client.Publishing.Intranet.Lists.Articles,list_Stories_Title;</property>
<property name="WebName" type="string">$Resources:Client.Publishing.Intranet.SiteTemplates,webpart_Library_Url;</property>
<property name="Width" type="string">$Resources:Client.Publishing.Intranet.SiteTemplates,webpart_Stories_Width;</property>
</properties>
</data>
</webPart>
</webParts>
I'm trying to catch regular exceptions from a WCF service in a Silverlight client application. For that I've included the respective changes in my WCF service as given in this MSDN article.
But when I configure the behavior extension and use the same in endpoint behavior, the error mentioned above is coming up, and the service is not able to run due to this error.
I am putting here my configuration. Kindly suggest how can I solve this?
<extensions>
<!--Add a behavior extension within the service model-->
<!-- Here SilverlightFaultBehavior is a class in AppServiceLib namespace -->
<behaviorExtensions>
<add name="myFaultExtension"
type="AppServiceLib.SilverlightFaultBehavior,AppServiceLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</behaviorExtensions>
</extensions>
<endpointBehaviors>
<behavior name="myFaultBehavior">
<**myFaultExtension**/>
</behavior>
</endpointBehaviors>
I had this error with my custom behavior extension that I wanted to add as an endpoint behavior. So, I edited the schema used in Visual Studio 2017 to get rid of the warning in my web.config file. It's the same warning that you received:
The element 'behavior' has invalid child element 'CustomSecurity'. List of possible elements expected: 'clientVia, callbackDebug, callbackTimeouts, clear, clientCredentials, transactedBatching, dataContractSerializer, dispatcherSynchronization, remove, synchronousReceive, webHttp, enableWebScript, endpointDiscovery, soapProcessing'.
My web.config has:
<system.serviceModel>
<extensions>
<behaviorExtensions>
<add name="CustomSecurity"
type="FullyQualifiedPath.MyCustomBehaviorExtension, MyAssemblyName"/>
</behaviorExtensions>
</extensions>
<endpointBehaviors>
<behavior name="CustomServiceBehavior">
<CustomSecurity />
</behavior>
</endpointBehaviors>
<endpoint address="https://SomeServer/MyService.svc/soap"
behaviorConfiguration="CustomServiceBehavior" binding="basicHttpBinding"
bindingConfiguration="BasicHttpBinding_IProject" contract="ProjectService.IProject"
name="BasicHttpBinding_IProject" />
The CustomSecurity XML node always had the blue squiggly line underneath it in Visual Studio. It shows up as a Warning in the Error List window. I wanted to get rid of it because each time I tried to update a Service Reference, it would fail because of the warning in web.config.
So, to fix it, you'll need to edit the Schema that Visual Studio uses to validate elements. So, I opened my web.config, then selected XML on the main Visual Studio menu bar. Then select Schemas. You'll get a long list of schemas. Find "DotNetConfig.xsd" (or DotNetConfig[XX].xsd where XX is the .NET Framework version) as seen below.
Update: you might want to edit any/all xsd files with the DotNetConfig file prefix. Typically you do not want to use all of the DotNetConfigXX.xsd files at once. It's best to have the "Use this schema" option (in the Use column) turned on for only one; otherwise, you might see errors about schema elements already being defined.
Browse to the path shown in the Location column and edit the xsd file. Search for:<xs:element name="behavior" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior">
Then add a new xs:element node within the xs:choice node with the name of your custom behavior extension; in my case, CustomSecurity. Save the file and Visual Studio should validate against the new schema automatically and you should not get a warning in your web.config any longer.
<xs:element name="behavior" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior">
<xs:complexType>
<xs:annotation>
<xs:documentation>The behavior element contains a collection of settings for the behavior of an endpoint.</xs:documentation>
</xs:annotation>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="CustomSecurity" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior/CustomSecurity">
<xs:complexType>
<xs:annotation>
<xs:documentation>Specifies the behavior extension class applied to the endpoint.</xs:documentation>
</xs:annotation>
<xs:anyAttribute namespace="http://schemas.microsoft.com/XML-Document-Transform" processContents="strict" />
</xs:complexType>
</xs:element>
<xs:element name="clientVia" vs:help="configuration/system.serviceModel/behaviors/endpointBehaviors/behavior/clientVia">
<xs:complexType>
<xs:annotation>
<xs:documentation>Specifies the URI for which the transport channel should be created.</xs:documentation>
</xs:annotation>
<xs:attribute name="viaUri" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>A string that specifies a URI that indicates the route a message should take.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="lockAttributes" type="xs:string" use="optional" />
<xs:attribute name="lockAllAttributesExcept" type="xs:string" use="optional" />
<xs:attribute name="lockElements" type="xs:string" use="optional" />
<xs:attribute name="lockAllElementsExcept" type="xs:string" use="optional" />
<xs:attribute name="lockItem" type="boolean_Type" use="optional" />
<xs:anyAttribute namespace="http://schemas.microsoft.com/XML-Document-Transform" processContents="strict" />
</xs:complexType>
</xs:element>
This causes problems when the version of the assembly is autoincremented during assembly compile/build.
Fixed since .NET 4.0. Version/Culture/PublicKeyToken may be dropped so that the config no longer needs the autoincremented value of the version.
<behaviorExtensions>
<add name="serviceKeyBehavior"
type="MyNamespace.ServiceKeyBehaviorExtensionElement, MyAssembly"/>
</behaviorExtensions>
I ran into this same issue. The solution for me was actually provided in the aforementioned duplicate posting Hearing "element 'behavior' has invalid child element" should be ignored, but prevented from updating service reference because of it. Turned out the 'type' field is very sensitive. Ended up using the Console.WriteLine(typeof(BetterErrorMessagesFaultBehavior).AssemblyQualifiedName); mentioned as an answer on the other post to get the exact type I needed.
<add name="myFaultExtension"
type="AppServiceLib.SilverlightFaultBehavior,AppServiceLib, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
Try to define your WCF in web.config with the editor to prevent mistakes. (Especially when you required to write the whole type name).
Right click on the web.config, then Edit WCF Configuration:
Then go to: Advanced --> Extensions --> behavior element extensions --> New
Then under (General) click on the left small button and choose the new behavior. It will write the full type name in the app.config for you.
Now you can see your new behavior under the <extensions> tag in the app.config with the correct type name.
iCode's solution worked for me but I had to edit all versions of DotNetCofig4x.xsd files found in ...Xml/Schemas/. x in 4x.xsd meaning 40.xsd, 45.xsd, 47.xsd and 471.xsd