JBoss logging module has been around for 7 years.... So I don't know WTF
you're talking about...
Steve Ebersole wrote:
OMG, did you just chastize me for the same exact thing y'all are
doing?
On May 5, 2008, at 8:20 AM, Bill Burke wrote:
> Shame on Steve for introducing yet another logging framework. All
> you're gonna do is piss off every JBoss AS user that wants to debug
> Hibernate and has to figure out shitLog4j.
>
> I hate to single you out, but this is another example of the ivory
> tower, silo development we have at JBoss where nobody cares about how
> they fit into the bigger picture. The world if bigger than Hibernate.
>
> David M. Lloyd wrote:
>> I'm a bit hazy on the details but I understand that some logging
>> frameworks allow you to subclass a base logger class, and some don't
>> - so if you do so it's really difficult to properly weave in the
>> appropriate substitution. Last time I heard, Trustin still didn't
>> have a solution to the problem.
>> Have you already made the switch to JDK logging in the jbossas core?
>> If so, is there a sensible LogManager yet?
>> Also, do we need to do anything funky like support different
>> configurations on a per-deployment basis? I am under the impression
>> that Glassfish does this, but I haven't figured out the details yet.
>> For configurations, I get what you're saying - though I imagine
>> there's probably users out there who want to use their own logging
>> framework and configuration in certain deployments, so I think we'd
>> need a way to support that - maybe just by detecting the presence of
>> a logging implementation in the deployment or something.
>> Otherwise, based on what I know of the various logging configuration
>> formats, we could probably just rewrite the logging configuration
>> into a bean deployment that just uses the JDK logging API to acquire
>> and configure Logger and Handler instances, rather than try to use
>> the stupid properties system that the default LogManager uses.
>> - DML
>> On 05/04/2008 02:42 PM, Scott Stark wrote:
>>> All that I can recall as a reasonable compromise was to simply move
>>> to the jdk logging with the replacement logging handlers based on
>>> the log4j type of appenders I ported over when previously looking at
>>> this problem. Trustin has since introduced log2log, we could always
>>> use jboss retro to map framework X onto the jbossas core, but that
>>> does not cover the framwork X configuration files.
>>>
>>> How I can see the mc and jbossas deployment framework fitting in is
>>> by rewriting the logging system X config files onto the current
>>> jbossas implementation if that is desired. The problem always is
>>> whether the logging in question is part of a user application, or a
>>> jbossas framework. In reality I only see jdk logging for the server
>>> frameworks and other frameworks wanting to integrate with the server
>>> logs having a jdk logger option, or an adaptor.
>>>
>>> What are the log2log issues showing up?
>>>
>>> David M. Lloyd wrote:
>>>> Well, that's a good project, but bytecode weaving seems like a
>>>> pretty heavy-duty solution to a simple problem.
>>>>
>>>> The basic problem is, people (within JBoss and without) are going
>>>> to use the frameworks they're going to use. How much effort is it
>>>> to adapt log2log (which has already run into some interesting
>>>> technical dilemmas) to another framework, versus just adding
>>>> another API facade? It seems like the microcontainer arch would be
>>>> perfectly suited towards auto-wiring the appropriate logging API.
>>>>
>>>> Wouldn't it be nice if we could say, "deploy your app in
>>>> JBossAS/JBossMC and it will *just work*, regardless of what logging
>>>> frameworks are being used by what"?
>>>>
>>>> - DML
>>>>
>>>> On 05/02/2008 01:41 PM, Ales Justin wrote:
>>>>> What about if we used this:
>>>>> -
https://svn.jboss.org/repos/log2log/trunk
>>>>> with-in one of our deployers, and you could mark certain
>>>>> deployments as being 'dragged' through Log2Log to
'clean-up' logging?
>>>>>
>>>>> Steve Ebersole wrote:
>>>>>> I apologize for the tone in my last response. The original
>>>>>> thread was frustrating enough, and here it is being relived. I
>>>>>> let that frustration get to me when I should not have.
>>>>>>
>>>>>> On May 2, 2008, at 12:12 PM, Steve Ebersole wrote:
>>>>>>
>>>>>>> I cannot help that AS seems to think that every piece of
>>>>>>> technology needs to be complete re-written in house.
Y'all have
>>>>>>> you're own logging framework, great, add it to the other
50 out
>>>>>>> there.
>>>>>>>
>>>>>>> The part that you are missing is that Hibernate is first and
>>>>>>> foremost a standalone library. And in terms of integration,
I
>>>>>>> have to consider integration with many containers. I'm
sure
>>>>>>> they all want jboss-logging as the 'yet another logging
api' in
>>>>>>> their environments as well.
>>>>>>>
>>>>>>> I used to use commons-logging which had a very specific
problem
>>>>>>> that slf4j solves in a unique way *on any platform*...
>>>>>>>
>>>>>>> If you recall, I asked about experiences using jboss-logging
in
>>>>>>> environments other than within JBoss AS and (in keeping with
the
>>>>>>> general theme of that thread) got no replies to the question
>>>>>>> asked:
>>>>>>>
http://lists.jboss.org/pipermail/jboss-development/2007-July/010398.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On May 2, 2008, at 11:30 AM, Scott Stark wrote:
>>>>>>>
>>>>>>>> And we said sure, introduce yet another logging api?
>>>>>>>>
>>>>>>>> Steve Ebersole wrote:
>>>>>>>>> I initiated that very discussion on this very list
almost a
>>>>>>>>> year ago ;)
>>>>>>>>>
>>>>>>>>> On May 2, 2008, at 11:15 AM, Paul Gier wrote:
>>>>>>>>>
>>>>>>>>>> I upgraded this based on JBAS-5133 and
Steve's request. I
>>>>>>>>>> can switch it back to the old version if
that's what is needed.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Scott Stark wrote:
>>>>>>>>>>> Why was hibernate updated to 3.3.0 in jbossas
trunk, and why
>>>>>>>>>>> is this pulling in yet another logging
framework? This needs
>>>>>>>>>>> to be reverted, and why there has to be yet
another logging
>>>>>>>>>>> framework dependency brought in explained.
>>>>>>>>>>> *** CONTEXTS IN ERROR: Name -> Error
>>>>>>>>>>>
vfsfile:/media/disk/workspace/tck5/jboss-5.0.0.CR1/server/cts/tmp/jsr88/ejb3_annotations_entity_vehicles.ear
>>>>>>>>>>> -> java.lang.NoClassDefFoundError:
org/slf4j/LoggerFactory
>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>> jboss-development mailing list
>>>>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -----------------------------
>>>>>>>>> Steve Ebersole
>>>>>>>>>
>>>>>>>>> Project Lead
>>>>>>>>>
http://hibernate.org
>>>>>>>>> steve(a)hibernate.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> jboss-development mailing list
>>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jboss-development mailing list
>>>>>>>> jboss-development(a)lists.jboss.org
>>>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------
>>>>>>> Steve Ebersole
>>>>>>>
>>>>>>> Project Lead
>>>>>>>
http://hibernate.org
>>>>>>> steve(a)hibernate.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------
>>>>>> Steve Ebersole
>>>>>>
>>>>>> Project Lead
>>>>>>
http://hibernate.org
>>>>>> steve(a)hibernate.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-development(a)lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development(a)lists.jboss.org
>>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>>>
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/jboss-development
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
> _______________________________________________
> jboss-development mailing list
> jboss-development(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/jboss-development
-----------------------------
Steve Ebersole
Project Lead
http://hibernate.org
steve(a)hibernate.org
_______________________________________________
jboss-development mailing list
jboss-development(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-development