XStream

This is a very much needed feature. I would like to get some timeline on when this would evlove.

Please update the mailing list with timneline details ont his issue.

Thanks
Ram

This will also help when extending classes. Decoupling old versions and newer versions with more fields.

Cheers

Tom

Hi, this really is a problem as we would like to use xml-encoding to save certain information (internal state) into a data base; classes converted into xml are likely to change over time.

Is there any other way to CATCH the ConversionException thrown, when we have a field in xml-stream which no longer exists in the CLASS?

The proposed API would be ok, but a more general handling in form of "IF tag xxx is found and cannot be converted THEN do action as specified", sort of user-exit (sorry for the old fashioned word) could be helpful as well.

thanx, peter

I have the same problem.
I need to ignore tags that doesn't match object fields.
I found a dirty solution modifying the class
com.thoughtworks.xstream.converters.reflection.ReflectionConverter

where say:

Class type;
String classAttribute = reader.getAttribute(classAttributeIdentifier);
if (classAttribute != null) {
type = classMapper.lookupType(classAttribute);
} else if (!validField) {
type = classMapper.lookupType(reader.getNodeName());
} else {
type = classMapper.lookupDefaultType(reflectionProvider...
}

change to:

Class type;
String classAttribute = reader.getAttribute(classAttributeIdentifier);
if (classAttribute != null) {
type = classMapper.lookupType(classAttribute);
} else if (!validField) {
try{ type = classMapper.lookupType(reader.getNodeName()); } catch( Exception e ){ // If can't get the type set null to ignore type = null; }
} else {
type = classMapper.lookupDefaultType(reflectionProvider...
}

and then test for type!=null doing:

if( type!=null ){
Object fieldValue = context.convertAnother(result, type);
...
...
}
reader.moveUp();

Another solution is to implement a new ReflectionConverter and attach it as default converter, but this have other problems (see XSTR-142).

Aside from migration, I think this would also be a nice security feature. We use xstream to serialize objects for error traces, and some of that information is sensitive (like SSN or account number), and we don't want it lying around in logs.

I don't know if it would be a separate feature request, but having a central, shared repository of ignored fields would be useful, eg, "SSN", "SocialSecurity*", etc.

Thanks.

Peter,

What you are asking for is a valid thing but it's referring to ignore fields to serialize (rather than deserialize, which is what the issue refers to).

To solve your problem, all you need to do is mark the sensitive fields using the Java transient keyword - XStream will then ignore them.

Ah, but I pass these objects around jms buses and over other serialization boundries, like stateless session beans.

So, I'd like an xstream specific "ignore" feature, not something that would also negate java serialization, like transient. I'd also want to turn it on and off an a per xstream instance basis, so if I use xstream for message transport, I'd want all the fields, but my logging/error xstream instance would have some ignore fields turned on.

Should I file a separate feature request? I can think of a few other related features:

1. regex matching field names, eg SocialSecurity*
2. Class agnostic ignores, eg, any field in any class named SSN.
3. Externalize this in a file. ;o) I can wait for this, as I'm sure it touches a number of other areas...

--pete

I agree with Peter. I need to be able to output subsets of an object's attributes - they are used in soap messages. Sorta like views of an object. So marking fields transient doesn't work for my purposes - I need to define the interesting fields more dynamically.

The Java binary ObjectInputStream currently ignores serialized fields that are missing from the class on deserialization. It seems like it would be a good goal to have the default behavior of XStream do the same thing as a way to encourage adoption. Providing extended behavior, either though the XStream class or through additional methods on the ObjectInputStream returned by XStream is a great idea, provided it does not interfere with the default behavior people expect from Java serialization. We'll be incorporating Marcos' change in the version we use because we plan on making XML serialization be a user-selectable replacement for binary serilaization in our application. (At least we will once we find a fix for XSTR-245 ;^)

What do you think of Marcos "dirty solution" to solve this issue ? Does it have drawbacks that I should be aware of ?

I think as Philip Gust that xstream should work as ObjetcInputStream, ignoring fields that are missing from the class and Marcos solution seems to do exactly that...

Was implemented in 1.1.3: XStream.omitField()

Sorry, my fault. This feature is not yet implemented for deserialization.

Patch with unit test only.

OmitField will now be respected also at deserialization. So call:

xstream.omitField(DefiningType.class, "didExistOnce");

to omit a field "didExistOnce" that was defined previously in DefiningType.class, but is gone now.