Return-Path: Delivered-To: apmail-incubator-cxf-user-archive@locus.apache.org Received: (qmail 67352 invoked from network); 16 Apr 2007 17:20:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 16 Apr 2007 17:20:07 -0000 Received: (qmail 42373 invoked by uid 500); 16 Apr 2007 17:20:10 -0000 Delivered-To: apmail-incubator-cxf-user-archive@incubator.apache.org Received: (qmail 42267 invoked by uid 500); 16 Apr 2007 17:20:10 -0000 Mailing-List: contact cxf-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cxf-user@incubator.apache.org Delivered-To: mailing list cxf-user@incubator.apache.org Received: (qmail 42224 invoked by uid 99); 16 Apr 2007 17:20:09 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Apr 2007 10:20:09 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: local policy) Received: from [198.51.119.137] (HELO mail2.avid.com) (198.51.119.137) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Apr 2007 10:20:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Accessing Message Context, HttpServletRequest, and HttpServletResponse Date: Mon, 16 Apr 2007 13:19:41 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Accessing Message Context, HttpServletRequest, and HttpServletResponse Thread-Index: AceARcAbgbD5lY9mQTWHaMPa6a10swABY1+w From: "Christopher Moesel" To: X-Virus-Checked: Checked by ClamAV on apache.org Good point, Fred. I've added the following snippet to the end of the section: "Of course, it is always a good idea to program defensively if using transport-specific entities like the HttpServletRequest and HttpServletResponse. If the transport were changed (for instance to the JMS transport), then these values would likely be null." -Chris -----Original Message----- From: Fred Dushin [mailto:fred@dushin.net]=20 Sent: Monday, April 16, 2007 12:11 PM To: cxf-user@incubator.apache.org Subject: Re: Accessing Message Context, HttpServletRequest, and HttpServletResponse Just bear in mind that this is fragile, and servants should be coded =20 defensively for the case in which this information is not available. =20 (E.g., due to underlying changes in the transport implementation, or =20 an administrative modification that changes the transport type, all =20 together) That being said, the idea that all information about the request =20 context is available is laudable, and CXF should be commended for =20 it. You never know when an application is going to need information =20 about what's really going on under the hood, and in a managed =20 language like Java, it's pretty senseless to throw this information =20 away. -Fred On Apr 16, 2007, at 11:52 AM, Christopher Moesel wrote: > I needed access to the request object from within my service > implementation. So after finding nothing in the documentation, I dug > through the samples and found a way. > > I thought this would be useful to others, so I added it to the User > Guide WIKI at the bottom of: > http://cwiki.apache.org/confluence/display/CXF20DOC/Servlet+Transport > > If this is the incorrect place for it, or if this is not the =20 > recommended > approach, please feel free to modify, move, or delete it at will. > > Thanks, > Chris >