On 06/06/2012 12:35 PM, Bill Burke wrote: > I do not want to use the JBoss Logging annotation framework as I do not > want to have a hard dependency on JBoss Logging for my project. > > Is there a manual API that I can use instead to build a message? > Something like: > > String getMessage(long id, Object... params); No, there isn't (and if there were, it'd be part of JBoss Logging, so...). You can however use the maven-shade-plugin to slurp the JBoss Logging classes into your project (even under another package name). It's a pretty small project and we're working to make it smaller.

On 6/6/12 1:32 PM, Bill Burke wrote: > > > On 6/6/12 2:11 PM, David M. Lloyd wrote: >> On 06/06/2012 12:35 PM, Bill Burke wrote: >>> I do not want to use the JBoss Logging annotation framework as I do not >>> want to have a hard dependency on JBoss Logging for my project. >>> >>> Is there a manual API that I can use instead to build a message? >>> Something like: >>> >>> String getMessage(long id, Object... params); >> >> No, there isn't (and if there were, it'd be part of JBoss Logging, >> so...). You can however use the maven-shade-plugin to slurp the JBoss >> Logging classes into your project (even under another package name). >> It's a pretty small project and we're working to make it smaller. >> > > Eh, I guess I could just use reflection techniques to create my own > abstraction and stuff the logging interfaces in a separate jar. > > BTW, this is ridiculously over-engineered and at least for me, harder to > adapt to my project. These engineering hours could have been better > spent elsewhere. You don't have to use it. You just need a message format that meets TAG-2. Everything the framework does, is meets the TAG-3 requirements (discussed ad nauseam years ago).

On 06/06/2012 11:37 AM, Jason T. Greene wrote: > On 6/6/12 1:32 PM, Bill Burke wrote: >> >> On 6/6/12 2:11 PM, David M. Lloyd wrote: >>> On 06/06/2012 12:35 PM, Bill Burke wrote: >>>> I do not want to use the JBoss Logging annotation framework as I do not >>>> want to have a hard dependency on JBoss Logging for my project. >>>> >>>> Is there a manual API that I can use instead to build a message? >>>> Something like: >>>> >>>> String getMessage(long id, Object... params); >>> No, there isn't (and if there were, it'd be part of JBoss Logging, >>> so...). You can however use the maven-shade-plugin to slurp the JBoss >>> Logging classes into your project (even under another package name). >>> It's a pretty small project and we're working to make it smaller. >>> >> Eh, I guess I could just use reflection techniques to create my own >> abstraction and stuff the logging interfaces in a separate jar. >> >> BTW, this is ridiculously over-engineered and at least for me, harder to >> adapt to my project. These engineering hours could have been better >> spent elsewhere. > You don't have to use it. You just need a message format that meets > TAG-2. Everything the framework does, is meets the TAG-3 requirements > (discussed ad nauseam years ago). > This was all done before I started so I could be wrong, but I think JBoss Logging is supposed to be used. https://issues.jboss.org/browse/ANDIAMO-2

On 6/6/12 2:11 PM, David M. Lloyd wrote: > On 06/06/2012 12:35 PM, Bill Burke wrote: >> I do not want to use the JBoss Logging annotation framework as I do not >> want to have a hard dependency on JBoss Logging for my project. >> >> Is there a manual API that I can use instead to build a message? >> Something like: >> >> String getMessage(long id, Object... params); > > No, there isn't (and if there were, it'd be part of JBoss Logging, > so...). You can however use the maven-shade-plugin to slurp the JBoss > Logging classes into your project (even under another package name). > It's a pretty small project and we're working to make it smaller. > Eh, I guess I could just use reflection techniques to create my own abstraction and stuff the logging interfaces in a separate jar. BTW, this is ridiculously over-engineered and at least for me, harder to adapt to my project. These engineering hours could have been better spent elsewhere.

