[
https://issues.apache.org/jira/browse/SLIDER-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14498687#comment-14498687
]
Gour Saha commented on SLIDER-773:
----------------------------------
{quote}
Right now, it IS calling the non-pkg version (by passing in null as the third
param)
{quote}
You are right. I put the null back.
{quote}
This is an interesting case. This method was originally written by Sumit to
define the add on package file name on HDFS. However, line 82"String targetName
= appDefinition.pkgName;" was originally assigned some other values which
caused appConfig has a different add on package file name than the actual one
on HDFS. That's why I modified 82 to be assigned appDefinition.pkgName.
I also noticed the if block assign this name again, but it contains more logic
in case the user provided a folder, vs a file as the add on package file. so we
should leave the if block there
{quote}
Actually I was not referring to removing the if block. I was saying that if the
logic is correct as it exists today, then we don't need the line {{targetName =
appDefinition.pkgName;}} inside the if block. Everything else stays as is.
Also, the log statements outside the if block should be modified accordingly to
avoid confusion to a developer that {{appDefinition.pkgName}} should have
changed inside.
{quote}
I believe what you mentioned is a general principal for declaring variables.
However, in our case, the declaration must be of type TreeMap instead of a
normal Map, because we need an ordered map so that we can traverse it in order
{quote}
I understand your point, but you need it only when you call methods which are
exposed by the implementation class only, say lowerEntry or lowerKey of
TreeMap. Since you are not making any such calls, you don't need the
declaration variable to be of type TreeMap.
> Add co-processor support for app packages
> -----------------------------------------
>
> Key: SLIDER-773
> URL: https://issues.apache.org/jira/browse/SLIDER-773
> Project: Slider
> Issue Type: Bug
> Components: app-package, client
> Affects Versions: Slider 0.60
> Reporter: Sumit Mohanty
> Assignee: thomas liu
> Priority: Critical
> Fix For: Slider 0.80
>
> Attachments: 773-suggest.txt, Co-processorSupport.pdf,
> SLIDER-773_review_comments.patch, coprocessor-after.patch,
> coprocessor-apri-4th.patch, coprocessor.patch, coprocessor.patch
>
>
> It is typical for applications to allow plugins/co-processors that are
> essentially a set of additional jar files in the classpath and optionally a
> set of config files or config changes.
> Current, slider app packages can handle additional config changes/entries
> very well. Additional configs files can be added as well but it is not easy
> if the config files include parameters that need to be resolved by the agent.
> This requires app package changes. Dropping additional jar files into the
> class path is not easy and requires app package changes.
> It is not efficient to modify the app package to support such plugins. App
> packaging and create command should be modified such that the user can
> dynamically specify additional jars, config files, configs etc.
> Specific scenarios are modifying HBase to add support for Phoenix or Ranger.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
