OSB: Custom XPath vs Java Callout classloader difference

the Custom Xpath classloader doesn't access the jars in the domain lib folder (like /opt/oracle/domains/osbpl1do/lib folder), while the java callout does. So a function might work when invoked by JavaCallout, but give a nasty error from a customxpath:

 java.lang.ClassNotFoundException: org.apache.commons.codec.binary.Hex
 at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:297)
 at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:270)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
 at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
 at weblogic.utils.classloaders.GenericClassLoader.loadClass(GenericClassLoader.java:179)

If you need some common libraries in a Custom Xpath, you better add the jar explicitly to the JVM classpath

vi /opt/oracle/domains/osbpl1do/bin/setDomainEnv.sh

EXT_POST_CLASSPATH=/opt/oracle/domains/osbpl1do/lib/commons-codec-1.4.jar

restart your managed server
Check the JVM classpath:

pid="the managed server pid"
jinfo -sysprops ${pid} | grep java.class.path | awk -F'=' '{print $2}'

this gives me this new classpath:

....many more
/opt/oracle/fmw11_1_1_5/wlserver_10.3/server/lib/xqrl.jar
/opt/oracle/domains/osbpl1dom/lib/commons-codec-1.4.jar
/opt/oracle/fmw11_1_1_5/patch_wls1035/profiles/default/sys_manifest_classpath/weblogic_patch.jar
....many more

For more on WebLogic classloader, see here

Java callout in SOA Suite

oracle.tip.mediator.common.api.IJavaCallout is the interface to implement.

Here the interface is documented.

I have been looking for the Javadoc online but could find none.

It is in C:\Oracle1\Middleware\jdeveloper\soa\modules\oracle.soa.mediator_11.1.1\mediator.jar

Voila a Java callback naked and crude:

import java.util.logging.Logger;

import oracle.tip.mediator.common.api.CalloutMediatorMessage;
import oracle.tip.mediator.metadata.CaseType;


public class MyClass implements oracle.tip.mediator.common.api.IJavaCallout {

    public void initialize(Logger logger) {
    }

    public boolean preRouting(CalloutMediatorMessage calloutMediatorMessage) {
        return false;
    }

    public boolean preRoutingRule(CaseType caseType, CalloutMediatorMessage calloutMediatorMessage) {
        return false;
    }

    public boolean postRoutingRule(CaseType caseType, CalloutMediatorMessage calloutMediatorMessage, CalloutMediatorMessage calloutMediatorMessage1, Throwable throwable) {
        return false;
    }

    public boolean postRouting(CalloutMediatorMessage calloutMediatorMessage, CalloutMediatorMessage calloutMediatorMessage1, Throwable throwable) {
        return false;
    }

    public boolean preCallbackRouting(CalloutMediatorMessage calloutMediatorMessage) {
        return false;
    }

    public boolean postCallbackRouting(CalloutMediatorMessage calloutMediatorMessage, Throwable throwable) {
        return false;
    }
}

To be noticed that the postRouting/postRoutingRule have 2 parameters, one is the request and the other the response (I guess!)

Callback has a single parameter because there is no way to remember the request to which this callback is the response.... at least not in Mediator.


Here a good Hello World tutorial on the subject.

Coherence: running 2 coh clusters in OSB

Step 1:

backup the old library 3.5.2b463 existing at
/Oracle/Middleware/coherence_3.5/lib/

and replace it with the "latest stable" 3.5.3/465p6

We should definitely avoid using 2 different versions of Coherence for the OSB and the Custom cluster, just to make our life simpler.

Now, OSB should start the internal Coherence cluster using the 3.5.3/465p6 version (check the MS logs)

Step 2:

put somewhere in the MS classpath the tangosol-coherence-override.xml for the Custom node.
This will not interfere with the built-in OSB Coherence, which is loading its config from
com.bea.alsb.coherence-impl.jar!/tangosol-coherence-override.xml and $DOMAIN_HOME/config/osb/coherence/osb-coherence-override.xml

Check the line
Created a new cluster "OSB-cluster" with Member(Id=1, Timestamp=bla, Address=127.0.0.1:7890..)


which corresponds to the $DOMAIN_HOME/config/osb/coherence/osb-coherence-override.xml settings



Step 3:

