I'm using RAD 9.0 and trying to configure Queue connection factories in WebSphere Application Server 8.5. I have IBM MQ 7.0 (32-bit) installed on the same machine (Win7 64-bit).
After configuring Queue connection factories when I click on Test Connection it give an error :
A connection could not be made to WebSphere MQ for the following reason: CC=2;RC=2495;AMQ8568: The native JNI library 'mqjbnd' was not found. For a client installation this is expected. [3=mqjbnd]
Native library path (under JMS>WebSphere MQ messeging provider) is set to C:/Program Files (x86)/IBM/WebSphere MQ\java\lib.
I also tried to set it to C:/Program Files (x86)/IBM/WebSphere MQ\java\lib64 but still I'm getting the same error.
Also is it necessary to configure Queue Connection Factory for configuring Listener Port for MDB?
The error message means you have configured the connection factory to have a transport type of Bindings and so the WMQ Resource Adapter within WAS needs to load the native libraries located in the MQ installation (note the MQ client installation does not come with these libraries).
Assuming you want to connect in Bindings mode AND you have a full local MQ Server installation on the same box as the WAS server then you will need to configure the 'Native Library Path' on the WebSphere MQ messaging provider panel in WAS (Resources > JMS > JMS Providers). You should alter the provider that is at the same scope as the defined queue connection factory.
The MQ_INSTALL_ROOT property is an old property used in WAS 6.0 and WAS 6.1 and is only intended to be used for migration reasons in WAS 7 and onwards.
Note: If you have an ND environment then the 'Test Connection' operation could potentially run on the dMgr process rather than the server. If your dMgr is on a different host then the libraries will not be found. In this case you should ensure that the application server is running before selecting the 'Test Connection' button.
WAS uses environment variable MQ_INSTALL_ROOT to point to (embedded) WebSphereMQ Client (Environment->WebSphere Variables). Default value is ${WAS_INSTALL_ROOT}/lib/WMQ. I think you don't need a separate installation of WebSphereMQ client - it comes with WAS (I'm working with WAS8, but I guess they did not change it in 8.5).
As for your question, it might be the issue with the path: it uses spaces. Try to install WebSphereMQ client libs in a directory without spaces (e.g. C:\IBM\WMQClient). But I think you do not need it, check directory ${WAS_INSTALL_ROOT}/lib/WMQ - it should be there.
And about Activation Specification - you don't need Queue Connection Factory, you need only queue definition where Activation Specification will connect to.
Related
I am using SSLCIPHERSUITE(TLS_RSA_WITH_AES_128_CBC_SHA256) in our application (verified that it is used in the generated binding file) and same ciphersuite is also configured on the channel.
However, I am constantly getting the below error –
2020-03-19 12:52:46,145 [Camel (camelContext) thread #13 - JmsConsumer[queue]] [WARN] o.a.c.c.jms.DefaultJmsMessageListenerContainer [] - Could not refresh JMS Connection for destination 'queue' - retrying in 5000 ms. Cause: JMSWMQ0018: Failed to connect to queue manager 'ABC' with connection mode 'Client' and host name 'null'.; nested exception is com.ibm.mq.MQException: JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2400' ('MQRC_UNSUPPORTED_CIPHER_SUITE').
com.ibm.msg.client.jms.DetailedJMSException: JMSWMQ0018: Failed to connect to queue manager 'ABC' with connection mode 'Client' and host name 'null'.
When looked at ibm mq logs at the client end, the ciphersuite it is using is SSL_RSA_WITH_AES_128_CBC_SHA256
Troubleshooting tried:
Using -Dcom.ibm.mq.cfg.useIBMCipherMappings=false. Looks like this is not working for some reason and hence it is using SSL*** instead of TLS***. Tried a different ciphersuite as well and noticed same behavior. Configured same option in JMSAdmin call which generates binding file but no use.
Tried using preferTLS option provided by IBM but not useful in this case
Tried specifying FIPS setting at client end to YES and NO but same issue
Verified Java policy and it is unlimited strength jurisdiction policy
Verified Java version supports TLS**** cipher suite that is configured
Upgraded versions of ibm mq jars to 8.0.0.10 which is wmq client version on linux, also tried 8.0.0.12, 9.0.4.0, 9.1.**
Upgraded jms.jar to 2.0
Got certificates verified from MQ team and they all look right and complete
Can someone please let me know if they have faced similar issue and how it was resolved?
App is also using spring-jms 3.1.0-RELEASE and camel-jms 2.10.0
Finally resolved this issue. Had to configure -Dcom.ibm.mq.cfg.useIBMCipherMappings=false at two places. One in java opts of tomcat server startup and other in JMSAdmin used for generating binding file.
Downloaded and unpacked Websphere Liberty Profile wlp-javaee7-8.5.5.9.zip. I am behind a firewall and I was trying to install the adminCenter, but got the error:
CWWKF1219E: The IBM WebSphere Liberty Repository cannot be reached. Verify that your computer has network access and firewalls are configured correctly, then try the action again. If the connection still fails, the repository server might be temporarily unavailable.
To solve this I used information from http://viralpatel.net/blogs/http-proxy-setting-java-setting-proxy-java/.
Is there a better method to configure the access of various IBM utils to external repositories?
You can also set http proxy settings for installUtility by putting
proxyHost=my.proxy.server.ibm.com
proxyPort=9080
proxyUser=myname
proxyPassword={aes}AH5NLyd7DfGb12pK17Pw+
in your ${wlp.install.dir}/etc/repositories.properties as described in the Knowledge Center
Note that the password should be encoded with securityUtility
I'm connecting to the WebSphere instance from the stand-alone Java app which is quite trivial:
InitialContext initCtx = new InitialContext();
That code was working perfectly in WebSphere 7, but after updating to WebSphere 8.5 I got the following exception:
Caused by: org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07 completed: No
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1276)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1457)
at com.ibm.rmi.corba.ClientDelegate.createRequest(ClientDelegate.java:1164)
at com.ibm.CORBA.iiop.ClientDelegate.createRequest(ClientDelegate.java:1423)
at com.ibm.rmi.corba.ClientDelegate.request(ClientDelegate.java:1886)
at com.ibm.CORBA.iiop.ClientDelegate.request(ClientDelegate.java:1379)
at org.omg.CORBA.portable.ObjectImpl._request(ObjectImpl.java:458)
at com.ibm.WsnBootstrap._WsnNameServiceStub.getProperties(_WsnNameServiceStub.java:38)
at com.ibm.ws.naming.util.WsnInitCtxFactory.mergeWsnNSProperties(WsnInitCtxFactory.java:1441)
... 43 more
After research, I've fout out that IBM support page, which said to go to CSIv2 inbound and outbound settings (by me, Admin Console->Security->GlobalSecurity->RMI/IIOP security) and set the transport to SSL-Supported.
However, it didn't change anything. I've tried to change the 'Cleint certificate authentication' to Never, and Transport to TCP/IP for both CSIv2 inbound and outbound, but still without success. The error persisted until I've turned off 'Enable administrative security', which is not an option, because I need to enable 'Application Security' (the application logic depends of that).
How can I make my code working again? Everything was OK on WebSphere 7.
My research on this issue may prove useful to others;
WebSphere 8 changed the default setting of RMI/IIOP SSL security from
'supported' to 'required'. If you want a secure connection you'll need
to get the certs from the server and set Java system properties to files that specify the location of the certs;
com.ibm.CORBA.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/sas.client.props
com.ibm.SSL.ConfigURL=file:/opt/IBM/JazzSM/profile/properties/ssl.client.props
If this doesn't work, you'll need to start debugging by setting the following System properties;
com.ibm.CORBA.Debug=true
com.ibm.CORBA.CommTrace=true
com.ibm.CORBA.Debug.Output=/tmp/corba.log
By studying this log and orb trace logs in the working directory, I found that the client failed to establish an ephemeral TCP connection to the server at "port=0". No mention of SSL in the logs! I wrote a small app to test my code running as a java console app and found that the SSL connection was successful and it worked fine. By diff'ing the logs, I found that only in the good case, the JVM was finding a local file 'orb.properties'. I then found that in my problem case, my test app was using a different JVM and my real app was using a JVM that had no 'orb.properties'. I could resolve the problem in a number of ways .. e.g. by including an orb.properties in my application and injecting the contents as System properties.
In my case switching CSIV inbound to SSL-Supported from SSL-required and restarting the server helped.
The error description
org.omg.CORBA.TRANSIENT: initial and forwarded IOR inaccessible vmcid: IBM minor code: E07
is very vague and happens under many, not directly connected circumstances.
In my case it had nothing to do with RMI/IIOP security settings, but it was a classpath problem. I was still using old version of com.ibm.ws.webservices.thinclient.
Switching to thinclient 8.5.0, as well as setting the launch JRE to standard (Oracle) JVM has fixed the problem.
i am trying to access MQ queues using JMS. i am getting the below
java.lang.UnsatisfiedLinkError: no mqjbnd05 in java.library.path
i am passing
-Djava.library.path="C:\Program Files\IBM\WebSphere MQ\java\lib"
as the VM argument while running the program in eclipse. This issue is discussed quite a lot on the net but with out any conclusion. Has anyone resolved this? TIA.
As I had to deal with this error myself; and it took me a lot of time to find the right answer, I'd like to share it with the next one, who comes along this thread...
Actually the solution to the problem was very simple (at least in my case). It was not related to any CLASSPATH, java.library.path or installation issues.
I simply forgot to switch the MQConnectionFactory into the Client mode.
This has to be done, by simply calling
cf.setTransportType(WMQConstants.WMQ_CM_CLIENT);
or
cf.setTransportType(WMQConstants.WMQ_CM_BINDINGS_THEN_CLIENT);
or any other connection type, that fits your needs.
By default, the ConnectionFactory is in "Binding" mode (WMQ_CM_BINDINGS), which is intended for local server installations, as it is is stated in the IBM Documentation:
To connect to a queue manager in bindings mode, a WebSphere MQ classes for JMS application must run on the same system on which the queue manager is running.
This transport type is the same as the XMSC_WMQ_CONNECTION_MODE (WMQConstants.WMQ_CONNECTION_MODE) property, when using JNDI or the JmsFactoryFactory.
The same should apply to the other ConnectionFactory types: MQQueueConnectionFactory, MQTopicConnectionFactory, MQXAConnectionFactory, MQXAQueueConnectionFactory and MQXATopicConnectionFactory
Check the IMB Knowledge Center for more information about the different connection/binding options:
https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031720_.htm
https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q030560_.htm
You probably have some older MQ jar files either in your CLASSPATH, in the lib or in the EAR.
Remove them and you should be fine.
You should not put MQ files in your EAR or in the WEB-INF/lib folders. They should be in the classpath of your appserver.
I came across this while connecting using IBM MQ api.
I didn't find this issue to be related to classpath either.
This happened to me when I instantiated MQQueueManager before setting MQEnvironment's hostname and channel.
Just ensure that your code does not do that and that it instantiates the manager after the environment is set. Something like..
MQEnvironment.hostname = "mq hostname";
MQEnvironment.channel = "mq channel";
..more code..
this._queueManager = new MQQueueManager(qManager);
(Observed that it's OK to set MQEnvironment.port after MQQueueManager is initialized, but one would probably initialize everything related to MQEnvironment together)
This can happen if you actually installed MQ Client instead of MQ Server.
IBM has even written a whole help page about it:
WebSphere MQ Client installation missing mqjb*.dll files
Problem(Abstract)
You install the WebSphere MQ Client and notice three dll's are missing from the \Program Files\IBM\WebSphere MQ\Java\lib\ directory.
Symptom
The following dlls appear in the directory on a server install, but are not part of the Java™ client:
03/17/2003 10:59a 19,456 mqjbdf02.dll
03/17/2003 10:59a 57,856 mqjbnd05.dll
03/17/2003 10:59a 36,864 MQXAi02.dll
The subdirectory \jdbc\ appears on the server, but not on the client machine.
03/17/2003 10:59a 61,440 jdbcdb2.dll
03/17/2003 10:59a 61,440 jdbcora.dll
Cause
The files are missing because they are not provided nor needed in a client install.
Resolving the problem
The files are only included in the WebSphere MQ Server product.
Here is an easy recipe: Tell the Java VM to Load the DLL. Is your code similiar, e.g. do you use System.loadLibrary to load mqjbnd05.dll?
If yes - does it work outside eclipse, like starting the application from the command line? If this is the case, you could try starting the whole eclipse IDE with that library path.
And sometimes we have trouble with pathnames that contain spaces. Copy the dll to C:\, put that on the lib path and try again.
Ah, that's the problem, the specified dll is missing. This blog has a solution. Good luck!
In my case when I set the transport type , the error goes away. I was using MQConnectionFactory
mQQueueConnectionFactory.setTransportType( JMSC.MQJMS_TP_CLIENT_MQ_TCPIP);
I've deployed some Managed Beans on WebSphere 6.1 and I've managed to invoke them through a standalone client, but when I try to use the application "jconsole" distributed with the standard JDK can can't make it works.
Has anyone achieved to connect the jconsole with WAS 6.1?
IBM WebSphere 6.1 it's supossed to support JSR 160 JavaTM Management Extensions (JMX) Remote API. Furthermore, it uses the MX4J implementation (http://mx4j.sourceforge.net). But I can't make it works with neither "jconsole" nor "MC4J".
I have the Classpath and the JAVA_HOME correctly setted, so the issue it's not there.
WebSphere's support for JMX is crap. Particularly, if you need to connect to any secured JMX beans. Here's an interesting tidbit, their own implementation of jConsole will not connect to their own JVM. I have had a PMR open with IBM for over a year to fix this issue, and have gotten nothing but the runaround. They clearly don't want to fix this issue.
The only way I have been able to invoke remote secured JMX beans hosted on WebSphere has been to implement a client using the "WebSphere application client". This is basically a stripped down app server used for stuff like this.
Open a PMR with IBM. Perhaps if more people report this issue, they will actually fix it.
Update: You can run your application as a WebSphere Application Client in RAD. Open the run menu, then choose "Run...". In the dialog that opens, towards the bottom on the left hand side, you will see "WebSphere v6.1 Application Client". I'm not sure how to start and Application Client outside of RAD.
IT WORKS !
http://issues.apache.org/jira/browse/GERONIMO-4534;jsessionid=FB20DD5973F01DD2D470FB9A1B45D209?page=com.atlassian.jira.plugin.system.issuetabpanels%3Aall-tabpanel
1) Change the config.xml and start the server.
-see here how to change config.xml: http://publib.boulder.ibm.com/wasce/V2.1.0/en/working-with-jconsole.html
2) start the jconsole with : jconsole -J-Djavax.net.ssl.keyStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.keyStorePassword=secret -J-Djavax.net.ssl.trustStore=%GERONIMO_HOME%\var\security\keystores\geronimo-default -J-Djavax.net.ssl.trustStorePassword=secret -J-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;%GERONIMO_HOME%\repository\org\apache\geronimo\framework\geronimo-kernel\2.1.4\geronimo-kernel-2.1.4.jar
[or your version of geronimo-kernel jar]
3) in the jconsole interface->advanced, input:
JMX URL: service:jmx:rmi:///jndi/rmi://localhost:1099/JMXSecureConnector
user name: system
password: manager
4) click the connect button.
If you want the WebSphere MBeans this one works for me:
The key is to configure the classpath and the security properly.
in one line:
jconsole -J-Dwas.install.root=C:/was61 -J-Djava.ext.dirs=C:/was61/plugins;C:/was61/plugins/com.ibm.ws.security.crypto_6.1.0;C:/was61/lib;C:/was61/java/jre/lib/ext -J-Dcom.ibm.SSL.ConfigURL="file:../../properties/ssl.client.props" -J-Dcom.ibm.CORBA.ConfigURL="file:../../properties/sas.client.props" service:jmx:iiop://host:port/jndi/JMXConnector
where port = bootstrap port ex: (2809)
Be careful when setting the sas and the ssl props.
Robert
I have successfully connected to ActiveMQ and ServiceMix using the JConsole. Does WAS 6.1 use Java Management Extension (JMX) technology? JMX is required for JConsole.
If your path is set correctly it should work fine. On windows you go to System Properties -> Advanced Tab -> Environment Variables. Have your JAVA_HOME System variable set to the path of your JDK or JRE and your Path variable with %JAVA_HOME%/bin added somewhere in there. Then all you need to do is go to Start->Run->JConsole. Select the correct Process Name and your done.
Where are you having problems at? I hope this helps.
Edit:
Here is the Java Doc's on JConsole.
Hmm... I know that WebSphere is kind of hard to configure. Thats part of the reason we used ServiceMix for our ESB. Maybe its not enabled by default in WebSphere and you would have to turn it on in the config somewhere.
Websphere 6.1 does not support the JConsole for some reason even though it fully implements the JMS specs. Seems to be a week area at the moment. Your best bet is to look at the Admin client to implement you own console.
You all seem to be incorrect. I am running Websphere 6.1.041 , using JDK 1.5 , and I just started up Jconsole and used the "simple connect" tab to connect to localhost with port=0 and without a username and password and it works fine.