tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/7-robotlegs-v2-loggingRobotlegs: Discussion 2013-02-19T11:38:57Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T09:13:19Z2011-10-29T09:13:19ZRobotlegs v2: logging<div><p>H Creyenders,</p>
<p>thanks!</p>
<p>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.</p>
<p>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.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T10:01:20Z2011-10-29T10:01:20ZRobotlegs v2: logging<div><p>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.</p>
<p>I would suggest to remove the whole logging functionality out of
the base classes.</p></div>Weyerttag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T10:11:47Z2011-10-29T10:11:47ZRobotlegs v2: logging<div><p>Hi Weyert.. Where are you seeing it in the mediator mapping? I
can't find any references...</p>
<p>Oh - in the stage watcher?</p>
<p>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).</p>
<p>I expect we will decouple that part from the as3commons logger
as we get nearer - at this point you have to build
<em>something</em> first you can assume it's a short cut for
now.</p>
<p>Sx</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T10:44:17Z2011-10-29T10:44:17ZRobotlegs v2: logging<div><p>Hi Stray, Great. news. It's just that I am a bit scared of
memory leaks in one my projects ;)</p></div>Weyerttag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T13:37:24Z2011-10-29T13:37:24ZRobotlegs v2: logging<div><p>Howdy all,</p>
<p>The as3commons Logger (v2) <em>is</em> an adapter. It provides
support for over 20 logging frameworks:</p>
<p><a href=
"http://www.as3commons.org/as3-commons-logging/index.html">http://www.as3commons.org/as3-commons-logging/index.html</a></p>
<p>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.</p>
<p>By depending on as3commons Logging we provide users with the
ability to tie into their logging framework of choice with minimal
effort.</p>
<p>Writing a custom adapter would be a duplication of effort, and
is actually a surprisingly large undertaking.</p>
<p>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.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T13:43:12Z2011-10-29T13:43:12ZRobotlegs v2: logging<div><p>Ah - that's it. I knew it was decoupled in some way.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T14:16:58Z2011-10-29T14:16:58ZRobotlegs v2: logging<div><p>I've opened up an issue here:</p>
<p><a href=
"https://github.com/robotlegs/robotlegs-framework/issues/28">https://github.com/robotlegs/robotlegs-framework/issues/28</a></p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T16:28:08Z2011-10-29T16:28:08ZRobotlegs v2: logging<div><p>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.<br>
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.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-29T22:40:57Z2011-10-29T22:40:57ZRobotlegs v2: logging<div><p>We'll have a closer look at the innards of as3commons before any
final decision.</p>
<p>I agree with you on the general parameters anything shipped with
RL<br>
should conform to, but you also have to see that we aren't in
the<br>
business of implementing logging frameworks, so we have to either
drop<br>
logging from the internals or settle on some framework that
already<br>
exists.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-10-31T08:25:35Z2011-10-31T08:25:35ZRobotlegs v2: logging<div><p>Here's a basic setup, not tested, or even compiled, but just to
get a basic feel of the proposed architecture:<br>
<a href=
"https://github.com/creynders/robotlegs-framework/tree/version2/src/org/robotlegs/v2/extensions/logging">
https://github.com/creynders/robotlegs-framework/tree/version2/src/...</a><br>
(I kept the two extensions that were already there, but they're not
used in the code in api and impl)</p>
<p>No strings attached, if it's crap or for whatever other reason
not useable: no problem. It's just a proposition.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-01T09:26:01Z2011-11-01T09:26:01ZRobotlegs v2: logging<div><p>Hi there,</p>
<p>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).<br>
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.<br>
He has written a small Wiki page on the ideas behind as3-logging
here:</p>
<p><a href=
"https://code.google.com/p/as3-commons/wiki/whylogging">https://code.google.com/p/as3-commons/wiki/whylogging</a></p>
<p>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.</p>
<p>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:</p>
<p>LOGGER_FACTORY.setup = new SimpleTargetSetup(new
TraceTarget());</p>
<p>Quite painless I think. But its okay if you don't share my
opinion of course :)</p>
<p>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.</p>
<p>But for as3-logging the API docs are very complete, so for most
classes I believe the explanations are quite well done:<br>
<a href=
"http://www.as3commons.org/as3-commons-logging/asdoc/index.html">http://www.as3commons.org/as3-commons-logging/asdoc/index.html</a></p>
<p>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 :)</p>
<p>Sorry for disturbing you guys :)</p>
<p>cheers,</p>
<p>Roland</p></div>Roland Zwagatag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-01T15:01:42Z2011-11-01T16:51:58ZRobotlegs v2: logging<div><p>@roland: thanks for the clarification and as I said, probably I
overlooked some things, so sorry for that!</p>
<p>I'll try to clarify myself as well:<br>
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...<br>
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..."</p>
<p>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.</p>
<p>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.</p>
<p>-edited: final sentence just didn't come out right.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-02T04:10:49Z2011-11-09T22:06:35ZRobotlegs v2: logging<div><p>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.</p>
<pre>
<code>public static const LOGGER_FACTORY: LoggerFactory = new LoggerFactory();</code>
</pre>
<p>VS.</p>
<pre>
<code>private static var _loggerFactory: LoggerFactory;
public static function getInstance(): LoggerFactory {
return _loggerFactory ||= new LoggerFactory();
}</code>
</pre>
<p>And instead of putting it into a class like you are used to from
Java</p>
<pre>
<code>LoggerFactory.INSTANCE</code>
</pre>
<p>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.</p>
<pre>
<code>LOGGER_FACTORY</code>
</pre>
<p>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.</p>
<pre>
<code>var factory: LoggerFactory = new LoggerFactory();
// no code related to the singleton is included with this statement</code>
</pre>
<p>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)</p>
<p><strong>About the naming:</strong> 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.</p>
<p>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:</p>
<pre>
<code>private static const logger: ILogger = LOGGER_FACTORY.getNamedLogger("com.mycompany.mypackage.MyClass");</code>
</pre>
<p>As that is a bit uncomfortable to read and to write I added the
<code>get*Logger</code> 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. <em>(Yes: We are
talking about microseconds if not nanoseconds here ... but
still.)</em></p>
<p><strong>Complexity:</strong> 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:</p>
<p><em>logging-core:</em> just the core api commands, ideal to use
for shipping with a framework (like robot legs, basically
LoggerFactory and ILogger ) <em>logging-setup:</em> Various ways of
setting up logging, something one wouldn't want to ship with robot
legs <em>logging-integration:</em> Additional targets with
dependencies to other swcs. (eventually split up in one swc per
dependency)</p>
<p>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. <a href=
"http://code.google.com/p/as3-commons/issues/detail?id=66">http://code.google.com/p/as3-commons/issues/detail?id=66</a></p>
<p><em>Setup Processes</em> 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".</p>
<p>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.</p>
<p><a href=
"http://www.as3commons.org/as3-commons-logging/asdoc/org/as3commons/logging/setup/RegExpSetup.html">
http://www.as3commons.org/as3-commons-logging/asdoc/org/as3commons/...</a></p>
<p>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.</p>
<p><a href=
"http://www.as3commons.org/as3-commons-logging/asdoc/org/as3commons/logging/setup/log4j/Log4JStyleSetup.html">
http://www.as3commons.org/as3-commons-logging/asdoc/org/as3commons/...</a></p>
<p>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.</p></div>Martin Heideggertag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-02T10:42:20Z2011-11-02T10:42:22ZRobotlegs v2: logging<div><p>@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 :)</p>
<p>cheers!</p>
<p>Roland</p></div>Roland Zwagatag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-02T12:08:54Z2011-11-02T12:08:55ZRobotlegs v2: logging<div><p>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...</p></div>Roland Zwagatag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-02T12:12:12Z2011-11-02T12:12:12ZRobotlegs v2: logging<div><p>Martin's reply is on the issue tracker:</p>
<p><a href=
"https://github.com/robotlegs/robotlegs-framework/issues/28">https://github.com/robotlegs/robotlegs-framework/issues/28</a></p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-09T22:11:26Z2011-11-09T22:11:26ZRobotlegs v2: logging<div><p>Actually, Martin's post was stuck in the spam queue - sorry
about that.</p></div>Shaun Smithtag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-11T14:48:29Z2011-11-11T14:48:29ZRobotlegs v2: logging<div><p>@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+</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-11T15:35:35Z2011-11-15T10:18:31ZRobotlegs v2: logging<div><p>Martin can be found on G+ over here:</p>
<p><a href=
"https://plus.google.com/u/0/106293142644811337956/about">https://plus.google.com/u/0/106293142644811337956/about</a></p></div>Roland Zwagatag:robotlegs.tenderapp.com,2009-10-18:Comment/109591412011-11-15T13:05:07Z2011-11-15T13:05:07ZRobotlegs v2: logging<div><p>@Roland: thanks! Martin had already contacted me however.</p></div>creynders