Proposal: adapter reorganization

[co...@costin.dnt.ro]

Hi,

In last few months we developed and worked with 6 different server
protocols ( ajp11, 12, 13, 23, jni, http), and we learned a lot. 

Looking at the code, and also mod_jk's internal abstraction (which
supports the 3 biggest servers ) we can define a simpler and cleaner 
interface that will allow better optimizations and abstractions.

All adapters we have define 4 methods:
- startResponse( int status, String message, MimeHeaders headers)
- doWrite( byte[], int, int )
- readRequest() 
- doRead()

It seems that extending the BufferedInputStream/OS is not needed,
and can be safely replaced with the 2 output methods overriden in
Response. 

It also seems we provide 2 redundant mechanisms - extending the
RequestImpl and setters. Today we extend RequestImpl and ResponseImpl
only to implement the 4 methods mentioned above, and readRequest() is the
only one that uses internal fields. By changing it to:
- readRequest(Request req) 
we don't need to extend any more.

My proposal is again a slow evolution to a simpler model:

- create a new Adapter interface with the above 4 methods. Make
RequestImpl/ResponseImpl use the Adapter. 

- migrate all adapters to implement the new interface.

Why:
- the code will be easier to maintain and cleaner.

- we'll be able to start doing changes in RequestImpl to use better
representation for the internal objects ( MessageBytes or StringPool/int
instead of Strings, more efficient buffering and conversions, etc)

- consistent model - same patterns ( Strategy, Chain of
Responsablity) as in Interceptors.

- better support for char-byte ( since we'll have a clear model for the
output, with all component's behavior known )

Why not:

- changing something that works - the changes are only in form, the code
is the same, probably no impact on stability.

- less flexible - the old mechanism ( extending Request/Response) is still
available).

Next step: 
- more callbacks/hooks to allow lazy evaluation
- finish the interfaces based on the experience we gain.


Costin
  

Re: Proposal: adapter reorganization

[Gal Shachor <sh...@il.ibm.com>]

+1.

This is really going to make our life easier! Plus reduce the number of 
objects that we all needed to learn when started to develop the Tomcat 
connectors and considering the small number of active developers it
should
help.

	Gal Shachor

costin@costin.dnt.ro wrote:
> 
> Hi,
> 
> In last few months we developed and worked with 6 different server
> protocols ( ajp11, 12, 13, 23, jni, http), and we learned a lot.
> 
> Looking at the code, and also mod_jk's internal abstraction (which
> supports the 3 biggest servers ) we can define a simpler and cleaner
> interface that will allow better optimizations and abstractions.
> 
> All adapters we have define 4 methods:
> - startResponse( int status, String message, MimeHeaders headers)
> - doWrite( byte[], int, int )
> - readRequest()
> - doRead()
> 
> It seems that extending the BufferedInputStream/OS is not needed,
> and can be safely replaced with the 2 output methods overriden in
> Response.
> 
> It also seems we provide 2 redundant mechanisms - extending the
> RequestImpl and setters. Today we extend RequestImpl and ResponseImpl
> only to implement the 4 methods mentioned above, and readRequest() is the
> only one that uses internal fields. By changing it to:
> - readRequest(Request req)
> we don't need to extend any more.
> 
> My proposal is again a slow evolution to a simpler model:
> 
> - create a new Adapter interface with the above 4 methods. Make
> RequestImpl/ResponseImpl use the Adapter.
> 
> - migrate all adapters to implement the new interface.
> 
> Why:
> - the code will be easier to maintain and cleaner.
> 
> - we'll be able to start doing changes in RequestImpl to use better
> representation for the internal objects ( MessageBytes or StringPool/int
> instead of Strings, more efficient buffering and conversions, etc)
> 
> - consistent model - same patterns ( Strategy, Chain of
> Responsablity) as in Interceptors.
> 
> - better support for char-byte ( since we'll have a clear model for the
> output, with all component's behavior known )
> 
> Why not:
> 
> - changing something that works - the changes are only in form, the code
> is the same, probably no impact on stability.
> 
> - less flexible - the old mechanism ( extending Request/Response) is still
> available).
> 
> Next step:
> - more callbacks/hooks to allow lazy evaluation
> - finish the interfaces based on the experience we gain.
> 
> Costin
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org