[
https://issues.apache.org/jira/browse/YARN-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15263481#comment-15263481
]
Xuan Gong commented on YARN-4577:
---------------------------------
Thanks for the view, [~sjlee0]
bq. in serviceInit(), serviceStart(), serviceStop(), shouldn't we call
wrapped.serviceInit() instead of wrapper.init(), and so on?
Looks like the serviceInit/serviceStart/serviceStop are protected functions, so
we can not do that. When we call init(), it would automatically call
serviceInit.
bq.Coupled with the unit test strategy, you might want to consider supporting
some type of an override mechanism for system classes. Other use cases of
ApplicationClassLoader provide this (although it's case by case).
Thought about it. Add the improvement for it.
bq. Would you be able to come up with a unit test still? I know it's somewhat
tricky, but you might be able to find a way to test a few things. You might
want to take a look at TestRunJar.testClientClassLoader() to see if you can
reuse some of the ideas there.
Tried several different ways to test it. But it is hard. A good unit test for
this could be similar as I did for the manual testing. But unfortunately, I do
not know how to do it.
> Enable aux services to have their own custom classpath/jar file
> ---------------------------------------------------------------
>
> Key: YARN-4577
> URL: https://issues.apache.org/jira/browse/YARN-4577
> Project: Hadoop YARN
> Issue Type: Improvement
> Affects Versions: 2.8.0
> Reporter: Xuan Gong
> Assignee: Xuan Gong
> Attachments: YARN-4577.1.patch, YARN-4577.2.patch,
> YARN-4577.20160119.1.patch, YARN-4577.20160204.patch,
> YARN-4577.20160428.patch, YARN-4577.3.patch, YARN-4577.3.rebase.patch,
> YARN-4577.4.patch, YARN-4577.5.patch, YARN-4577.poc.patch
>
>
> Right now, users have to add their jars to the NM classpath directly, thus
> put them on the system classloader. But if multiple versions of the plugin
> are present on the classpath, there is no control over which version actually
> gets loaded. Or if there are any conflicts between the dependencies
> introduced by the auxiliary service and the NM itself, they can break the NM,
> the auxiliary service, or both.
> The solution could be: to instantiate aux services using a classloader that
> is different from the system classloader.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: yarn-issues-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
