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);
Related
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.
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 have Tomcat 7.0 that has some Java code that I use to connect to a Weblogic 12c server to manage the weblogic server. I can use RMI/IIOP but I cannot use T3. Everyone says make sure the wlfullclient.jar file is used and available to the Tomcat classpath. It is. I know because if I remove it the error I get is "Unsupported protocol: T3". And my RMI/IIOP connection does not work. So I just swtiched the IIOP protocol to T3 and I get:
Failed to retrieve RMIServer stub: javax.naming.NameNotFoundException: Name [t3://127.0.0.1:7001/weblogic.management.mbeanservers.domainruntime] is not bound in this Context. Unable to find [t3:]
Looking around at all the online documentation I am wondering if this means I have to set up a config file on my tomcat. All the context connection info is in the code--host, port, userID, password, etc.
So am confused as to why Tomcat says it cannot find t3 and why it can't bind to the weblogic.management.mbeanservers.domainruntime mbean. What am I missing?
Try putting
"weblogic.management.remote" as JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES
in your Environment, plus principal and credentials, then create new JMXServiceURL(...) with
"service:jmx:t3://localhost:7001/jndi/weblogic.management.mbeanservers.domainruntime"
and pass that to JMXConnectorFactory.connect(serviceUrl, env).
Also, wlthint3client.jar should be enough for this - but I am not sure about this, it's probably safer to build your own wlfullclient.jar as you did...
I am not sure how you generated the wlfullclient.jar and what version of JVM you are using.
Can you make sure you follow the steps mentioned in the below page to generate the jar.
http://docs.oracle.com/cd/E12840_01/wls/docs103/client/jarbuilder.html
Those jar can be deceiving.
Whichever you use, make sure is at the begining at the path, and also you can add this code to check you have everything in place.
Class<?> cl =
Class.forName("weblogic.management.remote.t3.ClientProvider");
it is absolutely no problem to connect to a ActiveMQ as standalone client. The only thing you need is to add the activemq-all-5.4.1.jar and there you go...
...
prop.put(Context.SECURITY_AUTHENTICATION , "system");
prop.put(Context.SECURITY_CREDENTIALS,"manager");
prop.put(Context.INITIAL_CONTEXT_FACTORY,"org.apache.activemq.jndi.ActiveMQInitialContextFactory");
prop.put(Context.PROVIDER_URL,"tcp://localhost:61616");
prop.put("connectionFactoryNames", "TopicCF");
prop.put("topic.topic1", "topic1");
InitialContext ctx = new InitialContext(prop);
...
Now you want to connect to Glassfish V3.x and it seems impossible to get the right libraries and classes in order to connect. While it still was possible in Glassfish V2.x I did not succeed yet to get the equivalent of above code running for Glassfish !
...
Properties properties = new Properties();
properties.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.appserv.naming.S1ASCtxFactory");
properties.put(Context.PROVIDER_URL, "iiop://localhost:3700");
InitialContext context = new InitialContext(properties)
...
Does anyone have an answer on this ? No, I dont want to deploy an enterprise app-client just to read from a Glassfish queue. There are similar threads here, but none guides anywhere.
Thanks for any tips
Sven
This is the complete list of client jars for glassfish 3 :
auto-depends.jar
deployment-common.jar
glassfish-corba-internal-api.jar
internal-api.jar
management-api.jar
bean-validator.jar
dol.jar
glassfish-corba-newtimer.jar
javax.ejb.jar
orb-connector.jar
common-util.jar
ejb-container.jar
glassfish-corba-omgapi.jar
javax.jms.jar
orb-iiop.jar
config-api.jar
ejb.security.jar
glassfish-corba-orb.jar
javax.resource.jar
security.jar
config-types.jar
glassfish-api.jar
glassfish-corba-orbgeneric.jar
javax.servlet.jar
ssl-impl.jar
config.jar
glassfish-corba-asm.jar
glassfish-naming.jar
javax.transaction.jar
transaction-internal-api.jar
connectors-internal-api.jar
glassfish-corba-codegen.jar
gmbal.jar
jta.jar
container-common.jar
glassfish-corba-csiv2-idl.jar
hk2-core.jar
kernel.jar
When connecting to Glassfish V3, there is no need to supply any properties to the InitialContext constructor. You can simply use the no-arg constructor. To specify the server name and port, set the -Dorg.omg.CORBA.ORBInitialHost and -Dorg.omg.CORBA.ORBInitialPort properties on the JVM, respectively.
As for the libraries, all you should need to include is the gf-client.jar file. It can be found at $GLASSFISH_HOME/lib. This jar file will automatically include whatever other libraries are needed.
For more information, please see http://glassfish.java.net/javaee5/ejb/EJB_FAQ.html#StandaloneRemoteEJB. Although that document addresses using EJBs in a stand-alone client, the same solutions apply to using JMS.
You can go see the solution I found when encountering quite the same issue : With which maven dependencies can i create a standalone JMS client for Glassfish ?
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.