Database persistence based JMS messaging in Jboss EAP 7.0 - jboss7.x

I am trying to configure JDBC database based persistence for JMS messaging in JBoss Version 7.0.6.GA.
When I look at JBoss 7.0 docs - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html/configuring_messaging/configuring_persistence, I don't see any documentation about "Messaging Journal Persistence Using a JDBC Database".
But when I look at JBoss 7.1 docs - https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/configuring_messaging/configuring_persistence#messaging_journal_persistence_using_a_jdbc_database, it does details about "Messaging Journal Persistence Using a JDBC Database".
Do that mean JBoss 7.0 EAP doesn't support database persistence based JMS messaging? Do I need to migrate to JBoss 7.1 to achieve this?

Looking at JBoss 7.1 release notes, I can conclude that we can use JDBC to persist JMS messages only after JBoss 7.1.x and above. This feature is not supported in JBoss 7.0 EAP.

Related

Is that possible to communicate JMS Topic of HornetQ with ActiveMQ or vice versa

I have a HornetQ project on JBoss 6 using JDK-6, and an ActiveMQ project on WildFly 18 using JDK-11. Can I access the HornetQ topic in the ActiveMQ project or vice versa?
If you're using ActiveMQ Artemis embedded in WildFly 18 then you should be able to connect to it from your HornetQ client because ActiveMQ Artemis is based on the HornetQ code-base and has maintained backwards compatibility with older HornetQ clients.
However, you will not be able to use the ActiveMQ Artemis JMS client to talk to HornetQ.

Use ActiveMQ 5 and IBM MQ 8 in the same application

I have a java application that connects to both ActiveMQ and IBM MQ. I'm currently using IBM MQ 7.1 and trying to upgrade to use the MQ 8.0 client. The MQ 8 jars reference JMS 2.0 classes, like JMSRuntimeException. the ActiveMQ-all jar includes JMS 1.1 classes which conflict with JMS 2.0.
Is there any way to utilize both?
One easy way you can do it is to use the direct WebsphereMQ classes and NOT use it as a JMS provider, then your conflict will evaporate.

Hazelcast ClassCastException when deploying a mule application that uses Hazelcast in mule 3.6.2 ee

I'm trying to deploy a Mule application which uses Hazelcast to cache the result of some methods that are frequently used. However, while deploying the application I got the following error:
java.lang.ClassCastException: Cannot cast com.hazelcast.client.txn.ClientTxnPortableHook to com.hazelcast.nio.serialization.PortableHook
at java.lang.Class.cast(Class.java:3176) ~[?:1.7.0_79]
at com.hazelcast.util.ServiceLoader$1.next(ServiceLoader.java:97) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.load(PortableHookLoader.java:48) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.(PortableHookLoader.java:41) ~[hazelcast-3.1.6.jar:3.1.6]
I've tried to use the loader override function by placing the next setting in mule-deploy.properties:
loader.override=-com.hazelcast
The Mule application uses Hazelcast 3.5, and Mule 3.6.2 EE uses Hazelcast 3.1.6. Can you tell me a possible solution?
I have reviewed the link provided by Enrique (ClassCastException when casting to the same class) and it was useful because there were two different classpaths, but there were other aspects to be considered in the solution of the problem:
The Hazelcast versions were different. The Mule application used Hazelcast 3.5, and Mule 3.6.2 EE used Hazelcast 3.1.6.
There was not log configuration for Hazelcast in the mule server.
Because I really need to use the Hazelcast 3.5, it was not a choice to downgrade the Hazelcast to 3.1.6. So, I had to replace the version of the Hazelcast in the mule server to 3.5 and remove this library from the Mule application. And then I had to made a lot of tests to discard possible incompatibility issues. The tests were successful.
For the log configuration for Hazelcast in the mule server, I had to add the next JVM parameter to the mule server wrapper:
wrapper.java.additional.44=-Dhazelcast.logging.type=log4j
I used "log4j" because I was using Log4j2. You can see more information about this configuration in the next link:
http://docs.hazelcast.org/docs/3.5/manual/html/logging.html

weblogic 12c + websphere mq 6

I'm can't find instruction for integration websphere mq 6 + weblogic 12 c by websphere native protocol (no jms!). It possible? Goal - deploy mdb in weblogic for getting message from websphere mq queue.
and response.
Please help with link or instruction.
Alex
I understand that the option of using WebLogic's Foreign JMS provider configuration is not available to you as you want to NOT use the JMS API, but MQ's specific API, correct?
If that is the case you could always try to write some MQ Client code using the MQ API, as you would for a stand-alone application, and then deploy it inside WebLogic, although I'm not sure whether that would give you any real benefit.
One thing I am pretty sure you will NOT be able to do is write a Message-Driven Bean which connects to an MQ Series queue using the MQ API. MDBs are a Java EE concept and they are meant to connect to JMS providers.

Jboss Mbeans visible in jmx-console but not in JConsole

JBoss(4.0.x) has many useful MBeans (org.apache.commons.modeler.*) that are visible in:
/jmx-console
But i cannot see these beans listed in JConsole (MBeans tab).
Are these beans not exposed to outside world?
JBoss 4.x has its own internal MBean server, separate from the default JVM one (JBoss AS 4.x pre-dates Java 5 and its MBean server, so needed its own).
I believe that in JBoss AS 5.x you can tell it to use the JVM's MBean server, but I don't think JBoss AS 4.x provides that option.
Are these beans not exposed to outside world?
Yes they are - JBoss AS's internal MBean server is just as exposed as the JVM's one, it's just exposed differently. JConsole talks to the JVM's MBean server, you need different tools to talk to the JBoss AS one.
P.S. JBoss AS 4.0 is eye-poppingly old (2004? 2005?). You really should update it.