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