Issue Details (XML | Word | Printable)

Key: XSTR-367
Type: Improvement Improvement
Status: Closed Closed
Resolution: Won't Fix
Assignee: Joerg Schaible
Reporter: Stephan Morais
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
XStream

SingleValueConverter should pass UnmarshallingContext to fromString method

Created: 04/Dec/06 04:56 PM   Updated: 25/Feb/08 04:53 PM   Resolved: 11/Feb/08 06:01 PM
Return to search
Component/s: None
Affects Version/s: None
Fix Version/s: None

JDK version and platform: 1.5


 Description  « Hide

I need use a SingleValueConverter in order to make use of attribute mapping. The problem is that unlike the Converter interface, there's no way to get at the UnmarshallingContext in the fromString method. For example, via a Converter impl, I could call something like context.getRequiredType() in order to figure out how to unmarshal a string. I can't do this with a SingleValueConverter.



Joerg Schaible added a comment - 05/Dec/06 07:19 AM

Hi Stephan,

please use a normal Converter implementation. The SingleValueConverter is meant for simple types with a single string representation - nothing more.

  • Jörg

Joerg Schaible made changes - 05/Dec/06 07:19 AM
Field Original Value New Value
Status Open [ 1 ] Resolved [ 5 ]
Resolution Won't Fix [ 2 ]
Stephan Morais added a comment - 06/Dec/06 03:56 PM

Sure, of course I'd use that if I could. The problem, as noted above, is that I want to alias certain fields as attributes. You'll notice that unless a single value converter is used, you can't get a field to map to an attribute.


Stephan Morais added a comment - 06/Dec/06 07:03 PM

See reply to comment on close.


Stephan Morais made changes - 06/Dec/06 07:03 PM
Status Resolved [ 5 ] Reopened [ 4 ]
Resolution Won't Fix [ 2 ]
Stephan Morais added a comment - 06/Dec/06 07:07 PM

Maybe I'm reading this wrong, but here's what I see in AttributeMapper:

protected SingleValueConverter getLocalConverterFromItemType(Class type) {
Converter converter = converterLookup.lookupConverterForType(type);
if (converter != null && converter instanceof SingleValueConverter) { return (SingleValueConverter)converter; } else { return null; }

I suppose another workaround to this would be to also allow normal Converters in this case.


Joerg Schaible added a comment - 07/Dec/06 02:33 AM

Can you elaborate a bit more about your special use case? We had until now no need for the UnmarshallingContext in a SIngleValueConverter, since those converters are typically used to convert a dedicated type, so there's no need for providing this info again. Apart from this information, no call to any other method in the UnmarshallingContext is even valid within the context of a SingleValueConverter. Since the value of an attribute has to be a single string, the AttributeMapper is restricted to use SingleValueConverter only.


Alan Moss added a comment - 07/Dec/06 10:28 PM

I may have stumbled across a need for this feature as well. In my case, I would like to map a simple Java 5+ enum as an attribute. As per an email with Joerg, currently, I must create a specific SingleValueConverter(SVC) for my enum for this to work. Below is a SVC that illustrates this:

class SingleValueEnumConverter extends AbstractSingleValueConverter {

private final Class enumType;

public SingleValueEnumConverter(Class type) { this.enumType = type; }

public boolean canConvert(Class c) { return c.equals(enumType); }

public Object fromString(String value) { return Enum.valueOf(enumType, value); }
}

This will work, but It would be nice to have a generic SingleValueEnumConverter that could take advantage of the UnmarshallingContext if it were provided to the SVC.


Joerg Schaible added a comment - 06/Aug/07 03:53 PM

It is not as simple as it might look. Context.getRequiredType() will return the type of the current XML element ... but not the type of the attribute. Therefore providing the context will not help to solve this.


Joerg Schaible added a comment - 11/Feb/08 06:01 PM

Enums have now attribute support. Therefore this issue lacks again of a valid use case.


Joerg Schaible made changes - 11/Feb/08 06:01 PM
Assignee Joerg Schaible [ joehni ]
Resolution Won't Fix [ 2 ]
Status Reopened [ 4 ] Resolved [ 5 ]
Joerg Schaible added a comment - 25/Feb/08 04:53 PM

Closed after no further comment has been given.


Joerg Schaible made changes - 25/Feb/08 04:53 PM
Status Resolved [ 5 ] Closed [ 6 ]