[
https://issues.apache.org/jira/browse/HIVE-26984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17683337#comment-17683337
]
Zoltan Haindrich commented on HIVE-26984:
-----------------------------------------
copied from HIVE-26985:
I think you could probably achieve something similar by using AspectJ or
Byteman or other java agent stuff; or you could write your own agent:
https://stackify.com/what-are-java-agents-and-how-to-profile-with-them/
What's the problem with those approaches?
I will leave a -1 here as it makes a significant API change by making the
HiveConf constructor protected - which will break all 3rd party extensions
which may use `new HiveConf()`
> Deprecate public HiveConf constructors
> --------------------------------------
>
> Key: HIVE-26984
> URL: https://issues.apache.org/jira/browse/HIVE-26984
> Project: Hive
> Issue Type: Improvement
> Reporter: László Bodor
> Assignee: László Bodor
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> From time to time we investigate configuration object problems that are hard
> to investigate. We can improve this area, e.g. with HIVE-26985, but first, we
> need to introduce a public static factory method to hook into the creation
> process. I can see this pattern in another projects as well, like:
> HBaseConfiguration.
> Creating custom HiveConf subclasses can be useful because putting optional
> (say: if else branches or whatever) stuff into the original HiveConf object's
> hot codepaths can turn it less performant instantly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
