Need clarification on cxf-servlet.xml config file.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Need clarification on cxf-servlet.xml config file.

Glen Mazza
Administrator
Hello, I have two questions on my own DoubleIt tutorial--in particular the portion[1] where you can choose a default WEB-INF/cxf-servlet.xml config file for your web service provider, or explicitly name your config file[2] (say ws-beans.xml) in your web.xml.  Just to confirm (and I may be incorrect on these points):

1.)  If you use the default filename cxf-servlet.xml, you do *not* need to explicitly list the <import resource="..."/> as you do in the ws-beans.xml file as shown in [1].  With cxf-servlet.xml, *all* of the imports are automatically brought in, and with an explicitly specified ws-beans.xml file, *none* of the imports are brought in unless you explicitly specify them--is that correct?

2.)  (And this related to (1) above) -- Looking at the CXF source code, class org.apache.cxf.transport.servlet.CXFServlet's loadAdditionalConfig method[3] is where the code seems to look for cxf-servlet.xml if no other config file is specified in the web.xml:

String location = servletConfig.getInitParameter("config-location");
if (location == null) {
    location = "/WEB-INF/cxf-servlet.xml";
}

This is where I'm getting confused though.  If this is the code that activates cxf-servlet.xml by default if nothing is specified in the web.xml, why does this cxf-servlet.xml file *not* need to have the <import resource="..."/> explicitly specified?  AFAICT, there should be no difference in requirements over whether imports need to be specified or not between a default cxf-servlet.xml and an explicitly specified ws-beans.xml.

Thanks,
Glen

[1] http://www.jroller.com/gmazza/date/20080417#WFstep8
[2] http://www.jroller.com/gmazza/date/20080417#WFstep7
[3] http://tinyurl.com/4732dk
Reply | Threaded
Open this post in threaded view
|

Re: Need clarification on cxf-servlet.xml config file.

Ian Roberts
Glen Mazza wrote:
> 1.)  If you use the default filename cxf-servlet.xml, you do *not* need to
> explicitly list the <import resource="..."/> as you do in the ws-beans.xml
> file as shown in [1].  With cxf-servlet.xml, *all* of the imports are
> automatically brought in, and with an explicitly specified ws-beans.xml
> file, *none* of the imports are brought in unless you explicitly specify
> them--is that correct?

As I understand it, the two choices when using CXF are (a) use the
Spring ContextLoaderListener to set up the application context or (b)
don't use the CLL, and instead let the CXF servlet load its own context
including beans defined in cxf-servlet.xml.  In case (a) Spring needs to
be told where to find the bean definitions that make up the CXF
infrastructure (the bus, etc.), but in case (b) the context created by
the CXF servlet has these definitions imported automatically.

The important thing is that the CXF infrastructure bean definitions have
to get into the context somehow - in case (a) this is typically done
using <import> but alternatively you could remove the imports from your
ws-beans.xml and add the corresponding resource URLs to the
contextConfigLocation parameter in web.xml, the results should be identical.

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:META-INF/cxf/cxf.xml
      classpath:META-INF/cxf/cxf-extension-soap.xml
      classpath:META-INF/cxf/cxf-servlet.xml
      WEB-INF/ws-beans.xml
    </param-value>
</context-param>

Ian

--
Ian Roberts               | Department of Computer Science
[hidden email]  | University of Sheffield, UK
Reply | Threaded
Open this post in threaded view
|

Re: Need clarification on cxf-servlet.xml config file.

Glen Mazza
Administrator
ianroberts wrote
As I understand it, the two choices when using CXF are (a) use the
Spring ContextLoaderListener to set up the application context or (b)
don't use the CLL, and instead let the CXF servlet load its own context
including beans defined in cxf-servlet.xml.  In case (a) Spring needs to
be told where to find the bean definitions that make up the CXF
infrastructure (the bus, etc.), but in case (b) the context created by
the CXF servlet has these definitions imported automatically.

The important thing is that the CXF infrastructure bean definitions have
to get into the context somehow - in case (a) this is typically done
using <import> but alternatively you could remove the imports from your
ws-beans.xml and add the corresponding resource URLs to the
contextConfigLocation parameter in web.xml, the results should be identical.

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:META-INF/cxf/cxf.xml
      classpath:META-INF/cxf/cxf-extension-soap.xml
      classpath:META-INF/cxf/cxf-servlet.xml
      WEB-INF/ws-beans.xml
    </param-value>