On 6/6/12 2:41 PM, David M. Lloyd wrote: > On 06/06/2012 01:32 PM, Bill Burke wrote: >> >> >> On 6/6/12 2:11 PM, David M. Lloyd wrote: >>> On 06/06/2012 12:35 PM, Bill Burke wrote: >>>> I do not want to use the JBoss Logging annotation framework as I do >>>> not >>>> want to have a hard dependency on JBoss Logging for my project. >>>> >>>> Is there a manual API that I can use instead to build a message? >>>> Something like: >>>> >>>> String getMessage(long id, Object... params); >>> >>> No, there isn't (and if there were, it'd be part of JBoss Logging, >>> so...). You can however use the maven-shade-plugin to slurp the JBoss >>> Logging classes into your project (even under another package name). >>> It's a pretty small project and we're working to make it smaller. >>> >> >> Eh, I guess I could just use reflection techniques to create my own >> abstraction and stuff the logging interfaces in a separate jar. >> >> BTW, this is ridiculously over-engineered and at least for me, harder to >> adapt to my project. These engineering hours could have been better >> spent elsewhere. > > Yes, creating your own abstraction when there's a perfectly good one > ready and easy to use is indeed over-engineering. :) > "easy to use" is certainly your perception, not mine. And my logger is not a full-blown abstraction, just a small wrapper over existing logging frameworks. But...since you couldn't provide simple methods like: String getMessage(long messageId, Object... params); info(long messageId, Object... params) I'm stuck writing Yet Another Redundant Fucking Logging Abstraction for i18n because I absolutely refuse to be dependent on any specific Yet Another Fucking Logging Abstraction.

On 6/6/12 3:19 PM, David M. Lloyd wrote: > Up to you, but you get to be the one to tell the translation team I'll just forward those emails onto you. > why > they have to key all their messages off of an integer ID instead of a > descriptive name. And you also get to reinvent the tooling which > provides them with the English translation to work from. You mean all this crap isn't built on top of simple property files? (At least thats what I saw in the jboss-logging-processor testsuite) > Doesn't sound > like a good use of time to me. > I agree. Which is why this is at the very bottom of my queue now because you guys had to over-engineer this.

From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Wednesday, June 6, 2012 2:17:03 PM Subject: Re: [jboss-as7-dev] manual way to do logging? On 6/6/12 2:27 PM, Bill Burke wrote: > > > On 6/6/12 3:19 PM, David M. Lloyd wrote: >> Up to you, but you get to be the one to tell the translation team > > I'll just forward those emails onto you. > >> why >> they have to key all their messages off of an integer ID instead >> of a >> descriptive name. And you also get to reinvent the tooling which >> provides them with the English translation to work from. > > You mean all this crap isn't built on top of simple property files? > (At > least thats what I saw in the jboss-logging-processor testsuite) > >> Doesn't sound >> like a good use of time to me. >> > > I agree. Which is why this is at the very bottom of my queue now > because you guys had to over-engineer this. Right its not like you had any opportunity during the TAG discussions to disagree with any particular discussion. Or that you got to see people saying they disliked the first API which looked similar to what you just pasted here because of duplication of messages, like of type safety, lack of message in the java source, performance problems etc. Oh wait you did! -- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a division of Red Hat _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

From: "Jason T. Greene" <jason.greene(a)redhat.com&gt; To: "Andrig Miller" <anmiller(a)redhat.com&gt; Cc: "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org&gt;, "Bill Burke" <bburke(a)redhat.com&gt; Sent: Wednesday, June 6, 2012 3:02:00 PM Subject: Re: [jboss-as7-dev] manual way to do logging? On 6/6/12 3:43 PM, Andrig Miller wrote: > I'm not sure we have to have these discussions over and over and > over > again. From my perspective, performance being my primary concern, > JBoss logging has been awesome, and it meets all the companies > requirements. I haven't been able to put an exact percentage on it > yet, but the use of JBoss logging has improved throughput on all > the > workloads I have tested, that is for sure. > > If we continue to pollute the code base with different logging > frameworks, a lot of those gains could start to disappear. Besides > the fact, that we are about to ship a product in multiple languages > for the first time, and we have to continue to finish the work we > started. > > Is is all that difficult to adopt JBoss logging? This all seems > counter productive. Right I think we need to know why it needs to be abstracted. What is missing from jboss logging that requires RESTEasy to have an abstraction? Once we know the answer to that question, we can either add whatever the missing thing is, or recommend how to go about building something custom with similar perf characteristics (if the advice is even wanted). -- Jason T. Greene JBoss AS Lead / EAP Platform Architect JBoss, a division of Red Hat

