As long as HRP can be a drop in for all uses, I'm pretty easy about it.
I'm just nervous about dropping functionality that someone downstream is
using. So far GlassFish seems to be ok with the change but i'm only
really in the "get it to compile phase."
On 11/12/10 9:43 AM, Oleksiy Stashok wrote:
> IMO there is no need in general Adapter, it's just adding mess.
> GrizzlyAdapter comparing to Adapter has support for static resources
> handling and URL decoding, which is possible to skip.
> HttpRequestProcessor corresponds to class functionality, but we can
> try to come to something shorter :)
>
> WBR,
> Alexey.
>
>
>
> On Nov 12, 2010, at 15:25 , Justin Lee wrote:
>
>> Yeah. HttpRequestProcessor shouldn't be the final name. I just
>> needed something unique and picked that as the least offensive
>> temporary-might-accidentally-become-permanent name that ryan and I
>> could come up with. In addition to that, I think we're going to need
>> to reintroduce the general Adapter interface (whatever we want to
>> call it). There are several implementations out there (like the
>> jruby and jersey bits) and i'm not sure if they implement Adapter
>> directly or use GrizzlyAdapter. I know GlassFish references
>> com.sun.grizzly.tcp.Adapter directly and i'm not sure that replacing
>> those references with HttpRequestProcessor is always the right thing
>> to do.
>>
>> On 11/12/10 8:50 AM, Oleksiy Stashok wrote:
>>> Hi,
>>>
>>> would like to ask your opinion on better name for GrizzlyAdapter in
>>> Grizzly 2.0.
>>> We picked up a name HttpService, which seemed good, but appears it
>>> has a lot of conflicts, cause HttpService name is used in OSGi and
>>> other GF components.
>>>
>>> For now we renamed it to HttpRequestProcessor, but hope we will be
>>> able find something better.
>>>
>>> What do you think?
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey.
>