Develop Reference

Spring data mongo conversion is not working for Object type since version 3.2

We have upgraded the Spring Data Mongo recently and since then some read and update queries are failing with the following error,
org.springframework.data.mapping.MappingException: Expected to read Document Document{} into type class java.lang.Object but didn't find a PersistentEntity for the latter!
While debugging, found that the type is Object and it doesn't have _class then this error is thrown.
It was working fine before 3.2.
When checked in the 3.1's source code, the read method in class MappingMongoConverter has a logic to cast the bson to an Object type if the ClassTypeInfomartion is Object.
In a few of our object models, we store additional information about the document as an Object.
Is it possible to configure in Spring to convert the bson to Object instead of failing?
Thanks in advance.

Spring Data Mongo can take the type information from _class, but if the application cannot rely on that field, it needs to tell the driver what type the data it expects to get.
My current project uses this for that purpose:
public interface BusinessesRepository extends MongoRepository<SomeApplicationType, String>
(Spring Data will autogenerate a subclass with the proper class selection logic for such an interface.)
Slightly lower-level you have MongoTemplate with its find(Query, Class<T>) function, which accepts something like SomeApplicationType.class as the second parameter and uses that information to instantiate an object to populate the fields with.
I don't know what function your code calls to retrieve and deserialize your data, so I can't be more specific.

The service class does not comply to one or more requirements of the JAX-RPC 1.1 specification, and may not deploy or function correctly

I am new to Java Webservices, currently I am trying to create a simple SOAP based web-services but getting issue in creating it.
Here is my webservice class:
#WebService
public class Teams {
private TeamsUtility utils;
public Teams() {
utils = new TeamsUtility();
utils.make_test_teams();
}
#WebMethod
public Team getTeam(String name) { return utils.getTeam(name); }
#WebMethod
public List<Team> getTeams() { return utils.getTeams(); }
#WebMethod
public String getDummyTeams() { return "Hi"; }
}
As you can see I have 3 methods here. Now if I just keep getDummyTeams and ask eclipse to create a WebService, then I have no issues. But when I tried to add remaining 2 methods public Team getTeam(String name) & public List<Team> getTeams() then while creating webservice I am getting error as :
The service class "helloservice.endpoint.Teams" does not comply to one
or more requirements of the JAX-RPC 1.1 specification, and may not
deploy or function correctly. The field or property "players" on the
value type "helloservice.endpoint.Team" used via the service class
"helloservice.endpoint.Teams" has a data type, "java.util.List", that
is not supported by the JAX-RPC 1.1 specification. Instances of the
type may not serialize or deserialize correctly. Loss of data or
complete failure of the Web service may result.
Here is my Team class:
#XmlRootElement
public class Team implements Serializable{
private List<Player> players;
private String name;
public Team() {
}
public Team(String name, List<Player> players) {
setName(name);
setPlayers(players);
}
// Setter & Getter methods
}
Can you please help me how do I fix this issue? I want to use java.util.List. Is there any settings I have to change in eclipse to use collections while creating SOAP based web-services?

This is not a direct response to the question. But nevertheless I would like to point out that you may consider not to use JAX-RPC at all.
First of all, JAX-RPC is an old API, which has been replaced with JAX-WS.
Reasons you may want to stay with JAX-RPC 1.1: ... If you want to send SOAP encoded messages or create RPC/encoded style WSDL.
And that leads us to the question "what is an RPC-encoded WSDL style?"
The WSDL file contains the definition of the methods of your webservice. And there are 4 ways/styles to define these methods:
RPC/encoded
RPC/literal
Document/encoded
Document/literal
Each style has advantages and disadvantages. The most important one is the following remark:
Although it is legal WSDL, RPC/encoded is not WS-I compliant.
WS-I stands for "webservice interoperability". So, as the quote clarifies, even though JAX-RPC supports RPC/encoded WSDL files, that doesn't mean it's compatible with other RPC/encoded technologies (e.g. webservices written in PHP). JAX-RPC webservices between Java and PHP may seem to work at first, but will sometimes break in specific cases. So the lesson is: avoid RPC/encoded WSDL files. And that's exactly why JAX-WS doesn't support them.
Unfortunately, sometimes you don't have a choice (e.g. another company provides the webservice) If it's a RPC/encoded WSDL file, then you won't be able to use JAX-WS. If the hosted webservice is also written in Java, then you could risk using JAX-RPC. If it's written in some other language, then I wouldn't take the risk. You're better of writing a custom handler when that happens. (You can still safely use JAXB (Java Xml Binding) to perform the (un)marshalling (conversion from/to xml) using annotations, just like with JAX-WS webservices.)
But how do you know if it's an RPC/encoded WSDL file? You just open it in a text editor, and look for the binding tag. The following example is an RPC/literal style WSDL file. So you can use JAX-WS with this webservice.
<binding name="MyService" type="tns:MyService">
<soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="rpc"/>
<operation name="method">
<soap:operation soapAction=""/>
<input>
<soap:body use="literal" .../>
</input>
<output>
<soap:body use="literal" .../>
</output>
</operation>
</binding>
When you define your own webservice, you can choose the WSDL style by annotating your class with #SOAPBinding(style=Style.RPC, use=Use.LITERAL).
A source of confusion: both JAX-RPC and JAX-WS use SOAP. There's also a thing called XML-RPC which is an old standard (before SOAP). But JAX-RPC does not use XML-RPC. On the other hand, SOAP is sometimes called "XML based RPC".

