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

David M. Lloyd david.lloyd at redhat.com
Mon May 5 16:00:14 EDT 2008 

Well I'd be just as happy to put it in 5.1.

- DML

On 05/05/2008 03:00 PM, Bill Burke wrote:
> Cool. Let's delay JBoss 5 another year to complete this refactoring too...
> 
> 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
>

More information about the jboss-development mailing list