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

Bill Burke bburke at redhat.com
Sun Jun 10 09:21:44 EDT 2012


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 at 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 at 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 at lists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>>>> jboss-as7-dev at lists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> jboss-as7-dev mailing list
>>>>>>>>>> jboss-as7-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com




More information about the jboss-as7-dev mailing list