james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: Fundamental Flaws
Date Tue, 17 Nov 2009 12:01:15 GMT
On Mon, Nov 16, 2009 at 4:47 PM, Simon Funnell
<simonfunnell@googlemail.com> wrote:
> Hi,
>
> Thanks for reply, I've done some enjoyable research on the information sent.
> I like guice, its well engineered. Also karaf looks a great project, thumbs
> up to both. My framework is not suitable for James/James is not suitable for
> my framework at present because of the following reasons.
>
> Amongst dictionary.com's definitions the word 'Flaw' is expressed thus: 'A
> feature that mars the perfection of something.'.
>
> My next statement will certainly raise some flags of concern however I am
> hoping you will hear me out as 'flawed' does not mean that something is
> wrong, impractical, useless or not a work of art. James is useful, practical
> and a work of art, but it, like many other projects, has some fundamental
> flaws. From this I hope you understand they are not with James specifically.
> There are frameworks and the like that deal with these issues but I have
> come to believe the problem is with component design itself. What I hope to
> highlight with a pretty simple example is the reason why they are flawed, it
> should be obvious to most people It does not attempt to address how the
> issue could be resolved and while the solution is pretty obvious, its not
> necessarily immediately practical.
>
> Anyhow, here goes. Any component that contains any sort of logging code is
> flawed. However its not just logging, its other cross-cutting concerns as
> well. If logging is to be defined in a component it should be applied
> declaratively such as how it is done in guice with annotations in a way
> similar to 'Transaction' and the like. This is still flawed in my eyes
> however as such things are not a concern of the component at all. The
> component should not be concerned with when or how it does logging because
> it is used in many contexts with different logging policies.

it's important to understand that logging is an important form of user
interaction for james (and many other servers)

avalon knew this, and made logging a core part of their server
component framework.  a more contemporary approach would probably talk
about monitoring (with better interfaces for automated agents) but the
basics are unchanged. i think it would be possible - but difficult -
to come up with a aspect weaved declarative monitoring framework that
covered all the necessary use cases.

if you can come up with such a design that would be cool :-)

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message