I think JAX RPC 1.1 doesn't support List as data type for service bean classes. Use Array instead. you can see this answer for similar issue

The primary reason why the collection classes are not standardized for use in Java Web services is that they are loosely typed collections. In the absence of significant additional data from the user, it is not possible to map a Java collection to a well-defined Schema and clear rules to the runtime for serializing and deserializing elements of the collection.
Use Java arrays instead of collections to represent sequences of elements in WSDL. Java arrays are strongly typed and, as a result, map to and from strongly-typed Schema, yielding interoperable WSDL and SOAP traffic with clear rules for deserialization and serialization to and from Java.
See link.

JAX-RPC 1.1 spec provides something called pluggable serializers and deserializers to support collection classes.

JAX-RPC 1.1 spec does not specify a clear mapping between the java.util.List object and XML.since you are returning java.util.List type.
change your method like
public Team[] getTeams() { return utils.getTeams(); }
And your getTeams() implementation should be match with this.

axis2: serialization of wsdl2java generated objects

Using axis2's wsdl2java tool and a third-party wsdl I have generated service stub and supporting classes (data holders). Since there is a need to do post-processing of loaded data from a service, there is a need to serialize one of the data holder objects.
1) is there a standard axis2 tool / approach that can be used for the purpose?
2) since the data holder class does not implement Serializable interface what would be the easiest way of serializing the object into xml format with the ability to restore the original object?
Data binding option was used (-d jaxbri) and each field of the class in question is annotated with #XmlElement tag, e.g.:
#XmlElement(name = "ID", required = true)
protected String id;

Ok, here is how I solved it:
axis2 generated java classes set (client side) had an object called ObjectFactory. Majority of its methods create JAXBElement objects with values of fields of the class holder
I had to implement a serializable wrapper class aSerializable for the class holder, such that it uses the ObjectFactory to create the JAXBElement objects for all the fields.
some external code uses the wrapper class to create an serializable object and writes it to the output stream.
on the receiving end:
ASerializable aSerializable;
A a;
aSerializable= (ASerializable)in.readObject();
a.setID((String)aSerializable.getID().getValue());
it still looks like extra work for the pre-annotated class serialization, but better than serializing into some text format and manual type checking during deserialization.

Getting Exception while generating the WebService when HashMap is passed as parameter

I am trying to create a webservice which takes a VO and VO contains a parameter of type Map. I wrote this simple Service and trying to create the webservice out of it. While creating the webservice I am getting exception that its not supported.
public MyVO myService(MyVO vo) {
return vo;
}
public class VO{
private String name;
private Map<String, Serializable> paramsMap;
}
Error Which I am getting :
The field or property on the value type used via the service class has a data type, "java.util.Map", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
I am not sure what's wrong with this. Any help or work around?
thanks in advance.

