Password hardcoded in JMS Adapter on OC4J

Lonneke Dikmans December 15th, 2007

One of the problems when you develop components in a service oriented architecture, is dealing with hard coded settings. When you invoke a webservice, you need to tell the client where it can find the service. This means hard coding the endpoint. When the application is ready to be promoted to the testing environment, you need to change this. In production it gets even worse: when an administrator decides to move a service, every client that uses it is in trouble. It gets worse when you use security: you need to authenticate and usually the passwords differ between development, test and production environments (at least they should).
That is one nice things of an Enterprise Service Bus: it abstracts endpoints from the clients. I was fiddling around with a JMS Adapter in an Oracle ESB project when I ran into a weird problem. The adapter failed with the message:


The Adapter Framework was unable to establish an outbound JCA connection due to the following issue: ORABPEL-12133
ERRJMS_JMS_EXCEP.
Unable to create JMS connection due to JMS exception.
Please examine the log file to determine the problem.
[Caused by: JMSServer[XP-LDIKMANS:12601]: failed to authenticate "oc4jadmin/welcome1" via "[ JAZNUserAdaptor: user=oc4jadmin] ".]
; nested exception is:
ORABPEL-12511
.....
etc

When I installed the SOA Suite (10.1.3.1) on my laptop, I changed the password for oc4jadmin from welcome1 to something I like better. It does not make sense that adapters that are installed by default don’t inherit the new password. It still had the old one!

To fix this, you can simply edit the password of the JmsAdapter:

  • Log in to the enterprise manager console
  • Click on the container where the soa suite is installed
  • Click on the default application
  • Click on JmsAdapter from the modules list
  • Click on Administration
  • Select the eis/Jms/TopicConnectionFactory from the list
  • Change the password so it matches the password of oc4jadmin
  • Click apply

This fixed the problem. The weird thing is that connection settings are also stored in the wsdl endpoint:

<service name="AcmeJMSAdapter">
<port name="Produce_Message_pt"
binding="tns:Produce_Message_binding">
<jca:address location=/
"eis/Jms/TopicConnectionFactory"
UIConnectionName="appServerSOA"
....
mcf.Username="oc4jadmin"
mcf.Password=[encoded_password]
UIJmsProvider="OC4JJMS" />
</port>
</service>

Apparently these are only used design time and not runtime. This is a good thing (because of the reasons I mentioned before), but it makes it very hard to find problems like these.

Leave comment

Comments: (0)

Leave your comment: