[
https://issues.apache.org/jira/browse/HDFS-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214986#comment-13214986
]
Colin Patrick McCabe commented on HDFS-2990:
--------------------------------------------
The idea of splitting all of the Image and EditLog stuff out into a separate
package is interesting. I don't think it could be done without a lot of
refactoring, though.
I do not think that an ImageEditUtil class is the solution. The classes I'm
interested in aren't utilities, they are part of the core of the NameNode. For
example, EditLogInputStream, FSEditLogOp, and so forth.
The current OEV and OIV code duplicates basically all of these core classes,
and it's a real code smell. Whenever something changes, we need to implement
it in both parsers, which is silly. Also any improvements and bugfixes we make
to one parser don't improve or bugfix the other, etc.
The end goal here is to have a very minimal OEV that basically just pulls stuff
from the EditLogInputStream and prints it. No parsing, no tokenizing, nothing
like that.
Perhaps it is easier just to make the things I want public and use the
interface annotations? It seems to be done in a lot of other places.
I do understand the desire to keep the packages small. However, sometimes you
need more flexibility than the public/pcakage-private/private distinction can
give. I have heard that Java 7 is addressing this issue, but unfortunately
we're not there yet :(
> Move OfflineImageViewer, OfflineEditsViewer into the same package as the
> NameNode
> ---------------------------------------------------------------------------------
>
> Key: HDFS-2990
> URL: https://issues.apache.org/jira/browse/HDFS-2990
> Project: Hadoop HDFS
> Issue Type: Bug
> Reporter: Colin Patrick McCabe
> Assignee: Colin Patrick McCabe
> Attachments: HDFS-2990.patch
>
>
> Since OfflineImageviewer and OfflineEditsVeiwer are in different namespaces
> than the NameNode, we can't ruuse a lot of the code from the NameNode without
> making things public that we probably don't want to make public. Let's move
> them into the NameNode namespace to avoid this problem. These tools will
> always be tightly tied to the NameNode anyway (they are parsing the same
> on-disk structures, after all), so that is where they belong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