On 6/6/12 5:02 PM, Jason T. Greene wrote: > On 6/6/12 3:43 PM, Andrig Miller wrote: > >> I'm not sure we have to have these discussions over and over and over >> again. From my perspective, performance being my primary concern, >> JBoss logging has been awesome, and it meets all the companies >> requirements. I haven't been able to put an exact percentage on it >> yet, but the use of JBoss logging has improved throughput on all the >> workloads I have tested, that is for sure. >> The performance gains you are seeing are from not doing stupid things which are pretty easy to avoid. i.e. not doing string concatenations when your logging level isn't triggered.

>> If we continue to pollute the code base with different logging >> frameworks, a lot of those gains could start to disappear. Besides >> the fact, that we are about to ship a product in multiple languages >> for the first time, and we have to continue to finish the work we >> started. >> >> Is is all that difficult to adopt JBoss logging? This all seems >> counter productive. > > Right I think we need to know why it needs to be abstracted. What is > missing from jboss logging that requires RESTEasy to have an > abstraction? Once we know the answer to that question, we can either add > whatever the missing thing is, or recommend how to go about building > something custom with similar perf characteristics (if the advice is > even wanted). > The reasons are simple: I don't want a *hard* dependency on yet another logging abstraction within my codebase.

I really don't want to write a logging abstraction,

I just want to have a tiny level of indirection so that I'm not dependent on any one of them.

You don't think I have any right to be a little frustrated that I can't do this tiny level of indirection and that I have to use a full-blown code generation framework just to do logging?

You don't think it is even a little bit ridiculous that you are requiring code generation just to do logging? Come on guys...

You asked what's missing from JBoss Logging, I'll reiterate more completely

void info(String messageID, Object... params); void trace(String messageID, Object... params); void error(String messageID, Object... params); String getMessage(String messageID, Object... params); MessageFormat getMessageFormat(String messageID); Simple as that. You can whine about the performance implications all you want but, IMO, if you do a log-level check before you lookup the message, it shouldn't be an issue.

BTW, nobody answered my previous question, @MessageBundle is fine to use? Our translation teams know how to handle them? Considering you think JBoss Logging is already perfect, I'm guessing I'll have to revert to using reflection calls on @MessageBundle if I want to keep my delegation logger. P.S. BTW Jason, I did comment multiple times on TAG-3 years ago. I'd be happy to forward the emails. What I said then was: I don't want to be dependent on yet another logging abstraction and questioned why we were spending so many engineering hours on one. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

P.S. BTW Jason, I did comment multiple times on TAG-3 years ago. I'd be happy to forward the emails. What I said then was: I don't want to be dependent on yet another logging abstraction and questioned why we were spending so many engineering hours on one.

On 6/6/12 7:09 PM, Jason Greene wrote: > On Jun 6, 2012, at 5:32 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: >> >> P.S. BTW Jason, I did comment multiple times on TAG-3 years ago. I'd be happy to forward the emails. What I said then was: I don't want to be dependent on yet another logging abstraction and questioned why we were spending so many engineering hours on one. > > > Sure you ignored everyone's use cases, everyone's research and findings and then spent what 10 seconds of real thought to dump out some drivel about how everyone is over engineering and wasting time? I think the reasons for my approach to logging are valid. I was wrong to assume 2 years ago that a simple old-school approach would be offered in parallel to the behemoth you created. Sucks that my dead-simple approach cannot be accommodated.

