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 [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
