You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "John D. Ament" <jo...@apache.org> on 2017/09/17 14:37:09 UTC
CDI & Class Metadata Parsing
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).
John
Re: CDI & Class Metadata Parsing
Posted by "John D. Ament" <jo...@apache.org>.
Ok, PR is up - https://github.com/apache/cxf/pull/313
Please feel free to review. This is handling for me both OWB and Weld use
cases. From my testing though, getting it registered early seems to work
better than later since I rely on the CDI integration to create the bus.
John
On Mon, Sep 18, 2017 at 6:17 AM Sergey Beryozkin <sb...@gmail.com>
wrote:
> For it to be part of the CXF CDI module ? Sure, if it can help to
> improve it then yes, I'm not sure if activating it by default will work
> for Romain, but please create PR and let Andriy and Romain comment
>
> Thanks, Sergey
>
>
> On 18/09/17 11:08, John D. Ament wrote:
> > 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 <sb...@gmail.com>
> > 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 <sberyozkin@gmail.com
> >
> >>> 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/
> >>
> >
>
Re: CDI & Class Metadata Parsing
Posted by Sergey Beryozkin <sb...@gmail.com>.
For it to be part of the CXF CDI module ? Sure, if it can help to
improve it then yes, I'm not sure if activating it by default will work
for Romain, but please create PR and let Andriy and Romain comment
Thanks, Sergey
On 18/09/17 11:08, John D. Ament wrote:
> 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 <sb...@gmail.com>
> 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 <sb...@gmail.com>
>>> 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/
>>
>
Re: CDI & Class Metadata Parsing
Posted by "John D. Ament" <jo...@apache.org>.
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 <sb...@gmail.com>
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 <sb...@gmail.com>
> > 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/
>
Re: CDI & Class Metadata Parsing
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 <sb...@gmail.com>
> 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/
Re: CDI & Class Metadata Parsing
Posted by "John D. Ament" <jo...@apache.org>.
On Sun, Sep 17, 2017 at 5:09 PM Sergey Beryozkin <sb...@gmail.com>
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
> >
>
>
Re: CDI & Class Metadata Parsing
Posted by Sergey Beryozkin <sb...@gmail.com>.
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 ?
Sergey
> John
>