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