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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> > > > ----------------------------- > Steve Ebersole > > Project Lead > http://hibernate.org > steve(a)hibernate.org > > > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> >> >> ----------------------------- >> Steve Ebersole >> >> Project Lead >> http://hibernate.org >> steve(a)hibernate.org >> >> >> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development ----------------------------- Steve Ebersole Project Lead http://hibernate.org steve(a)hibernate.org _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>> >>> >>> ----------------------------- >>> Steve Ebersole >>> >>> Project Lead >>> http://hibernate.org >>> steve(a)hibernate.org >>> >>> >>> >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > ----------------------------- > Steve Ebersole > > Project Lead > http://hibernate.org > steve(a)hibernate.org > > > > ----------------------------- Steve Ebersole Project Lead http://hibernate.org steve(a)hibernate.org _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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

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(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>> >>>>>> >>>>>> >>>>>> ----------------------------- >>>>>> Steve Ebersole >>>>>> >>>>>> Project Lead >>>>>> http://hibernate.org >>>>>> steve(a)hibernate.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>>> >>>> ----------------------------- >>>> Steve Ebersole >>>> >>>> Project Lead >>>> http://hibernate.org >>>> steve(a)hibernate.org >>>> >>>> >>>> >>>> >>> >>> >>> ----------------------------- >>> Steve Ebersole >>> >>> Project Lead >>> http://hibernate.org >>> steve(a)hibernate.org >>> >>> >>> >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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.

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(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----------------------------- >>>>>>>>> Steve Ebersole >>>>>>>>> >>>>>>>>> Project Lead >>>>>>>>> http://hibernate.org >>>>>>>>> steve(a)hibernate.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-development mailing list >>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jboss-development mailing list >>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>> >>>>>>> >>>>>>> ----------------------------- >>>>>>> Steve Ebersole >>>>>>> >>>>>>> Project Lead >>>>>>> http://hibernate.org >>>>>>> steve(a)hibernate.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> ----------------------------- >>>>>> Steve Ebersole >>>>>> >>>>>> Project Lead >>>>>> http://hibernate.org >>>>>> steve(a)hibernate.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development ----------------------------- Steve Ebersole Project Lead http://hibernate.org steve(a)hibernate.org _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

<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(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss- >>>>>>>>>>>>> development >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ----------------------------- >>>>>>>>>>> Steve Ebersole >>>>>>>>>>> >>>>>>>>>>> Project Lead >>>>>>>>>>> http://hibernate.org >>>>>>>>>>> steve(a)hibernate.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jboss-development mailing list >>>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> jboss-development mailing list >>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>> >>>>>>>>> >>>>>>>>> ----------------------------- >>>>>>>>> Steve Ebersole >>>>>>>>> >>>>>>>>> Project Lead >>>>>>>>> http://hibernate.org >>>>>>>>> steve(a)hibernate.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----------------------------- >>>>>>>> Steve Ebersole >>>>>>>> >>>>>>>> Project Lead >>>>>>>> http://hibernate.org >>>>>>>> steve(a)hibernate.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jboss-development mailing list >>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> ----------------------------- >> Steve Ebersole >> Project Lead >> http://hibernate.org >> steve(a)hibernate.org >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development ----------------------------- Steve Ebersole Project Lead http://hibernate.org steve(a)hibernate.org

On Mon, May 5, 2008 at 7:15 PM, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > See, now we can have an actual technical discussion, even one that > is a > year later than it should have been. Or you can keep calling me > names. > Either way... Nobody has insulted you. The only problem is that you apparently demand, since as Bill noted the world revolves around Hibernate, that usage of slf4j would be met with a "great idea, thanks for adding a dependency :)" comment. Rémy _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Well I think you're all a bunch of poopyheads. That said, anyone care to comment on my idea? - DML On 05/05/2008 12:41 PM, Steve Ebersole wrote: > Great, more technical discussion from Remy... how surprising LOL > > On May 5, 2008, at 12:28 PM, Rémy Maucherat wrote: > >> On Mon, May 5, 2008 at 7:15 PM, Steve Ebersole <steve(a)hibernate.org&gt; >> wrote: >>> See, now we can have an actual technical discussion, even one that is a >>> year later than it should have been. Or you can keep calling me names. >>> Either way... >> >> Nobody has insulted you. The only problem is that you apparently >> demand, since as Bill noted the world revolves around Hibernate, that >> usage of slf4j would be met with a "great idea, thanks for adding a >> dependency :)" comment. >> >> Rémy >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > > > ----------------------------- > Steve Ebersole > > Project Lead > http://hibernate.org > steve(a)hibernate.org > > > > > > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

Great, more technical discussion from Remy... how surprising LOL

In slf4j, binding to log4j as the logging backend, one simply includes an additional jar (slf4j-log4j) and your done;

I have no clue how jboss-logging works, how it is configured, how it plays in environments other than JBoss AS.

I'm more than willing to take a look at what it might take to bridge slf4j and jboss-logging.

On Mon, 05 May 2008 20:12:29 +0200, Ales Justin <ales.justin(a)gmail.com&gt; wrote: > Weird that you have to modify some class, StaticLoggerBinder. > > What you could do is just add a System property which would take a list > of possible new impls, and the check if they exist on the classpath via > reflection, taking the first one existing. This is exactly why commons-logging was scrapped! reflection is not usable across different deployment scenarios.

This is exactly why commons-logging was scrapped! reflection is not usable across different deployment scenarios.

Doesn't jboss-logging rely on other jboss jars though? On May 5, 2008, at 12:37 PM, Ales Justin wrote: >> In slf4j, binding to log4j as the logging backend, one simply >> includes an additional jar (slf4j-log4j) and your done; > > What is the content of this jar? > We might do something similar slf4j --> jboss-logging --> jdk|log4j. > >> I have no clue how jboss-logging works, how it is configured, how >> it plays in environments other than JBoss AS. > > In AS you have conf/jboss-log4j.xml, which 'controls' all logging > inside AS env. > In other envs it depends. > e.g. standalone usage of jboss-logging + log4j --> put all 3 (jboss- > logging-spi, jboss-logging-log4j, log4j) artifacts on classpath + > log4j.properties and you're done. You code against jboss-logging- > spi, but that picks up jboss-logging-log4j at init, which inits > log4j, which is what gets used as the real impl. > > If you could look into slf4j-log4j, and see if we can write slf4j- > jbosslogging, that would be great. > I can help you with any questions, or we can hack that together - > after I find some time off from Emmanuel's jsr303. :-) > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development ----------------------------- Steve Ebersole Project Lead http://hibernate.org steve(a)hibernate.org

I understand that sooner or later we'll have to incorporate a library using the slf4j logging facade, so it's just a matter of time. I quickly wrote an slf4j-to-jboss-logging-spi adapter (slf4j-jboss-logging) so then it won't matter if hibernate uses slf4j or not, it will simply forward to our jboss-logging-spi.

Steve Ebersole wrote: > <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. Hey I tried to be helpful! :) I even wrote code to help jboss- logging fit your needs. I don't see any reason why it can't be used outside of the AS. If it couldn't be, I would consider that a bug. It is true that sl4j might be better, but IMO we really should try and pick one universal log adapter framework. Else integration is a mess (it already is). -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>> >>>>>>> >>>>>>> >>>>>>> ----------------------------- >>>>>>> Steve Ebersole >>>>>>> >>>>>>> Project Lead >>>>>>> http://hibernate.org >>>>>>> steve(a)hibernate.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> >>>>> >>>>> ----------------------------- >>>>> Steve Ebersole >>>>> >>>>> Project Lead >>>>> http://hibernate.org >>>>> steve(a)hibernate.org >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> ----------------------------- >>>> Steve Ebersole >>>> >>>> Project Lead >>>> http://hibernate.org >>>> steve(a)hibernate.org >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----------------------------- >>>>>>>>> Steve Ebersole >>>>>>>>> >>>>>>>>> Project Lead >>>>>>>>> http://hibernate.org >>>>>>>>> steve(a)hibernate.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-development mailing list >>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jboss-development mailing list >>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>> >>>>>>> >>>>>>> ----------------------------- >>>>>>> Steve Ebersole >>>>>>> >>>>>>> Project Lead >>>>>>> http://hibernate.org >>>>>>> steve(a)hibernate.org >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> ----------------------------- >>>>>> Steve Ebersole >>>>>> >>>>>> Project Lead >>>>>> http://hibernate.org >>>>>> steve(a)hibernate.org >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > ----------------------------- > Steve Ebersole > Project Lead > http://hibernate.org > steve(a)hibernate.org > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss- >>>>>>>>>>>>> development >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ----------------------------- >>>>>>>>>>> Steve Ebersole >>>>>>>>>>> >>>>>>>>>>> Project Lead >>>>>>>>>>> http://hibernate.org >>>>>>>>>>> steve(a)hibernate.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jboss-development mailing list >>>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> jboss-development mailing list >>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>> >>>>>>>>> >>>>>>>>> ----------------------------- >>>>>>>>> Steve Ebersole >>>>>>>>> >>>>>>>>> Project Lead >>>>>>>>> http://hibernate.org >>>>>>>>> steve(a)hibernate.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ----------------------------- >>>>>>>> Steve Ebersole >>>>>>>> >>>>>>>> Project Lead >>>>>>>> http://hibernate.org >>>>>>>> steve(a)hibernate.org >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jboss-development mailing list >>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> ----------------------------- >>> Steve Ebersole >>> Project Lead >>> http://hibernate.org >>> steve(a)hibernate.org >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > ----------------------------- > Steve Ebersole > Project Lead > http://hibernate.org > steve(a)hibernate.org > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development _______________________________________________ jboss-development mailing list jboss-development(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-development

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(a)lists.jboss.org >>>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> ----------------------------- >>>>>>>>>>>> Steve Ebersole >>>>>>>>>>>> >>>>>>>>>>>> Project Lead >>>>>>>>>>>> http://hibernate.org >>>>>>>>>>>> steve(a)hibernate.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> jboss-development mailing list >>>>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> jboss-development mailing list >>>>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ----------------------------- >>>>>>>>>> Steve Ebersole >>>>>>>>>> >>>>>>>>>> Project Lead >>>>>>>>>> http://hibernate.org >>>>>>>>>> steve(a)hibernate.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ----------------------------- >>>>>>>>> Steve Ebersole >>>>>>>>> >>>>>>>>> Project Lead >>>>>>>>> http://hibernate.org >>>>>>>>> steve(a)hibernate.org >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> jboss-development mailing list >>>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> jboss-development mailing list >>>>>>>> jboss-development(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>>> _______________________________________________ >>>>>>> jboss-development mailing list >>>>>>> jboss-development(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>>> _______________________________________________ >>>>>> jboss-development mailing list >>>>>> jboss-development(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>>> _______________________________________________ >>>>> jboss-development mailing list >>>>> jboss-development(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>>> ----------------------------- >>>> Steve Ebersole >>>> Project Lead >>>> http://hibernate.org >>>> steve(a)hibernate.org >>>> _______________________________________________ >>>> jboss-development mailing list >>>> jboss-development(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/jboss-development >>> _______________________________________________ >>> jboss-development mailing list >>> jboss-development(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-development >> >> >> ----------------------------- >> Steve Ebersole >> >> Project Lead >> http://hibernate.org >> steve(a)hibernate.org >> >> >> >> >> _______________________________________________ >> jboss-development mailing list >> jboss-development(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jboss-development > _______________________________________________ > jboss-development mailing list > jboss-development(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-development