On 6/7/12 3:19 PM, David M. Lloyd wrote: > On 06/07/2012 02:06 PM, Bill Burke wrote: >> >> >> On 6/6/12 7:09 PM, Jason Greene wrote: >>> On Jun 6, 2012, at 5:32 PM, Bill Burke&lt;bburke(a)redhat.com&gt; wrote: >>>> >>>> P.S. BTW Jason, I did comment multiple times on TAG-3 years ago. I'd be happy to forward the emails. What I said then was: I don't want to be dependent on yet another logging abstraction and questioned why we were spending so many engineering hours on one. >>> >>> >>> Sure you ignored everyone's use cases, everyone's research and findings and then spent what 10 seconds of real thought to dump out some drivel about how everyone is over engineering and wasting time? >> >> I think the reasons for my approach to logging are valid. I was wrong >> to assume 2 years ago that a simple old-school approach would be offered >> in parallel to the behemoth you created. Sucks that my dead-simple >> approach cannot be accommodated. > > Calling it a "behemoth" doesn't make it one. Let's see: 1. Write interface(s) with a method for each thing you want to log (annotated of course). 2. Add a maven plugin to generate code in your project 3. add generated code to your project 4. add X classes to your project and the permgen space associated with them. 5. Create a hard dependency to JBoss Logging or yet another maven plugin to shade in that dependency

vs. log.info(ID, Object... args); String msg = localization.generateMessage(ID, Object... args);

2 function calls compared to X extra Classes, Y extra methods, Z extra annotations, one extra maven plugin, generated code, and an extra hard library dependency unless you shade it in with an additional maven plugin. To gain: * in all probability, an array index instead of a hash lookup to locate a message format.

* "Type safety". for an interface that has *ONLY ONE REFERENCE* and of which type safety is meaningless considering all you're doing is generating strings.

Yup, pretty much a behemoth.

