jon 01/03/19 00:13:56
Modified: . TODO-1.0.txt
Log:
texen test: done
log4j stuff: done
Revision Changes Path
1.16 +0 -66 jakarta-velocity/TODO-1.0.txt
Index: TODO-1.0.txt
===================================================================
RCS file: /home/cvs/jakarta-velocity/TODO-1.0.txt,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- TODO-1.0.txt 2001/03/19 06:42:48 1.15
+++ TODO-1.0.txt 2001/03/19 08:13:55 1.16
@@ -1,57 +1,5 @@
+------------- Critical For Release -------------+
-o Log4j for Logging
-
- PLAN:
- Simply replace the org.apache.log package for now. Just a flat
- replacement for the features that log4j provides. The logging
- interface can come later.
-
- STATUS:
- [JVZ] I will do this if we can agree on this.
- [JSS]
- Ok, I wrote the start of a pluggable system. In other words,
- the LogManager can now be writen to Class.forName() the
- appropriate class. I took the default Avalon code and
- created an AvalonLoggingSystem. It should be possible to create
- a Log4JLoggingSystem and then have LogManager instantiate that
- instead.
-
- Note: We should probably make it so that this can be tied
- in with Turbine's logging system as well so that we can have a
- centralized system as needed. In other words, instead of logging
- to a separate log file, we should be able to have Turbine init
- Velocity and then have Turbine hand it a LoggingSystem to use.
- [GMJ] I assume what you meant was that with a nice
- logging interface, Turbine can write an adapter around
- it's logging system, so that it is compatible with
- what Velocity requires so you can just hand velocity
- a 'TurbineVelocityLogAdapter' that implements
- Velocity.LoggingSystemIfc (so to speak) :) And instead
- of depending on Class.forName() it would be great to be
- able to hand Vel a living instance, so the client app could
- do all the configuration it needs to, and give it to Vel
- like any other config val : setProperty( 'logger', mylogger);
-
- Note: Implementing Log4J might become somewhat difficult if we
- want to support all of its features because it will add a lot
- of configuration options to the vel.props file. For instance,
- the ability to log to a console + syslog + file all at the same
- time.
- [GMJ] a solution there would be to offer a nice adapter to
- log4j for people to use (use the one we use internally)
- so for that kind of 'advanced' use they would config log4j
- themselves, wrap in the adapter, and hand that to Vel.
- No muss, no fuss, and no endless config options.
-
- [GMJ] +1 on log4j - and I think a simple Interface here and now
- would go a long way. Nothing too fancy - just let people
- plug in what they want.
- - another issue is distribution - we have a nice thing now
- where the user doesn't have to go fetch anything to get vel
- going. I assume that we will include a tested version of
- log4j with the distro? [JSS] yes.
-
o Get a copy of Alexandria for Javadocs
PLAN:
@@ -88,20 +36,6 @@
STATUS:
[NONE]
-o Test for Texen
-
- PLAN:
- Just add a simple test for Texen to make sure things
- don't break when changes are made.
-
- STATUS:
- [JVZ] I will add the test for Texen.
- [GMJ] Any chance we want to push this and Anakia
- to the new Commons project? Good tools, good to
- be shared, and we will certainly get more
- people interested in Velocity...
- [JVZ] Done.
-
o Control Caching Resource Usage
Change resource caching to limit cache size and expire
