Le 11 déc. 2016 21:30, "John D. Ament" <johndam...@apache.org> 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).
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 (
https://github.com/apache/cxf/blob/3.1.x-fixes/integration/
cdi/src/main/java/org/apache/cxf/cdi/CdiBusBean.java#L43
).
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.
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
