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
Related
In Fabric8, the preferred way to obtain an ActiveMQ connection is via the mq-fabric profile, which provides an ActitveMQConnection object via Declarative Services. An example of this is given on GitHub, which works just fine.
However, I've yet to find a way for Declarative Services and Blueprint Services to collaborate in Fabric8 (or any OSGI-environment, really), thus, my OSGI application must either use DS or blueprint. Mixing both doesn't seem to be an option.
If you want to use blueprint (which I do), you must first create a broker through the web UI, then go back to the console and type cluster-list, finding the port that Fabric8 assigned to the broker and then configure a connection in blueprint like so:
<bean id="activemqConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="tcp://mydomain:33056" />
<property name="userName" value="admin" />
<property name="password" value="admin" />
</bean>
While this does work, it's not exactly deployment-friendly, as it involves a few manual steps that I'd like to avoid if possible. The main issue is that I don't know what that port is going to be. I've combed through the config files and couldn't find it anywhere.
Is there a cleaner, more automated way to obtain an ActiveMQ connection in Fabric8 via blueprint, or must we use Declarative Services?
Stumbled across a solution to this issue in the fabric-camel-demo, which illustrates how to instantiate an ActiveMQConnectionFactory bean in Fabric8 via Blueprint.
<!-- use the fabric protocol in the brokerURL to connect to the ActiveMQ broker registered as default name -->
<!-- notice we could have used amq as the component name in Camel, and avoid any configuration at all,
as the amq component is provided out of the box when running in fabric -->
<bean id="jmsConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
<property name="brokerURL" value="discovery:(fabric:default)"/>
<property name="userName" value="admin"/>
<property name="password" value="admin"/>
</bean>
Hope this helps!
Does anybody have a working example of how to configure a cluster of nodes to share an index using the infinispan directory provider? All the documentation on Infinispan (the documentation is seriously lacking btw) implies that it should be as easy as having some properties set but no matter how I try I cannot get it to work. The nodes in the cluster find eachother fine and I can do get operations on one node and get object that were put on another. But as soon as I do queries (use the index) it just starts to fail.
My infinispan config:
<global>
<transport clusterName="SomeCluster">
<properties>
<property name="configurationFile" value="jgroups-udp.xml" />
</properties>
</transport>
</global>
<namedCache name="access">
<clustering mode="distribution" />
<indexing enabled="true" indexLocalOnly="true">
<properties>
<property name="default.directory_provider" value="infinispan"/>
<property name="default.worker.backend" value="jgroups"/>
</properties>
</indexing>
</namedCache>
I have not found one example/tutorial which covers a distributed cache with a shared index, and I consider my google-fu to be great. I have asked on the infinispan community forum but havent gotten any replies there.
The errors I get are all related to the fact that only one node can be able to write to the index (the master node) but the config above, which according some the documentation on Hibernet Search should make one node a master node, does nothing as far as I can se.
Edit:Im using Infinispan 6.0.2.Final
Rather than JGroups backend I'd use InfinispanIndexManager - this manager already provides its own backend.
<indexing enabled="true" indexLocalOnly="true">
<properties>
<property name="default.indexmanager" value="org.infinispan.query.indexmanager.InfinispanIndexManager" />
<property name="default.exclusive_index_use" value="false" />
<property name="default.metadata_cachename" value="lucene_metadata_repl" />
<property name="default.data_cachename" value="lucene_data_dist" />
<property name="default.locking_cachename" value="lucene_locking_repl" />
<property name="lucene_version" value="LUCENE_36" />
</properties>
</indexing>
Now, configure all the caches to be clustered (distributed or replicated). Without specifying the cache configuration this way, the three caches are created using the default cache configuration - which is by default non-clustered.
I am not sure about the exclusive_index_use, though, maybe it's not necessary.
I agree that Infinispan documentation could be much better, usually I have to fallback to investigating source code. For examples of indexing configuration, you can look into the infinispan-query module/src/test/resources.
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>
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.
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