Add /Oracle/Middleware/coherence_3.5/lib/coherence.jar and /Oracle/Middleware/coherence_3.5/lib/je.jar to the MS classpath, so that we don't need to deploy these JARs in the OSB project making the JavaCallout to the Custom cluster.
REMEMBER: having these libraries in the CLASSPATH doesn't mean that the OSB internal cluster will load the Coherence classes in the System Classloader! The ALSB Coherence Cache Provider EAR specifies to load them in the EAR classloader!

If you are using this utility, add to MS classpath also /coh-sl/lib/coherence-serialization-support.jar which contains the PofSerialized classes (they are available here
http://coherence.politext.info/pof-serializer-generator-java-apt-plugin )



Step 4:
code your Java callout class to return instances of
org.apache.xmlbeans.XmlObject
Library Path: /Oracle/Middleware/modules/com.bea.core.xml.xmlbeans_2.2.0.0.jar

in practice:

import org.apache.xmlbeans.XmlObject;

public static XmlObject myJavaCallout() {
.... invoke your code getting data from Coherence Cache....
XmlObject returnObject = XmlObject.Factory.parse("");
return returnObject;

and make sure that in your OSB Java Callout you DON'T return by reference.



You will see that at the first invocation of Coherence you will join the Coherence Cluster, from the second onwards this will not happen.

HookedJarClassLoader.assertOpen

In a Java Callout in OSB I get this.... no clue why... no trace in google..

java.lang.IllegalStateException: Already closed
 at com.bea.wli.sb.resources.archive.classloader.HookedJarClassLoader.assertOpen(HookedJarClassLoader.java:345)
 at com.bea.wli.sb.resources.archive.classloader.HookedJarClassLoader.getResource(HookedJarClassLoader.java:174)
 at com.tangosol.util.ExternalizableHelper.loadResource(ExternalizableHelper.java:3020)
 at com.tangosol.io.pof.ConfigurablePofContext.loadResource(ConfigurablePofContext.java:1224)
 at com.tangosol.io.pof.ConfigurablePofContext.createPofConfig(ConfigurablePofContext.java:792)
 at com.tangosol.io.pof.ConfigurablePofContext.initialize(ConfigurablePofContext.java:754)
 at com.tangosol.io.pof.ConfigurablePofContext.setContextClassLoader(ConfigurablePofContext.java:324)
 at com.tangosol.coherence.component.util.daemon.queueProcessor.Service.ensureSerializer(Service.CDB:45)

investigating...

OSB: passing a OSB variable to a Java Callout

If you declare a Java static function with an input parameter of type Employee, and your $body contains a valid Employee structure, and you try to pass it to the Java callout as it is, you will get a wonderful:

Value of type 'org.apache.xmlbeans.impl.values.XmlAnyTypeImpl' cannot be type-cast to Employee

The reason being that internally OSB represents every variable (including $body) as a
https://www.docjar.com/docs/api/org/apache/xmlbeans/impl/values/XmlAnyTypeImpl.html

which implements the XmlObject interface, as specified here in the OSB Java Callout doc:

http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/eclipsehelp/ui_ref.html#sj_uiSplitJoinJavaCalloutProperties



No fear! In your Java code, you can use my fantastic XMLLoader class, do a toString on the XmlObject and parse it into the Java class using JAXB:

http://javatoolsforweblogic.googlecode.com/svn/trunk/xmlLoader/XMLLoader.java

OSB and Java Callout, a fierce discussion

here is my take:

During a discussion, somebody said that we should use Java Callouts with great care, because
A) they introduce an extra artifact, a JAR file (or multiple JAR files) to maintain;

and

B) because there are performance issues tied to Java Callouts.

For point A, I can only say that Ant exists :o) , so there is no real need to generate and deploy JARs by hand. Here http://ant.apache.org/ is Ant :o) , your friend.

For point B, I am still looking for some documentation or actual POC proving that Java Callouts introduce a performance hit, and under which circumstances, and of which extent. So if you are aware of anything, please show us.

I am not saying we SHOULD use Java Callouts, but I am not ruling out the technology in specific cases where it really makes sense.


Anyway here is the documentation from Oracle
http://download.oracle.com/docs/cd/E13159_01/osb/docs10gr3/userguide/pojo.html


I found this particularly interesting:

A single POJO can be invoked by one or more proxy services. All the threads in the proxy services invoke the same POJO. Therefore, the POJO must be thread safe. A class or method on a POJO can be synchronized, in which case it serializes access across all threads in all of the invoking proxy services. Any finer-grained concurrency (for example, to control access to a DB read results cache and implement stale cache entry handling) must be implemented by the POJO code.

It is generally a bad practice for POJOs to create threads.