Re: hibernate 3.3.0 upgrade, slf4j introduction into jbossas

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/20
07/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-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
>>> -----------------------------
>>> 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
> 
> 
> 
> 
> _______________________________________________
> 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

I love magic!

On May 5, 2008, at 2:39 PM, 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/20
07/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-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- 
>>>>>>>>>>>>>>
development
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
-----------------------------
>>>>>>>>>>>> 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
>>>> -----------------------------
>>>> 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
>> _______________________________________________
>> 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




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

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/20
07/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-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
>>>> -----------------------------
>>>> 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
>>
>>
>>
>>
>> _______________________________________________
>> 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