Return-Path: X-Original-To: apmail-cxf-users-archive@www.apache.org Delivered-To: apmail-cxf-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6B161E400 for ; Tue, 29 Jan 2013 13:50:28 +0000 (UTC) Received: (qmail 2357 invoked by uid 500); 29 Jan 2013 13:50:27 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 2137 invoked by uid 500); 29 Jan 2013 13:50:27 -0000 Mailing-List: contact users-help@cxf.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@cxf.apache.org Delivered-To: mailing list users@cxf.apache.org Received: (qmail 2118 invoked by uid 99); 29 Jan 2013 13:50:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 13:50:27 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates 209.85.217.174 as permitted sender) Received: from [209.85.217.174] (HELO mail-lb0-f174.google.com) (209.85.217.174) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Jan 2013 13:50:19 +0000 Received: by mail-lb0-f174.google.com with SMTP id l12so751263lbo.19 for ; Tue, 29 Jan 2013 05:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PyrWBu3jFVKURbCHBLJ+NgWJaCc1nmu+NIREsEWhhKk=; b=rW8srMVNk7HF/HF3dwQbo5ZZyd6ukA4JBmYdfUNaXsuhlSUIp6RzVHQTh6KB37Ddoj uHMKHzF4z2ZxKPJ9X7h802GPbu2s6w2KyzuQexC5a4JVmsM0VdaSqqbHtLLv0w59iXTQ Fxi2Wi0vm//tZZX14PFj7gksfRkygqFLaNpCxqZN5Hx6UQ1LNaRFEsj8Y3kYoPwWQmUh hTAWO/qDVcroZfePqj926v+AtN0I+QxThyzpBtoGWgoQBqJ21+dHlf7WhK0MqJIScvmW C4A2vdM30KaF4GKIPrgofmRS3sqjscnv/x4pyqtxQmkvjhZjIQtLoNiylVFkn6+kDcqa ZWjg== X-Received: by 10.112.17.3 with SMTP id k3mr533156lbd.42.1359467399008; Tue, 29 Jan 2013 05:49:59 -0800 (PST) Received: from [192.168.2.5] ([89.100.140.13]) by mx.google.com with ESMTPS id ft8sm5056792lab.9.2013.01.29.05.49.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 05:49:58 -0800 (PST) Message-ID: <5107D384.3030501@gmail.com> Date: Tue, 29 Jan 2013 13:49:56 +0000 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: users@cxf.apache.org Subject: Re: [CXF.REST] javax.ws.rs exception throwing from ExceptionMapper References: <5107CB9A.5010804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi Andrei On 29/01/13 13:44, Andrei Shakirin wrote: > Hi Sergei, > >> -----Original Message----- >> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com] >> Sent: Dienstag, 29. Januar 2013 14:16 >> To: users@cxf.apache.org >> Subject: Re: [CXF.REST] javax.ws.rs exception throwing from >> ExceptionMapper >> >> Hi Andrei >> On 29/01/13 12:51, Andrei Shakirin wrote: >>> Hi, >>> >>> Would like to discuss the following: >>> CXF Rest service implementation processes javax.ws.rs >> (NotFoaundException, BadRequestException) exceptions correctly. >>> But if these exception are thrown form exception mapper, client always >> receive InternalServerError exception. >>> >>> Is this behaviour specified by JAX-RS? >> >> I'm actually not seeing anything specific in the text, but I think at the moment >> that CXF is correct, because otherwise the question is how to map these >> rethrown exceptions and we can have an infinity loop - something the spec >> talks about, for example, an exception mapper sets a Response entity - next >> MessageBodyWriter throws the exception again - this 500, so I think it is 500 >> in this case too >> > > Hmm ... is it possible not to map exceptions thrown by ExceptionMapper again to avoid loops? > Is there any possibility to distinguish them? > The only thing the runtime can do is to catch the exception, check if it is an instance of WebApplicationException and if yes - getResponse on it, which is exactly what the mapper can do; and I think if we did it it would probably be not-portable... >>> I find convenient in some cases just to re-throw javax.ws.rs exceptions >> from mapper and not build Response manually. >>> >> Sure, in this case it is easy :-), all WebApplicationException instances have >> getResponse() method - so simply use exception.getResponse() - it will have >> a proper status set, etc.. > > Sure, if response is set. But if it is null? Mapper must build response manually, set correct response code - not a big deal, but anyway ... > For WebApplicationExceptions it is always set, as for the custom non WAE-exceptions - only the mappers know how to map them to anything but 500 :-) Cheers, Sergey > Regards, > Andrei. > >> >> HTH, Sergey >> >>> WDYT? >>> >>> Regards, >>> Andrei. >>> >>> >>>