</context-param>

Ian
Thanks Ian--that clarifies a lot.  I'll be updating that section soon.

Glen
Reply | Threaded
Open this post in threaded view
|

Re: Need clarification on cxf-servlet.xml config file.

Daniel Kulp
Administrator
In reply to this post by Ian Roberts

Exactly what Ian stated.

The one caveat though is that there are a bunch of things that may need to be
imported into the contextConfigLocation depending on what is needed:
META-INF/cxf/cxf.xml
META-INF/cxf/cxf-extension-addr.xml
META-INF/cxf/cxf-extension-corba.xml
META-INF/cxf/cxf-extension-http-binding.xml
META-INF/cxf/cxf-extension-http-jetty.xml
META-INF/cxf/cxf-extension-http.xml
META-INF/cxf/cxf-extension-javascript-client.xml
META-INF/cxf/cxf-extension-jaxrs-binding.xml
META-INF/cxf/cxf-extension-jaxws.xml
META-INF/cxf/cxf-extension-jms.xml
META-INF/cxf/cxf-extension-local.xml
META-INF/cxf/cxf-extension-management.xml
META-INF/cxf/cxf-extension-object-binding.xml
META-INF/cxf/cxf-extension-policy.xml
META-INF/cxf/cxf-extension-rm.xml
META-INF/cxf/cxf-extension-soap.xml
META-INF/cxf/cxf-extension-ws-security.xml
META-INF/cxf/cxf-extension-xml.xml

(We really should document all of them and when/why you would need each one)

The GOOD news is we have a:
META-INF/cxf/cxf-all.xml
that automatically grabs all of the above.   Thus, you COULD do:

<context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>
       classpath:META-INF/cxf/cxf-all.xml
       classpath:META-INF/cxf/cxf-servlet.xml
       WEB-INF/ws-beans.xml
     </param-value>
</context-param>

and pretty much get the entire thing setup just like if you did a pure
cxf-servlet.xml approach.    That said, cxf-all does bring in a lot of stuff
you may not need (just like cxf-servlet approach) so startup is slower,
memory footprint is higher, etc....

Dan



On Sunday 21 September 2008 6:28:53 pm Ian Roberts wrote:

> Glen Mazza wrote:
> > 1.)  If you use the default filename cxf-servlet.xml, you do *not* need
> > to explicitly list the <import resource="..."/> as you do in the
> > ws-beans.xml file as shown in [1].  With cxf-servlet.xml, *all* of the
> > imports are automatically brought in, and with an explicitly specified
> > ws-beans.xml file, *none* of the imports are brought in unless you
> > explicitly specify them--is that correct?
>
> As I understand it, the two choices when using CXF are (a) use the
> Spring ContextLoaderListener to set up the application context or (b)
> don't use the CLL, and instead let the CXF servlet load its own context
> including beans defined in cxf-servlet.xml.  In case (a) Spring needs to
> be told where to find the bean definitions that make up the CXF
> infrastructure (the bus, etc.), but in case (b) the context created by
> the CXF servlet has these definitions imported automatically.
>
> The important thing is that the CXF infrastructure bean definitions have
> to get into the context somehow - in case (a) this is typically done
> using <import> but alternatively you could remove the imports from your
> ws-beans.xml and add the corresponding resource URLs to the
> contextConfigLocation parameter in web.xml, the results should be
> identical.
>
> <context-param>
>     <param-name>contextConfigLocation</param-name>
>     <param-value>
>       classpath:META-INF/cxf/cxf.xml
>       classpath:META-INF/cxf/cxf-extension-soap.xml
>       classpath:META-INF/cxf/cxf-servlet.xml
>       WEB-INF/ws-beans.xml
>     </param-value>
> </context-param>
>
> Ian



--
Daniel Kulp
[hidden email]
http://www.dankulp.com/blog
Reply | Threaded
Open this post in threaded view
|

Re: Need clarification on cxf-servlet.xml config file.

