Posts Tagged ‘OC4J’

Exception-handling in JAX-WS Web Services on WebLogic

There is more to exception-handling in JAX-WS Web Services than meets the eye. Especially when throwing custom (checked) exceptions from your Java methods that are exposed as Web Service operations. There’s a nice blog by Eben Hewitt on using SOAP Faults and Exceptions in Java JAX-WS Web Services. I recommend reading it; especially when you get the following error: javax.xml.ws.soap.SOAPFaultException java.lang.NoSuchMethodException. This is one of the issues you might run into when migrating from Oracle Application Server (OC4J) to Oracle WebLogic Server.

Migrating EJB 3 applications from OC4J to WebLogic

In a previous post I talked about migrating JAX-WS Web Service projects from JDeveloper 10g/OC4J to JDeveloper 11g/WebLogic. This is one of the activities in a current migration project of a SOA-environment from an OC4J-based stack (OC4J 10g, JDeveloper 10g, SOA Suite 10g, ADF 10g, WebCenter 10g, EJB 3/TopLink Essentials) to a WebLogic-based stack (WebLogic 10g, SOA Suite 10g, ADF 11g, EJB 3/EclipseLink).

As mentioned in the previous post, a lot of migration steps are performed automatically when importing 10g projects in JDeveloper 11g. This is also the case for EJB 3 applications that use TopLink Essentials as persistence provider. All references to this provider are replaced with EclipseLink references since EclipseLink -based on TopLink 11g- is/will be the de facto Oracle persistence provider. Deployment of these EJB 3 components to our development environment -Integrated WebLogic Server in JDeveloper 11g- works fine and everything runs smoothly.

For test, acceptance and production environments we use separate WebLogic 10.3 installations. These are “clean” environments. Instead of having all kinds of frameworks deployed on your application server -as is the case for Oracle Application Server and the Integrated WebLogic Server in JDeveloper 11g- this environment is actually clean, lean and mean.

Although in my opinion this is what you want out-of-the-box -you don’t have all kinds of preinstalled frameworks that you do not use, less classloading issues, and so on- initial deployment of our EJB 3 components failed when deploying: NoClassDefFoundError: org/eclipse/persistence/jpa/PersistenceProvider. That’s because Oracle WebLogic 10.3 is not shipped with TopLink 11g/EclipseLink.

There are several solutions for this. You can use patches 9J3A and 5KXF to install TopLink 11g/EclipseLink on WebLogic 10.3. They can be downloaded using SmartUpdate; I couldn’t find them on MetaLink (yet). You can also install EclipseLink manually on an Oracle WebLogic domain as described in the EclipseLink’s User Guide. Other ways of solving this -although I don’t recommend these options- is to package the persistence provider with every application. That means including EclipseLink archives into an application’s WAR or EAR. Or you can switch to Kodo -BEA’s former JPA implementation- since this is shipped with Oracle WebLogic 10.3. However in the latter case you’re not using the go-forward/strategic persistence provider, which is EcslipseLink. Note that later versions of Oracle WebLogic will probably ship with EclipseLink.

Password hardcoded in JMS Adapter on OC4J

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.