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 Stefano Bagnara <ap...@bago.org> on 2008/08/13 13:08:52 UTC
[server.trunk] [PROPOSAL] delegating socket server
I just committed this code (CTR):
http://svn.apache.org/viewvc?view=rev&revision=685510
Robert, I know this was in your roadmap too.. even if I directly
committed this please take it as a proposal.
It only changes a couple of method visibility in main code so I decided
to be agile and commit it, so during the review process I can even test
the resulting build.
I hope this is one step in the same direction you had in your mind.
Please review and tell me what you think.
This uncouple the "Handlers" from cornerstone/excalibur so that the only
classes with cornerstone/excalibur depdendencies should be the "Servers".
I plan to test the resulting DelegatingSMTPServer in my environment, and
if this works fine I'd like to refactor all of our existing protocol
implementations by using this new "pattern".
Any objection?
Stefano
bago@apache.org ha scritto:
> Author: bago
> Date: Wed Aug 13 04:00:58 2008
> New Revision: 685510
>
> URL: http://svn.apache.org/viewvc?rev=685510&view=rev
> Log:
> First attempt at creating a delegating socket-server.
> - changed some visibility from AbstractJamesHandler to allow my extension.
> - Introduced ProtocolHandler and ProtocolHandlerHelper interfaces.
> - created a DelegatingJamesHandler that expose a ProtocolHandlerHelper service to the managed "ProtocolHandler" (received in the constructor).
> - created a DelegatingSMTPServer that is identical to SMTPServer but manages a pool of DelegatingJamesHandler (containing SMTPProtocolHandlers) instead of SMTPHandlers.
> - created an SMTPProtocolHandler by cloning the current SMTPHandler.
>
> The main advantage is that SMTPProtocolHandler has no knowledge of cornerstone/excalibur because they are incapsulated in the DelegatingJamesHandler .
> The used interfaces are meant to make it really simple the porting of our current services to this structure. We can then refactor the interface to expose better names for methods/services.
> We could also move the ProtocolHandler/ProtocolHandlerHelper to a lower layer.
>
> This code is *untested*, ATM.
>
> Added:
> james/server/trunk/avalon-socket-library/src/main/java/org/apache/james/socket/DelegatingJamesHandler.java (with props)
> james/server/trunk/avalon-socket-library/src/main/java/org/apache/james/socket/ProtocolHandler.java (with props)
> james/server/trunk/avalon-socket-library/src/main/java/org/apache/james/socket/ProtocolHandlerHelper.java (with props)
> james/server/trunk/smtpserver-function/src/main/java/org/apache/james/smtpserver/DelegatingSMTPServer.java (with props)
> james/server/trunk/smtpserver-function/src/main/java/org/apache/james/smtpserver/SMTPProtocolHandler.java (with props)
> Modified:
> james/server/trunk/avalon-socket-library/src/main/java/org/apache/james/socket/AbstractJamesHandler.java
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] [PROPOSAL] delegating socket server
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 25, 2008 at 10:57 AM, Stefano Bagnara <ap...@bago.org> wrote:
> Stefano Bagnara ha scritto:
>>
>> I just committed this code (CTR):
>> http://svn.apache.org/viewvc?view=rev&revision=685510
>>
>> Robert, I know this was in your roadmap too.. even if I directly committed
>> this please take it as a proposal.
>>
>> It only changes a couple of method visibility in main code so I decided to
>> be agile and commit it, so during the review process I can even test the
>> resulting build.
>>
>> I hope this is one step in the same direction you had in your mind. Please
>> review and tell me what you think.
>>
>> This uncouple the "Handlers" from cornerstone/excalibur so that the only
>> classes with cornerstone/excalibur depdendencies should be the "Servers".
>>
>> I plan to test the resulting DelegatingSMTPServer in my environment, and
>> if this works fine I'd like to refactor all of our existing protocol
>> implementations by using this new "pattern".
>>
>> Any objection?
>
> I just applied the pattern to all of our services.
>
> The ProtocolHandler and ProtocolHandlerHelper interfaces are not the best we
> can have, but they are a direct port of the previous code.
+1
but they are a good step forward
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] [PROPOSAL] delegating socket server
Posted by Stefano Bagnara <ap...@bago.org>.
Stefano Bagnara ha scritto:
> I just committed this code (CTR):
> http://svn.apache.org/viewvc?view=rev&revision=685510
>
> Robert, I know this was in your roadmap too.. even if I directly
> committed this please take it as a proposal.
>
> It only changes a couple of method visibility in main code so I decided
> to be agile and commit it, so during the review process I can even test
> the resulting build.
>
> I hope this is one step in the same direction you had in your mind.
> Please review and tell me what you think.
>
> This uncouple the "Handlers" from cornerstone/excalibur so that the only
> classes with cornerstone/excalibur depdendencies should be the "Servers".
>
> I plan to test the resulting DelegatingSMTPServer in my environment, and
> if this works fine I'd like to refactor all of our existing protocol
> implementations by using this new "pattern".
>
> Any objection?
I just applied the pattern to all of our services.
The ProtocolHandler and ProtocolHandlerHelper interfaces are not the
best we can have, but they are a direct port of the previous code.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: [server.trunk] [PROPOSAL] delegating socket server
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Aug 13, 2008 at 12:08 PM, Stefano Bagnara <ap...@bago.org> wrote:
> I just committed this code (CTR):
> http://svn.apache.org/viewvc?view=rev&revision=685510
>
> Robert, I know this was in your roadmap too.. even if I directly committed
> this please take it as a proposal.
CTR's fine - it's just important to keep on talking so that everyone
knows what's going on...
> It only changes a couple of method visibility in main code so I decided to
> be agile and commit it, so during the review process I can even test the
> resulting build.
cool
> I hope this is one step in the same direction you had in your mind. Please
> review and tell me what you think.
yes it is a step in the right direction
i've been thinking about some more radical changes but this is a good
first step and i'd need more time for analysis before i'd feel
confident presenting them...
> This uncouple the "Handlers" from cornerstone/excalibur so that the only
> classes with cornerstone/excalibur depdendencies should be the "Servers".
>
> I plan to test the resulting DelegatingSMTPServer in my environment, and if
> this works fine I'd like to refactor all of our existing protocol
> implementations by using this new "pattern".
fine by me
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org