Home → Robotlegs 2 →

Robotlegs v2: logging

• Edit

creynders

29 Oct, 2011 08:52 AM

I already have a little bit of feedback on v2, I know, probably it's premature...
I noticed you're using the as3commons logging framework for logging, but I really think this should be a custom one, that can be swapped out. And if you guys don't have the time/don't feel like doing that, I'd be more than willing to do it.
The reasons are twofold: 1/ many people are used to using another logging framework and have their workflow centered around that 2/I think it's a shame that this forced dependency is introduced, while it could be solved with adapters IMO
oh and 3/ the as3commons one is not one of the best I think.

Maybe I'm jumping to conclusions here, and it was your intention to make it 3rd-party framework free all along? Then just ignore this comment.

Oh and BTW, v2 looks GREAT!! :)

1. 1 Posted by Stray on 29 Oct, 2011 09:13 AM

   

   H Creyenders,

   thanks!

   And yes, you're right - logging is just one of the things you can 'build in' to the context. Shaun was playing with that logging solution as a way of testing our 'have it your way' context builder, so Robotlegs won't have any dependencies on any specific logging solution.

   If you notice - it's an extension (in the extensions package) - anything in that package can be excluded from your app, either because you don't need it or because you want to replace it with your own.

   Stray

   • Edit

2. 2 Posted by Weyert on 29 Oct, 2011 10:01 AM

   

   Yes, it looks like multiple classes like the Mediator Mapping are using the logging. The problem logging classes is that they can consume a lot of memory or cause memory leaks.

   I would suggest to remove the whole logging functionality out of the base classes.

   • Edit

3. Support Staff 3 Posted by Stray on 29 Oct, 2011 10:11 AM

   

   Hi Weyert.. Where are you seeing it in the mediator mapping? I can't find any references...

   Oh - in the stage watcher?

   There are a few things that we do need to warn about, but don't worry, we won't force you to compile parts you don't want and the stage watcher messages should never or only very rarely be seen (as they are looking for a problem).

   I expect we will decouple that part from the as3commons logger as we get nearer - at this point you have to build something first you can assume it's a short cut for now.

   Sx

   • Edit

4. 4 Posted by Weyert on 29 Oct, 2011 10:44 AM

   

   Hi Stray, Great. news. It's just that I am a bit scared of memory leaks in one my projects ;)

   • Edit

5. Support Staff 5 Posted by Shaun Smith on 29 Oct, 2011 01:37 PM

   

   Howdy all,

   The as3commons Logger (v2) is an adapter. It provides support for over 20 logging frameworks:

   http://www.as3commons.org/as3-commons-logging/index.html

   Robotlegs used to include as3commons Logging (version 1) but I removed it for size and performance reasons. The Logging library (now at version 2.7) has been completely re-written from the ground up specifically to address speed, memory and performance issues. It is now small (2.1kB), fast and stable enough to include in Robotlegs. The author has spent a considerable amount of time testing and tuning the library.

   By depending on as3commons Logging we provide users with the ability to tie into their logging framework of choice with minimal effort.

   Writing a custom adapter would be a duplication of effort, and is actually a surprisingly large undertaking.

   If we decide to include logging at all (which I think is the right thing to do) then it will be through the as3commons Logging adapter. Otherwise we'll have to leave logging out of the framework completely - which will severely cripple the cool extensions we are planning to build like Inspector Gadget.

   • Edit

6. Support Staff 6 Posted by Stray on 29 Oct, 2011 01:43 PM

   

   Ah - that's it. I knew it was decoupled in some way.

   • Edit

7. Support Staff 7 Posted by Shaun Smith on 29 Oct, 2011 02:16 PM

   

   I've opened up an issue here:

   https://github.com/robotlegs/robotlegs-framework/issues/28

   • Edit

