cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <>
Subject Re: [DISCUSS] CDI Beans & BeanManager.getReference
Date Sun, 11 Dec 2016 21:24:17 GMT

On Sun, Dec 11, 2016 at 4:08 PM Romain Manni-Bucau <>

> Le 11 déc. 2016 21:30, "John D. Ament" <> a écrit :
> All,
> So Romain had a good point, let's not pollute the vote thread with this
> issue.  I raised a problem with the current release, its related to an
> issue that's existed in the CDI integration for some time, but was made
> worse by a recent change in CXF for the 3.1.9 release.
> In old versions of CXF (e.g. 3.1.8 and prior, into the 3.0 line), the
> following logic was used to look up references to the bus in the
> AfterDeploymentValidation stage.
>         bus = (Bus)beanManager.getReference(
>             busBean,
>             busBean.getBeanClass(),
>             beanManager.createCreationalContext(busBean)
>         );
> R: sounds wrong since beanclass doesnt have to be in types (think @Typed)
> and therefore proxyable (beanclass has no runtime role normally).
Agreed and disagreed here.

I agree that bean class doesn't have to be in types, specifically for the
reason you're bringing up - @Typed.  In addition, you may get back an
instance created not by the bean instance you're working with, so makes

However, using bean.getBeanClass() is more correct.  It has to do with the
typesafe nature and makes sure you're getting back the type you're
expecting (for that bean).  Its also more consistent, since we're using the
bean class everywhere else in the class to do look ups.  Its at least what
I've always seen it be useful for.

> This fixed an issue in the CdiBusBean that went over looked (even myself
> missed it when working on that class) where its bean class was always
> Bus.class (
> cdi/src/main/java/org/apache/cxf/cdi/
> ).
> Now you might be wondering why this fixed it.  Since busBean was located at
> runtime, if you overrode the bean, by creating your own producer or
> implementation, then this issue went away.  The issue being that in Weld,
> when you use getReference(bean, SomeInterface.class, creationalContext)
> you're getting a proxy to the interface, which for some reason includes
> abstract methods.  In the proposed 3.1.9 release, since Bus.class is now
> hard coded in the extension it causes the proxy to always be based on the
> interface, regardless of the bean's class.
> I do suspect there is an underlying Weld issue.  Even if you pass in an
> interface, you should get an exception when locating the bean and not an
> invalid proxy implementation (or even better, do what OWB does and give you
> back a valid reference).
> R: Can you check thus before changing CXF which looks ok. If weld is biggy
> and get fixed the custom bean workaround sounds ok short term.

I filed a ticket against them, will wait to see responses from Martin or
Tomas, but realistically this means CXF is only compatible with some
versions of weld (e.g. newer versions).  Fixing this in CXF makes CXF more
compatible with a broader range of versions.  Basically 3.1.8 works with
weld 2.3+ from what I can tell (I didn't bother with older versions), 3.1.9
doesn't, but may work with a 2.4.2 version.

> Wdyt?
> The fix, to bring most compatibility back to CXF, I raised a PR that does
> the following:
> - Makes CdiBusBean return the right class.  This is for the default case
> where a user doesn't provide an implementation of Bus at runtime via a
> producer or direct inheritance.
> - Makes the extension use the located bean's getBeanClass() method to
> determine the type of reference to expect.
> - The ugly part - removed the "final" keyword from a number of methods in
> ExtensionManagerBus.  In order for it to be a valid CDI bean, you can't use
> final methods.
> There's another way I can think to fix this, outside of waiting on a new
> weld release.  Instead of the bean being application scoped, it can be
> dependent or singleton, which would remove the proxy requirement.
> Thoughts?
> John

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message