On 6/7/12 4:39 PM, David M. Lloyd wrote: >> Yup, pretty much a behemoth. > > I don't see it, man. The tooling is lightweight and the result has > proven to be fast at runtime *and* very nice to use and convenient at > development time. We evaluated *all* the requirements - not just the > ones you just thought of now - and came up with a solution that works > well for everyone (except for you). You need to let it go. > The fact that you can't accommodate such a simple request (and that it doesn't exist already) proves what a behemoth it is. And I didn't think of requirements *just now*. If I had known 2 years ago I would be required to use such a behemoth, I would have been just as much of an asshole then as I'm being right now. I know if Tim was still around he'd shit all over this as well. And finally, I'll let it go...write to the very bottom of my work-queue.

P.S. I hope we can have a few beers at JUDCon/JBossWorld and *NOT* talk about this.

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

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

> 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&gt; 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

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&lt;max.andersen(a)redhat.com&gt; 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 >> >

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&lt;max.andersen(a)redhat.com&gt; 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 >>>> >>> >> >> >

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&lt;max.andersen(a)redhat.com&gt; 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 >>>>>> >>>>> >>>> >>>> >>> >> >> >

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&lt;max.andersen(a)redhat.com&gt; 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

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&gt; 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&lt;max.andersen(a)redhat.com&gt; 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

unsubscribe On Sun 10 Jun 2012 04:49:02 PM CDT, Jason Greene wrote: > > 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&lt;bburke(a)redhat.com&gt; 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&lt;bburke(a)redhat.com&gt; 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&lt;max.andersen(a)redhat.com&gt; 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 -- steve(a)hibernate.org http://hibernate.org _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

On 6/8/12 3:06 AM, Emmanuel Bernard 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. We used to have a proxy mode feature for exactly this problem. You would set a sys prop and it would generate dynamic proxies implementing the the source code locales. This was quite a bit slower than the compile generated classes so it was intended to be develop mode only. The idea was that you just set it in your IDE settings and be done with it. It turns out it wasnt used very much, and it relied on runtime annotation retention, so it was killed. If enough people felt it was a problem though we could revisit that. What do you think?

Incorrect - annotation processing happens as a normal part of the javac build. You just have to have the generator on your classpath when you compile, same as any other dependency. You don't even need Maven to make it work; our examples just refer to Maven because it is by far the most common build system used right now. On 06/09/2012 09:32 AM, Bill Burke wrote: > So, I have to pop out of my IDE and run a maven build just to be able to > run tests within my IDE? Yikes... Another reason why I just won't use > JBoss Logging... > > On 6/8/12 2:37 PM, Jason T. Greene wrote: >> On 6/8/12 3:06 AM, Emmanuel Bernard 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. >> >> We used to have a proxy mode feature for exactly this problem. You would >> set a sys prop and it would generate dynamic proxies implementing the >> the source code locales. This was quite a bit slower than the compile >> generated classes so it was intended to be develop mode only. The idea >> was that you just set it in your IDE settings and be done with it. >> >> It turns out it wasnt used very much, and it relied on runtime >> annotation retention, so it was killed. If enough people felt it was a >> problem though we could revisit that. >> >> What do you think? >> >

You're never going to use an annotation processor, ever? They're a standard part of Java. They run automatically when you execute javac or use the standard compiler API. If your IDE can't run a standard build with annotation processing I'd say you have a different problem. On 06/09/2012 10:11 AM, Bill Burke wrote: > Given that my particular project is a maven projec, I'd have to edit my > IDE settings. Again, no thanks... For my project at least, there's no > set up guide for using it with an IDE. (and there won't ever be because > I'm not ever going to use JBoss Logging or anything else that requires a > similar dependency). Just load resteasy using a maven structure. > > On 6/9/12 10:57 AM, David M. Lloyd wrote: >> Incorrect - annotation processing happens as a normal part of the javac >> build. You just have to have the generator on your classpath when you >> compile, same as any other dependency. You don't even need Maven to >> make it work; our examples just refer to Maven because it is by far the >> most common build system used right now. >> >> On 06/09/2012 09:32 AM, Bill Burke wrote: >>> So, I have to pop out of my IDE and run a maven build just to be able to >>> run tests within my IDE? Yikes... Another reason why I just won't use >>> JBoss Logging... >>> >>> On 6/8/12 2:37 PM, Jason T. Greene wrote: >>>> On 6/8/12 3:06 AM, Emmanuel Bernard 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. >>>> >>>> We used to have a proxy mode feature for exactly this problem. You would >>>> set a sys prop and it would generate dynamic proxies implementing the >>>> the source code locales. This was quite a bit slower than the compile >>>> generated classes so it was intended to be develop mode only. The idea >>>> was that you just set it in your IDE settings and be done with it. >>>> >>>> It turns out it wasnt used very much, and it relied on runtime >>>> annotation retention, so it was killed. If enough people felt it was a >>>> problem though we could revisit that. >>>> >>>> What do you think? >>>> >>> >> >> >

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

>> Calling it a "behemoth" doesn't make it one. > > Let's see: > > 1. Write interface(s) with a method for each thing you want to log > (annotated of course).

1 is a strength so I'm assuming you're not arguing about that.

The only way I can measure cost is in runtime performance, development overhead, and (and this is the punch line) the translation team, who actually have a MUCH LARGER stake in this than any of us. And I think we hit it out of the park in all three areas.

I'll give you grand slams on performance and the translation team. I'd give you a sac fly for development overhead,

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Jason T. Greene" <jason.greene(a)redhat.com&gt; Cc: "Andrig Miller" <anmiller(a)redhat.com&gt;, "JBoss AS7 Development" <jboss-as7-dev(a)lists.jboss.org&gt; Sent: Wednesday, June 6, 2012 4:32:02 PM Subject: Re: [jboss-as7-dev] manual way to do logging? On 6/6/12 5:02 PM, Jason T. Greene wrote: > On 6/6/12 3:43 PM, Andrig Miller wrote: > >> I'm not sure we have to have these discussions over and over and >> over >> again. From my perspective, performance being my primary concern, >> JBoss logging has been awesome, and it meets all the companies >> requirements. I haven't been able to put an exact percentage on it >> yet, but the use of JBoss logging has improved throughput on all >> the >> workloads I have tested, that is for sure. >> The performance gains you are seeing are from not doing stupid things which are pretty easy to avoid. i.e. not doing string concatenations when your logging level isn't triggered.

>> If we continue to pollute the code base with different logging >> frameworks, a lot of those gains could start to disappear. Besides >> the fact, that we are about to ship a product in multiple >> languages >> for the first time, and we have to continue to finish the work we >> started. >> >> Is is all that difficult to adopt JBoss logging? This all seems >> counter productive. > > Right I think we need to know why it needs to be abstracted. What > is > missing from jboss logging that requires RESTEasy to have an > abstraction? Once we know the answer to that question, we can > either add > whatever the missing thing is, or recommend how to go about > building > something custom with similar perf characteristics (if the advice > is > even wanted). > The reasons are simple: I don't want a *hard* dependency on yet another logging abstraction within my codebase. I really don't want to write a logging abstraction, I just want to have a tiny level of indirection so that I'm not dependent on any one of them. You don't think I have any right to be a little frustrated that I can't do this tiny level of indirection and that I have to use a full-blown code generation framework just to do logging? You don't think it is even a little bit ridiculous that you are requiring code generation just to do logging? Come on guys... You asked what's missing from JBoss Logging, I'll reiterate more completely: void info(String messageID, Object... params); void trace(String messageID, Object... params); void error(String messageID, Object... params); String getMessage(String messageID, Object... params); MessageFormat getMessageFormat(String messageID); Simple as that. You can whine about the performance implications all you want but, IMO, if you do a log-level check before you lookup the message, it shouldn't be an issue. BTW, nobody answered my previous question, @MessageBundle is fine to use? Our translation teams know how to handle them? Considering you think JBoss Logging is already perfect, I'm guessing I'll have to revert to using reflection calls on @MessageBundle if I want to keep my delegation logger. P.S. BTW Jason, I did comment multiple times on TAG-3 years ago. I'd be happy to forward the emails. What I said then was: I don't want to be dependent on yet another logging abstraction and questioned why we were spending so many engineering hours on one. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com

----- Original Message ----- > From: "Bill Burke&quot;&lt;bburke(a)redhat.com&gt; > To: "Jason T. Greene&quot;&lt;jason.greene(a)redhat.com&gt; > Cc: "Andrig Miller&quot;&lt;anmiller(a)redhat.com&gt;, "JBoss AS7 Development&quot;&lt;jboss-as7-dev(a)lists.jboss.org&gt; > Sent: Wednesday, June 6, 2012 4:32:02 PM > Subject: Re: [jboss-as7-dev] manual way to do logging? > > > > On 6/6/12 5:02 PM, Jason T. Greene wrote: >> On 6/6/12 3:43 PM, Andrig Miller wrote: >> >>> I'm not sure we have to have these discussions over and over and >>> over >>> again. From my perspective, performance being my primary concern, >>> JBoss logging has been awesome, and it meets all the companies >>> requirements. I haven't been able to put an exact percentage on it >>> yet, but the use of JBoss logging has improved throughput on all >>> the >>> workloads I have tested, that is for sure. >>> > > The performance gains you are seeing are from not doing stupid things > which are pretty easy to avoid. i.e. not doing string concatenations > when your logging level isn't triggered. > That's only part of it. The design overall is much better from a performance perspective too. You can still use it poorly and have performance issues, as with anything.

On 6/6/12 3:19 PM, David M. Lloyd wrote: > Up to you, but you get to be the one to tell the translation team I'll just forward those emails onto you. > why > they have to key all their messages off of an integer ID instead of a > descriptive name. And you also get to reinvent the tooling which > provides them with the English translation to work from. You mean all this crap isn't built on top of simple property files? (At least thats what I saw in the jboss-logging-processor testsuite)

> Doesn't sound > like a good use of time to me. > I agree. Which is why this is at the very bottom of my queue now because you guys had to over-engineer this.

On 6/6/12 2:11 PM, David M. Lloyd wrote: > On 06/06/2012 12:35 PM, Bill Burke wrote: >> I do not want to use the JBoss Logging annotation framework as I do not >> want to have a hard dependency on JBoss Logging for my project. >> >> Is there a manual API that I can use instead to build a message? >> Something like: >> >> String getMessage(long id, Object... params); > No, there isn't (and if there were, it'd be part of JBoss Logging, > so...). You can however use the maven-shade-plugin to slurp the JBoss > Logging classes into your project (even under another package name). > It's a pretty small project and we're working to make it smaller. > Eh, I guess I could just use reflection techniques to create my own abstraction and stuff the logging interfaces in a separate jar. BTW, this is ridiculously over-engineered and at least for me, harder to adapt to my project. These engineering hours could have been better spent elsewhere.

