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

Steve Ebersole steve at hibernate.org
Mon May 5 15:55:54 EDT 2008 

I love magic!

On May 5, 2008, at 2:39 PM, David M. Lloyd wrote:

> Sure.  Everyone uses whatever log framework they want.  Then when  
> they all go in to the appserver, it all just works.  It's like magic!
>
> - DML
>
> On 05/05/2008 02:30 PM, Steve Ebersole wrote:
>> Can't you just use small words for those of us that aren't  
>> deployment experts? :)
>> On May 5, 2008, at 2:24 PM, David M. Lloyd wrote:
>>> Yeah, this is the exact basis of my idea to make emulation APIs  
>>> for AS/MC deployments.  We could provide APIs for every logging  
>>> framework known to mankind, including multiple versions of the  
>>> same framework if they happen to be incompatible (if we do our  
>>> deployments correctly anyway).
>>>
>>> Then the user just has to specify what logging API they use in  
>>> their deployment somehow (it would be cool if we could just  
>>> dynamically sniff out that info).  As Scott pointed out, we also  
>>> would need a way to parse all the different logging config  
>>> formats.  Which pretty much brings us up to date. :-)
>>>
>>> - DML
>>>
>>> On 05/05/2008 02:17 PM, Steve Ebersole wrote:
>>>> 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
>>>> _______________________________________________
>>>> 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
>> _______________________________________________
>> 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