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

[Sh...@lotus.com]

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

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