Would you be in favor of having one checked in and used by default if
you're using CDI integration?

On Mon, Sep 18, 2017 at 4:41 AM Sergey Beryozkin <[email protected]>
wrote:

> My understanding ClassUnwrapper callback was added to support these
> scenarios, Romain may've used it.
>
> Sergey
> On 17/09/17 23:27, John D. Ament wrote:
> > On Sun, Sep 17, 2017 at 5:09 PM Sergey Beryozkin <[email protected]>
> > wrote:
> >
> >> Hi
> >> On 17/09/17 15:37, John D. Ament wrote:
> >>> Hey
> >>>
> >>> So I just ran into an issue where ExceptionMappers weren't being
> >> processed
> >>> in CXF when they had a CDI normal scope.  Switching to a pseudo scope
> >>> (@Dependent) fixes it.  A similar issue to what I saw recently with
> Weld
> >>> and Generic Type being lost, except this was happening for both OWB and
> >>> Weld.
> >>>
> >>> While I was able to dig into the prior issue with generic type
> arguments,
> >>> that was a Weld specific issue.  I couldn't figure out why CXF wasn't
> >>> reading the metadata of the actual bean class.  I'm wondering if for
> CDI
> >>> use cases, if it makes sense for CXF to look at the actual class's
> >>> metadata, separate from the CDI instance that's being passed in (which
> is
> >>> just a proxy).
> >>>
> >> I think this is what is done for ex in the Spring case, is it not the
> >> case in the CXF CDI flow ? When JAXRSServerFactoryBean.createFromBeans,
> >> etc, is called then ClassResourceInfo would be initialized with the
> >> 'resource' class which may be the proxy, and the 'service' class which
> >> is the actual class.
> >> ClassHelper is used to find the actual 'service' class.
> >> May be CXF CDI needs to use ClassHelper ?
> >>
> >
> > Ok, so that answers a lot of questions (and I have a prototype fix!).
> So,
> > yes, CDI does in fact use ClassHelper to get the class in use.  However,
> it
> > doesn't work for CDI.  The methods in ClassHelper are based on Proxy,
> which
> > OWB and Weld do not use.  LIkewise, the SpringAopClassHelper is based on
> > Spring specific proxies.
> >
> > Funny thing is, I think my first question on this list was about
> > SpringAopClassHelper.  I like how this has come full circle.
> >
> > So now the prototype.  Weld and OWB use a classname suffix to indicate
> > their proxies.  Using that suffix, I can unwrap the parent class and get
> > things to work properly.
> >
> > Now the question is - should this be in the core ClassHelper, or should I
> > use ClassUnwrapper which is mentioned in the getRealClass(Bus,Object)
> > method?  I see that there's no implementations of ClassUnwrapper on the
> > classpath, so maybe its a dead code path?
> >
> > I will caution you - I suspect that changing this may cause some existing
> > apps using CXF + CDI to behave a little differently, but I suspect I may
> be
> > the first one to run into these.
> >
> >
> >>
> >> Sergey
> >>
> >>> John
> >>>
> >>
> >>
> >
>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>

Reply via email to