Wednesday Dec 28, 2011

Too Much Debug

Too Much Debug

Remains of a Roast Turkey

Well it is Christmas and as is traditional, in England at least, we had roast turkey dinner.  And of course no matter how big your family, turkeys come in only two sizes; massively too big or enormously too big!  So by the third day of Christmas you are ready never to eat turkey again until thanksgiving.  Your trousers no longer fit around the waist, your sweater is snug around the midriff, and your children start talking about the return of the Blob.

And my point?  Well just like the food world, sometimes in the SOA world too much of a good thing is bad for you.  I had just extended my BPM domain with OSB only to discover that I could no longer start the BAM server, or the newly configured OSB server.  The error message I was getting was:

starting weblogic with Java version:
FATAL ERROR in native method: JDWP No transports initialized, jvmtiError=AGENT_ERROR_TRANSPORT_INIT(197)
ERROR: transport error 202: bind failed: Address already in use
ERROR: JDWP Transport dt_socket failed to initialize, TRANSPORT_INIT(510)
JDWP exit error AGENT_ERROR_TRANSPORT_INIT(197): No transports initialized [../../../src/share/back/debugInit.c:690]
Starting WLS with line:
C:\app\oracle\product\FMW\JDK160~2\bin\java -client -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,address=8453,server=y,suspend=n

The mention of JDWP points to a problem with debug settings and sure enough in a development domain the setDomainEnv script is set up to enable debugging of OSB.  The problem is that the settings apply to all servers started with settings in the setDomainEnv script and should really only apply to the OSB servers.  There is a blog entry by Jiji Sasidharan that explains this and provides a fix.  However the fix disables the debug flag for all servers, not just the non-OSB servers.  So I offer my extension to this fix which modifies the setDomainEnv script as follows from:

set debugFlag=true


