Hi Sergey,

Glad to help.  CXF has saved us a lot of development time, so I'm happy to 
contribute back any way I can.

Working out more issues with servlet isolation atm.  Will let you guys know if 
any useful code comes out of it.

Cheers,
Gary

-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]] 
Sent: 03 March 2009 12:47
To: [email protected]
Subject: Re: CXF dual-servlet issues

Hi Gary

It's fixed now - I just copied your proposed code mostly unchanged (except for 
one minor typo) and it worked for all the variations just fine. I'd like to 
consider this tip being equivalent to a patch, a second one in your case (first 
one was to do with the ExceptionMapper injection issue). Arguably the fixes 
have been quite simple but it just saves time a lot if users not only open the 
issues (which does help in its own right) but also spend their own time and 
provide a hint as to why the problem is happening or indeed post a possible 
fix...Quite a few users are helping in this regard which is what we definitely 
appreciate

Cheers, Sergey

----- Original Message -----
From: "Sergey Beryozkin" <[email protected]>
To: <[email protected]>
Sent: Tuesday, February 24, 2009 7:48 PM
Subject: RE: CXF dual-servlet issues


Hi Gary

It's most helpful - many thanks. I'll pick up from here - I'm still tweaking 
the client api a bit but I'll have around 2 weeks or so to sort out all the 
issues raised recently. 2.1.5-SNAPSHOT will get updated too...

Cheers, Sergey

-----Original Message-----
From: Tong, Gary (IDEAS) [mailto:[email protected]]
Sent: 24 February 2009 17:23
To: [email protected]
Subject: RE: CXF dual-servlet issues

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());
                break;
            }
        }

    }

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.

Cheers,
Gary

-----Original Message-----
From: Sergey Beryozkin [mailto:[email protected]]
Sent: 20 February 2009 19:16
To: [email protected]
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)" <[email protected]>
To: <[email protected]>
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:

context.xml:

<?xml version="1.0"?>
<beans xmlns="http://www.springframework.org/schema/beans";
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
       xmlns:jaxrs="http://cxf.apache.org/jaxrs";
       xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd";>

  <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="/">
    <jaxrs:serviceBeans>
      <bean class="sandbox.cxf.controller.FooController"/>
    </jaxrs:serviceBeans>
    <jaxrs:extensionMappings>
      <entry key="json" value="application/json"/>
      <entry key="xml" value="application/xml"/>
    </jaxrs:extensionMappings>
  </jaxrs:server>

</beans>

web.xml:

<?xml version="1.0"?>
<web-app xmlns="http://java.sun.com/xml/ns/j2ee";
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
         xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
         version="2.4">

  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>WEB-INF/context.xml</param-value>
  </context-param>

  <listener>

<listener-class>org.springframework.web.context.ContextLoaderListener</l
istener-class>
  </listener>

  <servlet>
    <servlet-name>cxf</servlet-name>

<servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-clas
s>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>cxf</servlet-name>
    <url-pattern>/foo/*</url-pattern>
  </servlet-mapping>

</web-app>

FooController.java:

@Path("/foo/")
public class FooController {

    @GET
    @Path("/text/")
    @ProduceMime("text/plain")
        public String text() {
                return "foo";
        }

    @GET
    @Path("/response/")
    public Response response() {
        return new Response("foo");
    }

}

Response.java:

@XmlRootElement(name = "response")
@XmlAccessorType(XmlAccessType.FIELD)
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;
        }

}

Results:

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

But change web.xml from

  <servlet-mapping>
    <servlet-name>cxf</servlet-name>
    <url-pattern>/foo/*</url-pattern>
  </servlet-mapping>

To

  <servlet-mapping>
    <servlet-name>cxf</servlet-name>
    <url-pattern>/wtf/*</url-pattern>
  </servlet-mapping>

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

Bizarre...

------------------------------------------------------------------------
--
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 
https://secure.ms.com/servlet/cls. 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.


--------------------------------------------------------------------------
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.

Reply via email to