I have a foreign JMS provider set up for our Sonic installation, with username/password specified for both the JMS server (aka JNDI context) and the connection factory.
The JNDI lookups are working fine, but when trying to establish a connection use the connection factory, I get an InauthenticClient exception. When I set a notification watch on the Sonic message broker to see the rejections for connection requests coming from WebLogic, I see that the user name is not being supplied.
This all works in standalone test code with the same username and password, connecting directly to Sonic, and in Sonic's connection notification watches I do see the user name (different code; the WebLogic application is a servlet application written using Spring).
Has anyone seen a similar problem, or has an idea of what can be going wrong?
One other point - same username/password for both JNDI and ConnectionFactory.
BTW, I just tried changing the connection factory password to different values
1. from the original, whose encrypted value does not match that of the JNDI password;
2. back to the original
3. to another random value
4. back to the original.
Each time, after saving and activating the config change, I opened the JMS config descriptor in the domain's config directory, and looked at the encrypted passwords for the connection factory. None of the three encrypted values for the original password is the same as any of the others for the same password, and none match that for the connection factory. Is this the expected behavior?
Is the Servlet accessing the Connection Factory via an EJB standard resource reference? I think this may be needed so that the app server can have the opportunity to wrap the connection and inject the Foreign JMS credentials into "createConnection".
See http://docs.oracle.com/cd/E21764_01/web.1111/e13727/j2ee.htm#i1313669 for samples.
In my test web app (attached, includes sources), I have the following in web.xml:
And in weblogic.xml:
In the app, I just prepended “java:comp/env/” to the JNDI name spec'd in the res-ref-name, e.g,. java:comp/env/jms/sms/replication/SMS_Repl_XACF
I did not bother doing the same with the topics, it did not seem necessary. Is there any real wrapper-based benefit to doing so?