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. Ament <johndam...@apache.org> 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 <aaronander...@acm.org>
> 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
>
>
