[
https://issues.apache.org/jira/browse/HTTPCORE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12552159
]
Rachel Greenham commented on HTTPCORE-132:
------------------------------------------
Cool beans. :-) For my local change I did start off by doing it as a protected
factory method, but then changed it to taking a factory in the constructor
*primarily* to keep symmetry with the BufferingHttpServiceHandler constructor
in 4.0alpha6. But I'm happy with it either way.
I'll wait for 4.0beta1 to actually appear before upgrading to it. :-)
> In NIO, there doesn't seem to be a simple way to set a custom
> HttpRequestFactory
> --------------------------------------------------------------------------------
>
> Key: HTTPCORE-132
> URL: https://issues.apache.org/jira/browse/HTTPCORE-132
> Project: HttpComponents Core
> Issue Type: Wish
> Components: HttpCore NIO
> Affects Versions: 4.0-alpha6
> Environment: Java 5. Dev platform is OS X Leopard but I doubt that's
> relevant.
> Reporter: Rachel Greenham
> Priority: Minor
> Fix For: 4.0-beta1
>
> Attachments: ServerIOEventDispatch.java
>
>
> It appears that for developing a server application using NIO, you can't
> easily define a replacement HttpRequestFactory. It's hardcoded to create a
> new DefaultHttpRequestFactory in DefaultServerIOEventDispatch, in a method
> that can't be overridden because the subclass method also references a
> *private* data member (the allocator) of DefaultServerIOEventDispatch. It
> could be done by also instantiating and supplying an external
> ByteBufferAllocator in the overridden method, which "wastes" the instance
> created in the constructor. (I notice the constructor that lets you supply an
> allocator in 4.0-alpha6 is gone from later versions - but I'm not even
> interested in replacing the allocator, I just want to replace the request
> factory.)
> The way I am doing it is by actually *copying* the current source of
> DefaultServerIOEventDispatch to my project (with a rename) to make my own
> modified version to implement IOEventDispatch - which seems excessive for the
> small change I actually want. The change I made was simply to have a
> constructor that allows me to supply an already-instantiated
> HttpRequestFactory, in a similar fashion to the constructor of
> BufferingHttpServiceHandler takes an instantiated HttpResponseFactory.
> This also stops this IOEventDispatch from creating a new instance of the
> *factory* for each hit, which it seems to be doing at the moment...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