Glen Mazza
Administrator
dkulp wrote
The GOOD news is we have a:
META-INF/cxf/cxf-all.xml
that automatically grabs all of the above.   Thus, you COULD do:

<context-param>
     <param-name>contextConfigLocation</param-name>
     <param-value>
       classpath:META-INF/cxf/cxf-all.xml
       classpath:META-INF/cxf/cxf-servlet.xml
       WEB-INF/ws-beans.xml
     </param-value>
</context-param>

and pretty much get the entire thing setup just like if you did a pure
cxf-servlet.xml approach.    That said, cxf-all does bring in a lot of stuff
you may not need (just like cxf-servlet approach) so startup is slower,
memory footprint is higher, etc....

Dan
Thanks Dan, two more questions if you know:

1.) Do you know why the META-INF/cxf/cxf-servlet.xml that you have listed in the context-param above is not included in cxf-all.xml?  Class conflicts?

also

2.) As you and Ian have said, using the configuration file WEB-INF/cxf-servlet.xml brings in all of the components of CXF, i.e., is equivalent to exporting META-INF/cxf/cxf-all.xml.  What makes that automatically happen, where the components of the cxf-servlet.xml approach will equal the components in cxf-all.xml--does the cxf-servlet.xml approach import cxf-all.xml behind-the-scenes, or you manually need to add the components to the cxf-servlet.xml approach to keep the two approaches in sync?

Thanks,
Glen
Reply | Threaded
Open this post in threaded view
|

Re: Need clarification on cxf-servlet.xml config file.

Daniel Kulp
Administrator
On Tuesday 23 September 2008 3:53:06 pm Glen Mazza wrote:
> dkulp wrote:
>
> Thanks Dan, two more questions if you know:
>
> 1.) Do you know why the META-INF/cxf/cxf-servlet.xml that you have listed
> in the context-param above is not included in cxf-all.xml?  Class
> conflicts?

Yea, that's the one you DON'T want on there unless you are running in a
servlet.  In the standalone case, if you have that there, it replaces the
jetty based transport (cxf-extension-http-jetty) with the servlet version of
the http transport.  When not running in a servlet, that would be bad.  
Things like ws-addressing that bring up the jetty stuff for callbacks would
not work.

> also
>
> 2.) As you and Ian have said, using the configuration file
> WEB-INF/cxf-servlet.xml brings in all of the components of CXF, i.e., is
> equivalent to exporting META-INF/cxf/cxf-all.xml.  What makes that
> automatically happen, where the components of the cxf-servlet.xml approach
> will equal the components in cxf-all.xml--does the cxf-servlet.xml approach
> import cxf-all.xml behind-the-scenes, or you manually need to add the
> components to the cxf-servlet.xml approach to keep the two approaches in
> sync?

In the WEB-INF/cxf-servlet.xml case, what really happens is that we create
a "default" bus and thus the logic is exactly the same as occurs when
creating a command line client/service.   In that case, the SpringBusFactory
stuff grabs all the /META-INF/cxf/cxf-extension files it finds on the
classpath (note: we're NOT talking about the xml files,
literally "cxf-extension".   Literally, we call
classloader.getResources("/META-INF/cxf/cxf.extension") to get the URL[]).  
Those files are lists of the xml files to actually load.   cxf-all.xml isn't
in that list, it gets the raw cxf-extension-blah.xml files, but the affect is
the same.  

Note: this is how companies like IONA/Progress provide extensions to CXF.  
They have /META-INF/cxf/cxf.extension files in their jars that point to their
spring stuff.   When the bus is created, if those jars are on the classpath,
they get picked up and the extra functionality is loaded automatically.

In anycase, once the "default" bus is loaded into the Servlet, we then create
a child spring context with the WEB-INF/cxf-servlet.xml and refresh it thus
causing the beans in there to load.  

The cxf-all.xml thing is relatively new (I think introduced in 2.0.7/2.1.1).  
We mostly added it cause the list of things you need to import to get "all"
the functionality is growing.  WS-Policy, WS-SecurityPolicy, JAX-RS, etc...
all are having things you'll need to import.


--
Daniel Kulp
[hidden email]
http://www.dankulp.com/blog