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

Steve Ebersole steve at hibernate.org
Mon May 5 12:39:58 EDT 2008 

<quote>
The world if bigger than Hibernate
</quote>

True, and you know what... the word is bigger than JBoss AS.  As I   
have mentioned numerous times, it is extremely arrogant and "ivory  
tower"-ish to expect all libraries you want to consume into AS to  
comply with your logging requirement.

And honestly, this whole thread shows the issues with attempting to  
integrate with AS imo.  Namely almost a year ago I cam on this list  
and asked about this very thing we are now disucssing.  And none of  
you wanted to discuss it (oh some came and gave their opinions on  
topics other than the question asked, sure...).  Yet here y'all are a  
year later willing to discuss it and chastized me and so on and so  
forth.  An ounce of prevention...  But no (and not to single *you*  
out, though you certainly fall into this) you'd rather bash people  
after the fact as opposed to discuss before hand and come to a  
consensus.  And *thats* why this is so frustrating.


On May 5, 2008, at 11:29 AM, Bill Burke wrote:

> 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 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
>>>
>>> -- 
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>> _______________________________________________
>>> 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
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> 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