List Info

Thread: Re: hibernate 3.3.0 upgrade, slf4j introduction into jbossas




Re: hibernate 3.3.0 upgrade, slf4j introduction into jbossas
country flaguser name
United States
2008-05-05 10:27:58
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-d
evelopment/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-developmentlists.jboss.org
>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
-----------------------------
>>>>>>>>> Steve Ebersole
>>>>>>>>>
>>>>>>>>> Project Lead
>>>>>>>>> http://hibernate.org
>>>>>>>>> stevehibernate.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
_______________________________________________
>>>>>>>>> jboss-development
mailing list
>>>>>>>>> jboss-developmentlists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>
>>>>>>>>
_______________________________________________
>>>>>>>> jboss-development mailing
list
>>>>>>>> jboss-developmentlists.jboss.org
>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------
>>>>>>> Steve Ebersole
>>>>>>>
>>>>>>> Project Lead
>>>>>>> http://hibernate.org
>>>>>>> stevehibernate.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> -----------------------------
>>>>>> Steve Ebersole
>>>>>>
>>>>>> Project Lead
>>>>>> http://hibernate.org
>>>>>> stevehibernate.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
_______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-developmentlists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>
>>>>>
_______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-developmentlists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>
_______________________________________________
>>>> jboss-development mailing list
>>>> jboss-developmentlists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>
>>>
_______________________________________________
>>> jboss-development mailing list
>>> jboss-developmentlists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>> _______________________________________________
>> jboss-development mailing list
>> jboss-developmentlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral
.com
> _______________________________________________
> jboss-development mailing list
> jboss-developmentlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment


-----------------------------
Steve Ebersole

Project Lead
http://hibernate.org
stevehibernate.org




_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

Re: hibernate 3.3.0 upgrade, slf4j introduction into jbossas
user name
2008-05-05 11:29:33
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-d
evelopment/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/ct
s/tmp/jsr88/ejb3_annotations_entity_vehicles.ear 
>>>>>>>>>>>> ->
java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
>>>>>>>>>>>>
_______________________________________________
>>>>>>>>>>>>
jboss-development mailing list
>>>>>>>>>>>>
jboss-developmentlists.jboss.org
>>>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
-----------------------------
>>>>>>>>>> Steve Ebersole
>>>>>>>>>>
>>>>>>>>>> Project Lead
>>>>>>>>>> http://hibernate.org
>>>>>>>>>> stevehibernate.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
_______________________________________________
>>>>>>>>>> jboss-development
mailing list
>>>>>>>>>>
jboss-developmentlists.jboss.org
>>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>>
>>>>>>>>>
_______________________________________________
>>>>>>>>> jboss-development
mailing list
>>>>>>>>> jboss-developmentlists.jboss.org
>>>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>>
>>>>>>>>
>>>>>>>>
-----------------------------
>>>>>>>> Steve Ebersole
>>>>>>>>
>>>>>>>> Project Lead
>>>>>>>> http://hibernate.org
>>>>>>>> stevehibernate.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -----------------------------
>>>>>>> Steve Ebersole
>>>>>>>
>>>>>>> Project Lead
>>>>>>> http://hibernate.org
>>>>>>> stevehibernate.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
_______________________________________________
>>>>>>> jboss-development mailing list
>>>>>>> jboss-developmentlists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>>>
>>>>>>
_______________________________________________
>>>>>> jboss-development mailing list
>>>>>> jboss-developmentlists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>>
_______________________________________________
>>>>> jboss-development mailing list
>>>>> jboss-developmentlists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>>
>>>>
_______________________________________________
>>>> jboss-development mailing list
>>>> jboss-developmentlists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>>
_______________________________________________
>>> jboss-development mailing list
>>> jboss-developmentlists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
>>
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral
.com
>> _______________________________________________
>> jboss-development mailing list
>> jboss-developmentlists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment
> 
> 
> -----------------------------
> Steve Ebersole
> 
> Project Lead
> http://hibernate.org
> stevehibernate.org
> 
> 
> 
> 
> _______________________________________________
> jboss-development mailing list
> jboss-developmentlists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral
.com
_______________________________________________
jboss-development mailing list
jboss-developmentlists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-develop
ment

[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )