You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Glen Mazza <gm...@talend.com> on 2012/06/26 14:20:43 UTC
WebServiceContext value not being populated in SEI implementation
Hi I recently updated my JAX-WS Handler tutorial
(http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial, source code
https://github.com/gmazza/blog-samples/tree/master/jaxws_handler_tutorial)
originally from April 2010.
It runs fine on Metro, mostly fine on CXF except for one problem: In the
web service implementation
(http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial#hand6), the
WebServiceContext variable is not getting populated in CXF as it is with
Metro:
@Resource
private WebServiceContext context;
public int doubleIt(int numberToDouble) {
System.out.println("Context is" + ((context== null) ? "null" : "not null"));
return numberToDouble* 2;
}
Metro returns "not null", while CXF returns "null". The source code is
the same, just the dependencies are switched between the two stacks. Is
there anything different I need to do (that I didn't need to do before)
in order to get the CXF SEI to have a populated context value?
Thanks,
Glen
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
Re: WebServiceContext value not being populated in SEI implementation
Posted by Glen Mazza <gm...@talend.com>.
It might be good if this portion can be re-architected such that (A) not
defining contextConfigLocation and using a cxf-servlet.xml file, and (B)
defining cCL with a value of cxf-servlet.xml would be processed
equivalently, i.e., cxf-servlet.xml would simply be the default value
for ccL if the latter's not defined or left empty, and not something
that initiates different processing (even if largely similar). OTOH,
since contextConfigLocation can have multiple values, it might not be
*completely* logical to include cxf-servlet.xml if ccL is empty but
exclude it if it happens to have values there already, so maybe the
imperfect status quo is the best we can do right now.
Thanks,
Glen
On 06/28/2012 08:51 PM, Daniel Kulp wrote:
> On Thursday, June 28, 2012 07:29:24 PM Glen Mazza wrote:
>> Incidentally, is there any syntactical difference in the cxf-servlet.xml
>> file if I call it that and *don't* link it in via contextConfigLocation
>> or if I rename it and link it in? In particular are the circumstances
>> under which I might wish to declare "<import
>> resource="classpath:META-INF/cxf/cxf.xml"/>" (e.g., loading of JMX
>> beans) the same for both, or I might need that import for one type but
>> not for the other?
> If you rename and link in via contextConfigLocation, Spring creates a
> slightly different ApplicationContext subclass that provides some extra
> services around the Servlet containers, transaction managers, and contexts
> and such. If you do the cxf-servlet.xml, you don't get much of that as we
> use a very basic XMLApplicationContext thing. For MOST use cases, there
> really isn't any difference.
>
> Dan
>
>> Thanks,
>> Glen
>>
>> On 06/28/2012 06:40 PM, Glen Mazza wrote:
>>> OK, if I understand what you're saying correctly, "cxf-servlet.xml" is
>>> a magic name of sorts, to be used when I'm *not* explicitly declaring
>>> a contextConfigLocation--if I'm going to do the latter, avoid the
>>> magic name. I'll update this.
>>>
>>> Thanks,
>>> Glen
>>>
>>> PS: Has this been the case for quite some time, or an internal change
>>> in CXF 2.6 (as part of factoring out the Spring stuff)? I think the
>>> former, but IIRC my sample did work in 2010 as-is, so dunno.
>>>
>>> On 06/28/2012 05:43 PM, Daniel Kulp wrote:
>>>> Glen,
>>>>
>>>> I haven't completely figured out a true solution to the problem, but
>>>> I can
>>>> point out a way to "fix" it.
>>>>
>>>> In your web.xml, you are setting up a spring ContextLoaderListener,
>>>> but then
>>>> pointing it at classpath:META-INF/cxf/cxf.xml. That creates a very
>>>> basic
>>>> spring context with just a bus. The CXF servlet will then create a
>>>> child
>>>> context to load the cxf-servlet.xml. That then doesn't see the
>>>> BeanPostProcessor's in the parent context.
>>>>
>>>> There are really two ways to "fix" this:
>>>>
>>>> 1) (best) - rename the cxf-servlet.xml to something like
>>>> cxf-beans.xml and
>>>> point the contextConfigLocation to that. All the beans and such
>>>> would be
>>>> loaded into a single context which really is the preferred way to do
>>>> it.
>>>>
>>>> 2) REMOVE the ContextLoaderListener from the web.xml for CXF. The
>>>> CXFServlet will create a single context from the cxf-servlet.xml
>>>> which then
>>>> will inject properly.
>>>>
>>>> The big issue is that the Bus is created in one context and then the
>>>> Endpoint (and the DoubleItImpl) is created in another. There is
>>>> definitely
>>>> an issue with that. I'm going to see if there is anything we can
>>>> do to
>>>> work around it, but, IMO, your web.xml is a little "strange" for a
>>>> CXF app.
>>>>
>>>> Dan
>>>>
>>>> On Tuesday, June 26, 2012 08:20:43 AM Glen Mazza wrote:
>>>>> Hi I recently updated my JAX-WS Handler tutorial
>>>>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial, source
>>>>> code
>>>>> https://github.com/gmazza/blog-samples/tree/master/jaxws_handler_tutor
>>>>> ial)
>>>>>
>>>>> originally from April 2010.
>>>>>
>>>>> It runs fine on Metro, mostly fine on CXF except for one problem: In
>>>>> the
>>>>> web service implementation
>>>>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial#hand6),
>>>>> the
>>>>> WebServiceContext variable is not getting populated in CXF as it is
>>>>> with
>>>>>
>>>>> Metro:
>>>>> @Resource
>>>>> private WebServiceContext context;
>>>>>
>>>>> public int doubleIt(int numberToDouble) {
>>>>>
>>>>> System.out.println("Context is" + ((context== null) ?
>>>>>
>>>>> "null"
>>>>>
>>>>> : "not null")); return numberToDouble* 2;
>>>>> :
>>>>> }
>>>>>
>>>>> Metro returns "not null", while CXF returns "null". The source code
>>>>> is
>>>>> the same, just the dependencies are switched between the two
>>>>> stacks. Is
>>>>> there anything different I need to do (that I didn't need to do
>>>>> before)
>>>>> in order to get the CXF SEI to have a populated context value?
>>>>>
>>>>> Thanks,
>>>>> Glen
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog:www.jroller.com/gmazza
Re: WebServiceContext value not being populated in SEI implementation
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, June 28, 2012 07:29:24 PM Glen Mazza wrote:
> Incidentally, is there any syntactical difference in the cxf-servlet.xml
> file if I call it that and *don't* link it in via contextConfigLocation
> or if I rename it and link it in? In particular are the circumstances
> under which I might wish to declare "<import
> resource="classpath:META-INF/cxf/cxf.xml"/>" (e.g., loading of JMX
> beans) the same for both, or I might need that import for one type but
> not for the other?
If you rename and link in via contextConfigLocation, Spring creates a
slightly different ApplicationContext subclass that provides some extra
services around the Servlet containers, transaction managers, and contexts
and such. If you do the cxf-servlet.xml, you don't get much of that as we
use a very basic XMLApplicationContext thing. For MOST use cases, there
really isn't any difference.
Dan
>
> Thanks,
> Glen
>
> On 06/28/2012 06:40 PM, Glen Mazza wrote:
> > OK, if I understand what you're saying correctly, "cxf-servlet.xml" is
> > a magic name of sorts, to be used when I'm *not* explicitly declaring
> > a contextConfigLocation--if I'm going to do the latter, avoid the
> > magic name. I'll update this.
> >
> > Thanks,
> > Glen
> >
> > PS: Has this been the case for quite some time, or an internal change
> > in CXF 2.6 (as part of factoring out the Spring stuff)? I think the
> > former, but IIRC my sample did work in 2010 as-is, so dunno.
> >
> > On 06/28/2012 05:43 PM, Daniel Kulp wrote:
> >> Glen,
> >>
> >> I haven't completely figured out a true solution to the problem, but
> >> I can
> >> point out a way to "fix" it.
> >>
> >> In your web.xml, you are setting up a spring ContextLoaderListener,
> >> but then
> >> pointing it at classpath:META-INF/cxf/cxf.xml. That creates a very
> >> basic
> >> spring context with just a bus. The CXF servlet will then create a
> >> child
> >> context to load the cxf-servlet.xml. That then doesn't see the
> >> BeanPostProcessor's in the parent context.
> >>
> >> There are really two ways to "fix" this:
> >>
> >> 1) (best) - rename the cxf-servlet.xml to something like
> >> cxf-beans.xml and
> >> point the contextConfigLocation to that. All the beans and such
> >> would be
> >> loaded into a single context which really is the preferred way to do
> >> it.
> >>
> >> 2) REMOVE the ContextLoaderListener from the web.xml for CXF. The
> >> CXFServlet will create a single context from the cxf-servlet.xml
> >> which then
> >> will inject properly.
> >>
> >> The big issue is that the Bus is created in one context and then the
> >> Endpoint (and the DoubleItImpl) is created in another. There is
> >> definitely
> >> an issue with that. I'm going to see if there is anything we can
> >> do to
> >> work around it, but, IMO, your web.xml is a little "strange" for a
> >> CXF app.
> >>
> >> Dan
> >>
> >> On Tuesday, June 26, 2012 08:20:43 AM Glen Mazza wrote:
> >>> Hi I recently updated my JAX-WS Handler tutorial
> >>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial, source
> >>> code
> >>> https://github.com/gmazza/blog-samples/tree/master/jaxws_handler_tutor
> >>> ial)
> >>>
> >>> originally from April 2010.
> >>>
> >>> It runs fine on Metro, mostly fine on CXF except for one problem: In
> >>> the
> >>> web service implementation
> >>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial#hand6),
> >>> the
> >>> WebServiceContext variable is not getting populated in CXF as it is
> >>> with
> >>>
> >>> Metro:
> >>> @Resource
> >>> private WebServiceContext context;
> >>>
> >>> public int doubleIt(int numberToDouble) {
> >>>
> >>> System.out.println("Context is" + ((context== null) ?
> >>>
> >>> "null"
> >>>
> >>> : "not null")); return numberToDouble* 2;
> >>> :
> >>> }
> >>>
> >>> Metro returns "not null", while CXF returns "null". The source code
> >>> is
> >>> the same, just the dependencies are switched between the two
> >>> stacks. Is
> >>> there anything different I need to do (that I didn't need to do
> >>> before)
> >>> in order to get the CXF SEI to have a populated context value?
> >>>
> >>> Thanks,
> >>> Glen
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WebServiceContext value not being populated in SEI implementation
Posted by Glen Mazza <gm...@talend.com>.
Incidentally, is there any syntactical difference in the cxf-servlet.xml
file if I call it that and *don't* link it in via contextConfigLocation
or if I rename it and link it in? In particular are the circumstances
under which I might wish to declare "<import
resource="classpath:META-INF/cxf/cxf.xml"/>" (e.g., loading of JMX
beans) the same for both, or I might need that import for one type but
not for the other?
Thanks,
Glen
On 06/28/2012 06:40 PM, Glen Mazza wrote:
> OK, if I understand what you're saying correctly, "cxf-servlet.xml" is
> a magic name of sorts, to be used when I'm *not* explicitly declaring
> a contextConfigLocation--if I'm going to do the latter, avoid the
> magic name. I'll update this.
>
> Thanks,
> Glen
>
> PS: Has this been the case for quite some time, or an internal change
> in CXF 2.6 (as part of factoring out the Spring stuff)? I think the
> former, but IIRC my sample did work in 2010 as-is, so dunno.
>
> On 06/28/2012 05:43 PM, Daniel Kulp wrote:
>> Glen,
>>
>> I haven't completely figured out a true solution to the problem, but
>> I can
>> point out a way to "fix" it.
>>
>> In your web.xml, you are setting up a spring ContextLoaderListener,
>> but then
>> pointing it at classpath:META-INF/cxf/cxf.xml. That creates a very
>> basic
>> spring context with just a bus. The CXF servlet will then create a
>> child
>> context to load the cxf-servlet.xml. That then doesn't see the
>> BeanPostProcessor's in the parent context.
>>
>> There are really two ways to "fix" this:
>>
>> 1) (best) - rename the cxf-servlet.xml to something like
>> cxf-beans.xml and
>> point the contextConfigLocation to that. All the beans and such
>> would be
>> loaded into a single context which really is the preferred way to do it.
>>
>> 2) REMOVE the ContextLoaderListener from the web.xml for CXF. The
>> CXFServlet will create a single context from the cxf-servlet.xml
>> which then
>> will inject properly.
>>
>> The big issue is that the Bus is created in one context and then the
>> Endpoint (and the DoubleItImpl) is created in another. There is
>> definitely
>> an issue with that. I'm going to see if there is anything we can
>> do to
>> work around it, but, IMO, your web.xml is a little "strange" for a
>> CXF app.
>>
>> Dan
>>
>>
>>
>> On Tuesday, June 26, 2012 08:20:43 AM Glen Mazza wrote:
>>> Hi I recently updated my JAX-WS Handler tutorial
>>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial, source
>>> code
>>> https://github.com/gmazza/blog-samples/tree/master/jaxws_handler_tutorial)
>>>
>>> originally from April 2010.
>>>
>>> It runs fine on Metro, mostly fine on CXF except for one problem: In
>>> the
>>> web service implementation
>>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial#hand6), the
>>> WebServiceContext variable is not getting populated in CXF as it is
>>> with
>>> Metro:
>>>
>>> @Resource
>>> private WebServiceContext context;
>>>
>>> public int doubleIt(int numberToDouble) {
>>> System.out.println("Context is" + ((context== null) ?
>>> "null"
>>> : "not null")); return numberToDouble* 2;
>>> }
>>>
>>> Metro returns "not null", while CXF returns "null". The source code is
>>> the same, just the dependencies are switched between the two
>>> stacks. Is
>>> there anything different I need to do (that I didn't need to do before)
>>> in order to get the CXF SEI to have a populated context value?
>>>
>>> Thanks,
>>> Glen
>
>
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
Re: WebServiceContext value not being populated in SEI implementation
Posted by Daniel Kulp <dk...@apache.org>.
On Thursday, June 28, 2012 06:40:16 PM Glen Mazza wrote:
> OK, if I understand what you're saying correctly, "cxf-servlet.xml" is a
> magic name of sorts, to be used when I'm *not* explicitly declaring a
> contextConfigLocation--if I'm going to do the latter, avoid the magic
> name. I'll update this.
>
> Thanks,
> Glen
>
> PS: Has this been the case for quite some time, or an internal change
> in CXF 2.6 (as part of factoring out the Spring stuff)? I think the
> former, but IIRC my sample did work in 2010 as-is, so dunno.
I THINK it's been that way for some time, but not really sure.
Dan
>
> On 06/28/2012 05:43 PM, Daniel Kulp wrote:
> > Glen,
> >
> > I haven't completely figured out a true solution to the problem, but I
> > can point out a way to "fix" it.
> >
> > In your web.xml, you are setting up a spring ContextLoaderListener, but
> > then pointing it at classpath:META-INF/cxf/cxf.xml. That creates a
> > very basic spring context with just a bus. The CXF servlet will then
> > create a child context to load the cxf-servlet.xml. That then
> > doesn't see the BeanPostProcessor's in the parent context.
> >
> > There are really two ways to "fix" this:
> >
> > 1) (best) - rename the cxf-servlet.xml to something like cxf-beans.xml
> > and point the contextConfigLocation to that. All the beans and such
> > would be loaded into a single context which really is the preferred way
> > to do it.
> >
> > 2) REMOVE the ContextLoaderListener from the web.xml for CXF. The
> > CXFServlet will create a single context from the cxf-servlet.xml which
> > then will inject properly.
> >
> > The big issue is that the Bus is created in one context and then the
> > Endpoint (and the DoubleItImpl) is created in another. There is
> > definitely an issue with that. I'm going to see if there is anything
> > we can do to work around it, but, IMO, your web.xml is a little
> > "strange" for a CXF app.
> >
> > Dan
> >
> > On Tuesday, June 26, 2012 08:20:43 AM Glen Mazza wrote:
> >> Hi I recently updated my JAX-WS Handler tutorial
> >> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial, source
> >> code
> >> https://github.com/gmazza/blog-samples/tree/master/jaxws_handler_tutori
> >> al) originally from April 2010.
> >>
> >> It runs fine on Metro, mostly fine on CXF except for one problem: In
> >> the
> >> web service implementation
> >> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial#hand6), the
> >> WebServiceContext variable is not getting populated in CXF as it is
> >> with
> >>
> >> Metro:
> >> @Resource
> >> private WebServiceContext context;
> >>
> >> public int doubleIt(int numberToDouble) {
> >>
> >> System.out.println("Context is" + ((context== null) ?
> >> "null"
> >> :
> >> : "not null")); return numberToDouble* 2;
> >> :
> >> }
> >>
> >> Metro returns "not null", while CXF returns "null". The source code is
> >> the same, just the dependencies are switched between the two stacks.
> >> Is
> >> there anything different I need to do (that I didn't need to do before)
> >> in order to get the CXF SEI to have a populated context value?
> >>
> >> Thanks,
> >> Glen
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: WebServiceContext value not being populated in SEI implementation
Posted by Glen Mazza <gm...@talend.com>.
OK, if I understand what you're saying correctly, "cxf-servlet.xml" is a
magic name of sorts, to be used when I'm *not* explicitly declaring a
contextConfigLocation--if I'm going to do the latter, avoid the magic
name. I'll update this.
Thanks,
Glen
PS: Has this been the case for quite some time, or an internal change
in CXF 2.6 (as part of factoring out the Spring stuff)? I think the
former, but IIRC my sample did work in 2010 as-is, so dunno.
On 06/28/2012 05:43 PM, Daniel Kulp wrote:
> Glen,
>
> I haven't completely figured out a true solution to the problem, but I can
> point out a way to "fix" it.
>
> In your web.xml, you are setting up a spring ContextLoaderListener, but then
> pointing it at classpath:META-INF/cxf/cxf.xml. That creates a very basic
> spring context with just a bus. The CXF servlet will then create a child
> context to load the cxf-servlet.xml. That then doesn't see the
> BeanPostProcessor's in the parent context.
>
> There are really two ways to "fix" this:
>
> 1) (best) - rename the cxf-servlet.xml to something like cxf-beans.xml and
> point the contextConfigLocation to that. All the beans and such would be
> loaded into a single context which really is the preferred way to do it.
>
> 2) REMOVE the ContextLoaderListener from the web.xml for CXF. The
> CXFServlet will create a single context from the cxf-servlet.xml which then
> will inject properly.
>
> The big issue is that the Bus is created in one context and then the
> Endpoint (and the DoubleItImpl) is created in another. There is definitely
> an issue with that. I'm going to see if there is anything we can do to
> work around it, but, IMO, your web.xml is a little "strange" for a CXF app.
>
> Dan
>
>
>
> On Tuesday, June 26, 2012 08:20:43 AM Glen Mazza wrote:
>> Hi I recently updated my JAX-WS Handler tutorial
>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial, source code
>> https://github.com/gmazza/blog-samples/tree/master/jaxws_handler_tutorial)
>> originally from April 2010.
>>
>> It runs fine on Metro, mostly fine on CXF except for one problem: In the
>> web service implementation
>> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial#hand6), the
>> WebServiceContext variable is not getting populated in CXF as it is with
>> Metro:
>>
>> @Resource
>> private WebServiceContext context;
>>
>> public int doubleIt(int numberToDouble) {
>> System.out.println("Context is" + ((context== null) ? "null"
>> : "not null")); return numberToDouble* 2;
>> }
>>
>> Metro returns "not null", while CXF returns "null". The source code is
>> the same, just the dependencies are switched between the two stacks. Is
>> there anything different I need to do (that I didn't need to do before)
>> in order to get the CXF SEI to have a populated context value?
>>
>> Thanks,
>> Glen
--
Glen Mazza
Talend Community Coders
coders.talend.com
blog: www.jroller.com/gmazza
Re: WebServiceContext value not being populated in SEI implementation
Posted by Daniel Kulp <dk...@apache.org>.
Glen,
I haven't completely figured out a true solution to the problem, but I can
point out a way to "fix" it.
In your web.xml, you are setting up a spring ContextLoaderListener, but then
pointing it at classpath:META-INF/cxf/cxf.xml. That creates a very basic
spring context with just a bus. The CXF servlet will then create a child
context to load the cxf-servlet.xml. That then doesn't see the
BeanPostProcessor's in the parent context.
There are really two ways to "fix" this:
1) (best) - rename the cxf-servlet.xml to something like cxf-beans.xml and
point the contextConfigLocation to that. All the beans and such would be
loaded into a single context which really is the preferred way to do it.
2) REMOVE the ContextLoaderListener from the web.xml for CXF. The
CXFServlet will create a single context from the cxf-servlet.xml which then
will inject properly.
The big issue is that the Bus is created in one context and then the
Endpoint (and the DoubleItImpl) is created in another. There is definitely
an issue with that. I'm going to see if there is anything we can do to
work around it, but, IMO, your web.xml is a little "strange" for a CXF app.
Dan
On Tuesday, June 26, 2012 08:20:43 AM Glen Mazza wrote:
> Hi I recently updated my JAX-WS Handler tutorial
> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial, source code
> https://github.com/gmazza/blog-samples/tree/master/jaxws_handler_tutorial)
> originally from April 2010.
>
> It runs fine on Metro, mostly fine on CXF except for one problem: In the
> web service implementation
> (http://www.jroller.com/gmazza/entry/jaxws_handler_tutorial#hand6), the
> WebServiceContext variable is not getting populated in CXF as it is with
> Metro:
>
> @Resource
> private WebServiceContext context;
>
> public int doubleIt(int numberToDouble) {
> System.out.println("Context is" + ((context== null) ? "null"
> : "not null")); return numberToDouble* 2;
> }
>
> Metro returns "not null", while CXF returns "null". The source code is
> the same, just the dependencies are switched between the two stacks. Is
> there anything different I need to do (that I didn't need to do before)
> in order to get the CXF SEI to have a populated context value?
>
> Thanks,
> Glen
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com