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.

Serialize an object containing List field

I have a WebService that send a List of Vehicle to the Web Service Client, the Vehicle is implemented as follow :
public class Vehicle implements Serializable{
private static final long serialVersionUID = -8169481181178317205L;
private final String id;
private final LocalDate depositDate;
private final double price;
private final ArrayList<Integer> scores = new ArrayList<>();
private final ArrayList<String> comments = new ArrayList<>();
private Optional<Renter> renter = Optional.empty();
private int rentalNumber = 0;
}
As you can see, the vehicle object contains 2 fields wich are ArrayList. When I want to create the Web Service I have multiple warning telling me that Vehicle (which is the only object I want to send over the network) and other object aren't respecting the JAX-RPC convention and may not get sent properly.
How to get rid of these warnings ? Is this an obligation ?
The first solution I implemented was to transform the list into an array but is there anything else ?
EDIT 5: The problem comes the fact to add a parameter in the method i want to use for the web service.I tried to add a method like this one :
public StatePayment lol(int lol){
return StatePayment.DENIED;
}
And the Web Services Creation software returned me the same error. Isn't that possible to add a method with parameters ?
EDIT4:I created a fake method just to test what was the problem. It seems that when i had the parameter in the method signature i have the precedent error.
//Not working code
public StatePayment lol(Buyer buyer){
return StatePayment.DENIED;
}
//Working code
public StatePayment lol(Buyer buyer){
return StatePayment.DENIED;
}
I guess the problem comes from buyer but i can't get what could it be.
EDIT 3: When i want to create the webService by "new->WebService-> Selecting the methods.
I have the following error:
IWAB0398E Error in generating WSDL from Java: >java.lang.IllegalStateException: Error looking for paramter names in >bytecode: unexpected bytes in file
Is this a serialisation problem ?
The error happens when i select this method:
public int proceedToPayment(Buyer buyer) {
//Calcul du prix total du shoppingCart
long totalPrice = 0;
for(Vehicle v : buyer.getShoppingCart()) {
totalPrice += v.getPrice();
}
Bank buyerBank = buyer.getBank();
//Convertir totalPrice en euros vers la monnaie du Buyer.
if(buyerBank.bankTransaction(totalPrice, buyer) == StatePayment.DENIED) {
return 0;
}
removeShoppingCartFromBDD(buyer.getShoppingCart());
return 1;
}
EDIT 2: To be more clear, my principal question is. Am i forced to get rid of all these warning messages knowing that the only object that i will send over the network are Vehicle and the ones that are inside Vehicle (Renter)
EDIT 1: The warning message
The service class "MlvDataBaseImpl" does not comply to one or more
requirements of the JAX-RPC 1.1 specification, and may not deploy or
function correctly.
The method "exportObject" on the service class "MlvDataBaseImpl" is
overloaded. Overloaded methods are allowed by chapter 5.5.5 of the
JAX-RPC 1.1 specification, however, some JAX-RPC 1.1 compliant tools
may not allow overloaded methods or may generate WSDL with overloaded
operations as contrary to rule R2304 of the WS-I Basic Profile.
The value type "MlvDataBase" used via the service class
"MlvDataBaseImpl" 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 "Renter" used via the service class "MlvDataBaseImpl"
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 "Vehicle" used via the service class
"MlvDataBaseImpl" 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 "Buyer" used via the service class "MlvDataBaseImpl"
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 method "registerVehicle" on the service class "MlvDataBaseImpl"
uses a data type, "java.time.LocalDate", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "getRentableVehicles" on the service class
"MlvDataBaseImpl" uses a data type, "java.util.List", that is not
supported by the JAX-RPC specification. Instances of the type may not
serialize or deserialize correctly. Loss of data or complete failure
of the Web service may result.
The method "clone" on the service class "MlvDataBaseImpl" uses a
data type, "java.lang.Object", that is not supported by the JAX-RPC
specification. Instances of the type may not serialize or deserialize
correctly. Loss of data or complete failure of the Web service may
result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.server.RemoteStub", that is not supported
by the JAX-RPC specification. Instances of the type may not serialize
or deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.Remote", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.Remote", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.Remote", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.Remote", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.Remote", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.server.RMIClientSocketFactory", that is
not supported by the JAX-RPC specification. Instances of the type may
not serialize or deserialize correctly. Loss of data or complete
failure of the Web service may result.
The method "exportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.server.RMIServerSocketFactory", that is
not supported by the JAX-RPC specification. Instances of the type may
not serialize or deserialize correctly. Loss of data or complete
failure of the Web service may result.
The method "unexportObject" on the service class "MlvDataBaseImpl"
uses a data type, "java.rmi.Remote", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "setLog" on the service class "MlvDataBaseImpl" uses a
data type, "java.io.OutputStream", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "getLog" on the service class "MlvDataBaseImpl" uses a
data type, "java.io.PrintStream", that is not supported by the JAX-RPC
specification. Instances of the type may not serialize or deserialize
correctly. Loss of data or complete failure of the Web service may
result.
The method "getRef" on the service class "MlvDataBaseImpl" uses a
data type, "java.rmi.server.RemoteRef", that is not supported by the
JAX-RPC specification. Instances of the type may not serialize or
deserialize correctly. Loss of data or complete failure of the Web
service may result.
The method "toStub" on the service class "MlvDataBaseImpl" uses a
data type, "java.rmi.Remote", that is not supported by the JAX-RPC
specification. Instances of the type may not serialize or deserialize
correctly. Loss of data or complete failure of the Web service may
result.
The method "toStub" on the service class "MlvDataBaseImpl" uses a
data type, "java.rmi.Remote", that is not supported by the JAX-RPC
specification. Instances of the type may not serialize or deserialize
correctly. Loss of data or complete failure of the Web service may
result.
The method "equals" on the service class "MlvDataBaseImpl" uses a
data type, "java.lang.Object", that is not supported by the JAX-RPC
specification. Instances of the type may not serialize or deserialize
correctly. Loss of data or complete failure of the Web service may
result.
The service class "MlvDataBaseImpl" does not have a public default
constructor. Chapter 10.1 of the JAX-RPC 1.1 specification requires a
service class 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 service class to handle an incoming request message.
The field or property "declaringClass" on the value type
"java.lang.Enum" used via the service class "MlvDataBaseImpl" 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 "depositDate" on the value type "Vehicle" used
via the service class "MlvDataBaseImpl" has a data type,
"java.time.LocalDate", 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 "comments" on the value type "Vehicle" used
via the service class "MlvDataBaseImpl" 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.
The field or property "scores" on the value type "Vehicle" used via
the service class "MlvDataBaseImpl" 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.
The field or property "declaringClass" on the value type
"java.lang.Enum" used via the service class "MlvDataBaseImpl" 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 "shoppingCart" on the value type "Buyer" used
via the service class "MlvDataBaseImpl" 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.

Please look at this post JAXB annotations for nested element lists for more details, how to serialize lists.
As for the warnings, you need to search for each one in SO, there are many different subjects involved.

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.

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 bean to wsdl - how to make fields nillable?

I'm using JAX-WS api for wsdl generation.
Java-bean class is something like:
public class MyBean {
private String nullableField;
private String notNullableField;
// and here appropriate get/set/ters
}
When wsdl is generated then nullability of this fields is not specified.
Question: what (and where) necessary to specify that fields have corresponding nillable='' value in wsdl? I.e. how can I specify fields nullability in plain java code for wsdl?
At this time I'm generating wsdl and then correcting xml manually for fields nullability. That's not convenient. I want this nillable attribute'll be generated by java-ws automatically.
Any suggestions?
Thanks.

AFAIK, it is still not possible to generate nillable=false when using #WebParam i.e. when using a Java-first approach (as discussed in this thread). Actually, I'd recommend to use a WSDL-first approach if you want fine control.