You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2009/08/19 11:46:42 UTC

AbstractJamesService -> SocketsManager

IMHO the way inheritance is used in AbstractJamesService unnecessarily
increases coupling and prevents proper injection. i would prefer to
factor into a standard sockets class and a service specific factory
for Handlers. for management by phoenix, block subclasses would be
needed (the current ones could be reused) but the factory could be
injected. the factories could continue all the protocol logic could be
contained in the factory. given that a wrapper is used, an excalibur
independent API could be used.

opinions?
objections?

- robert

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


Re: AbstractJamesService -> SocketsManager

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sun, Aug 23, 2009 at 1:37 PM, Robert Burrell
Donkin<ro...@gmail.com> wrote:
> On Sat, Aug 22, 2009 at 5:45 PM, Norman Maurer<no...@apache.org> wrote:
>> I think removing them from the Session is  a good idea, but I would
>> prefer to inject them directly ( if they are needed).  So just keep
>> the Session as simple as possible.
>
> agreed
>
> this would only be a first step but should make switching to injection easier

i'm going to start looking at this now but don't let me hold you up: i
tend to use small commits and i'll update frequently.

- robert

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


Re: AbstractJamesService -> SocketsManager

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Sat, Aug 22, 2009 at 5:45 PM, Norman Maurer<no...@apache.org> wrote:
> I think removing them from the Session is  a good idea, but I would
> prefer to inject them directly ( if they are needed).  So just keep
> the Session as simple as possible.

agreed

this would only be a first step but should make switching to injection easier

- robert

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


Re: AbstractJamesService -> SocketsManager

Posted by Norman Maurer <no...@apache.org>.
I think removing them from the Session is  a good idea, but I would
prefer to inject them directly ( if they are needed).  So just keep
the Session as simple as possible.

Bye,
Norman

2009/8/22 Robert Burrell Donkin <ro...@gmail.com>:
> On Wed, Aug 19, 2009 at 9:59 PM, Robert Burrell
> Donkin<ro...@gmail.com> wrote:
>> On Wed, Aug 19, 2009 at 4:07 PM, Norman Maurer<no...@apache.org> wrote:
>>> I don't have a good Idea howto get this done. Maybe with some help of you ;)
>>
>> unless anyone else jumps in, i'll focus on this tomorrow
>
> the pattern ATM is to expose a configuration object through the
> session. this typically contains a mix of services and configuration.
> james services are typically broad APIs.
>
> for example, SMTPHandlerConfigurationData is exposed by SMTPSession.
> as well as configuration data such as max message size, it also has
> getters for UserRepository and MailServer services.
>
> i think it would be better if handlers were not directly coupled to
> services exposed through the session. i'd like to add explicit methods
> to session and remove the getter. i think that this would aid
> understanding and simplify the code.
>
> any objections?
>
> - robert
>
> ---------------------------------------------------------------------
> 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: AbstractJamesService -> SocketsManager

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 9:59 PM, Robert Burrell
Donkin<ro...@gmail.com> wrote:
> On Wed, Aug 19, 2009 at 4:07 PM, Norman Maurer<no...@apache.org> wrote:
>> I don't have a good Idea howto get this done. Maybe with some help of you ;)
>
> unless anyone else jumps in, i'll focus on this tomorrow

the pattern ATM is to expose a configuration object through the
session. this typically contains a mix of services and configuration.
james services are typically broad APIs.

for example, SMTPHandlerConfigurationData is exposed by SMTPSession.
as well as configuration data such as max message size, it also has
getters for UserRepository and MailServer services.

i think it would be better if handlers were not directly coupled to
services exposed through the session. i'd like to add explicit methods
to session and remove the getter. i think that this would aid
understanding and simplify the code.

any objections?

- robert

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


Re: AbstractJamesService -> SocketsManager

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 4:07 PM, Norman Maurer<no...@apache.org> wrote:
> I don't have a good Idea howto get this done. Maybe with some help of you ;)

unless anyone else jumps in, i'll focus on this tomorrow

- robert

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


Re: AbstractJamesService -> SocketsManager

Posted by Norman Maurer <no...@apache.org>.
I don't have a good Idea howto get this done. Maybe with some help of you ;)

Bye,
Norman

2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
> On Wed, Aug 19, 2009 at 10:48 AM, Norman Maurer<no...@apache.org> wrote:
>> +1,
>
> volunteers?
>
> - robert
>
> ---------------------------------------------------------------------
> 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: AbstractJamesService -> SocketsManager

Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 19, 2009 at 10:48 AM, Norman Maurer<no...@apache.org> wrote:
> +1,

volunteers?

- robert

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


Re: AbstractJamesService -> SocketsManager

Posted by Norman Maurer <no...@apache.org>.
+1,

Bye,
Norman

2009/8/19 Robert Burrell Donkin <ro...@gmail.com>:
> IMHO the way inheritance is used in AbstractJamesService unnecessarily
> increases coupling and prevents proper injection. i would prefer to
> factor into a standard sockets class and a service specific factory
> for Handlers. for management by phoenix, block subclasses would be
> needed (the current ones could be reused) but the factory could be
> injected. the factories could continue all the protocol logic could be
> contained in the factory. given that a wrapper is used, an excalibur
> independent API could be used.
>
> opinions?
> objections?
>
> - robert
>
> ---------------------------------------------------------------------
> 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