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.