Jason van Zyl wrote:
> > what is the current status of the logging stuff??
> > i would like to help to use log4j in turbine.
> > is there anyone working on this??
>
> I think someone at e-point was working on this? Rafal, wasn't
> a co-worker of yours working on something?
It's done and ready to commit.
We have a logging implemented as a true Turbine service.
It's a bootstrap service, just as ResourceService.
Tomek used a separate configuration file, to make the two
services independent. I expect that you probably won't
like this solution, but we ran into all sorts of dependency
problems between LoggingService, ResourceService and
TurbineServices broker class itself, so this seemed to be
the easiest solution.
Because of the recent changes (ResourceService & LoggingService)
the services framework lost much of it's design pattern purity.
There are things in Turbine that depend on the implementation
(TurbineServices) instead of interface (ServiceBroker).
This is not good. We need to enhance the framework to define
the two services. I don't see any posibility to do it otherwise,
because the broker *depends* on a configuration service and
logging.
Unfortunately I don't have time to work on that...
Going back to the LoggingService:
- org.apache.turbine.util.Log is a façade to the service
- there are two implementations of the service
- ServletLoggingService - sends all messages to the container's
context log
this implementation does not use any configuration settings
- TurbineLoggingService - uses an xml file to define logical logging
destinations (facilities?)
- each destitation uses an implementation of the Logger interface
therer are three implementations of this interface.
- ServletLogger - sends messages to the container's log
- FileLogger - sends messages to a file
- Log4JavaLogger - uses Log4J to write into a file, unix syslog
daemon, or remote
Log4J server.
- we have a few example config files, and an xdoc (it needs some work on
the language
side, but it's a good start)
- it's tested and working in our system right now.
- Log4JavaLogger depends on log4j.jar, there is a mechanism similar to
that
for JPython (prepare on demand).
The changes are pretty wide-sperad, so I'm not sure how should I
proceed:
Should I review it once more, and commit it tomorrow, or should I make
a patch available for others to review and wait with commiting?
Tell me what you think. I'll assume that no votes = go ahead and commit
tomorow.
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
