@WebService method returning a custom class containing a HashMap / JAX-WS

Greenhorn

Posts: 27

posted 15 years ago

Number of slices to send:

Optional 'thank-you' note:

Send

I am hoping someone else has seen this issue before.

I have JAX-WS endpoint service that has a method:

The hand coded BookOrder class looks like this:

/**
 * 
 */
package com.acme.book.beans;

import java.util.HashMap;
import java.util.Iterator;
import java.util.Map;
import java.util.Set;

import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlType;

/**
 * @date May 11, 2009

* @project BookOrderManagerWS
 * @filename BookOrder.java
 *
 */
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "BookOrder", namespace="http://beans.book.acme.com/")
public class BookOrder {
	
	private String orderID;
	private int orderType;
	private Book[] books;
	private HashMap<Integer, String> titleMap;
	
	/**
	 * @return the orderID
	 */
	public String getOrderID() {
		return orderID;
	}
	/**
	 * @param orderID the orderID to set
	 */
	public void setOrderID(String orderID) {
		this.orderID = orderID;
	}
	/**
	 * @return the orderType
	 */
	public int getOrderType() {
		return orderType;
	}
	/**
	 * @param orderType the orderType to set
	 */
	public void setOrderType(int orderType) {
		this.orderType = orderType;
	}
	/**
	 * @return the books
	 */
	public Book[] getBooks() {
		return books;
	}
	/**
	 * @param books the books to set
	 */
	public void setBooks(Book[] books) {
		this.books = books;
	}
	
	public HashMap<Integer, String> getTitleMap() {
		return titleMap;
	}
	public void setTitleMap(HashMap<Integer, String> titleMap) {
		this.titleMap = titleMap;
	}

}

We want to be able to compile our Java Bean objects into a "shared jar" that can be used by both the Client and Service sides of the wire - this is unusual, but in this case, the project owns both ends of the wire so they want to enforce consistent use of these objects. In the case of custom java classes, this approach works fine as we have done it w/o a problem as long as none of the classes use Map types (like HashMap).

The generated version of BookOrder.java looks like this (below) - (after running wsimport pointing at the WSDL served back from the running endpoint service). Of course the generated ObjectFactory.java file is based on this "generated" version of the Java bean classes. Now the BookOrder.java in the shared jar file and this generated BookOrder.java are different in that wsimport and JAXB have created a class w/ some inner class constructs to handle the ORIGINAL HashMap defined. This is where the problem occurs because when attempting to compile the client side code, we run into issues all resulting from this DIFFERENCE in mapping.

(removed most of the generated COMMENTs to shorten this post - it's already long enough :-) )

package com.acme.book.beans;

import java.util.ArrayList;
import java.util.List;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlType;

@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "BookOrder", propOrder = {
    "orderID",
    "orderType",
    "books",
    "titleMap"
})
public class BookOrder {

protected String orderID;
    protected int orderType;
    @XmlElement(nillable = true)
    protected List<Book> books;
  @XmlElement(required = true)
    protected BookOrder.TitleMap titleMap;         // here is the problem mapping

/**
     * Gets the value of the orderID property.
     * 
     * @return
     *     possible object is
     *     {@link String }
     *     
     */
    public String getOrderID() {
        return orderID;
    }

/**
     * Sets the value of the orderID property.
     * 
     * @param value
     *     allowed object is
     *     {@link String }
     *     
     */
    public void setOrderID(String value) {
        this.orderID = value;
    }

/**
     * Gets the value of the orderType property.
     * 
     */
    public int getOrderType() {
        return orderType;
    }

/**
     * Sets the value of the orderType property.
     * 
     */
    public void setOrderType(int value) {
        this.orderType = value;
    }

/**
     * Gets the value of the books property.
     * 
     * <p>
     * This accessor method returns a reference to the live list,
     * not a snapshot. Therefore any modification you make to the
     * returned list will be present inside the JAXB object.
     * This is why there is not a <CODE>set</CODE> method for the books property.
     * 
     * <p>
     * For example, to add a new item, do as follows:
     * <pre>
     *    getBooks().add(newItem);
     * </pre>
     * 
     * 
     * <p>
     * Objects of the following type(s) are allowed in the list
     * {@link Book }
     * 
     * 
     */
    public List<Book> getBooks() {
        if (books == null) {
            books = new ArrayList<Book>();
        }
        return this.books;
    }

/**
     * Gets the value of the titleMap property.
     * 
     * @return
     *     possible object is
     *     {@link BookOrder.TitleMap }
     *     
     */
    public BookOrder.TitleMap getTitleMap() {
        return titleMap;
    }

/**
     * Sets the value of the titleMap property.
     * 
     * @param value
     *     allowed object is
     *     {@link BookOrder.TitleMap }
     *     
     */
    public void setTitleMap(BookOrder.TitleMap value) {
        this.titleMap = value;
    }

// the "generated" inner class equivalent which is causing the issues

@XmlAccessorType(XmlAccessType.FIELD)
    @XmlType(name = "", propOrder = {
        "entry"
    })
    public static class TitleMap {

protected List<BookOrder.TitleMap.Entry> entry;

public List<BookOrder.TitleMap.Entry> getEntry() {
            if (entry == null) {
                entry = new ArrayList<BookOrder.TitleMap.Entry>();
            }
            return this.entry;
        }

@XmlAccessorType(XmlAccessType.FIELD)
        @XmlType(name = "", propOrder = {
            "key",
            "value"
        })
        public static class Entry {

protected Integer key;
            protected String value;

/**
             * Gets the value of the key property.
             * 
             * @return
             *     possible object is
             *     {@link Integer }
             *     
             */
            public Integer getKey() {
                return key;
            }

/**
             * Sets the value of the key property.
             * 
             * @param value
             *     allowed object is
             *     {@link Integer }
             *     
             */
            public void setKey(Integer value) {
                this.key = value;
            }

/**
             * Gets the value of the value property.
             * 
             * @return
             *     possible object is
             *     {@link String }
             *     
             */
            public String getValue() {
                return value;
            }

/**
             * Sets the value of the value property.
             * 
             * @param value
             *     allowed object is
             *     {@link String }
             *     
             */
            public void setValue(String value) {
                this.value = value;
            }

}
    }

}

The XML schema generated when the service endpoint was deployed (in addition to its WSDL) had the following definition for BookOrder:

Is there any way, using a custom binding file passed to wsimport to force the client-side generation process to end up with consistent classes such that the generated ObjectFactory.java can still work w/ our "shared" compiled JAR file containing our hand-coded BookOrder.java class? In other words, can we get the client-side generated BookOrder.java to match the original? I'd appreciate any suggestion or example where someone may have done this...assuming it is even possible.

In general, if we have Arrays or List types, none of this is a problem...but w/ Map types, it falls apart.

Thanks in advance.

With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.