Develop Reference

log output from qpid library running in weblogic

I am looking for a way to get more detail, like debug or verbose level logging, of a JMS message send over amqps to AzureServiceBus.
I am using qpid client 0.60.1 and I have no access to the calling code. I am working with a web application running in Weblogic. The application provides a servlet that has generic JMS functions, and I can use configuration that maps those to a specific providers' JMS connection factory libraries. To make qpid available to use, I add the qpid client jars to the CLASSPATH for when I start weblogic, and I provide a jndi.properties file that currently contains only two entries:
con
connectionfactory.ServiceBusConnectionFactory=amqps://?jms.username=&jms.password=
queue.inbound-general-q-QueueLookup=
Currently, this is the only message that I see in the weblogic log:
Connection ID:6147a0e7-1870-4a1a-8dd5-bd7102fc1aa4:106 connected to server: amqps://
I have been told that we don't have enough information to open a case with Microsoft.
I am looking for a way to get more detail, like debug or verbose level logging, of a message send. Ideally, want to see as much as possible: headers, properties, payload, etc.
The things I have access to change:
Weblogic environment, including classpath and any other java runtime flags
The jnd.properties file
I am reviewed the qpid.apache.org documentation on logging, but it has not been helpful to me as it is too vague.
The main application running in weblogic has these parameters in its runtime:
-Djava.util.logging.config.file=properties/logging.properties
-Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Jdk14Logger
I have tried adding some things to logging.properties, but it has never changed the output of the resulting log file to include anything from amqp.

Configure ACTIVEMQ_OPTS in ActiveMQ 5.15.4

I was trying to send an ObjectMessage containing a myObject, instance of myClass, using ActiveMQ as JMS Provider. Call to ActiveMQ is made through Mule 4.3.0.
An error occurred in the receiving application:
Failed to build body from content. Serializable class not available to broker. Reason: java.lang.ClassNotFoundException: Forbidden class client.MyClass! This class is not trusted to be serialized as ObjectMessage payload. Please take a look at http://activemq.apache.org/objectmessage.html for more information on how to configure trusted classes.
the page says:
If you need to exchange object messages, you need to add packages your applications are using. You can do that with by using
org.apache.activemq.SERIALIZABLE_PACKAGES system property of the
broker. You can add this system property to ACTIVEMQ_OPTS variable in
${ACTIVEMQ_HOME}/bin/env script.
I am using ActiveMQ 5.15.4 . In the \bin subfolder, there is no env script, only the activemq script.
Where should I configure ACTIVEMQ_OPTS so that I, will not get forbidden class error. Or if any alternative solutions will help.

You should define ACTIVEMQ_OPTS in your operating system shell, using the appropriate method for that operating system. For example in Linux set it in the user's profile script, or use the bin/env script.
If you are using Windows you can set it using the UI.

Failed to build body from content in activeMQ - Spring generic message used

I send a org.springframework.messaging.support.GenericMessage to a queue in ActiveMQ by org.springframework.jms.core.JmsTemplate. in ActiveMQ, I see this message :
Cannot display ObjectMessage body. Reason: Failed to build body from content.
Serializable class not available to broker.
Reason: java.lang.ClassNotFoundException: org.springframework.messaging.support.GenericMessage
and so I can't read that message in a client.
I set trustAllPackages to true in my activeMQConnectionFactory and problem doesn't solve. How to solve it ?

The JmsTemplate will serialize the entire GenericMessage as a java object, so spring-messaging is needed on the class path of the receiving system as well.
class not available to broker.
It looks like you might be trying to view the message in the admin UI, which doesn't understand spring-messaging classes.
If you want to map the GenericMessage to a JMS Message instead, use the JmsMessagingTemplate instead (one of the send() methods); the broker might be able to display such a message (depending on the payload type).

Simply put:
Add the required jar or class files or the serialised messages in the lib folder of activemq and restart activemq.
It worked for me

log4j log not working in Websphere when Class loader setting is parent first

I am having two problems. In my application we are using custom email functionality with javax.mail api. Mails are going fine with out any error when the class loader setting is kept as Parent First but custom logs are not getting generated with that class loader setting.
When I update the class loader to Parent Last then logs are getting generated but the custom email functionality is not working, its getting freezed at message.saveChanges(); line and server is throwing time out error.
I have mail.jar & log4j.jar included in the WEB-INF/lib of the application and the log4j.properties file is present in the classes folder
Could any one please let me know what is causing this issue and Is there a way to make both logging and email functionality work with a single class loader setting.
Thanks.

