I am dealing with a bank who sends the following header:
OFXHEADER: 100
DATA: OFXSGML
VERSION: 102
SECURITY: NONE
ENCODING: USASCII
CHARSET: 1252
COMPRESSION: NONE
OLDFILEUID: NONE
NEWFILEUID: NONE
Note that there is a space after the colon before the value. This is causing the following parse error:
java.lang.IllegalArgumentException: No enum constant net.sf.ofx4j.domain.data.ApplicationSecurity. NONE
at java.lang.Enum.valueOf(Enum.java:238)
at net.sf.ofx4j.io.DefaultStringConversion.fromString(DefaultStringConversion.java:81)
at net.sf.ofx4j.io.AggregateStackContentHandler.onHeader(AggregateStackContentHandler.java:50)
at net.sf.ofx4j.io.BaseOFXReader.processOFXv1Headers(BaseOFXReader.java:193)
at net.sf.ofx4j.io.BaseOFXReader.parse(BaseOFXReader.java:111)
at net.sf.ofx4j.io.BaseOFXReader.parse(BaseOFXReader.java:68)
at net.sf.ofx4j.io.AggregateUnmarshaller.unmarshal(AggregateUnmarshaller.java:44)
If I remove the space, it all parses fine. I looked at processOFXv1Headers and it does NOT trim the value. However, I also see that processOFXv2Headers DOES trim the header.
I looked at spec and it was unclear to me if v1 does NOT allow a space and v2 does?
So is this an issue the bank needs to fix or should OFX4J trim the v1 value also? Should this question be asked elsewhere?
I am dealing with a bank who sends the following header:
OFXHEADER: 100
DATA: OFXSGML
VERSION: 102
SECURITY: NONE
ENCODING: USASCII
CHARSET: 1252
COMPRESSION: NONE
OLDFILEUID: NONE
NEWFILEUID: NONE
Note that there is a space after the colon before the value. This is causing the following parse error:
java.lang.IllegalArgumentException: No enum constant net.sf.ofx4j.domain.data.ApplicationSecurity. NONE
at java.lang.Enum.valueOf(Enum.java:238)
at net.sf.ofx4j.io.DefaultStringConversion.fromString(DefaultStringConversion.java:81)
at net.sf.ofx4j.io.AggregateStackContentHandler.onHeader(AggregateStackContentHandler.java:50)
at net.sf.ofx4j.io.BaseOFXReader.processOFXv1Headers(BaseOFXReader.java:193)
at net.sf.ofx4j.io.BaseOFXReader.parse(BaseOFXReader.java:111)
at net.sf.ofx4j.io.BaseOFXReader.parse(BaseOFXReader.java:68)
at net.sf.ofx4j.io.AggregateUnmarshaller.unmarshal(AggregateUnmarshaller.java:44)
If I remove the space, it all parses fine. I looked at processOFXv1Headers and it does NOT trim the value. However, I also see that processOFXv2Headers DOES trim the header.
I looked at spec and it was unclear to me if v1 does NOT allow a space and v2 does?
So is this an issue the bank needs to fix or should OFX4J trim the v1 value also? Should this question be asked elsewhere?