[
https://issues.apache.org/jira/browse/STREAMS-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14087753#comment-14087753
]
ASF GitHub Bot commented on STREAMS-141:
----------------------------------------
Github user steveblackmon commented on a diff in the pull request:
https://github.com/apache/incubator-streams/pull/62#discussion_r15879286
--- Diff:
streams-contrib/streams-provider-twitter/src/main/java/org/apache/streams/twitter/serializer/StreamsTwitterMapper.java
---
@@ -68,7 +71,14 @@ public StreamsTwitterMapper() {
addDeserializer(DateTime.class, new
StdDeserializer<DateTime>(DateTime.class) {
@Override
public DateTime deserialize(JsonParser jpar,
DeserializationContext context) throws IOException, JsonProcessingException {
- return
TWITTER_FORMAT.parseDateTime(jpar.getValueAsString());
+ DateTime result = null;
+ try {
+ result =
TWITTER_FORMAT.parseDateTime(jpar.getValueAsString());
--- End diff --
same response as on the datasift PR. non-standard date parsing should be
the modules responsibility. i'd support creation of an advanced date parser
that could pick up dates without knowing the format before-hand, but not an
approach where every new one-off date format that is discovered requires a
change to streams-pojo to add a new format string + try/catch.
> StreamsTwitterMapper can't reprocess Streams Outputs
> ----------------------------------------------------
>
> Key: STREAMS-141
> URL: https://issues.apache.org/jira/browse/STREAMS-141
> Project: Streams
> Issue Type: Bug
> Reporter: Steve Blackmon
>
> Update StreamsTwitterMapper to parse DateTime as Twitter formatted strings OR
> RFC3339
--
This message was sent by Atlassian JIRA
(v6.2#6252)