You are really gonna bring this up again? I spent 10 minutes on my logging abstraction about 3 years ago, and will spend 2 more minutes hooking in resource bundle support and have zero code/library dependencies and avoid the performance hit that jboss-logging currently has (well, the code generation part of it anyways) and have something thats 100 times simpler that uses traditional best practices and libraries. So I guess you should rephrase your response... On 6/22/12 6:50 AM, Thomas Diesler wrote: > You may find that you need to spend so much energy on your logging > abstraction that it makes you wonder why not to use jboss-logging as > your logging abstraction in the first place. Is this NIH? > > -thomas > > On 06/06/2012 08:32 PM, Bill Burke wrote: >> >> On 6/6/12 2:11 PM, David M. Lloyd wrote: >>> On 06/06/2012 12:35 PM, Bill Burke wrote: >>>> I do not want to use the JBoss Logging annotation framework as I >>>> do not >>>> want to have a hard dependency on JBoss Logging for my project. >>>> >>>> Is there a manual API that I can use instead to build a message? >>>> Something like: >>>> >>>> String getMessage(long id, Object... params); >>> No, there isn't (and if there were, it'd be part of JBoss Logging, >>> so...). You can however use the maven-shade-plugin to slurp the JBoss >>> Logging classes into your project (even under another package name). >>> It's a pretty small project and we're working to make it smaller. >>> >> Eh, I guess I could just use reflection techniques to create my own >> abstraction and stuff the logging interfaces in a separate jar. >> >> BTW, this is ridiculously over-engineered and at least for me, >> harder to >> adapt to my project. These engineering hours could have been better >> spent elsewhere. >> >

