You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Carlos Sierra Andrés <cs...@gmail.com> on 2018/03/12 13:25:08 UTC
SSE support and regular endpoints
Hi there,
as you might already know we are implementing Aries JAX-RS OSGi spec on
top of CXF. We have found a problem when trying to add SSE support,
because it looks like it needs to use a special "transport id", so it
can't be used to have both regular SSE endpoints and regular endpoints
in the same application. Is this correct or are we doing something wrong?
Bests.
Carlos.
Re: SSE support and regular endpoints
Posted by Andriy Redko <dr...@gmail.com>.
Hi Carlos,
No need to appologize! Thanks a mill for the effort! Certainly, having the PR
helps the team (and literally everyone) to review and try it out. It may take
some time but it is worth to explore this route for sure. Thank a lot!
Best Regards,
Andriy Redko
CSA> Hi Andriy,
CSA> sorry for my late response. Life gets tangled sometimes.
CSA> As you suggested I have sent a pull request with the AsyncContext
CSA> implementation: https://github.com/apache/cxf/pull/398
CSA> I would really appreciate a review, because many things are likely wrong
CSA> and lurking. As a matter of fact systests/rs-sse fails.
CSA> However the implementation seems to work ok in the Aries JAX-RS
CSA> Whiteboard tests. We have also done manual testing on top of jetty and
CSA> tomcat and it seems to work correctly (at first sight).
CSA> Any insight will be very much appreciated.
CSA> Bests.
CSA> Carlos.
CSA> El 14/3/18 a las 12:18, Andriy Redko escribió:
>> Hi Carlos,
>> Yes, sure, the systests/rs-sse holds a test suite for SSE and different application containers.
>> https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-jetty/src/test/java/org/apache/cxf/systest/jaxrs/sse/jetty
>> https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-tomcat/src/test/java/org/apache/cxf/systest/jaxrs/sse/tomcat
>> https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-undertow/src/test/java/org/apache/cxf/systest/jaxrs/sse/undertow
>> What you may have run to is the suble but important detail: the transport id should be set on servlet and factory bean levels,
>> and it should much (this is is what you are missing probably, it is usually not needed in most cases). The Wiki page I referred to
>> explains that (with upcoming 3.2.3 this should be simplified and would need only factory bean to have transport set). We also have
>> a few sample projects:
>> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/sse_spring
>> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/sse_tomcat
>> We have had the discussion recently on dev@ list about not relying on Atm for SSE implementation, that would make things much
>> more simple and straigthforward. If you could submit the PR with your async implementation (even as a draft), the team could
>> review it and validate the idea.
>> Thanks.
>> Best Regards,
>> Andriy Redko
>> CSA> Hi Andriy,
>> CSA> could you point me to the tests that are started with the special
>> CSA> transport id? Just to see where we are doing something wrong, because in
>> CSA> our case changing the transport id breaks most of the regular endpoints.
>> CSA> In the meantime we have put together an impl that does not rely on
>> CSA> atmosphere, just uses asyncContext, and does not need any special
>> CSA> transport. Would you think this could be an interesting contribution or
>> CSA> is atmosphere needed for some reason?
>> CSA> It could also use a review by someone with CXF super knowledge.
>> CSA> Bests.
>> CSA> Carlos.
>> CSA> El 12/3/18 a las 16:09, Andrey Redko escribió:
>>>> Hi Carlos,
>>>> That's right, SSE in CXF requires dedicated transport, however it is fully
>>>> compatible with the existing HTTP transport (regular endpoints). Both SSE
>>>> and non-SSE endpoints should work just fine. Here is a link to the wiki,
>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75974373,
>>>> which will be a part of the official documentation section shortly.
>>>> Thanks.
>>>> Best Regards,
>>>> Andriy Redko
>>>> On Mon, Mar 12, 2018, 8:25 AM Carlos Sierra Andrés <cs...@gmail.com>
>>>> wrote:
>>>>> Hi there,
>>>>> as you might already know we are implementing Aries JAX-RS OSGi spec on
>>>>> top of CXF. We have found a problem when trying to add SSE support,
>>>>> because it looks like it needs to use a special "transport id", so it
>>>>> can't be used to have both regular SSE endpoints and regular endpoints
>>>>> in the same application. Is this correct or are we doing something wrong?
>>>>> Bests.
>>>>> Carlos.
Re: SSE support and regular endpoints
Posted by Carlos Sierra Andrés <cs...@gmail.com>.
Hi Andriy,
sorry for my late response. Life gets tangled sometimes.
As you suggested I have sent a pull request with the AsyncContext
implementation: https://github.com/apache/cxf/pull/398
I would really appreciate a review, because many things are likely wrong
and lurking. As a matter of fact systests/rs-sse fails.
However the implementation seems to work ok in the Aries JAX-RS
Whiteboard tests. We have also done manual testing on top of jetty and
tomcat and it seems to work correctly (at first sight).
Any insight will be very much appreciated.
Bests.
Carlos.
El 14/3/18 a las 12:18, Andriy Redko escribió:
> Hi Carlos,
>
> Yes, sure, the systests/rs-sse holds a test suite for SSE and different application containers.
>
> https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-jetty/src/test/java/org/apache/cxf/systest/jaxrs/sse/jetty
> https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-tomcat/src/test/java/org/apache/cxf/systest/jaxrs/sse/tomcat
> https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-undertow/src/test/java/org/apache/cxf/systest/jaxrs/sse/undertow
>
> What you may have run to is the suble but important detail: the transport id should be set on servlet and factory bean levels,
> and it should much (this is is what you are missing probably, it is usually not needed in most cases). The Wiki page I referred to
> explains that (with upcoming 3.2.3 this should be simplified and would need only factory bean to have transport set). We also have
> a few sample projects:
>
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/sse_spring
> https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/sse_tomcat
>
> We have had the discussion recently on dev@ list about not relying on Atm for SSE implementation, that would make things much
> more simple and straigthforward. If you could submit the PR with your async implementation (even as a draft), the team could
> review it and validate the idea.
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> CSA> Hi Andriy,
>
> CSA> could you point me to the tests that are started with the special
> CSA> transport id? Just to see where we are doing something wrong, because in
> CSA> our case changing the transport id breaks most of the regular endpoints.
>
> CSA> In the meantime we have put together an impl that does not rely on
> CSA> atmosphere, just uses asyncContext, and does not need any special
> CSA> transport. Would you think this could be an interesting contribution or
> CSA> is atmosphere needed for some reason?
>
> CSA> It could also use a review by someone with CXF super knowledge.
>
> CSA> Bests.
>
> CSA> Carlos.
>
>
> CSA> El 12/3/18 a las 16:09, Andrey Redko escribió:
>>> Hi Carlos,
>>> That's right, SSE in CXF requires dedicated transport, however it is fully
>>> compatible with the existing HTTP transport (regular endpoints). Both SSE
>>> and non-SSE endpoints should work just fine. Here is a link to the wiki,
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75974373,
>>> which will be a part of the official documentation section shortly.
>>> Thanks.
>>> Best Regards,
>>> Andriy Redko
>>> On Mon, Mar 12, 2018, 8:25 AM Carlos Sierra Andrés <cs...@gmail.com>
>>> wrote:
>>>> Hi there,
>>>> as you might already know we are implementing Aries JAX-RS OSGi spec on
>>>> top of CXF. We have found a problem when trying to add SSE support,
>>>> because it looks like it needs to use a special "transport id", so it
>>>> can't be used to have both regular SSE endpoints and regular endpoints
>>>> in the same application. Is this correct or are we doing something wrong?
>>>> Bests.
>>>> Carlos.
>
>
>
Re: SSE support and regular endpoints
Posted by Andriy Redko <dr...@gmail.com>.
Hi Carlos,
Yes, sure, the systests/rs-sse holds a test suite for SSE and different application containers.
https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-jetty/src/test/java/org/apache/cxf/systest/jaxrs/sse/jetty
https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-tomcat/src/test/java/org/apache/cxf/systest/jaxrs/sse/tomcat
https://github.com/apache/cxf/tree/master/systests/rs-sse/rs-sse-undertow/src/test/java/org/apache/cxf/systest/jaxrs/sse/undertow
What you may have run to is the suble but important detail: the transport id should be set on servlet and factory bean levels,
and it should much (this is is what you are missing probably, it is usually not needed in most cases). The Wiki page I referred to
explains that (with upcoming 3.2.3 this should be simplified and would need only factory bean to have transport set). We also have
a few sample projects:
https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/sse_spring
https://github.com/apache/cxf/tree/master/distribution/src/main/release/samples/jax_rs/sse_tomcat
We have had the discussion recently on dev@ list about not relying on Atm for SSE implementation, that would make things much
more simple and straigthforward. If you could submit the PR with your async implementation (even as a draft), the team could
review it and validate the idea.
Thanks.
Best Regards,
Andriy Redko
CSA> Hi Andriy,
CSA> could you point me to the tests that are started with the special
CSA> transport id? Just to see where we are doing something wrong, because in
CSA> our case changing the transport id breaks most of the regular endpoints.
CSA> In the meantime we have put together an impl that does not rely on
CSA> atmosphere, just uses asyncContext, and does not need any special
CSA> transport. Would you think this could be an interesting contribution or
CSA> is atmosphere needed for some reason?
CSA> It could also use a review by someone with CXF super knowledge.
CSA> Bests.
CSA> Carlos.
CSA> El 12/3/18 a las 16:09, Andrey Redko escribió:
>> Hi Carlos,
>> That's right, SSE in CXF requires dedicated transport, however it is fully
>> compatible with the existing HTTP transport (regular endpoints). Both SSE
>> and non-SSE endpoints should work just fine. Here is a link to the wiki,
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75974373,
>> which will be a part of the official documentation section shortly.
>> Thanks.
>> Best Regards,
>> Andriy Redko
>> On Mon, Mar 12, 2018, 8:25 AM Carlos Sierra Andrés <cs...@gmail.com>
>> wrote:
>>> Hi there,
>>> as you might already know we are implementing Aries JAX-RS OSGi spec on
>>> top of CXF. We have found a problem when trying to add SSE support,
>>> because it looks like it needs to use a special "transport id", so it
>>> can't be used to have both regular SSE endpoints and regular endpoints
>>> in the same application. Is this correct or are we doing something wrong?
>>> Bests.
>>> Carlos.
Re: SSE support and regular endpoints
Posted by Carlos Sierra Andrés <cs...@gmail.com>.
Hi Andriy,
could you point me to the tests that are started with the special
transport id? Just to see where we are doing something wrong, because in
our case changing the transport id breaks most of the regular endpoints.
In the meantime we have put together an impl that does not rely on
atmosphere, just uses asyncContext, and does not need any special
transport. Would you think this could be an interesting contribution or
is atmosphere needed for some reason?
It could also use a review by someone with CXF super knowledge.
Bests.
Carlos.
El 12/3/18 a las 16:09, Andrey Redko escribió:
> Hi Carlos,
>
> That's right, SSE in CXF requires dedicated transport, however it is fully
> compatible with the existing HTTP transport (regular endpoints). Both SSE
> and non-SSE endpoints should work just fine. Here is a link to the wiki,
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75974373,
> which will be a part of the official documentation section shortly.
>
> Thanks.
>
> Best Regards,
> Andriy Redko
>
> On Mon, Mar 12, 2018, 8:25 AM Carlos Sierra Andrés <cs...@gmail.com>
> wrote:
>
>> Hi there,
>>
>> as you might already know we are implementing Aries JAX-RS OSGi spec on
>> top of CXF. We have found a problem when trying to add SSE support,
>> because it looks like it needs to use a special "transport id", so it
>> can't be used to have both regular SSE endpoints and regular endpoints
>> in the same application. Is this correct or are we doing something wrong?
>>
>> Bests.
>>
>> Carlos.
>>
>>
Re: SSE support and regular endpoints
Posted by Andrey Redko <dr...@gmail.com>.
Hi Carlos,
That's right, SSE in CXF requires dedicated transport, however it is fully
compatible with the existing HTTP transport (regular endpoints). Both SSE
and non-SSE endpoints should work just fine. Here is a link to the wiki,
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=75974373,
which will be a part of the official documentation section shortly.
Thanks.
Best Regards,
Andriy Redko
On Mon, Mar 12, 2018, 8:25 AM Carlos Sierra Andrés <cs...@gmail.com>
wrote:
> Hi there,
>
> as you might already know we are implementing Aries JAX-RS OSGi spec on
> top of CXF. We have found a problem when trying to add SSE support,
> because it looks like it needs to use a special "transport id", so it
> can't be used to have both regular SSE endpoints and regular endpoints
> in the same application. Is this correct or are we doing something wrong?
>
> Bests.
>
> Carlos.
>
>