This link shows the data types supported by JAX-RPC 1.1 and Map (and all its subclasses aren't supported).
JAX-RPC 1.1 Specification, section 5.1.3 states:
Other standard Java classes (for
example: classes in the Java
Collection Framework) are mapped using
pluggable serializers and
deserializers. Refer to the chapter 15
(“Extensible Type Mapping”) for more
details on the pluggable serializers
and deserializers.
One workaround is to have an array of key/value pair JavaBean that you can pass through a parameter.
Example:
public final class KVPair<T> implements Serializable {
private String key;
private T value;
//Getters and setters
}
And have a service that has a map of KVPair.
service.consume(KVPair[] map);
IBM DeveloperWorks shows examples of mapping arrays as a Complex Type in WSDL.

Java ClassCastException when generating WSDL in Eclipse?

I am trying to create a new Web Service in Eclipse (bottom up, apache axis 1, tomcat 6), but I get warnings before the attempt and then an error after.
Error:
IWAB0398E Error in generating WSDL from Java: java.lang.ClassCastException: org.apache.axis.encoding.ser.BeanSerializer cannot be cast to org.apache.axis.encoding.Serializer
Here is where I use Serializable:
public class IntegrationUtils extends Utilities implements java.io.Serializable {
private static final long serialVersionUID = 7515033201857603982L;
Summary of Warnings:
A lot of the warnings have to do with classes used by my web service class not having default constructors.
Here are the warnings:
The service class "net.abc.Indy.WebService.IntegrationUtils" does not comply to one or more requirements of the JAX-RPC 1.1 specification, and may not deploy or function correctly.
The service class "net.abc.Indy.WebService.IntegrationUtils" does not comply to one or more requirements of the JAX-RPC 1.1 specification, and may not deploy or function correctly.
The field or property "headers" on the value type "org.apache.axis.AxisFault" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.util.ArrayList", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "cause" on the value type "java.rmi.RemoteException" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.lang.Throwable", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "noClasses" on the value type "org.apache.axis.description.TypeDesc" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.lang.Class", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "noObjects" on the value type "org.apache.axis.description.TypeDesc" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.lang.Object", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "propertyDescriptorMap" on the value type "org.apache.axis.description.TypeDesc" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.util.Map", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "type" on the value type "org.apache.axis.utils.BeanPropertyDescriptor" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.lang.Class", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "actualType" on the value type "org.apache.axis.utils.BeanPropertyDescriptor" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.lang.Class", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "javaType" on the value type "org.apache.axis.description.FieldDesc" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.lang.Class", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "headers" on the value type "org.apache.axis.AxisFault" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.util.ArrayList", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The field or property "cause" on the value type "java.rmi.RemoteException" used via the service class "net.abc.Indy.WebService.IntegrationUtils" has a data type, "java.lang.Throwable", that is not supported by the JAX-RPC 1.1 specification. Instances of the type may not serialize or deserialize correctly. Loss of data or complete failure of the Web service may result.
The value type "org.w3c.dom.Element" used via the service class "net.abc.Indy.WebService.IntegrationUtils" does not have a public default constructor. Chapter 5.4 of the JAX-RPC 1.1 specification requires a value type to have a public default constructor, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the value type during deserialization.
The value type "org.w3c.dom.TypeInfo" used via the service class "net.abc.Indy.WebService.IntegrationUtils" does not have a public default constructor. Chapter 5.4 of the JAX-RPC 1.1 specification requires a value type to have a public default constructor, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the value type during deserialization.
The value type "org.apache.axis.description.TypeDesc" used via the service class "net.abc.Indy.WebService.IntegrationUtils" does not have a public default constructor. Chapter 5.4 of the JAX-RPC 1.1 specification requires a value type to have a public default constructor, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the value type during deserialization.
The value type "org.apache.axis.utils.BeanPropertyDescriptor" used via the service class "net.abc.Indy.WebService.IntegrationUtils" does not have a public default constructor. Chapter 5.4 of the JAX-RPC 1.1 specification requires a value type to have a public default constructor, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the value type during deserialization.
The value type "org.apache.axis.description.FieldDesc" used via the service class "net.abc.Indy.WebService.IntegrationUtils" does not have a public default constructor. Chapter 5.4 of the JAX-RPC 1.1 specification requires a value type to have a public default constructor, otherwise a JAX-RPC 1.1 compliant Web service engine may be unable to construct an instance of the value type during deserialization.
Thanks for any help!

You get a ClassCastException, whenever you have duplicate JARs or JAR-files with the same class-files in it. In you case it could be a different Axis version too. The problem typically occures, when your tomcat instantiates a axis-class and sends this instance to your application. Your application on the other side can uses its own jars (packaged into you WAR or EAR). And because of the posibility of a multi classloader hirarchie in a Web- or Java EE-Container you can run different webapps with there own jar-files-versions at the same server at the same time.
But how to solve it? Well, search for these classes (shown in the StackTrace) in all jars of you tomcat and your web-application and check, which one is used to instantiate Axis-Requests/-responses. The easiest solution is, to remove the relevant jar from you web application and to compile your code against the jar's of you runtime environment (your tomcat). If the tomcat-jar-versions are not usable for your case, try to patch the server-jars.
An alternative solution can be a different configuration of your web-application/server to controll the classloaders.