This thread will probably never die :D ;-) -- Alessio Soldano Web Service Lead, JBoss _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

F**k you Nvidia!!!!!!! Oh wait, wrong discussion.

On 06/22/2012 10:07 AM, Aaron Walker wrote: > I hope it never does.... It's discussions like this that keep me subscribed to this list :) > > I was waiting for someone else to throw in another hand-grenade... > > Best thread in a long while :) > > On 22/06/2012, at 1:28 PM, Alessio Soldano wrote:

Actually manual logging is hard. You need a truck. http://media.treehugger.com/assets/images/2011/10/truck-logging-trees-pho... On 06/22/2012 11:07 AM, James Perkins wrote: > On 06/22/2012 08:13 AM, David M. Lloyd wrote: >>> F**k you Nvidia!!!!!!! >>> >>> Oh wait, wrong discussion. _______________________________________________ jboss-as7-dev mailing list jboss-as7-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

JBoss Logging has solved that problem too! They custom make a truck per log. The downside is you can only buy these custom trucks through a JBoss Logging distributor. And, if you already have a fleet of trucks that are the same model to make maintenance easier you're screwed, but hey, its really cool to have a truck tailor made per log! On 6/22/12 1:00 PM, Anil Saldhana wrote: > Actually manual logging is hard. You need a truck. > http://media.treehugger.com/assets/images/2011/10/truck-logging-trees-pho... > > On 06/22/2012 11:07 AM, James Perkins wrote: >> On 06/22/2012 08:13 AM, David M. Lloyd wrote: >>>> F**k you Nvidia!!!!!!! >>>> >>>> Oh wait, wrong discussion. > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >