Logging

[cherreman]

Hi,

I was wondering if users would be interested in having more logging info from Spring AS's internals, especially the IoC container. We currently have minimal logging enabled via an event that gets dispatched inside the container and have done this to stay away from the Flex logging API in order to stay AS3 compliant.

We could however expand the logging based on event dispatching since it is really only a temp solution, or we could create a logging facade similar to SLF4J (http://www.slf4j.org) and provide a Flex logging API adapter. (I also noticed the http://code.google.com/p/log4as3/ project, has anyone used this?)

I'm curious to know what you guys think.

regards,
Christophe

[martino.piccinato]

Yes, I'd definitely like to see much more log in SpringAS in all framework lifecycle phases.

I'm uncertain about which is the best way to do it though. Obviously strict AS3 compatibility must be retained so flex logging api cannot be used directly.

I've had quick a look at the log4as3 and it's quite nice, it would need just some clean up and some more "adapters" maybe. If Spring AS decide to go for a "traditional" logging library this could definitely be an option.

The other option would be to continue using the AS3 event system improving a bit the LogEvent class and the event hanldlers. It might seem unusual but maybe it looks more natural in AS3 where events are an important part of the core API.

An advantage of doing this would be to have an extremely light logging framework (just 2/3 classes). Everybody could then plug in handlers to use any other logging framework (or even no logging framework at all).

The main disadvantage I see for this is having to register a logger event handler at least for each class hierarchy where logging is needed (as it is done now with FlexXMLApplicationContext).
A global EventDispatcher (and log handlers) might be used around all framework but I don't know if it would be as clean and clearer as a "normal" log framework. I'm in doubt about it.

All considering my vote now still goes for log4as3 (or any other custom flexible log framework) but I'm curious to hear other opinions too.

[jfai]

It would be great to have more logging, but it needs to be optional and adaptable, especially to mx.logging. Please see <http>://jira.springframework.org/browse/SESPRINGACTIONSCRIPTAS-19.

Jürgen

[martino.piccinato]

While still being undecided I just wanted to throw in another idea: maybe the best thing would be to not have a logging framework at all.

What I mean is that instead of throwing in a more or less complex logging library or use log events stuff the framework might just create its own lifecycle events (e.g. ObjectInstantiationEvent, IocErrorEvent ecc.).

These events will be generically useful and probably not a performance burden (will be dispatched mainly on the framework startup and/or first time a lazy object is initialized) and could be (if needed) used ALSO for logging through an ad hoc listener/adapater with some logging framework. A default one for SpringAS (e.g. to use during testing/debug) might be given through a separate project.

This will keep the framework lightweight, leave logging (a cross-cut problem!) to a separate (optional) module and at the same time possibly create a series of SpringAS events interesting also for other purposes and not directly related to logging.

[borfnorton]

I agree with this. leave logging out of SpringAS. Right now I have my own logging implementation and if I could just listen for certain events from SpringAS and log those if I care, that would be satisfactory. Lets not have SpringAS get bloated as I think the whole AS3 community still has a lot of sorting out to do with regards to what projects will be running which roles (app contexts, vs logging frameworks etc)

IF SpringAS is to move forward with logging, please make it adaptable to the Flex ILogger framework and classes

Actually.. yes make the "logging" portion of SpringAS might be as simple as a bunch of very lightweight adapters for other known frameworks

[666shooter]

count me in here, I agree with keeping things as light as possible. Implement a bunch of lifecycle specific events and leave the logging frameworks far away
We really need AOP! hehe