On Sun, Dec 11, 2016 at 5:38 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> Le 11 déc. 2016 22:24, "John D. Ament" <johndam...@apache.org> a écrit : > > Romain, > > On Sun, Dec 11, 2016 at 4:08 PM Romain Manni-Bucau <rmannibu...@gmail.com> > wrote: > > > 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). > > > > > 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 > sense. > > 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. > > > Not for a producer and not being a type in types beanclass is not supposed > handled by cdi so this is really an incorrect usage i think - unspecified > if not incorrect. > > I don't follow. This is what the spec says The second parameter represents a bean type that must be implemented by any client proxy that is returned. The only bean type that you know must be implemented by the bean is the value of Bean.getBeanClass or the return values of getTypes. Since this is a client proxy, the passed in type is what gets used as the proxy interface. > > > > > > > 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. > > > > 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 > > >
