Re: [jboss-as7-dev] manual way to do logging?

It's not an accurate usage of the word self-righteousness. I am simply showing our philisophical difference by restating what you have already said. You want to keep your "old school" approach and you are unwilling to consider any of the gathered requirements. This is putting the how ("old school approach") over the what (actual goals). Another thing is that this is not a Jason and David framework. A lot of people had a hand in this, and a great deal of the implementation was done by external contributors. One of them we ended up hiring (James). The API design had significant contribution from Emanuel and Max and others. A number of localization efforts had even considered as well. Yes we also did measurements both by ourselves and independently (Andy). The key aspects looked at were memory usage and contention. Eliminating the overhead of bundles was significant. You can try and belittle this all you want but all evidence to date backs up our claims. (oh and BTW the bug is one superfluous string concatenation not two since javac combines constants). It will be fixed (and it's a simple thing to do). Now as to proof, you approach hasn't proven anything. That requires facts and data (see scientific method). All you seem to offer as "proof" is a mixture of logical fallacies and insult hurling. It's a shame to see your contributions over the last few years to AS be in this form. I had hoped we'd all be on the same team. On Jun 10, 2012, at 8:21 AM, Bill Burke<bburke(a)redhat.com> wrote: > If I had used this over-engineered project from the beginning I would have been screwed because it does 2 string concatenations *EVERY LOG MESSAGE* irregardless of logging level, with no way to swap it out. You talk about how you put SO MUCH EFFORT, research, and thought into everything and yet there's a simple rookie mistake in the implementation. Its funny how much Andy et. al. praised the performance of JBoss Logging. Guess it goes to show you how much logging really has on system performance (which is pretty much my observation with all the profiling I've done over the years). Awesome you all put so much work into it! > > public final void jbossLoggingSucksBecause(final String reason) { > log.logf(FQCN, (Logger.Level.INFO), null, ((projectCode +"000099: ")+ jbossLoggingSucksBecause$str()), reason); > } > > So spare me all your self-righteousness. Users don't give a shit about implementation details, so if I want to use a different approach for whatever reason that differs from the self-proclaimed uberness of Jason/David that's my prerogative, so fuck off. I've isolated logging in my projects, because in my own experience logging frameworks suck. Glad I've proven yet again, that this personal axiom holds true. > > On 6/9/12 1:23 PM, Jason Greene wrote: >> I know you think that's a good thing but it's really not. We write software to accomplish a goals that meet the needs of our users over our own personal enjoyment (and by users i mean the priority is on the ones that see the log messages, not the ones that write them) Apparently you prefer the opposite. >> >> On Jun 9, 2012, at 10:36 AM, Bill Burke<bburke(a)redhat.com> wrote: >> >>> I'll rephrase that...Being a dick requires no effort from me. :) >>> >>> On 6/9/12 11:33 AM, Bill Burke wrote: >>>> Yes, I'll spend 10x the effort just to be a dick :) >>>> >>>> On 6/9/12 11:26 AM, David M. Lloyd wrote: >>>>> Yet you'll expend 10x the effort bitching and moaning? That seems >>>>> incongruous to me. >>>>> >>>>> On 06/09/2012 10:12 AM, Bill Burke wrote: >>>>>> Not gonna bother filing a bug, because I ain't gonna use it. >>>>>> >>>>>> On 6/9/12 10:58 AM, David M. Lloyd wrote: >>>>>>> File bugs here: http://issues.jboss.org/browse/LOGTOOL >>>>>>> >>>>>>> On 06/09/2012 09:27 AM, Bill Burke wrote: >>>>>>>> Well, in looking at the way you do things, it is impossible to do manual >>>>>>>> logging. Sigh... >>>>>>>> >>>>>>>> So, at least I thought I could at least remove jboss logging as a binary >>>>>>>> dependency yet still use the processor to generate basic string >>>>>>>> constants based on included localization property files... >>>>>>>> >>>>>>>> BUT... >>>>>>>> >>>>>>>> There's a small bug (or maybe it is a feature) in that creating the >>>>>>>> message string is *ALWAYS* a string concatination if you have a message id: >>>>>>>> >>>>>>>> public final String jbossLoggingSucks() { >>>>>>>> String result = ((projectCode +"000102: ")+ >>>>>>>> jbossLoggingSucks$str()); >>>>>>>> return result; >>>>>>>> } >>>>>>>> >>>>>>>> When you fix that, let me know. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 6/8/12 4:11 AM, Max Rydahl Andersen wrote: >>>>>>>>> >>>>>>>>>> That's the crux really. I always bitch when I have to add a log message with JBoss logging compared to the good old log4j. But I would not meet the requirements. >>>>>>>>>> >>>>>>>>>> See it positively, it's annoying enough to add a log or throw an exception that I do it less often and my code is even more efficient :D >>>>>>>>>> The other annoying bit is when your log interface is in a common module and you work on a dependent module. This requires full recompilation and I am often bitten by this with method not found exceptions. >>>>>>>>> >>>>>>>>> Yes, same happened often in eclipse plugins - they tend to move the logging message/interfaces into each module and only >>>>>>>>> truly shared ones out in common. >>>>>>>>> >>>>>>>>> It's all a balance act. >>>>>>>>> >>>>>>>>> /max >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 8 juin 2012, at 09:44, Max Rydahl Andersen<max.andersen(a)redhat.com> wrote: >>>>>>>>>> >>>>>>>>>>> btw. yes, I also think jboss logging is over-engineered for basic usage but >>>>>>>>>>> for stuff that needs to be memory efficient and i18n maintainable I don't recall >>>>>>>>>>> seeing anything better.... >>>>>>>>>>> >>>>>>>>>>> On 08 Jun 2012, at 09:31, Max Rydahl Andersen wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Bill/David, >>>>>>>>>>>> >>>>>>>>>>>> I unfortunately cannot use JBoss Logging yet because of how Eclipse plugins are built, but >>>>>>>>>>>> just a few observations on this "fun" topic ;) >>>>>>>>>>>> >>>>>>>>>>>> Static vs non-static logging: >>>>>>>>>>>> ------------------------------------- >>>>>>>>>>>> >>>>>>>>>>>> Eclipse plugins already are used to have to create a static string message in an interface to do i18n of logging; they even provide tooling to make this easy to do - that helps *alot*; >>>>>>>>>>>> jboss logging doesn't have that though. >>>>>>>>>>>> >>>>>>>>>>>> Unfortunately we actually in Eclipse world also have the non-interface based stuff too that Bill wants and yes its awesome you can just write it quick'n'dirty but maan its a mess to work with >>>>>>>>>>>> afterwards over time. (In resteasy you probably don't see it because its much smaller than the number of eclipse plugins we have to maintain, but if I could choose now, I would like >>>>>>>>>>>> to have that stick hit me everytime I was lazy) >>>>>>>>>>>> >>>>>>>>>>>> Hacker tip: Nothing prevents you from doing a generic highlevel interface field you can use everytime you are feeling lazy - good thing is you or others can easily find the usages of that >>>>>>>>>>>> and go through and convert these messages. just saying. >>>>>>>>>>>> >>>>>>>>>>>> Performance: >>>>>>>>>>>> ------------------- >>>>>>>>>>>> >>>>>>>>>>>> Jason and David aren't full of shit here. >>>>>>>>>>>> >>>>>>>>>>>> They proved early on in AS7 lifetime that even basic stuff in logging like checking if log is activated was costing as much as 10% overhead - even with logging disabled. That was before string concatenation gets into play. >>>>>>>>>>>> >>>>>>>>>>>> And if you don't trust them then I can tell you Eclipse went through the exact same exercise some years back. They had grown organically over time from a few small plugins to thousands. and suddenly they >>>>>>>>>>>> were faced with several hundred megabytes of overhead and a sluggish performance. Their move to use static interfaces made a big impact in runtime performance AND memory usage. >>>>>>>>>>>> >>>>>>>>>>>> JBoss Logging actually takes this even further - but i'll leave David and Jasons to explain those :) >>>>>>>>>>>> >>>>>>>>>>>> Usability: >>>>>>>>>>>> ------------- >>>>>>>>>>>> >>>>>>>>>>>> You do not need an additional maven plugin if you just use the plain standard annotation processor. >>>>>>>>>>>> You keep saying you need one so i'm curious why you think that. >>>>>>>>>>>> >>>>>>>>>>>> There is though one place where this annotation processor sucks, and that is that it isn't isolated >>>>>>>>>>>> enough to be reusable and runnable within an IDE such as Eclipse :) >>>>>>>>>>>> https://issues.jboss.org/browse/LOGTOOL-51 captures that; this shouldn't affect you though since you >>>>>>>>>>>> are just using maven and vi. >>>>>>>>>>>> >>>>>>>>>>>> ....and I'm all for that beer too - can we talk about how JBoss Logging could be made to work with Eclipse logging framework ? :) >>>>>>>>>>>> >>>>>>>>>>>> /max >>>>>>>>>>>> >>>>>>>>>>>> On 08 Jun 2012, at 00:43, Bill Burke wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 6/7/12 6:21 PM, David M. Lloyd wrote: >>>>>>>>>>>>>> On 06/07/2012 04:55 PM, Bill Burke wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> P.S. I hope we can have a few beers at JUDCon/JBossWorld and *NOT* talk >>>>>>>>>>>>>>> about this. >>>>>>>>>>>>>> >>>>>>>>>>>>>> :-D >>>>>>>>>>>>>> >>>>>>>>>>>>>> Don't get me wrong, I'm not pissed or anything. I do love a good >>>>>>>>>>>>>> argument though. >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Oh thank god! I love a good argument too! I don't know about you, but >>>>>>>>>>>>> sitting at home every day, you get a bit ornery.... >>>>>>>>>>>>> >>>>>>>>>>>>> I've exhausted my arguments anyways. Hopefully Jim can take the banner >>>>>>>>>>>>> and run with it... >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> jboss-as7-dev mailing list >>>>>>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jboss-as7-dev mailing list >>>>>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jboss-as7-dev mailing list >>>>>>>>>>> jboss-as7-dev(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> -- >>> Bill Burke >>> JBoss, a division of Red Hat >>> http://bill.burkecentral.com >>> >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com > > _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev