Re: JAX-RS 2.1 SSE transport - SseTransportCustomizationExtension is not CDI autodiscoverable
Thanks for the quick response! I am in the process of creating an integration test for Meecrowave that demonstrates a successful configuration of this transport and I will note this future enhancement. Regards, Aaron On Monday, February 5, 2018 8:14 AM, John D. Amentwrote: BTW you can find the open PR here: https://github.com/apache/cxf/pull/369And to be clear, no, the class shouldn't have a CDI scope as we don't want a hard dependency on CDI in this module. John On Mon, Feb 5, 2018 at 9:12 AM John D. Ament wrote: Hi Aaron, Yes, already aware of this limitation. It's probably because the bean discovery mode is ignored in these JARs. Can you try adding it as a scanned JAR in meecrowave? For CXF 3.2.3 (didn't have enough time to finish in 3.2.2) the default discovery mechanism will move from being CDI to a ServiceLoader. That should avoid this problem in the future. John On Mon, Feb 5, 2018 at 9:09 AM Aaron Anderson wrote: Hi All, I was able to successfully configure the CXF 3.2.1 SSE transport on Meecrowave (Tomcat 9/OpenWebBeans 2) but something that took me a long time to figure out was that the SseTransportCustomizationExtension CDI class was not being auto-detected by CDI. This class has no CDI annotations so it is ignored by the CDI container's classpath scanning. I ended up creating a simple extension as a workaround: public class SSECDIExtension implements Extension { void addBeansFromJava(@Observes final BeforeBeanDiscovery bbd, final BeanManager bm) { bbd.addAnnotatedType(bm.createAnnotatedType(SseTransportCustomizationExtension.class)); }} Since the transport ID needs to be set on both as a CXF servlet initialization parameter and by this extension perhaps not having this class was done intentionally. Even if that is the case from a usability standpoint I think it would be best if this customizer was auto-discovered. Should I go ahead and create an issue and a pull request that simply adds a CDI scope or named annotation so the class is automatically recognized by CDI? Thanks! Aaron
Re: JAX-RS 2.1 SSE transport - SseTransportCustomizationExtension is not CDI autodiscoverable
BTW you can find the open PR here: https://github.com/apache/cxf/pull/369 And to be clear, no, the class shouldn't have a CDI scope as we don't want a hard dependency on CDI in this module. John On Mon, Feb 5, 2018 at 9:12 AM John D. Amentwrote: > Hi Aaron, > > Yes, already aware of this limitation. It's probably because the bean > discovery mode is ignored in these JARs. Can you try adding it as a > scanned JAR in meecrowave? > > For CXF 3.2.3 (didn't have enough time to finish in 3.2.2) the default > discovery mechanism will move from being CDI to a ServiceLoader. That > should avoid this problem in the future. > > John > > > On Mon, Feb 5, 2018 at 9:09 AM Aaron Anderson > wrote: > >> Hi All, >> I was able to successfully configure the CXF 3.2.1 SSE transport on >> Meecrowave (Tomcat 9/OpenWebBeans 2) but something that took me a long time >> to figure out was that the SseTransportCustomizationExtension CDI class >> was not being auto-detected by CDI. This class has no CDI annotations so it >> is ignored by the CDI container's classpath scanning. I ended up creating a >> simple extension as a workaround: >> public class SSECDIExtension implements Extension { >> void addBeansFromJava(@Observes final BeforeBeanDiscovery bbd, final >> BeanManager bm) { >> bbd.addAnnotatedType(bm.createAnnotatedType(SseTransportCustomizationExtension.class)); >> }} >> Since the transport ID needs to be set on both as a CXF servlet >> initialization parameter and by this extension perhaps not having this >> class was done intentionally. Even if that is the case from a usability >> standpoint I think it would be best if this customizer was auto-discovered. >> Should I go ahead and create an issue and a pull request that simply adds >> a CDI scope or named annotation so the class is automatically recognized by >> CDI? >> >> Thanks! >> >> Aaron > >
Re: JAX-RS 2.1 SSE transport - SseTransportCustomizationExtension is not CDI autodiscoverable
Hi Aaron, Yes, already aware of this limitation. It's probably because the bean discovery mode is ignored in these JARs. Can you try adding it as a scanned JAR in meecrowave? For CXF 3.2.3 (didn't have enough time to finish in 3.2.2) the default discovery mechanism will move from being CDI to a ServiceLoader. That should avoid this problem in the future. John On Mon, Feb 5, 2018 at 9:09 AM Aaron Andersonwrote: > Hi All, > I was able to successfully configure the CXF 3.2.1 SSE transport on > Meecrowave (Tomcat 9/OpenWebBeans 2) but something that took me a long time > to figure out was that the SseTransportCustomizationExtension CDI class > was not being auto-detected by CDI. This class has no CDI annotations so it > is ignored by the CDI container's classpath scanning. I ended up creating a > simple extension as a workaround: > public class SSECDIExtension implements Extension { > void addBeansFromJava(@Observes final BeforeBeanDiscovery bbd, final > BeanManager bm) { > bbd.addAnnotatedType(bm.createAnnotatedType(SseTransportCustomizationExtension.class)); > }} > Since the transport ID needs to be set on both as a CXF servlet > initialization parameter and by this extension perhaps not having this > class was done intentionally. Even if that is the case from a usability > standpoint I think it would be best if this customizer was auto-discovered. > Should I go ahead and create an issue and a pull request that simply adds > a CDI scope or named annotation so the class is automatically recognized by > CDI? > > Thanks! > > Aaron