Framework/Container

[Simon Funnell <si...@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

Re: Fundamental Flaws

[Danny Angus <da...@gmail.com>]

Simon,


> My next statement will certainly raise some flags of concern however I am
> hoping you will hear me out

Oh we're very sensitive to the nuances of language here, we have a
multi-lingual team and have learned the hard way not to make to many
assumptions about the difference between a words common usage and its
real meaning!

> There are frameworks and the like that deal with these issues but I have
> come to believe the problem is with component design itself.

We do struggle with component design, but more because purity of
design is hard to implement in a code base that has adopted, and
rejected, a number of approaches over the years.


> Anyhow, here goes. Any component that contains any sort of logging code is
> flawed.

Agreed, but remember that James did this before it was possibel to be
agnostic about logging and you're probably the first guy who has had
such a beef with it!

> 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.

Indeed it is the right forum, post away. But remember that the problem
is the effort not the ideas, so also feel free to submit patches.

> 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.

Documentation is *always* more than welcome!

d.

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

Re: Fundamental Flaws

[Robert Burrell Donkin <ro...@gmail.com>]

On Mon, Nov 16, 2009 at 4:47 PM, Simon Funnell
<si...@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

Re: Fundamental Flaws

[Stefano Bagnara <ap...@bago.org>]

2009/11/16 Simon Funnell <si...@googlemail.com>:
> My framework is not suitable for James/James is not suitable for
> my framework at present because of the following reasons.

You talk about "your framework" but you didn't provide much
information about this. Please let us know what "your framework" is
and why you decided to create "your framework" instead of using an
existing framework (what frameworks did you evaluated, too).

> James is useful, practical
> and a work of art, but it, like many other projects, has some fundamental
> flaws.

I agree.

> [...] but I have
> come to believe the problem is with component design itself.

I mostly agree.

> Anyhow, here goes. Any component that contains any sort of logging code is
> flawed. [...]
> 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 prefer pratical/concrete stuff. This message would be a waste of
time if you don't follow up with more details, so please go ahead. I
have to admit that "How a java application should deal with logging"
is something that would probably have a better audience in different
lists, but I'm happy to hear your option and discuss it for James. I
admit I don't understand how you think logging should work from your
sentence.

Stefano

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

Fundamental Flaws

[Simon Funnell <si...@googlemail.com>]

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 <si...@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

Re: Framework/Container

[Norman Maurer <no...@googlemail.com>]

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 <si...@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