DaanHoogland commented on issue #2992: PoC for log library surface reduction (2991) URL: https://github.com/apache/cloudstack/pull/2992#issuecomment-439316167 tl;dr you are not giving any argument to not use this strategy, you are only saying why this PoC is just a PoC. What you are describing is very elaborate as well, @rafaelweingartner. The script you describe is error prone. Not all calls and declaration are formatted the same way and the expressions look a bit to simple. I have seen the attempt to use slf4j in the console proxy code and it needs to be addressed as well. It is in the wrong place and incomplete. you say "For instance, your proposal could be applied to JPA ... as well, will we do that (when we move towards Spring-data and a real JPA implementation)? I hope not…". I do hope so, and I think you should as well, but this will be very challenging in the DAO case. I think it would be great if we could. I think we should definitely do this for a lot of external libraries, not reinventing the wheel but abstracting out and isolating dependencies on external eccentricities of those libraries, like call syntax/sematics. As you can see in my description of the issue (#2991) I am not being religious. I exclude (not definitely but as example) the DAO framework, as indeed spring data may make it more convenient to go about it differently. But NOTE: this is a temptation, luring us into a tie into the specifics of a framework we decide to commit ourself into in such a way. As you can see in #987 and #2276 and, I am sure numerous upgrade attempts by others as well, what you describe is not as simple as you say without isolating the use of an external library. I will follow up on this PR given mandate. we need to reduce the internal exposure to external libraries, not reinventing the wheel but isolating there use in proxy libraries. Your solution to upgrading log4j is not unifying logging framework use but only upgrading log4j as a one off solution essentially perpetuating the problem. In short, this PoC in itself will not solve the problem. it needs follow up and I dedicate myself to that. I do not want a PR like #2276, with 1710 files changed if a dependency decides to change a signature or a exposed structure. This will disable merging forward and hinder regular maintenance.
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
