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