This most likely is caused because Log4J doesn't load the configuration file (log4j.xml or log4j.properties) that you think it does.
Add the log4j.debug=true system property, restart the server and watch the logs. The logs (in SystemOut.log or SystemErr.log) will tell you exactly which configuration file was loaded.

Your version of JavaMail must be fairly old since you are using the 'mail.jar'.
Upgrade the JavaMail included with websphere to 1.5.3 which contains the fix for Bug 6668 -skip unusable Store and Transport classes. From the bug report:
In complex class loading situations, it can be possible for there to be
multiple copies of the JavaMail classes. A Store or Transport defined
by one copy may be loaded by another copy, but it won't be usable because
they're in different ClassLoaders. In this case, JavaMail should skip
over the unusable class and try to load the class from another ClassLoader.
This can happen, for example, in GlassFish if the application includes the
JavaMail classes, the application class loader is configured to prefer
application classes over system classes, and the app server itself tries
to use JavaMail when running in the context of the application.
You need to then remove that old version of JavaMail from your WEB-INF/lib and if need be, place JavaMail 1.5.3 in WEB-INF/lib too. I've tested this fix for GlassFish so I'm assuming lots of other appservers suffer this same issue.
You can download the latest snapshot and official releases from the JavaMail reference implementation home page.

How to pass data from an application to a JCA resource adapter?

I want to configure a self-written JCA 1.6 inbound resource adapter (RA). My big problem is that the RA needs to get access to some (dynamic) configuration data living in the application that uses the RA.
Now I know that this is against the original idea of the whole JCA idea but unfortunately I cannot change this design as quickly as I'd like/have to.
The data I need to get to the RA is
the port it's supposed to listen on,
the license used for the whole application (the feature the RA supplies requires extra licensing)
additional configuration data stored in a db
I've come up with four ideas:
Use the asadmin create-resource-adapter-config. Due to the fact that glassfish doesn't seem to restart apps depending on the RA, we need to restart the application after this. While this attempt is suitable for the port, it won't fit for the other data.
Use administered objects to give my application a means to pass data in to the RA. This idea is mentioned here. I guess this does it, but the spec states in chapter 13.4.2.3 that
Note, administered objects are not used for setting up asynchronous message
deliveries to message endpoints. The ActivationSpec JavaBean is used to hold all
the necessary activation information needed for asynchronous message delivery
setup.
But I cannot get any dynamic data to the ActivationSpec object (neither through a DeploymentDescriptor nor through annotations). Or did I miss something here? :-)
Use JDBC directly to access the data (also grabbed the idea from here). While this is presumably the best idea, it does not work for the mentioned licensing data as it is not stored in the db.
The last idea I had was to put a method in the MessageDrivenBean (through my interface) that is used to fetch data from within the RA. That method could be called from the RA and would supply the data. But: I just think that is quite abusive as it couples the RA to the app.
Dear community, what are your thoughts on this one? I'm afraid it's not so easy to find answers to these questions, so I'd be quite happy about opinions!
Thanks and cheers,
Julius

In the ra.xml there is the possibility to define config-properties. In Websphere these then show up as editable fields in a table of custom properties for the selected resource adapter. I'm working on a similar problem, I also need to pass hostname / port info to an RA. Unfortunately I haven't figured out how to read the contents of these fields from within the RA however.

The solution I finally came up with is to use the #ConfigProperty annotation. This means I use option one of my question above.
So my ResourceAdapter class looks like this:
public class Hl7ResourceAdapter implements ResourceAdapter {
#ConfigProperty
private Integer port = null;
// Rest from ResourceAdapter interface omitted here...
// Use port here to open socket...
}
The #ConfigProperty fields can now be set through either
a resource-adapter-config
the ra.xml deployment descriptor
Now in order to reconfigure these settings I use glassfish's REST interface to change these settings programmatically (one could also use the asadmin create-resource-adapter-config command). I circumvent the problem, that glassfish does not restart the application that uses the resource adapter by simply restarting it myself through REST. (To be precise: I disable the application and then reenable it to get around another bug in glassfish)
A few additional notes:
We deploy the resource adapter's .rar file into the .ear of the application using it.
We have a separate application outside glassfish (standalone) that calls the REST interface to do such things as restart the resource adapter application etc. It is obvious that an application cannot restart itself properly.
Hope this helps. kutuzof, will this get you any further?