Hi,
this is the *exact* thing I was concerned about in my previous email in
regarding the approach for developing components. At a certain stage when
components are complex enough they begin relying on infrastructure. In this
case the need to integrate with the turbine service directory and the
logging service. They already integrate with the config and component model.
Basically before we proceed we need to decide what we would od in a case
like this?
At 08:44 21/2/01 -0500, Sam Ruby wrote:
>Jon Stevens wrote:
>>
>> Martin Poeschl wrote:
>>
>> > the pool.jar includes util.Log but it doesn't include services.logging.
>*
>> >
>> > should the logging-service be included??
>> >
>> > martin
>>
>> Ug. Yucky *necessary* dependencies. I'm starting to feel like the
>> pool.jar cannot be abstracted from Turbine any longer. That bugs
>> me and I don't know a solution other than to disable logging in
>> the pool. After all of the discussion on general@jakarta, I'm
>> starting to feel like no one in J2EE land is interested in this
>> pool any longer anyway. Anyone have other ideas, suggestions or
>> comments?
>
>
>Either:
>
>1) We need to make the abstraction for logging independent of Turbine and a
>Jakarta "standard".
>
>2) Standardize Jakarta on a single concrete implementation
>(jakarta-log4j?).
>
>or
>
>3) as you stated, not do logging in reusable components. (YUCK).
>
>I'm copying the library-dev mailing list as the people there will obviously
>need to grapple with these types of issues.
>
>- Sam Ruby
>
>
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
