You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Rachel Greenham (JIRA)" <ji...@apache.org> on 2007/12/15 00:02:45 UTC
[jira] Created: (HTTPCORE-132) In NIO, there doesn't seem to be a
simple way to set a custom HttpRequestFactory
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
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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCORE-132) In NIO, there doesn't seem to be a
simple way to set a custom HttpRequestFactory
Posted by "Rachel Greenham (JIRA)" <ji...@apache.org>.
[ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Updated: (HTTPCORE-132) In NIO, there doesn't seem to be a
simple way to set a custom HttpRequestFactory
Posted by "Rachel Greenham (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rachel Greenham updated HTTPCORE-132:
-------------------------------------
Attachment: ServerIOEventDispatch.java
My trivially-changed source based on DefaultServerIOEventDispatch.java, just with altered constructors to take a HttpRequestFactory.
> 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
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Resolved: (HTTPCORE-132) In NIO, there doesn't seem to be a
simple way to set a custom HttpRequestFactory
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCORE-132.
----------------------------------------
Resolution: Fixed
Fix Version/s: 4.0-beta1
Rachel,
In SVN trunk all I/O event dispatch implementations now expose protected factory methods for request/response factories and byte buffer allocators. I am not very keen to add more constructor parameters (especially used infrequently) because there are already quite a few. Please check out the latest code snapshot and re-open the issue if you think the provided solution is not sufficient.
Oleg
> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org