Setting destination MQMD properties without the com.ibm libraries - java

I have to use JMS in order to send messages with IBM MQ queues. The libraries used are
javax.jms.*
Everything works as expected. Unfortunately the queue itself needs advanced properties set on the MQMD (message descriptor). To do so you would have to enable them first on a destination with
((JmsDestination) destination).setBooleanProperty(WMQConstants.WMQ_MQMD_WRITE_ENABLED, true);
which uses the
import com.ibm.msg.client.jms.JmsDestination;
library. Due to technical reasons I am not allowed to use these libraries. Is there a way to get this working with the standard javax libraries?
The only MQMD fields I need to define manually is the replyToQueueManager and the UserId
Edit: I can get it working with reflections but still some fields are not set as expected

Related

How to get back Kafka producer and consumer configuration (Java API)?

The use case is following.
I am passing producer or consumer reference over many objects instances in Java code.
At some of them I would like to do some checks for the Kafka configuration.
It means I would like to get back, what effective configuration is stored in Kafka Producer/Consumer (including defaults).
I do not see anthing explicit in java docs:
KafkaProducer
KafkaConsumer
So, how to get back Kafka producer and consumer configuration?
Unfortunately it's not possible. I have to admit it could be a useful feature for showing the "core" configuration properties at least (avoiding the possibility to get the "secrets" for authentication stuff for example).
The only solution that I see today for you is to have a link between the consumer/producer instance and the related properties bag used for setting the client configuration. I understand it's a waste of memory because such configuration is internally in the client but you need to keep your properties bag for having it.

Websphere MQ JMS - Configuration Options

I am currently successfully using an MQConnectionFactory to connect and post to a Websphere MQ queue using JMS.
However I'm getting a requirement from a client that I must use mqclient.ini instead.
So my question is, for a 'standard' JMS setup, should I be using:
Straight up MQConnectionFactory instance
A JMS configuration file
An mqclient.ini file
? What would one use one over the other? Does one take precedence over another?
The mqclient.ini and JMSconfig files are used setting attributes like what client side exits to use, TCP level overrides etc. They are basically used for configuring the client libraries/jars. They are not meant for application configuration for example what queue manager or queue to use. This sort of info, connection factory or destination info, is typically pulled from a JNDI so that the configuration can be modified without affecting application.

Alternative to apache commons configuration for reading properties from database

I have just discovered that Apache commons-configuration can read properties from a DataSource, but it does not cache them. My application needs to read properties a lot of times and it is to slow to access the database each time.
I have a Camel application that sends all messages to routes that ends with my custom beans. These beans are created with scope prototype (I believe in OOP) and they will/need to read some properties and a data source (which reads from properties url/name/etc) that depends from the current user from a SQL db. Each message I receive creates a bean and so properties are reread.
Unfortunately, I am not free to choose where to read properties from because now there is another software (GUI) not written by me that is a User/properties manager that writes to db. So I need to read properties from it.
Can you suggest me an alternative?
You could use the Netflix Archaius project, which adds the caching behavior you are looking for as well as dynamic refresh capabilities. Archaius is built around Commons Configuration.
So, rather than subclassing the DatabaseConfiguration, you could use Archaius' DynamicConfiguration, which extends Commons' AbstractConfiguration. This class will cache whatever source you would like, and refresh the properties at an interval you specify using their poll scheduling class.
The only class you would have to implement is a PolledConfigurationSource which pulls data from the database and places it in a Map. Should be pretty simple.
https://github.com/Netflix/archaius/wiki/Users-Guide

Is it possible to manually set JMS properties when using WMQ API?

I have traditional (com.ibm.mq.jar) MQ application in Java for testing purpose. Now I need to use that application to send some messages to JMS. When I try to set any JMS property on MQ message, for example:
message.setStringProperty("JMSDestination", "queue:///" + queueName);
I always get error: 2471 - MQRC_PROPERTY_NOT_AVAILABLE. It works if I just remove JMS from the property name.
Is it possible to set JMS properties directly on MQMessage? What is a correct way to do that on MQ level?
Btw. I have the same application in .NET where setting JMS properties this way is possible so I'm only trying to use the same code in Java.
It is not allowed to do this manually. Please use the JMS API to set JMS properties.
Restrictions to MQ properties are explained here.
One thing is interessting in that document page though,
The names of properties specified directly as MQRFH2 elements are not guaranteed to be validated by the MQPUT call.
You could perhaps work around this, on a short term basis. There seems to be no guarantee that setting the MQRFH2 elements directly will not be validated, though.

How to set a JMS message property within JAX-WS handler?

Is there any way to set a JMS message property within a JAX-WS handler? I am trying to set a custom property on the message, to be used by a MDB message selector.
I've tried setting the properties on the SOAPMessage within a SOAPHandler, but that doesn't work so I think those properties may be at a different level that does not apply to the message selector. And it doesn't work if I put the property in the BindingProvider's requestContext either.
For anyone reading this in the future: I was able to find a way to set JMS properties within a handler, but it appeared that the IBM generated MDB code was actually removing those properties. You may have to ditch the JMSListenerMDB in order to solve this issue.

Categories