You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Geir Egil Hansen (JIRA)" <ax...@ws.apache.org> on 2005/11/04 09:07:19 UTC
[jira] Created: (AXIS-2285) Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
--------------------------------------------------------------------------------------------------------------------------------------
Key: AXIS-2285
URL: http://issues.apache.org/jira/browse/AXIS-2285
Project: Apache Axis
Type: Bug
Components: Serialization/Deserialization
Versions: 1.3
Environment: Windows XP
Reporter: Geir Egil Hansen
Example:
I make a class on the server side. The class contains some data members.
Like
class MyClass{
String str1;
}
Some clients are generated uses the WSDL file.
In the next server version I need to add another datamember to the class:
class MyClass{
String str1;
String str2;
}
Then the Axis client based on the previous version throws an exception. The exception is thrown from the class BeanDeserializer at around line 250. And the code doing it is like this:
if (propDesc == null) {
throw new SAXException( Messages.getMessage("badElem00", javaType.getName(), localName));
return null;
}
Throwing an exception here in the client makes it impossible to extend the functionality on the server side. I have tested .NET clients, other Java clients, Borland C++ Builder and none of them throws any exception. And I think it is wrong to throw any here, because the client code is supposed to deserialize any datamembers it knwos about. It does need what it does not know anything about. It would be a different matter if an existing datameber was removed in the new version (like str1 was removed in the example). THEN an exception must be thrown.
I think this is a bug and should be fixed. Now we ask our customers if they are to use Axis to generate the client, and if they are, we give them a new version of the BeanSerializer.java where the code is changed to
if (propDesc == null) {
//@TODO: No such field. Throwing exception here makes code not backwards compatible.
log.warn("No such field in client code: " + javaType.getName() + "/" + localName);
// throw new SAXException(
// Messages.getMessage("badElem00", javaType.getName(),
// localName));
return null;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-2285) Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
Posted by "Tom Jordahl (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-2285?page=comments#action_12356810 ]
Tom Jordahl commented on AXIS-2285:
-----------------------------------
What you are talking about here is changing the contract (the Schema in the WSDL) and versioning the service.
This is a very hard problem, and while ignore unknown elements *might* solve your problem, it doesn't solve the whole problem.
> Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AXIS-2285
> URL: http://issues.apache.org/jira/browse/AXIS-2285
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.3
> Environment: Windows XP
> Reporter: Geir Egil Hansen
>
> Example:
> I make a class on the server side. The class contains some data members.
> Like
> class MyClass{
> String str1;
> }
> Some clients are generated uses the WSDL file.
> In the next server version I need to add another datamember to the class:
> class MyClass{
> String str1;
> String str2;
> }
> Then the Axis client based on the previous version throws an exception. The exception is thrown from the class BeanDeserializer at around line 250. And the code doing it is like this:
> if (propDesc == null) {
> throw new SAXException( Messages.getMessage("badElem00", javaType.getName(), localName));
> return null;
> }
> Throwing an exception here in the client makes it impossible to extend the functionality on the server side. I have tested .NET clients, other Java clients, Borland C++ Builder and none of them throws any exception. And I think it is wrong to throw any here, because the client code is supposed to deserialize any datamembers it knwos about. It does need what it does not know anything about. It would be a different matter if an existing datameber was removed in the new version (like str1 was removed in the example). THEN an exception must be thrown.
> I think this is a bug and should be fixed. Now we ask our customers if they are to use Axis to generate the client, and if they are, we give them a new version of the BeanSerializer.java where the code is changed to
> if (propDesc == null) {
> //@TODO: No such field. Throwing exception here makes code not backwards compatible.
> log.warn("No such field in client code: " + javaType.getName() + "/" + localName);
> // throw new SAXException(
> // Messages.getMessage("badElem00", javaType.getName(),
> // localName));
> return null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-2285) Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
Posted by "Geir Egil Hansen (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-2285?page=comments#action_12356845 ]
Geir Egil Hansen commented on AXIS-2285:
----------------------------------------
Maybe you are right about that Tom ("changing the contract").
However, most of the clients I tried does not complain when adding a new datamember to the class.
So far only Axis client code does.
What is the rest of the problem?
> Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AXIS-2285
> URL: http://issues.apache.org/jira/browse/AXIS-2285
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.3
> Environment: Windows XP
> Reporter: Geir Egil Hansen
>
> Example:
> I make a class on the server side. The class contains some data members.
> Like
> class MyClass{
> String str1;
> }
> Some clients are generated uses the WSDL file.
> In the next server version I need to add another datamember to the class:
> class MyClass{
> String str1;
> String str2;
> }
> Then the Axis client based on the previous version throws an exception. The exception is thrown from the class BeanDeserializer at around line 250. And the code doing it is like this:
> if (propDesc == null) {
> throw new SAXException( Messages.getMessage("badElem00", javaType.getName(), localName));
> return null;
> }
> Throwing an exception here in the client makes it impossible to extend the functionality on the server side. I have tested .NET clients, other Java clients, Borland C++ Builder and none of them throws any exception. And I think it is wrong to throw any here, because the client code is supposed to deserialize any datamembers it knwos about. It does need what it does not know anything about. It would be a different matter if an existing datameber was removed in the new version (like str1 was removed in the example). THEN an exception must be thrown.
> I think this is a bug and should be fixed. Now we ask our customers if they are to use Axis to generate the client, and if they are, we give them a new version of the BeanSerializer.java where the code is changed to
> if (propDesc == null) {
> //@TODO: No such field. Throwing exception here makes code not backwards compatible.
> log.warn("No such field in client code: " + javaType.getName() + "/" + localName);
> // throw new SAXException(
> // Messages.getMessage("badElem00", javaType.getName(),
> // localName));
> return null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (AXIS-2285) Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
Posted by "Geir Egil Hansen (JIRA)" <ax...@ws.apache.org>.
[ http://issues.apache.org/jira/browse/AXIS-2285?page=comments#action_12356768 ]
Geir Egil Hansen commented on AXIS-2285:
----------------------------------------
"It does need what it does not know about". Mystery sentence with no meaning.
Here is a new try:
I think it is wrong to throw an exception on the client here, because it does not have to be able to deserialize any data members it does not have any knowledge about anyway. In this case the client is generated based on the previous version, and thus it does not know about the new datamember. By NOT throwing any exception here the client does not have to be rebuilt with every change on the object from the server side.
It seems that many other client code generating tools (Borland, MS etc) accepts new data members in objects without complaining.
> Deserializing objects on client side with unknown data members from server side causes exception, makes server code harder to maintain
> --------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AXIS-2285
> URL: http://issues.apache.org/jira/browse/AXIS-2285
> Project: Apache Axis
> Type: Bug
> Components: Serialization/Deserialization
> Versions: 1.3
> Environment: Windows XP
> Reporter: Geir Egil Hansen
>
> Example:
> I make a class on the server side. The class contains some data members.
> Like
> class MyClass{
> String str1;
> }
> Some clients are generated uses the WSDL file.
> In the next server version I need to add another datamember to the class:
> class MyClass{
> String str1;
> String str2;
> }
> Then the Axis client based on the previous version throws an exception. The exception is thrown from the class BeanDeserializer at around line 250. And the code doing it is like this:
> if (propDesc == null) {
> throw new SAXException( Messages.getMessage("badElem00", javaType.getName(), localName));
> return null;
> }
> Throwing an exception here in the client makes it impossible to extend the functionality on the server side. I have tested .NET clients, other Java clients, Borland C++ Builder and none of them throws any exception. And I think it is wrong to throw any here, because the client code is supposed to deserialize any datamembers it knwos about. It does need what it does not know anything about. It would be a different matter if an existing datameber was removed in the new version (like str1 was removed in the example). THEN an exception must be thrown.
> I think this is a bug and should be fixed. Now we ask our customers if they are to use Axis to generate the client, and if they are, we give them a new version of the BeanSerializer.java where the code is changed to
> if (propDesc == null) {
> //@TODO: No such field. Throwing exception here makes code not backwards compatible.
> log.warn("No such field in client code: " + javaType.getName() + "/" + localName);
> // throw new SAXException(
> // Messages.getMessage("badElem00", javaType.getName(),
> // localName));
> return null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira