[ 
https://issues.apache.org/jira/browse/BEAM-5180?focusedWorklogId=137909&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-137909
 ]

ASF GitHub Bot logged work on BEAM-5180:
----------------------------------------

                Author: ASF GitHub Bot
            Created on: 24/Aug/18 17:40
            Start Date: 24/Aug/18 17:40
    Worklog Time Spent: 10m 
      Work Description: angoenka commented on issue #6251: [BEAM-5180] Relax 
back restriction on parsing file scheme
URL: https://github.com/apache/beam/pull/6251#issuecomment-415830568
 
 
   From the java.net.URI docs,
   
   A hierarchical URI is subject to further parsing according to the syntax
   
   `[scheme:][//authority][path][?query][#fragment]`
   Which enforces  //
   
   But to support HDFS and unblock our selves we should go with the rollback.

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 137909)
    Time Spent: 2h 10m  (was: 2h)

> Broken FileResultCoder via parseSchema change
> ---------------------------------------------
>
>                 Key: BEAM-5180
>                 URL: https://issues.apache.org/jira/browse/BEAM-5180
>             Project: Beam
>          Issue Type: Bug
>          Components: sdk-java-core
>    Affects Versions: 2.6.0
>            Reporter: Jozef Vilcek
>            Assignee: Kenneth Knowles
>            Priority: Blocker
>          Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Recently this commit
> [https://github.com/apache/beam/commit/3fff58c21f94415f3397e185377e36d3df662384]
> introduced more strict schema parsing which is breaking the contract between 
> _FileResultCoder_ and _FileSystems.matchNewResource()_.
> Coder takes _ResourceId_ and serialize it via `_toString_` methods and then 
> relies on filesystem being able to parse it back again. Having strict 
> _scheme://_ breaks this at least for Hadoop filesystem which use _URI_ for 
> _ResourceId_ and produce _toString()_ in form of `_hdfs:/some/path_`
> I guess the _ResourceIdCoder_ is suffering the same problem.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to