james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Funnell <simonfunn...@googlemail.com>
Subject Fundamental Flaws
Date Mon, 16 Nov 2009 16:47:08 GMT

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 

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.

I  have an approach that addresses these issues and if this is the 
appropriate forum I will send another post containing some commentary on 
how to do something about it. I think it is the right forum as I 
actually use James as a business tool so I am also expressing things I 
would like to see as a user too. At present I don't think I have any 
code that is useful and I will continue to use James as I am at present. 
I do believe however that I can contribute some ideas and documentation.

I hope this is of interest, I look forward to feed back.



Norman Maurer wrote:
> Hi Simon,
> first of nice to hear you are interested in James :) I already started
> to replace many Avalon dependencies from the components of James. The
> current Idea is to replace Avalon with Guice for DI. We use
> Guicey-fruit to support JSR250 for dependency Injection which provides
> at least some "standards".
> At the moment I do this step by step by providing some kind of Adapter
> between Avalon and Guice to allow the "smooth" migration. Have a look
> at the AvalonAsyncSMTPServer for example to get some idea about how it
> works atm:
> http://svn.apache.org/repos/asf/james/server/trunk/smtpserver-function/src/main/java/org/apache/james/smtpserver/mina/AvalonAsyncSMTPServer.java
> All the "Avalon*" classes will get removed when every component is
> rewritten to work with Guice (jsr250).
> As Container I'm currently lookin at karaf
> (http://felix.apache.org/site/apache-felix-karaf.html). Not sure if
> this is really the way to go.
> So any feedback / sugguestions are really welcome, and feel free to
> ask more questions  :)
> Bye,
> Norman
> 2009/11/15 Simon Funnell <simonfunnell@googlemail.com>:
>> Hi,
>> I've been using James for a couple of years now and enjoy the service it
>> provides, I actually use quite a few things from the Jakarta project. With
>> the development of version 3 I have become interested in integrating James
>> with an existing server framework I have been developing. On the wiki
>> homepage it discusses moving away from the Avalon framework and I am happy
>> to contribute code I have written should it be useful.  I read elsewhere on
>> the wiki that the terminology surrounding the ideas of
>> containers/micro-kernels/etc is a bit vague and this is actually some of the
>> issues the framework addresses. I was wondering if someone can provide me
>> with a brief list of requirements for a James container and/or any
>> information/links to documentation that discusses the subject.
>> Thanks,
>> Simon
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org

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

View raw message