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.
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.
Thanks,
Simon
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 <[email protected]>:
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: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
