On 7/27/01 10:21 AM, "Fedor Karpelevitch" <[EMAIL PROTECTED]>
wrote:
>> -----Original Message-----
>> From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
>> Sent: Thursday, July 26, 2001 2:04 PM
>> To: [EMAIL PROTECTED]
>> Subject: Torque has been separated
>>
>>
>> Hi,
>>
>> Torque is has now been completely separated. If you look at the
>> jakarta-turbine-torque module you will see that the package structure
>> has been left the same to cause as few problems as possible.
>>
>> The package structure should be cleaned up and we should define
>> an API for Torque in the same fashion as we are doing for Turbine.
>>
>> I think the following should be done as well:
>>
>> 1) Separate the connection pool and make it pluggable
>> so that torque can easily be integrated into other application
>> that already use PoolMan, or the commons connection pool, or
>> the struts connection pool or whatever
>>
>> 2) XML an configuration
>>
>> 3) Use the digester to turn the datamodel into an object and
>> get rid of the dependency on xerces. It would be nice to
>> use the digester with MinML so that the distribution can
>> be tiny
>>
>> 4) Get rid of the Log wrapper in all the code and use the log4j
>> Category c = Category.getInstance(classname) method so
>> that torque can easily be integrated into other apps. Either
>> log4j or the logging API will dominate and I'm going to take
>> log4j. But as Ceki has noted they are so similar it is very
>> easy to change from one to the other
>
> I am not sure this is a good idea. This would imply you _have_to_ use log4j,
> right?
Yes, you have to use log4j. In highly used components it's going to
come down to using the Sun logging API or using log4j. It's easy
to convert between one or the other. Right now Turbine bundles
the big log4j JAR but there is a core JAR which is much smaller.
> And if you are using torque in some app you may want to have torque use this
> app's logging facilities. I did just that - wrote an impl of LoggingService
> which delegated all calls to our app's logging facils. I am not sure it is
> easy to do if torque is hardcoded to use log4j.
I've noted this and explained that this is much easier using log4j as
all you have to do is make a log4j appender that adapts itself
to whatever logging mechanism you want. So if you really wanted
to you could use as many disparate logging systems together in
the by making a small log4j appender around each of them. Writing
an appender is _much_ simpler than doing anything with the logging
service in 2.1.
Everyone always tries to make a _simple_ logging mechanism, just like
everyone tries to roll their own webapp framework, and what you
arrive at is something like log4j. It allows total flexibility,
very powerful and doesn't limit you in any way integrating with
other logging systems.
The core log4j JAR is something like 80k and for something as
important as robust logging I don't think it's a problem to
include it.
For example, in Tambora I made a simple appender around a peer type
class that logs to a database. The appender was very simple
to make and I was able to log to a database without any difficulty.
I don't see any drawbacks in using log4j (or eventually the Sun logging API
and it's not hard to switch), but there are a lot of drawbacks in trying
use a home grown logging system because all you're doing is replicating
what log4j does. I think it's as small as you can get for a logging
package that provides everything needed for logging.
>>
>> 5) Some analysis on what we actually have would be prudent. Torque
>> is somewhat based on the work of Scott Ambler and I would like
>> to know where it is the same and where it diverges so we know
>> what we're dealing with.
>>
>> Everything seems to working in the TDK which is still the only place
>> I really test torque but if others want to try some stand-alone
>> examples that would be great. I'll put the 5 items above in the
>> notes file in the jakarta-turbine-torque repository.
>
> The same question as I had before: do you think torque's dev cycle should be
> independent of Turbine's?
Torque's development cycle will definitely be separated from Torque's.
It's just that at the moment there are no examples or tests for stand-alone
torque so I use the TDK sample app to test it. This will change shortly.
> WBR, fedor.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
--
jvz.
Jason van Zyl
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
