[jboss-dev] hibernate 3.3.0 upgrade, slf4j introduction into jbossas

Steve Ebersole steve at hibernate.org
Mon May 5 15:17:51 EDT 2008 

Another option might be dynamic replacement of the logging framework  
with a different impl altogether.  There is an example of this in  
allowing code using commons-logging to remain unchanged, and a  
different implementation of the commons-logging APIs to be substituted  
with slf4j logging: http://day-to-day-stuff.blogspot.com/2007/07/no-more-commons-logging.html 
   In fact I use this setup already in the hibernate testsuite to  
account for other libraries (commons-collections, etc) which use  
commons-logging and have them dynamically use my slf4j setup.

On May 5, 2008, at 8:11 AM, 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 at lists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -----------------------------
>>>>>>>> Steve Ebersole
>>>>>>>>
>>>>>>>> Project Lead
>>>>>>>> http://hibernate.org
>>>>>>>> steve at hibernate.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> jboss-development mailing list
>>>>>>>> jboss-development at lists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-development at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>>
>>>>>>
>>>>>> -----------------------------
>>>>>> Steve Ebersole
>>>>>>
>>>>>> Project Lead
>>>>>> http://hibernate.org
>>>>>> steve at hibernate.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> -----------------------------
>>>>> Steve Ebersole
>>>>>
>>>>> Project Lead
>>>>> http://hibernate.org
>>>>> steve at hibernate.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-development at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>>>>
>>>> _______________________________________________
>>>> jboss-development mailing list
>>>> jboss-development at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>>> _______________________________________________
>>> jboss-development mailing list
>>> jboss-development at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-development
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development
> _______________________________________________
> jboss-development mailing list
> jboss-development at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-development


-----------------------------
Steve Ebersole

Project Lead
http://hibernate.org
steve at hibernate.org

More information about the jboss-development mailing list