cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tong, Gary \(IDEAS\)" <>
Subject RE: CXF dual-servlet issues
Date Tue, 24 Feb 2009 17:22:57 GMT
As far as I can tell, this issue is caused by RequestPreprocessor.handleExtensionMappings

    private void handleExtensionMappings(Message m, UriInfo uriInfo) {
        String path = uriInfo.getPath(false);
        for (Map.Entry<?, ?> entry : extensionMappings.entrySet()) {
            if (path.endsWith("." + entry.getKey().toString())) {
                updateAcceptTypeHeader(m, entry.getValue().toString());
                updatePath(m, path, entry.getKey().toString());


UriInfoImpl.getPath takes the REQUEST_URI from message ("/foo/foo/response.xml"), the base
address ("/foo/"), and sends it to HttpUtils.getPathToMatch(String, String, boolean) which
strips the base address from the URI and returns "/foo/response.xml".  This is then passed
through the extension mappings bit.  If a match is found, then the Accept header is updated,
as is the path.

The problem comes when the path is updated.  Previously, the path was "/foo/foo/response.xml".
 However, as uriInfo.getPath strips off the first "/foo/" and returns "/foo/response.xml",
when updatePath is called, it ends up updating the REQUEST_URI to "/foo/response" instead
of "/foo/foo/response" as it should.

Any number of ways to fix this, I suppose.  One way may be to add an updatePath method to
HttpUtils and switch RequestPreprocessor.updatePath to use it.

    public static void updatePath(Message m, String path) {
        String baseAddress = getBaseAddress(m);
        boolean pathSlash = path.startsWith("/");
        boolean baseSlash = path.endsWith("/");
        if (pathSlash && baseSlash) {
            path = path.substring(1);
        } else if (!pathSlash && !baseSlash) {
            path = "/" + path;
        m.put(Message.REQUEST_URI, baseAddress + path);

I'd submit a patch + unit tests, but I can't access the source repo from here.


-----Original Message-----
From: Sergey Beryozkin []
Sent: 20 February 2009 19:16
Subject: Re: CXF dual-servlet issues

I'm impressed :-) Looks like it's all down to a url pattern you choose :-) Yeah - I'm too
exhausted :-) too at the moment so will check early next week.
I'm about to complete the client api stuff for 2.2. and will dedicate the remaining time to
addressing the various issues raised recently

Cheers, Sergey

----- Original Message -----
From: "Tong, Gary (FID)" <>
To: <>
Sent: Friday, February 20, 2009 6:59 PM
Subject: CXF dual-servlet issues

Will investigate more on Monday, but this is currently breaking in CXF 2.1.4:


<?xml version="1.0"?>
<beans xmlns=""

  <import resource="classpath:META-INF/cxf/cxf.xml" />
  <import resource="classpath:META-INF/cxf/cxf-extension-jaxrs-binding.xml" />
  <import resource="classpath:META-INF/cxf/cxf-servlet.xml" />

  <jaxrs:server id="cxfMapping" address="/">
      <bean class="sandbox.cxf.controller.FooController"/>
      <entry key="json" value="application/json"/>
      <entry key="xml" value="application/xml"/>



<?xml version="1.0"?>
<web-app xmlns=""






public class FooController {

        public String text() {
                return "foo";

    public Response response() {
        return new Response("foo");


@XmlRootElement(name = "response")
public class Response {

        @XmlElement(name = "msg")
        private String message;

        public Response() {

        public Response(String message) {
                this.message = message;

         * @return the message
        public String getMessage() {
                return message;

         * @param message
         *            the message to set
        public void setMessage(String message) {
                this.message = message;



GET /foo/foo/text -> 200 "foo"
GET /foo/foo/response.xml -> 404
GET /foo/foo/response.json -> 404

But change web.xml from




GET /wtf/foo/text -> 200 "foo"
GET /wtf/foo/response.xml -> 200 ...
GET /wtf/foo/response.json -> 200 ...


This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments
mentioned or an official confirmation.
Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments
mentioned or may advise the issuers. This is not research and is not from MS Research but
it may refer to a research analyst/research report. Unless indicated, these views are the
author's and may differ from those of Morgan Stanley research or others in the Firm. We do
not represent this is accurate or complete and we may not update this. Past performance is
not indicative of future returns. For additional information, research reports and important
disclosures, contact me or see You should not use e-mail
to request, authorize or effect the purchase or sale of any security or instrument, to send
transfer instructions, or to effect any other transactions. We cannot guarantee that any such
requests received via e-mail will be processed in a timely manner. This communication is solely
for the addressee(s) and may contain confidential information. We do not waive confidentiality
by mistransmission. Contact me if you do not wish to receive these communications. In the
UK, this communication is directed in the UK to those persons who are professional and eligible
counterparties (as defined in the UK Financial Services Authority's rules).

NOTICE: If received in error, please destroy and notify sender. Sender does not intend to
waive confidentiality or privilege. Use of this email is prohibited when received in error.

View raw message