I am throwing here this followup question.
Is it safe to extend (overwrite) DFSInputStream class, in terms of future
Yarn implementation design/changes etc. Unfortunately I have to overwrite
DFSInputStream as If I would overwrite HdfsDataInputStream (as I should) I
can't overwrite all the API i am
I have specific complex stream scheme, which I want to hide from the user
(short answer), also some security reasons (limiting possible read buffer
size).
2013/9/26 java8964 java8964
> Just curious, any reason you don't want to use the DFSDataInputStream?
>
> Yong
>
> --
Just curious, any reason you don't want to use the DFSDataInputStream?
Yong
Date: Thu, 26 Sep 2013 16:46:00 +0200
Subject: Extending DFSInputStream class
From: tmp5...@gmail.com
To: user@hadoop.apache.org
Hi
I would like to wrap DFSInputStream by extension. However it seems that the
DFSInputStr
The way we have gotten around this in the past is extending and then
copying the private code and creating a brand new implementation.
On Thu, Sep 26, 2013 at 10:50 AM, Jay Vyas wrote:
> This is actually somewhat common in some of the hadoop core classes :
> Private constructors and inner class
This is actually somewhat common in some of the hadoop core classes :
Private constructors and inner classes. I think in the long term jiras
should be opened for these to make them public and pluggable with public
parameterized constructors wherever possible, so that modularizations can
be provided