rem Added so that only OSB server starts in debug mode
if "%SERVER_NAME%"=="osb_server1" (
    set debugFlag=true

This enables debugging to occur on managed server osb_server1 (this should match the name of one of your OSB servers to enable debugging).  It does not enable the debug flag for any other server, including other OSB servers in a cluster.  After making this change it may be necessary to restart the Admin Server because it is probably bound to the debug port.

So the moral of this tale is don’t eat too much turkey, don’t abuse the debug flag, but make sure you can get the benefits of debugging.

Have a great new year!

Thursday Sep 29, 2011

Mapping the Java World Part I

How to Customise Java/XML Mapping in SOA Suite
Part I Setting Up EclipseLink MOXy

The Challenge

java-xml-duke-mediumDuring a recent POC, the customer asked us to integrate with several of their backend EJBs, which hosted legacy code talking to backend systems.  The EJB interfaces could not be changed, and had to be called a certain way to be successful.  The customer was looking to phase out another set of "integration EJBs", written over the last few years that orchestrated their core backend EJBs.  SOA Suite will allow them to drastically reduce their development time, and provide much better visibility into the processes as they run.  Given their past experiences (writing their integration EJBs was painful and long winded), one of the key requirements was to support their legacy EJBs without writing code in the SOA environment.  At first glance this seemed impossible, because we couldn't change anything on the EJB side.  In addition many of the parameters to the interfaces contained either incomplete annotations or methods that didn't follow the JavaBeans spec.  This was not previously a problem for them because all their EJBs ran in the same JVM and were making local Java calls

We decided to use a powerful yet obscure feature of SOA Suite to do the mapping.  Chapter 49.7 of the SOA Suite Developer's guide mentions this marriage between EclipseLink MOXy and SOA Suite, but it does more than advertised, and works outside of the Spring Framework components.  We decided to use this functionality to "fix" some of the things we had mapping issues with in the customer code.  Additionally, we used the framework to do other helpful tasks, such as changing namespaces, fixing arrays, and removing unnecessary mappings.

In this article we'll cover the theory behind the use of this functionality, basic setup and usage, and several examples to get you started.


When we use an EJB Reference or a Spring component in SOA Suite we usually want to wire it to a non-Java resource.  When we do this JDeveloper uses JAXB to create an XML representation of the parameters and return values of the methods in the Java interface we are using.  In this article we will show how to override those mappings.  Overriding the default generation of mappings allows us to specify target namespaces, rationalize the structure of the data and remove unneeded properties in the Java classes.  Some things we may want to customize include:

  • Specifying concrete implementations for abstract classes and interfaces in the interface
    • This allows us to map to Java objects in the interface which cannot be instantiated directly.  For example often we have lists of abstract classes or interfaces, by  specifying the possible concrete implementations of these classes we can generate an XML schema that includes additional properties available only through the concrete classes.
  • Hiding unwanted properties
    • This allows us to remove properties that are not needed for our implementation, or not needed because they are convenience properties such as the length of an array or collection which can easily be derived from the underlying array or collection.
  • Providing wrappers for arrays and collections
    • The default mapping for an array or collection is to provide a list of repeating elements.  We can modify the mapping to provide a wrapper element that represents the whole array or collection, with the repeating elements appearing a level down inside this.
  • Changing WSDL namespaces
    • It is often necessary to change the namespaces in a generated WSDL to match a corporate standard or to avoid conflicts with other components that are being used.


EclipseLinkMoxySOA Suite allows us to describe in XML how we want a Java interface to be mapped from Java objects into XML.  The file that does this is called an “Extended Mapping” (EXM) file.  When generating a WSDL and its associated XML Schema from a Java interface SOA Suite looks for an EXM file corresponding to the Java Interface being generated from.  Without this file the mapping will be the “default” generation, which simply attempts to take each field and method in the Java code and map it to an XML type in the resulting WSDL.  The EXM file is used to describe or clarify the mappings to XML and uses EclipseLink MOXy to provide an XML version of Java annotations.  This means that we can apply the equivalent of Java annotations to Java classes referenced from the interface, giving us complete control over how the XML is generated.  This is illustrated in the diagram which shows how the WSDL interface mapping depends on the JavaInterface of the EJB reference or Spring component being wired (obviously), but is modified by the EXM file which in turn may embed or reference an XML version of JAXB annotations (using EclipseLink MOXy).

The mapping will automatically take advantage of any class annotations in the Java classes being mapped, but the XML descriptions can override or add to these annotations, allowing us fine grained control over our XML interface.  This allows for changes to be made without touching the underlying Java code.


Using the mapper out of the box is fairly simple.   Suppose you set up an EJB Reference or Spring component inside your composite.  You'd like to call this from a Mediator or BPEL Process which expect to operate on a WSDL.  Simply drag a wire from the BPEL process or Mediator to the EJB or Spring component and you should see a WSDL generated for you, which contains the equivalent to the Java components business interface and all required types.  This happens for you, as the tool goes through the classes in your target.

But what if you get a "Schema Generation Error" or if the generated WSDL isn't correct.  As discussed earlier there may be a  number of changes we need or want to make to the mapping.   In order to use an "Extended Mapping", or EXM file, we need to do the following:

  1. We need to register the EclipseLink MOXy schema with JDeveloper.  Under JDeveloper Tools->Preferences->XML Schemas we click Add… to register the schema as an XML extension.

    The schema is found in a jar file located at <JDEV_HOME>/modules/org.eclipse.persistence_1.1.0.0_2-1.jar! and the schema is inside this jhar at /xsd/eclipselink_oxm_2_1.xsd so the location we register is jar:file:/<JDEV_HOME>/modules/org.eclipse.persistence_1.1.0.0_2-1.jar!/xsd/eclipselink_oxm_2_1.xsd where <JDEV_HOME> is the location where you installed JDeveloper.

    NOTE: This will also work as OXM instead of XML.  But if you use an .oxm extension then in each project you use it you must add a rule to copy .oxm files from the source to the output directory when compiling.
  2. Change the order of the source paths in your SOA Project to have SCA-INF/src first.  This is done using the Project Properties…->Project Source Paths dialog.  All files related to the mapping will go here.  For example, <Project>/SCA-INF/src/com/customer/EXM_Mapping_EJB.exm, where com.customer is the associated java package.
  3. We will now use a wizard to generate a base mapping file.
    1. Launch the wizard New XML Document from XML Schema (File->New->All Technologies->General->XML Document from XML Schema).
    2. Specify a file with the name of the Java Interface and an .exm extension in a directory corresponding to the Java package of the interface under SCA-INF/src.  For example, if your EJB adapter defined soa.cookbook.QuoteInterface as the remote interface, then the directory should be <Project>/SCA-INF/src/soa/cookbook and so the full file path would be <Project>/SCA-INF/src/soa/cookbook/QuoteInterface.exm.  By using the exm extension we are able to Use Registered Schema which will automatically map to the correct schema so that future steps in the wizard will understand what we are doing.
    3. The weblogic-wsee-databinding schema should already be selected, select a root element of java-wsdl-mapping and generate to a Depth of 3.  This will give us a basic file to start working with.
  4. As recommended by Oracle, separate out the mappings per package, by using the toplink-oxm-file element.  This will allow you, per package, to define re-usable mapping files outside of the EXM file.  Since the EXM file and the embedded mappings have different XML root elements, defining them separately allows JDeveloper to provide validation and completion, a sample include is shown below:

    <?xml version="1.0" encoding="UTF-8" ?>
    <java-wsdl-mapping xmlns="">
        <toplink-oxm-file file-path="./mappings.xml" java-package="soa.cookbook"/>

  5. Create an "OXM Mapping" file to store custom mappings.  As mentioned, these files are per package, separate from the EXM files, and re-usable.  We can use the "New XML Document from Schema" to create these as well.  In this case, they will have an XML or OXM extension, use the persistence registered schema (, and be stored relative to the EXM file.  That is, they can go in the same directory, or in other directories, as long as you refer to them by relative path from the EXM file.

    <?xml version="1.0" encoding="UTF-8" ?>
    <xml-bindings xmlns="">
      <!-- Set target Namespace via namespace attribute -->
      <xml-schema namespace=

  6. In the newly created OXM Mapping file, we can use completion and validation to ensure we follow the EclipseLink MOXy documentation.  For example, to declare that a field is to be transient and not show up in the WSDL mapping, do this:

    <?xml version="1.0" encoding="UTF-8" ?>
    <xml-bindings xmlns="">
      <!-- Set target Namespace via namespace attribute -->
      <xml-schema namespace=
        <java-type name="soa.cookbook.QuoteRequest">
            <!-- Can remove mappings by making them transient via xml-transient element -->
        <xml-transient java-attribute="product"/>

  7. Once complete, delete any existing wires to the Java components and rewire.  You should notice the dialog box change to indicate that an extended mapping file was used.

    Note that an “extended mapping file” was used.
  8. As an iterative process, changing a mapping is quite easy.  Simply delete the wire, and JDeveloper will offer to delete the WSDL file, which you should do.  Make updates to the EXM and OXM Mapping files as required, and rewire.  Often this occurs several times during development, as there are multiple reasons to make changes.  We will cover some of these in our next entry.


The extended mapping file puts the SOA composite developer in control of his own destiny when it comes to mapping Java into XML.  It frees him from the tyranny of Java developer specified annotations embedded in Java source files and allows the SOA developer to customize the mapping for his own needs.  In this blog entry we have shown how to set up and use extended mapping in SOA Suite composites.  In the next entry we will show some of the power of this mapping.


To use this effectively you need to download the following patch from MetaLink:

    • Note that this patch includes a number of fixes that includes a performance fix for the Java/XML mapping in SOA Suite.

Sample Code

There is a sample application uploaded as  Unzip the provided file and open the EXMMappingApplication.jws in JDeveloper.  The application consists of two projects:

    • This project contains an EJB and needs to be deployed before the other project.  This EJB provides an EJB wrapper around a POJO used in the Spring component in the EXMMapping project.
  • EXMMapping
    • This project contains a SOA composite which has a Spring component that is called from a Mediator, there is also an EJB reference.  The Mediator calls the Spring component or the EJB based on an input value.  Deploy this project after deploying the EJB project.

Key files to examine are listed below:

  • in package soa.cookbook
    • This is the same interface implemented by the Spring component and the EJB.
    • It takes a QuoteRequest object as an input parameter and returns a QuoteResponse object.
  • Quote.java_diagram in package soa.cookbook
    • A UML class diagram showing the structure of the QuoteRequest and QuoteResponse objects.
  • EXM_Mapping_EJB.exm in package soa.cookbook
    • EXM mapping file for EJB.
    • This is used to generate EXM_Mapping_EJB.wsdl file.
  • QuoteInterface.exm in package soa.cookbook
    • EXM mapping file for Spring component.
    • This is used to generate QuoteInterface.wsdl file.
  • mappings.xml in package soa.cookbook
    • Contains mappings for QuoteRequest and QuoteResponse objects.
    • Used by both EXM files (they both include it, showing how we can re-use mappings).
    • We will cover the contents of this file in the next installment of this series.

Sample request message

<soap:Envelope xmlns:soap="">
  <soap:Body xmlns:ns1="
        <ns1:product>Product Number 1</ns1:product>
        <ns1:product>Product Number 2</ns1:product>
        <ns1:product>Product Number 3</ns1:product>
      <!-- provider should be “EJB” or “Spring” to select the appropriate target -->


This blog article was co-written with my colleague Andrew Gregory.  If this becomes a habit I will have to change the title of my blog!


Blaise Doughan, the Eclipse MOXy lead was extremely patient and helpful as we worked our way through the different mappings.  We also had a lot of support from David Twelves, Chen Shih-Chang, Brian Volpi and Gigi Lee.  Finally thanks to Simone Geib and Naomi Klamen for helping to co-ordinate the different people involved in researching this article.

Friday Jun 17, 2011

Begin the Clone Wars Have!

How to clone an existing virtual box image without having to duplicate the disk.[Read More]

Tuesday May 17, 2011

Installing the Latest & Greatest

Setting up Virtual Box with an Oracle Enterprise Linux 6 Image running SOA Suite and OSB, allowing the use of HotSpot 1.6 or HotSpot 1.7 or JRockit.[Read More]

Thursday Feb 03, 2011

Gone With the Wind?

[Read More]

Friday Jan 21, 2011

Fusion Middleware Released

[Read More]

Tuesday Oct 19, 2010

Installing an 11g SOA Cluster – Part III Configuration

[Read More]

Monday Mar 29, 2010

Cold Start

[Read More]

Monday Nov 30, 2009

Calling EJB 3 from BPEL 10.1.3

[Read More]

Tuesday Nov 10, 2009

Obtaining WSDL from a Deployed 10g BPEL Process

[Read More]

Friday Oct 30, 2009

Software Required for Test 11g SOA Cluster

[Read More]

Tuesday Oct 27, 2009

What I learnt About Clustering

[Read More]

Wednesday Jul 01, 2009

11g SOA Suite Now Available

[Read More]

Tuesday Jun 30, 2009

Clustering SOA Suite

[Read More]

Wednesday Jun 03, 2009

OTN Podcast

[Read More]

Musings on Fusion Middleware and SOA Picture of Antony Antony works with customers across the US and Canada in implementing SOA and other Fusion Middleware solutions. Antony is the co-author of the SOA Suite 11g Developers Cookbook, the SOA Suite 11g Developers Guide and the SOA Suite Developers Guide.


« March 2015