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

David M. Lloyd david.lloyd at redhat.com
Mon May 5 15:39:12 EDT 2008 

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

More information about the jboss-development mailing list