Also, as we are planning to change our DAS logging code, we should also
consider performance enhancements on that area. Today, I see various places
where we are doing log like this:
DebugUtil.debugln(getClass(), debug, "Adding table/column: " + typeName +
"/" + propertyName);
And I would recommend having something like this :
if( logger.isDebugEnabled)
logger.debugln(getClass(), debug, "Adding table/column: " + typeName
+ "/" + propertyName);
The problem with current code related to performance and garbage collection,
is that, even if debug is not enabled, lot's of strings are created
(e.g"Adding table/column: " + typeName + "/" + propertyName) and will
need to be
garbage collected slowing server performance.
This is a good tip for all other areas of Tuscany, altough I haven't
investigated other areas in detail.
- Luciano
On 8/24/06, Kevin Williams <[EMAIL PROTECTED]> wrote:
My poor choice of wording. I really meant "any concerns" rather than
"any objections". Thanks again!
Jim Marino wrote:
>
> On Aug 23, 2006, at 8:05 PM, Kevin Williams wrote:
>
>> Thanks for your input. I enjoyed the "evils of common logging" link.
>>
>> So, if we avoid JCL then my next suggestion would be to use either
>> Java logging or log4j directly and our users will need to deal with
>> the -- possibly -- separate logging system. Are there any
>> objections to this route?
>>
> Hopefully you didn't think I was "objecting" to using clogging (it's
> the DAS peoples' decision) but was just trying to save you the pain I
> had using that. Not knowing all of the requirements I would probably
> do one of the following:
>
> 1. Use log4j and for people that wanted to use DAS with another
> logging solution have them add an appender that pipes the information
> somewhere else
>
> 2. Externalize logging like SCA. The bootstrap would provide a
> MonitorFactory implementation that would be responsible for creating
> implementations of a specific logging interface. You could create an
> environment property that points to the factory impl to instantiate
> and have a constructor that takes an instance. The factory could then
> delegate to something else and you could have a default that uses
> reflection and sends everything to Log4J. This has the advantage of
> allowing for strongly typed logging as well as not forcing things to
> go through log4j (which may not be that big of a deal). Each
> subsystem would be responsible for using the monitor factory to
> create monitor implementations for particular components.
>
> Jim
>
>> Thanks,
>>
>> --Kevin
>>
>>
>> Jim Marino wrote:
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
-----------------------------------------------------
Luciano Resende
SOA Opensource - Apache Tuscany
-----------------------------------------------------
