On 8/2/11 8:18 AM, Marek Potociar wrote:
>
> No-one is ruling out proprietary support for comet or websockets. We would however not put it into the API, since this
> area needs more experimenting.
>
Which is why I think we should only do something simple for Async HTTP
and skip the Atmosphere stuff. Making it pure HTTP runs the danger of
people not using an Atmosphere-like API. Also Comet/Websocket protocols
really don't fall under the REST umbrella, IMO.
>>> Not all JAX-RS users run their apps in a full JavaEE environment. I
>>> would prefer we don't try to introduce features that
>>> conditionally work only in some environments.
>>
>> It was just one possible solution to the mentioned problem. There can be other solutions which will work in Java SE. BTW, in times of embedded GlassFish and Web Profiles, why should one actually use JAX-RS in a non EE environment?
>
> I don't know. Maybe because one is an OSGi or Spring purist or wants to run the service in Google AppEngine or ...
>
I have *a lot* of users that don't want to run in a full EE environment.
I have a few that just want to run within an embeddable HTTP engine
(not even within a Servlet container). I will fight to the death of
adding any required feature that mandates EE or doesn't allow for a
standalone JAX-RS implementation.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com