cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sbery...@progress.com>
Subject RE: CXF dual-servlet issues
Date Tue, 03 Mar 2009 21:39:06 GMT
Hi Gary

This all sounds really good.
I know of one issue with CXF servlets (which rely on a Spring context
loader), specifically one can't have two CXF servlets routing to the
same jaxrs:endpoint, for ex :

CXFServlet1 : /bar/*
CXFServlet2 : /foo/*

jaxrs:endpoint: /baz

In this case /foo/baz requests won't be handled. One workaround is to
introduce two resource classes with /bar and /foo respectively and have
'/' in both (single) CXFServlet and jaxrs:endpoint definitions. Another
one is to have '/' in CXFServlet only but introduce two jaxrs:endpoints
with /foo and /bar, sharing the same resource class.
That said, this is one issue I'm aware of at the moment

Cheers, Sergey

-----Original Message-----
From: Tong, Gary (IDEAS) [mailto:Gary.Tong@morganstanley.com] 
Sent: 03 March 2009 18:02
To: dev@cxf.apache.org
Subject: RE: CXF dual-servlet issues

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:sberyozk@progress.com] 
Sent: 03 March 2009 12:47
To: dev@cxf.apache.org
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" <sberyozk@progress.com>
To: <dev@cxf.apache.org>
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:Gary.Tong@morganstanley.com]
Sent: 24 February 2009 17:23
To: dev@cxf.apache.org
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:sberyozk@progress.com]
Sent: 20 February 2009 19:16
To: dev@cxf.apache.org
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)" <Gary.Tong@morganstanley.com>
To: <dev@cxf.apache.org>
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.

Mime
View raw message