On 11/16/06, Nestor Urquiza <[EMAIL PROTECTED]> wrote:
Since it took me a while to learn about the commons-logging wrapper and current log engines I will post here my results just in case someone has a similar problem in the future:
<snip-sample-code/> Thanks for posting for the archives. I prefer the properties files for quick configuration. See log4j manual [1] for details. Please feel free to post any of this on the Commons SCXML wiki.
questions/ideas: --------------- Wouldn't be better to include in both the tracert that implements SCXMLListener and the SCXMLListener itself a notification mechanism? We already have SCXMLListener#warning(), what about having SCXMLListener#trace()? That way we could trace what is happenning with most of the classes member of org.apache.commons.scxml.model which means we are able to track down what is happenning with the data model part.
<snap/> The Tracer is meant to be a one-stop shop for basic examples -- it provides a dummy impl (that logs callbacks) for most interfaces that one needs while dealing with the Commons SCXML APIs. The warning() method comes from the SAX ErrorHandler and is really orthogonal to logging. Its probably best to stick with JCL the way its currently done. -Rahul [1] http://logging.apache.org/log4j/docs/manual.html
Maybe PathResolverHolder is the place to specify a method trace() that could be generically implemented by an abstract class from where finally the data model bits would inherit. maybe the best way is just to separately define the trace() method for those bits we are interested in. Bottom line the idea of having a trace of what is going on and my failure to make the whole system log into a unique file made me think about this alternative which maybe is even better than just logging. Thanks, -Nestor
<snip/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
