Paul Hammant wrote, On 17/03/2003 0.21:
Nicola,
Attributes is a bit quiet. I have a pending request to the list and CC the author about removal of commons-logging (it is only used for 1 warning). I am plucking up courage to make teh commit.
;-))
I'd commit it without remorse. Put yourself in the name of the committers and commit it, it really makes no sense.
Gulp. I lack the karma.
? Isn't it J-C-sandbox? Anyone can ask for commit karma and have it with no questions asked. As for partecipating in codebases, well, it's a sandbox... if noone replied, commit as per lazy consensus.
That despite putting in a marathon pairing session with James Strachan, Joe Walnes, Charles Lowell, and Mike Royal at TW head office. James committer the patches other than the one Charles and I had done. A neat excercise in TDD and
BTW, I'm still thinking about the logging thing.
Imagine that we have all logging calls done like this:
//@log("hello log");
As a comment? Or a javadoc tag generates into some type of attribute, then conditionally aspected into action. Neat.
Something like that... the fact is that AOP has a big problem, which is the easiness of coding and maintaining the code.
AOP is cool for pre and post processing of methods, and for the establishment of pluggable chains, but it looks like it already hit the "everything is a nail" antipattern in some projects.
For example,IMHO logging is not a an aspect that is estraneous to the initial source code.
If I have logging in many places in my app, it means that I *need* it there, like asserts... ever tried moving asserts outside of the code? Some call them unit tests ;-), but it's simply another use case.
For me logging, asserts, etc I call them "concerns" rather than "aspects". They are not part of the application architecture, but are a common concern for all classes.
Thus I see these embedded in code, instead of being specified elswhere, but defined with a meta-language, that can be morphed at will at compile time.
To make the classes compileable without concerns easily I put them in comments. Not usual javadoc tags, because they pertain to methods or classes. I want them to be part of the code.
I'm still thinking about implementation details, but the easiest way I see now is Ant filtered copy with a special filterchain.
I am actually leaning towards no-logging. AltRMI now does not depend on any logger. It has a monitor that can be added, and logging can adapt from that.
monitor... ?
we would have logging disabled by default, but we can transform the class to use logging when running, and even transform the log calls to make them compatible with the logging toolkit we want to use.
Not quite sure how, unless I hit it on the head above.
The class is filtered for these before being compiled. I think also about a special filter that adds a logging class for every package, so it becomes the logging aggregator of that package.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
