On 25/05/2016 15:03, Mark Thomas wrote: > On 25/05/2016 12:26, Rémy Maucherat wrote: >> 2016-05-25 12:43 GMT+02:00 Mark Thomas <ma...@apache.org>:
<snip/> >>> 1. Simplified JULI that uses JUL directly but with our existing >>> LogManager and configuration extensions. <snip/> >>> Thoughts? >>> >> >> I'd vote 6. Switching is a lot of trouble with little benefit. >> What would be the changes for 1 exactly ? The thing is/was supposed to be >> simple already. <snip/> > To be sure of the performance impact, we'd need to try it. I took a > quick look at this and it isn't quite as simple as a global search and > replace. I've set up a local branch where I can try this. I'll see how > much work it turns out to be. It is 2-3 hours of effort to switch all the Tomcat code to go directly to j.u.l. There is a fair amount of automated conversion so some further manual clean-up is likely to be required. Pros: - No need for JARs to depend on JULI. In theory this makes it easier for other folks to consume things like Jasper or Tomcat JDBC. - JULI becomes a 'drop-in' extension to j.u.l. that folks can use without having to change any existing code Cons: - It breaks multiple APIs. We pass Log instances in quite a few places. - Minimal performance difference. I ran the same test 5 times with no clear performance difference. If there is one, it is going to be small. - It is likely to cause merge errors for back-ports. - The code isn't as clean as the Logger API does not support log.<level>(String, Throwable) Overall, I think this was an interesting experiment but it is not worth it for the majority of the code. If there is demand from down-stream consumers of components like Jasper or WebSocket to remove the JULI dependency then we can look at that on a case by case basis. I'll keep the branch locally for now in case it is useful. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
