I'm using an old version of WildFly (10.1) which uses the ActiveMQ Artemis that comes with it, and I was trying to switch the store method from a store in the file system to store in the database (and I know that the ActiveMQ Artemis default way to store the is better).
So I'm using this configuration for ActiveMQ Artemis:
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
<server name="default">
<security-setting name="#">
<role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
</security-setting>
<address-setting name="#" dead-letter-address="jms.queue.DLQ" expiry-address="jms.queue.ExpiryQueue" max-size-bytes="10485760" page-size-bytes="2097152" message-counter-history-day-limit="10"/>
<http-connector name="http-connector" socket-binding="http" endpoint="http-acceptor"/>
<http-connector name="http-connector-throughput" socket-binding="http" endpoint="http-acceptor-throughput">
<param name="batch-delay" value="50"/>
</http-connector>
<in-vm-connector name="in-vm" server-id="0"/>
<http-acceptor name="http-acceptor" http-listener="default"/>
<http-acceptor name="http-acceptor-throughput" http-listener="default">
<param name="batch-delay" value="50"/>
<param name="direct-deliver" value="false"/>
</http-acceptor>
<in-vm-acceptor name="in-vm" server-id="0"/>
<jms-queue name="ExpiryQueue" entries="java:/jms/queue/ExpiryQueue"/>
<jms-queue name="DLQ" entries="java:/jms/queue/DLQ"/>
<connection-factory name="InVmConnectionFactory" entries="java:/ConnectionFactory" connectors="in-vm"/>
<connection-factory name="RemoteConnectionFactory" connectors="http-connector" entries="java:jboss/exported/jms/RemoteConnectionFactory"/>
<pooled-connection-factory name="activemq-ra" entries="java:/JmsXA java:jboss/DefaultJMSConnectionFactory" connectors="in-vm" transaction="xa"/>
</server>
</subsystem>
and than using jboss-cli.bat (I'm using Windows), I run this command:
/subsystem=messaging-activemq/server=vmvanz:write-attribute(name=journal-datasource, value=ExampleDS)
And I get this error:
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0201: Unknown attribute 'journal-datasource'",
"rolled-back" => true
}
I try the same command in WildFly 14 and work. I read the documentation from 10.1 and it show the same command line.
Does someone knows if this is a problem from this version or know some other way to configure?
WildFly 10.1 doesn't support the journal-datasource attribute. It ships with version 1.0 of the ActiveMQ messaging configuration schema. This is specified in your configuration here:
<subsystem xmlns="urn:jboss:domain:messaging-activemq:1.0">
The journal-datasource attribute wasn't available until version 2.0 of the ActiveMQ messaging configuration schema which first appeared in WildFly 11.
Also, the documentation you linked is for WildFly 13. This is visible in the URL:
https://docs.wildfly.org/13/Admin_Guide.html#Messaging_JDBC_Store_for_Messaging_Journal
Related
Could anyone let me know if one publisher can be used for passing different parameters (Data Types), like integer, float, string, char etc...
Does Open Splice DDS Community edition have any limitations for publishers? If so how many publishers can it accommodate?
<OpenSplice>
<Domain>
<Name>ospl_sp_ddsi</Name>
<Id>0</Id>
<SingleProcess>true</SingleProcess>
<Service name="ddsi2">
<Command>ddsi2</Command>
</Service>
<Service name="durability">
<Command>durability</Command>
</Service>
<Service enabled="false" name="cmsoap">
<Command>cmsoap</Command>
</Service>
</Domain>
<DDSI2Service name="ddsi2">
<General>
<NetworkInterfaceAddress>192.168.147.179</NetworkInterfaceAddress>
<AllowMulticast>true</AllowMulticast>
<EnableMulticastLoopback>true</EnableMulticastLoopback>
<CoexistWithNativeNetworking>false</CoexistWithNativeNetworking>
</General>
<Compatibility>
<!-- see the release notes and/or the OpenSplice configurator on DDSI interoperability -->
<StandardsConformance>lax</StandardsConformance>
<!-- the following one is necessary only for TwinOaks CoreDX DDS compatibility -->
<!-- <ExplicitlyPublishQosSetToDefault>true</ExplicitlyPublishQosSetToDefault> -->
</Compatibility>
</DDSI2Service>
<DurabilityService name="durability">
<Network>
<Alignment>
<TimeAlignment>false</TimeAlignment>
<RequestCombinePeriod>
<Initial>2.5</Initial>
<Operational>0.1</Operational>
</RequestCombinePeriod>
</Alignment>
<WaitForAttachment maxWaitCount="10">
<ServiceName>ddsi2</ServiceName>
</WaitForAttachment>
</Network>
<NameSpaces>
<NameSpace name="defaultNamespace">
<Partition>*</Partition>
</NameSpace>
<Policy alignee="Initial" aligner="true" durability="Durable" nameSpace="defaultNamespace"/>
</NameSpaces>
</DurabilityService>
<TunerService name="cmsoap">
<Server>
<PortNr>none</PortNr>
</Server>
</TunerService>
</OpenSplice>
A DDS-publisher can have multiple writers of different topics where each topic-type can include various parameters of various types (including bounded and unbounded types such as arrays and sequences).
The OpenSplice CE (Community Edition) doesn't have any limitation for publishers, but when you want to run more than 10 applications on a single machine you have to change the DDSI/Discovery/ParticipantIndex parameter from its default 'auto' value to 'none', see also this post: http://forums.opensp...index#entry4024
Cheers
I have created a web service endpoint using Apache CXF 2.5.2, but I am having some issues with schema validation and MTOM interacting. If I enable MTOM and schema validation I must use the base64Binary type directly, however I am trying to conform to a fixed spec where the MTOM field also has a "contentType" attribute.
<jaxws:properties>
<entry key="mtom-enabled" value="true"/>
<entry key="schema-validation-enabled" value="true"/>
</jaxws:properties>
Is it possible to only enable schema validation for inbound or outbound messages? For example something like:
<entry key="schema-validation-enabled" value="inbound"/>
Alternatively is there an alternate way of achieving this, such as overriding the outbound message validation?
Thanks.
Since Apache CXF 3.0 this is sort of possible. You can't disable the validation on an in/outbound basis, but you can ignore the validation errors selectively (so you're still getting the performance hit).
You configure reader (inbound) & writer (outbound) validation event handlers in the CXF configuration.
<jaxws:properties>
<!-- Validation of the SOAP Message-->
<entry key="schema-validation-enabled" value="true" />
<entry key="jaxb-reader-validation-event-handler">
<bean class="com.example.cxf.InboundValidationEventHandler" />
</entry>
<entry key="jaxb-writer-validation-event-handler">
<bean class="com.example.cxf.OutboundValidationEventHandler" />
</entry>
</jaxws:properties>
Create the ValidationEventHandlers like this and return true. Returning true informs CXF to ignore a single validation error and continue validation.
package com.example.cxf;
import javax.xml.bind.ValidationEvent;
import javax.xml.bind.ValidationEventHandler;
public class InboundValidationEventHandler implements ValidationEventHandler {
public boolean handleEvent(ValidationEvent event) {
String message = event.getMessage();
Throwable t = event.getLinkedException();
System.out.println("Ignoring Inbound Validation EVENT : " + message);
// ignore
return true;
}
}
How I stop Jackrabbit using SimpleSecurityManager?
I'm trying to call session.getUserManager() but I get a repository exception as SimpleSecurityManager.getUserManager() explicity throws it.
<Security appName="Jackrabbit">
<SecurityManager class="org.apache.jackrabbit.core.DefaultSecurityManager" workspaceName="security">
</SecurityManager>
<AccessManager class="org.apache.jackrabbit.core.security.simple.SimpleAccessManager">
<!-- <param name="config" value="${rep.home}/access.xml"/> -->
</AccessManager>
<LoginModule class="org.apache.jackrabbit.core.security.authentication.DefaultLoginModule">
<param name="anonymousId" value="anonymous"/>
<param name="adminId" value="admin"/>
</LoginModule>
</Security>
Rest of code for those that will ask...
Repository repository = new TransientRepository();
Session jackrabbitSession = repository.login(credentials);
UserManager userManager = session.getUserManager();
The user manager is a Jackrabbit extension. It's not a part of the JCR. So, you need to use a JackrabbitSession, not just a Session. Here's a link to the wiki:
http://wiki.apache.org/jackrabbit/UserManagement
When configuring the service for handling UsernameToken and signatures, it's setup like this:
<service name="serviceName">
<inbound>
<cxf:inbound-endpoint address="someUrl" protocolConnector="httpsConnector" >
<cxf:inInterceptors>
<spring:bean class="org.apache.cxf.binding.soap.saaj.SAAJInInterceptor" />
<spring:bean class="org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor">
<spring:constructor-arg>
<spring:map>
<spring:entry key="action" value="UsernameToken Timestamp Signature" />
<spring:entry key="passwordCallbackRef" value-ref="serverCallback" />
<spring:entry key="signaturePropFile" value="wssecurity.properties" />
</spring:map>
</spring:constructor-arg>
</spring:bean>
</cxf:inInterceptors>
</cxf:inbound-endpoint>
</inbound>
</service>
But how is it possible to create a policy of what algorithms that are allowed, and what parts of the message that should be signed?
You'd have to ask the Mule folks. Last I checked, they hadn't moved to CXF 2.2.x yet. If they ARE on 2.2.x, you could use the WS-SecPol support built into CXF.
Running into an issue where our datasources for two different DBMS (MS-SQLServer and Informix) are not picking up the security-domain configuration in the login-config.xml file.
Our datasources look like this:
<datasources>
<local-tx-datasource>
<jndi-name>ourTX</jndi-name>
<connection-url>jdbc:informix-sqli://our.server.com:1526/wlms:informixserver=ol_db</connection-url>
<driver-class>com.informix.jdbc.IfxDriver</driver-class>
<security-domain>ourDS</security-domain>
<!-- corresponding type-mapping in the standardjbosscmp-jdbc.xml (optional) -->
<metadata>
<type-mapping>InformixDB</type-mapping>
</metadata>
<min-pool-size>5</min-pool-size>
<max-pool-size>50</max-pool-size>
<prefill>yes</prefill>
<prepared-statement-cache-size>10</prepared-statement-cache-size>
<idle-timeout-minutes>5</idle-timeout-minutes>
<new-connection-sql>set lock mode to wait 4;set isolation to cursor stability;</new-connection-sql>
<check-valid-connection-sql>SELECT count(*) FROM dummy;</check-valid-connection-sql>
</local-tx-datasource>
</datasources>
And our login-config.xml has the following entry:
<application-policy name="ourDS">
<authentication>
<login-module code="org.jboss.resource.security.SecureIdentityLoginModule" flag="required">
<module-option name="userName">user</module-option>
<module-option name="password">-4e5f8b6c4217c342c03b57ed16d31678</module-option>
<module-option name="managedConnectionFactoryName">jboss.jca:service=LocalTxCM,name=ourTX</module-option>
</login-module>
</authentication>
</application-policy>
However, once the JBoss server is deployed, we get an error like this for Informix:
13:23:13,521 WARN [JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Incorrect password or user com.informix.asf.IfxASFRemoteException: user#my.computer.com is not known on the database server.)
And for MS-SQLServer we get a similar error to Informix which looks like:
13:25:23,053 WARN [JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (com.microsoft.sqlserver.jdbc.SQLServerException: Login failed for user ''. The user is not associated with a trusted SQL Server connection.)
Now if, we comment out the security-domain element in the *-ds.xml file and replace it with a simple user name and a clear text password, both datasource work with both database engines. We're using the 'all' server configuration in JBoss. We've made sure that login-config.xml is getting loaded on start-up. And the hqsqldb-ds.xml using the security-domain element works. But using our added application-policy to the login-config.xml, it seems that the datasource does not get the values when establishing a new connection.
Any ideas what we're doing wrong? Have we missed something?
We were testing the validity of the datasource through the admin-console. Because of where we were testing the database, this is bug in the JBoss EAP 5.0.0.GA version. While not confirmed, may also be a but bug in the admin-console for 5.0.1.GA and maybe 5.0.2.GA.
Everything above was actually working.