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

Steve Ebersole steve at hibernate.org
Mon May 5 15:30:19 EDT 2008 

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

More information about the jboss-development mailing list