8. Support Staff 8 Posted by creynders on 29 Oct, 2011 04:28 PM

   

   I think it's definitely a good idea to have internal logging (optionally), but I'm still not convinced by the as3commons logging framework. Granted I haven't dug real deep into the code, but at a first glance there's a bunch of things that could be better. If however, I've overlooked things, I'm sorry.
   Apart from the horrible static access - which can be skipped, I know - my main gripe's that setting output level tresholds and for instance multiple logging targets is convoluted and messy. In general that's my feeling with this entire logging framework: it tries to do too much and appears to be complex (even though it maybe isn't). An logging framework shipped with RL should be extremely simple to setup, use and extend IMO.

   • Edit

9. Support Staff 9 Posted by Till Schneidere... on 29 Oct, 2011 10:40 PM

   

   We'll have a closer look at the innards of as3commons before any final decision.

   I agree with you on the general parameters anything shipped with RL
   should conform to, but you also have to see that we aren't in the
   business of implementing logging frameworks, so we have to either drop
   logging from the internals or settle on some framework that already
   exists.

   • Edit

10. Support Staff 10 Posted by creynders on 31 Oct, 2011 08:25 AM

    

    Here's a basic setup, not tested, or even compiled, but just to get a basic feel of the proposed architecture:
    https://github.com/creynders/robotlegs-framework/tree/version2/src/...
    (I kept the two extensions that were already there, but they're not used in the code in api and impl)

    No strings attached, if it's crap or for whatever other reason not useable: no problem. It's just a proposition.

    • Edit

11. 11 Posted by Roland Zwaga on 01 Nov, 2011 09:26 AM

    

    Hi there,

    I would like to offer my .00002 cents here. I'm not sure why you think as3commons-logging is convoluted or messy. IMHO its actually quite lean and mean. (Then again, I am biased since I'm part f the as3commons team, hehe).
    I know that Martin (the guy behind as3-logging) is spending a tremendous amount of time tweaking the library for optimal speed and memory consumption.
    He has written a small Wiki page on the ideas behind as3-logging here:

    https://code.google.com/p/as3-commons/wiki/whylogging

    You mention this "it tries to do too much and appears to be complex ". I don't agree, as3-logging only tries to do one thing: logging :) If it is too complex, well, I guess that is a matter of perspective. The setup process is uncommon (ok, that doesn't sit well with the name of the project, I agree hehe), but its mainly designed for optimal speed. The reason that it offers this huge load of adapters for existing frameworks is too ease the transition if people would like to switch from a specific framework to as3-logging. Using the adapters enables one to gradually make the transition.

    If a framework such as RL would use logging (and I believe it should, if a framework can report its internal processes this is great for debugging). RL is also focused on speed, as3-logging is highly optimized, so I believe it would be a good marriage :) as3logging is turned off by default, so if people aren't interested in logs, they won't be bothered. If they do want to see what's going on, they simply add one line of code to their sources to see traces:

    LOGGER_FACTORY.setup = new SimpleTargetSetup(new TraceTarget());

    Quite painless I think. But its okay if you don't share my opinion of course :)

    The introduction page is still a bit modest, that's true too. But we're working hard in the background. There are plans for a complete site overhaul and in this process a lot of the doc pages will be looked into as well.

    But for as3-logging the API docs are very complete, so for most classes I believe the explanations are quite well done:
    http://www.as3commons.org/as3-commons-logging/asdoc/index.html

    Anyways, like I said, I am biased since I'm an as3commons member, but I felt the need to chime in a little bit here :)

    Sorry for disturbing you guys :)

    cheers,

    Roland

    • Edit

12. Support Staff 12 Posted by creynders on 01 Nov, 2011 03:01 PM

    

    @roland: thanks for the clarification and as I said, probably I overlooked some things, so sorry for that!

    I'll try to clarify myself as well:
    I think as3-logging appears to be complex, because it tries to cater to too many styles and frameworks out-of-the-box. When looking at the API docs I see a bunch of classes in api, setup, targets, integration, simple, ... and the relation between those isn't very clear. Now I've looked at it more in-depth I think I do understand what does what, but still...
    For instance I'm still wondering whether it's possible to have a different setup per module? I suppose I can use the LoggerFactory class to achieve that? But when looking at the docs of LoggerFactory I'm confused since it does implement a getNamedLogger meth, but not getLogger. So is the only way to retrieve a logger through the global getLogger method? Which is basically just a convenience method to a static class meth? I'm sorry, but my spontaneous reaction is: "ughh..."

    Don't get me wrong I don't want to dis as3-logging, I think it's probably a fine logging framework, but I still don't think it should be included by default for two reasons: 1/ too broad (which is a good thing, but not when merging it INTO a framework) and 2/ my skin just crawls with the LOGGER_FACTORY static approach.

    But maybe I just don't know what I'm talking about and I'm certain you guys are far better programmers than me in all respects.

    -edited: final sentence just didn't come out right.

    • Edit

