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