Thanks Zhijie Shen for the patch
Yes, I think it should, but I prefer to put it in ApplicationBaseProtocol when ApplicationHistoryClientService has implemented DT related methods.
history protocol already have these methods so don't need to wait , as they have dummy iplementation for that.
ApplicationBaseProtocol and ApplicationContext are completely different things. ApplicationBaseProtocol is the PRC interface. Previously, I thought we should have a uniformed ApplicationContext: on the RM side, it wraps RMContext; while on the AHS side, it wraps ApplicationHistory. However, inspired by RMWebServices#getApps, I think the RPC interface is a better place to uniform the way of retrieving app info, so I created ApplicationBaseProtocol. And ApplicationContext is no longer useful.
ApplicationBaseProtocol would be the base protocol of Client and history however application context is something different. The motivation for context is to wrap RM and AHS application data, SO I think having context make sense as protocol has totally different motivation and methods as well when we add the delegation methods to it.
I understand the big patch is desperate for review, but I've to do that because the patch is aiming to refactor the code to avoid duplicate web-UI code for RM and for AHS. The two webUI should share the common code path, and then display similarly.
I am fine with this if this is something you want to do.
+ * The protocol between clients and the <code>ResourceManager</code> or
+ * <code>ApplicationHistoryServer</code> to get information on applications,
+ * application attempts and containers.
+ * </p>
This should be=> it is a base protocol for application client and history.
Shouldn't we add @Idempotent to getallapplications as well?
If we add appliction context back then we need to rebase the patch according to that.