13. 13 Posted by Martin Heidegge... on 02 Nov, 2011 04:10 AM

    

    The LOGGER_FACTORY discussion was open and closed many times. For setting up logging its become common to have one singleton to access. AS3 offers the very useful syntax of public constants. Compared to classic singletons they are very easy to code and keep the swf size small.

    public static const LOGGER_FACTORY: LoggerFactory = new LoggerFactory();
    

    VS.

    private static var _loggerFactory: LoggerFactory;
    public static function getInstance(): LoggerFactory {
       return _loggerFactory ||= new LoggerFactory();
    }
    

    And instead of putting it into a class like you are used to from Java

    LoggerFactory.INSTANCE
    

    we AS3 heroes can put them in constants/function files. This doesn't swell the size of your class, is less to write and fast to execute.

    LOGGER_FACTORY
    

    Of course there is the way to go without a singleton approach (just static methods) but then you could never use more than one LoggerFactory which can be a nice thing with more complex systems.

    var factory: LoggerFactory = new LoggerFactory();
    // no code related to the singleton is included with this statement
    

    I do not recommend using Singletons in any programming language but if there is no way around ActionScript3 actually offers a surprisingly elegant way all it needs is for people to get accustomed to it. (I barely met programmers accustomed to it)

    About the naming: Writing constants big is a convention in AS3. I didn't see a need to break it. I found it irritating at first too but after using it a few times its comforting. The name LoggerFactory is a relic of V1 times that we kept as everybody knew it. Other names like LoggerPool have been in discussion but for just a name we didn't want to break old APIs. But even today after a lot of thinking I can not think of other names that would not leave a significant space for misinterpretation, and most people get what its used for.

    One of my main goals was to keep the dependencies, and with it the swf size, low: getClassLogger(class) is equal to getNamedLogger(toLogName(class)) and I mention that to illustrate: In the end, all we deal with are names=strings. The lowest common denominator. That is why the LoggerFactory just implements names. The smallest swf size would be consumed if you wrote:

    private static const logger: ILogger = LOGGER_FACTORY.getNamedLogger("com.mycompany.mypackage.MyClass");
    

    As that is a bit uncomfortable to read and to write I added the get*Logger functions. But they are optional! They consume your CPU and your SWF size just if you feel too lazy. A framework like robot legs that is used by many, many people can only be encouraged to use that complex syntax. (Yes: We are talking about microseconds if not nanoseconds here ... but still.)

    Complexity: Yes, the swc of as3commons is big, we have connectors to a lot of platforms and we have a variety of ways to set it up: In my dream I'd like to have 3 swc's:

    logging-core: just the core api commands, ideal to use for shipping with a framework (like robot legs, basically LoggerFactory and ILogger ) logging-setup: Various ways of setting up logging, something one wouldn't want to ship with robot legs logging-integration: Additional targets with dependencies to other swcs. (eventually split up in one swc per dependency)

    There is already a request for this in our issue tracker and I am sure I can push it a little more if you say you need this for a RobotLegs 2 release. http://code.google.com/p/as3-commons/issues/detail?id=66

    Setup Processes Of course we have targets with just one log statement like you show in your example. Our setup process allows a setup to distinguish between the targets assigned to loggers by their full name, for example "org.robotolegs.v2.api".

    The Regexp setup can use different targets after applying a regexp to it: /$org.robotlegs./ filters for all loggers which name starts with org.robotlegs.

    http://www.as3commons.org/as3-commons-logging/asdoc/org/as3commons/...

    That allows for logging configurations far more flexible than the traditional hierarchical approach. However we also offer this traditional setup in a log4j style way.

    http://www.as3commons.org/as3-commons-logging/asdoc/org/as3commons/...

    I hope I could shed some light as to why the things in as3commons are the way they are. I don't mean to suggest that as3commons is ideal for any case but I am willing to hear your problems with it and see if I can do something about it.

    • Edit

14. 14 Posted by Roland Zwaga on 02 Nov, 2011 10:42 AM

    

    @creyenders I don't think its a matter of us being better or worse programmers than you are. If the library comes across as overly-complicated for you at first sight, well, then that means we have some work to do in the documentation department :) Your criticisms are noted and will be taken into account I'm sure :)

    cheers!

    Roland

    • Edit

15. 15 Posted by Roland Zwaga on 02 Nov, 2011 12:08 PM

    

    By the way, Martin Heidegger has replied more extensively to your questions and comments, but somehow his reply doesn't show up here. Must be something getting stuck in the moderation system or something...

    • Edit

16. Support Staff 16 Posted by Shaun Smith on 02 Nov, 2011 12:12 PM

    

    Martin's reply is on the issue tracker:

    https://github.com/robotlegs/robotlegs-framework/issues/28

    • Edit

17. Support Staff 17 Posted by Shaun Smith on 09 Nov, 2011 10:11 PM

    

    Actually, Martin's post was stuck in the spam queue - sorry about that.

    • Edit

18. Support Staff 18 Posted by creynders on 11 Nov, 2011 02:48 PM

    

    @martin: I'd really like to respond to your post, but I don't think we should flood the RL forums with a discussion on as-commons. Can I find you on G+ ? I searched for your name, but nobody turned up, except references to your namesake obviously. And I didn't see a forum on as3-commons. You can find me @camillereynders on twitter and Camille Reynders on G+

    • Edit

19. 19 Posted by Roland Zwaga on 11 Nov, 2011 03:35 PM

    

    Martin can be found on G+ over here:

    https://plus.google.com/u/0/106293142644811337956/about

    • Edit

20. Support Staff 20 Posted by creynders on 15 Nov, 2011 01:05 PM

    

    @Roland: thanks! Martin had already contacted me however.

    • Edit

21. Shaun Smith closed this discussion on 01 Jun, 2012 12:00 PM.