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