Re: Proposal for a Xalan-Java 2 Extensions library - Redirectextension alternative

[Daniel Lopez <D....@uib.es>]

Hi,
I implemented a somehow similar architecture into our web applications
framework; we are quite happy with it so I thought I would through it in
this brainstorming discussion.


What we do is (remember that this for java programs):
.- First, we have a LogPipe interface which developers have to implement
if they want to specify a special way of logging. This specific classes
have to implement a couple of methods similar to
public abstract void log( String logLevel,
                          String message);
Loglevel is a useful attribute to group messages and its usefulness will
be clearer afterwards
.- Second we have a Logger object that is used throughout the system to
log messages. This object redirects messages to the appropriate LogPipe
implementation depending on the loglevel of the message.
.- Third, to specify the configuration we use special files (formatted
in XML! ;) ) that allow the user to define new loglevels, to specify the
logpipes used and to enable/disable loglevels. 
For example:
<LOGGING>
	<LOGLEVEL
		NAME="MY_LOG_LEVEL" >
	</LOGLEVEL>
<!--
Defines a custom log level, MY_LOG_LEVEL, that the user is probably
using inside his code.
-->
	<LOGPIPE
		CLASSNAME = "org.leaf.log.StandardLogPipe"
		LOG="TRUE" >
<!--
Specifies that the implementation that must be used for this pipe is
org.leaf.log.StandardLogPipe, which is the standard provided by the 
framework and does nothing else but System.err.println.
-->
		<PROPERTY NAME="ADD_DATE" VALUE="FALSE" />
<!--
Every log pipe implementation can have its own properties to modify
its behaviour
-->
		<ACTIVATED LEVELNAME="LOG_PRODUCTION" />
		<DEACTIVATED LEVELNAME="SECURITY_TRAFFIC" />
		<ACTIVATED LEVELNAME="MY_LOG_LEVEL" />
<!--
Defines the log levels that must be redirected to this pipe. The first
two levels are already defined in the framework.
-->
	</LOGPIPE>
</LOGGING>

With this configuration, a call to theLogger.log("LOG_PRODUCTION","my
message") would be sent
to the stderr, and a call to theLogger.log("SECURITY_TRAFFIC","my
security message")would be
ignored. If you changed the LOGPIPE->CLASSNAME, you could specify a
logPipe that stores messages
in a database, another one that sends you mails when the loglevel is
CRITICAL_ERROR etc. Various log pipes can be defined, log levels can be
nested so I think the system is flexible enough ;).

Applying this to what Chris asked, you will just have to configure the
Logger that the processor
has to use and then using <xsl:message xalan:target="error">Log this to
err log.</xsl:message>
would be the translated inside the processor to theLogger.("error","Log
this to err log.").

I hope I hadn't bored you with this long message,
Just my 2 eurocents, quite cheap nowadays :)
Dan
-------------------------------------------
Daniel Lopez Janariz (D.Lopez@uib.es)
Web Services
Computer Center
Balearic Islands University
-------------------------------------------


Shane_Curcuru@lotus.com wrote:
> 
> One cheap-o suggestion: why not implement your own ErrorHandler (or
> ProblemListener, etc.) and pass that into the processor?  Then you'll get
> callbacks for any xsl:message elements that get processed, and you can do
> whatever logging you want from there with the message text.  Obviously
> you'd need to encode the selection of different output into the text of the
> message itself, which isn't pretty, but this might be a simpler solution if
> you're in a hurry.  And anyone else who uses your stylesheet without your
> ErrorHandler would still get normal results, with just a few extra
> characters sent to System.out.
> 
> I do still like the general idea of being able to specify to the processor
> where/how to output messages and other stuff though, but it sounds like
> that needs a little more design (and some implementation!).
> 
> ---- you "Chris P. McCabe" <ch...@choicehotels.com> wrote ---
> >   I think having an output target of xsl:message would be a nice feature.
> > What would really be cool is if you could add a level of abstraction to
> the
> > target and have something like:
> > <xsl:message xalan:target="error">Log this to err log.</xsl:message>
> ...
> ----    ----
> - Shane        Automation, Test & Build guy
> mailto:shane_curcuru@lotus.com  AIM:xsltest
>   http://alphaworks.ibm.com/tech/LotusXSL
>   http://xml.apache.org/xalan