StringArrayPropertyEditor automatically trimming values?

[rabueckers]

If I use the StringArrayPropertyEditor to read in the following value "AB,CD " to a property it trims the trailing space, which then equates to the following array -> new String[] {"AB", "CD"}

What I would like it to do is create a String[] that is equal to -> new String[] {"AB", "CD "} respecting the space after the letter D, but it appears the value is trimmed way before it even gets to the StringArrayPropertyEditor.

Is there an easy way to eliminate this automatic trimming?

I've placed code snippets below to help give a concrete example.

<!-- app context snippet -->
<bean id="tradeTokenizer"
class="org.springframework.batch.item.file.transfo rm.FixedLengthTokenizer">
<property name="names" value="ISIN,Quantity,price,CUSTOMER,totalAmount,ta xable,totalTaxAmount,purchaseDate,discountCodes" />
<property name="columns" value="1-12, 13-15, 16-20, 21-29, 30-38, 39, 40-48, 49-56, 57-62" />
</bean>


// Trade Object Snippet
public class Trade implements Serializable {
private String isin = "";
private long quantity = 0;
private Double price = new Double(0);
private String customer = "";
private BigDecimal totalAmount = new BigDecimal(0);
private String taxable = "Y";
private BigDecimal totalTaxAmount = new BigDecimal(0);
private Date purchaseDate = new Date();
private String[] discountCodes;

public Trade() {
}
}


// Test class snippet
public static final String TRADE_LINE = "UK21341EAH4521535.11customer5+12345678Y+000003212 0090101AB,CD ";

@Test
public void testTradeTokenizer() throws Exception {
Assert.assertNotNull(tradeTokenizer);
FieldSet set = tradeTokenizer.tokenize(TRADE_LINE);
assertEquals(9, set.getFieldCount());

assertEquals("AB,CD", set.readString("discountCodes"));

// raw string read obtains the non-trimmed value
assertEquals("AB,CD ", set.readRawString("discountCodes"));
}

@Test
public void testTradeLineMapper() throws Exception {
assertNotNull(tradeLineMapper);
Object object = tradeLineMapper.mapLine(TRADE_LINE, 0);
assertNotNull(object);
Trade trade = (Trade) object;

assertTrue(Arrays.equals(new String[] {"AB", "CD"}, trade.getDiscountCodes()));

// this will fail
assertTrue(Arrays.equals(new String[] {"AB", "CD "}, trade.getDiscountCodes()));
}

Thanks in advance!

Bob

[Dave Syer]

StringArrayPropertyEditor is from Spring Core. Raise an issue in the SPR-* JIRA if you think this is a problem.

[rabueckers]

Thanks! I posted a new thread in the Spring Core Container forum, to see if anyone has further thoughts.

[DHGarrette]

From the looks of your code, it seems like your issue is not with StringArrayPropertyEditor at all since the StringArrayPropertyEditor is not dealing with TRADE_LINE. As you've shown with testTradeTokenizer(), the tokenizer is doing exactly what you want. Your problem is in the tradeLineMapper. I'm going to have to assume (since you didn't post your implementation) that tradeLineMapper is a DefaultLineMapper. In that case you would just need to have a FieldSetMapper implementation that uses readRawString() and that will get you what you want.

By the way, StringArrayPropertyEditor does not trim automatically.

Also, please always use CODE tags when posting code. It makes it much easier to read.

[rabueckers]

Yes, you are correct, the tradeLineMapper is a DefaultLineMapper. I have also registered customEditors and was hoping to just utilize the BeanWrapperFieldSetMapper to do the mapping automatically taking into account the custom editors. e.g. BigDecimalPropertyEditor 12345 -> 123.45, CustomLength2StringArrayPropertyEditor "123456" -> String[] {"12", "34", "56"};

If I implement a new custom FieldSetMapper, I won't be able to automatically take advantage of the custom property editors I created. I instead would end up explicitly calling that logic in the newly created implementation of the FieldSetMapper. Is that indeed the case, or am I missing something here?!?!

Thanks again for your help and your patience as this stuff is all new to me!

Bob

[DHGarrette]

I think I see where you're going. I'd be interested to see the full use case. Is that something you could share?

[rabueckers]

Rather than giving you my domain specific example(company policy), I'll try to explain my situation further in the context of my modified spring-batch-samples (MultiLine OrderJob). At a high level I need to read in a fixed-width text file and create a composite POJO -> OrderComposite(consisting of a FileHeader object, List<Order>, FileFooter object). I then need to be take the OrderComposite object and create a fixed-length output file, using a writer.

Remember the input file has BigDecimal values specified as S9(7)V99 e.g. 12345678, which I have on the Order POJO as a BigDecimal type. I utilize a custom property editor to do the conversion (BigDecimalPropertyEditor). The property editor will handle the conversion from the file input value of 12345678 to the Java BigDecimal value of 123456.78. I have other custom editors as well, but the BigDecimalPropertyEditor will suffice for this example. That sums up the Reader scenario.

The Writer scenario... I need to be able to go from my OrderComposite object to a fixed-width output file. The output file once again has BigDecimal values in the S9(7)V99 format, so I need to convert from the POJO value of 123456.78 to 12345678, and I was thinking I would be able to use the same custom property editor to do this. I would really like to do this without having to explicitly write custom field extractors.

File Format - Multi-line fixed width as follows:
File Header
Orders... an order consists of a order header, various other order properties, List<LineItem>, order footer
File Footer

Reader - read fixed-width input file (with S9(7)V99 formatted elements) and create a OrderComposite POJO converting values to a BigDecimal format with appropriate decimal position. I was able to do all of this for the Reader using the DefaultLineMapper and the BeanWrapperFieldSetMapper with the customEditors property set appropriately. I didn't need to write any explicit mapper code that did the mapping, it was handled automatically as part of the BeanWrapperFieldSetMapper with customEditors.

OrderComposite POJO - consisting of a FileHeader object, List<Order>, FileFooter object

Writer - create fixed-width output file from the OrderComposite POJO, now this time converting back from Java BigDecimal to S9(7)V99 format.

I hope this sheds some light on what it is I'm trying to accomplish.Let me know if you need anything else to make sense of what I'm attempting to do.

Let me know if you have any questions, as I know I have rambled on....and on.....

Thanks for your time and guidance!

Bob