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 3440B99DF for ; Tue, 27 Sep 2011 14:36:33 +0000 (UTC) Received: (qmail 54130 invoked by uid 500); 27 Sep 2011 14:36:32 -0000 Delivered-To: apmail-cxf-users-archive@cxf.apache.org Received: (qmail 54076 invoked by uid 500); 27 Sep 2011 14:36:32 -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 54068 invoked by uid 99); 27 Sep 2011 14:36:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Sep 2011 14:36:32 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=FREEMAIL_FROM,FREEMAIL_REPLY,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates 74.125.82.49 as permitted sender) Received: from [74.125.82.49] (HELO mail-ww0-f49.google.com) (74.125.82.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Sep 2011 14:36:24 +0000 Received: by wwp14 with SMTP id 14so5984850wwp.6 for ; Tue, 27 Sep 2011 07:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ecC6JBz8wN0FV76zZuM9li7KapcC/TSJ1LOuovs0RR8=; b=qpn3tps5ZvSXLNKEMXAxSsF1O0RF/I67p5RhyFPsngaZ/H9ABmQf7ONoc3ZF6vTCcD Rxc0KA3b54Id0x/KMvo6w1qEtUX+TLsudMizK5kjgkMgK5smNCvptsl7fCm483uCTDiv se18M9U7rv7ycDzI5Lf6vv/6S2LCK0RNDR4cw= Received: by 10.227.132.141 with SMTP id b13mr9284794wbt.29.1317134164558; Tue, 27 Sep 2011 07:36:04 -0700 (PDT) Received: from [10.36.226.4] ([217.173.99.61]) by mx.google.com with ESMTPS id es10sm30226926wbb.4.2011.09.27.07.36.03 (version=SSLv3 cipher=OTHER); Tue, 27 Sep 2011 07:36:03 -0700 (PDT) Message-ID: <4E81DF52.6000608@gmail.com> Date: Tue, 27 Sep 2011 15:36:02 +0100 From: Sergey Beryozkin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: users@cxf.apache.org Subject: Re: CXF-DOSGI subproject ML? References: <4E7E114C.4050203@talend.com> <4E80439F.2090307@gmail.com> <4E805814.6050707@gmail.com> <4E80620A.2050707@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Hi - can you consider providing a patch, it seems GreeterException is available ? lets try the "cause" first, and if target is not null - then try that. May be ServiceInvocationHandler should also throw ServiceException directly without wrapping it Cheers, Sergey On 27/09/11 14:00, Andr�s Liter wrote: > Hello Sergey, > > could you please check my screenshots of debugging? I uploaded them here: > > Response to client @ place of call: > https://docs.google.com/leaf?id=0BzVD18l494R1ZDZmNWNiMDQtYTQwNy00OTUzLThjNjItZmQ5MWI5NTkzOWU0&hl=hu > (Here is where I expect variable 'ex' to be instanceof GreeterException, but > it isnt) > > Response to client @ ServiceInvocationHandler: > https://docs.google.com/leaf?id=0BzVD18l494R1OTY2OWMzNTAtNWFhNS00ZmI4LTk5YmItYmRlZGMxMjYzMmRh&hl=hu > > I wonder if these are correct. > > Thank you very much, > Andr�s > > On Mon, Sep 26, 2011 at 1:29 PM, Sergey Beryozkinwrote: > >> Please do, I'll be happy to apply a patch if you can find the cause of the >> problem >> >> Cheers, Sergey >> >> On 26/09/11 12:24, Andr�s Liter wrote: >> >>> Hello Sergey, >>> >>> yes, when I debugged strange thing happened (at least to me :) ): >>> ServiceInvocationHandler matched the exception from the server with the >>> invoked method's ones and execution has stepped into the if clause (line >>> 75), to throw theCause; >>> But then the iteration ended normally and the exception at line 80 has >>> been >>> thrown instead of line 75. Kind of confusing, but I can carry on debugging >>> at least :) >>> >>> On Mon, Sep 26, 2011 at 12:46 PM, Sergey Beryozkin>>> wrote: >>> >>> Hi Andr�s >>>> >>>> I'm afraid I don't know the answer at the moment. >>>> I agree that if an interface method declares a custom Exception then it >>>> has >>>> to be thrown - I'm not seeing the attachment - do you see in the debugger >>>> if >>>> ServiceInvocationHandler manages to match a Throwable instance to one of >>>> the >>>> exception classes in the map, before proceeding with throwing >>>> ServiceException ? >>>> >>>> Cheers, Sergey >>>> >>>> >>>> >>>> On 26/09/11 11:16, Andr�s Liter wrote: >>>> >>>> Hello Sergey, >>>>> >>>>> thanks for the tips! >>>>> >>>>> I tried the Greeter sample as well, and in my environment its exception >>>>> handling fails the same way I described before (the custom exception is >>>>> declared, no compilation error, but then a runtime exception / error >>>>> (execution stops :( )). >>>>> >>>>> I debugged this exception as well at the client side (for me it only >>>>> shows that my custom exception is wrapped). I attached the variables >>>>> scrrenshot anyway, and I've also attached the debugged variables at >>>>> ServiceInvocationHandler's catch clause (exception_debugged_sih.png). >>>>> Are these proper? >>>>> >>>>> Thanks, >>>>> Andr�s >>>>> >>>>> On Mon, Sep 26, 2011 at 11:19 AM, Sergey Beryozkin>>>> > wrote: >>>>> >>>>> Hi >>>>> >>>>> Here is the way it's handled on the client side: >>>>> >>>>> http://svn.apache.org/repos/__****asf/cxf/dosgi/trunk/dsw/cxf-**__** >>>>> dsw/src/main/java/org/apache/_****_cxf/dosgi/dsw/handlers/__** >>>>> ServiceInvocationHandler.java<**http://svn.apache.org/repos/__** >>>>> asf/cxf/dosgi/trunk/dsw/cxf-__**dsw/src/main/java/org/apache/_** >>>>> _cxf/dosgi/dsw/handlers/__**ServiceInvocationHandler.java >>>>>> >>>>> >>>>> dsw/src/main/java/org/apache/****cxf/dosgi/dsw/handlers/** >>>>> ServiceInvocationHandler.java<**http://svn.apache.org/repos/** >>>>> asf/cxf/dosgi/trunk/dsw/cxf-**dsw/src/main/java/org/apache/** >>>>> cxf/dosgi/dsw/handlers/**ServiceInvocationHandler.java >>>>>> >>>>> >>>>>> >>>>>> >>>>> I don't recall if I was the last one who changed that code or if >>>>> David was applying more changes afterwards. I suspect that was code >>>>> was supposed to be compliant with the spec we were implementing at a >>>>> time :-) >>>>> >>>>> Looking at this code: >>>>> >>>>> http://svn.apache.org/repos/__****asf/cxf/dosgi/trunk/samples/**__** >>>>> greeter/client/src/main/java/_****_org/apache/cxf/dosgi/**samples/** >>>>> __greeter/client/Activator.****java>>>> repos/__asf/cxf/dosgi/trunk/**samples/__greeter/client/src/** >>>>> main/java/__org/apache/cxf/**dosgi/samples/__greeter/** >>>>> client/Activator.java >>>>>> >>>>> >>>>> greeter/client/src/main/java/****org/apache/cxf/dosgi/samples/**** >>>>> greeter/client/Activator.java<**http://svn.apache.org/repos/** >>>>> asf/cxf/dosgi/trunk/samples/**greeter/client/src/main/java/** >>>>> org/apache/cxf/dosgi/samples/**greeter/client/Activator.java >>>>>> >>>>> >>>>>> >>>>>> >>>>> suggests that custom exceptions have to be thrown - so I suspect >>>>> that if you get a ServiceException then no mapping was successful... >>>>> >>>>> The best way to figure out what is happening is to checkout the >>>>> source, start the client container in a debug mode and get a >>>>> breakpoint in ServiceInvocationHandler... >>>>> >>>>> Hope that helps a bit, >>>>> >>>>> Cheers, Sergey >>>>> >>>>> >>>>> >>>>> On 26/09/11 10:01, Andr�s Liter wrote: >>>>> >>>>> Thanks. >>>>> >>>>> So I have some kind of misunderstanding about DOSGi CXF's >>>>> exception >>>>> handling. >>>>> >>>>> My scenario is the following: >>>>> I created a simple client-server architecture, where both client >>>>> and server >>>>> components run on Equinox and the communication is based on >>>>> DOSGi CXF. The >>>>> webservices worked fine, then I decided to put some >>>>> exception-handling into >>>>> the application. I subclassed java.lang.Exception to create a >>>>> common >>>>> exception for my app, then subclassed that exception for specific >>>>> exceptions. Of course both client and server bundles use these >>>>> exceptions, >>>>> as I put them into the interface bundle. >>>>> >>>>> Then I wanted to test the exceptions: the client called the >>>>> server side >>>>> service operation, which threw my specific exception, but it was >>>>> wrapped in >>>>> the following exceptions: >>>>> >>>>> java.lang.reflect.__****UndeclaredThrowableException / >>>>> java.lang.reflect.__****InvocationTargetException / >>>>> org.osgi.framework.__****ServiceException / >>>>> java.lang.reflect.__****InvocationTargetException / >>>>> MySpecificException >>>>> >>>>> And here comes my question: Is this wrapping provided by the CXF >>>>> DOSGi >>>>> runtime? I mean is this the way it should work? If so, how could >>>>> I catch >>>>> this exception nicely on the client side? In nicely I mean that >>>>> so far the >>>>> only way I figured out was having a catch block for >>>>> UndeclaredThrowable (or >>>>> Exception.. :)), which just makes having custom exceptions >>>>> useless :) And >>>>> naturally, my IDE (Eclipse) wants the custom exception to be >>>>> catched.. >>>>> >>>>> I tried to make my application exception by subclassing >>>>> InvocationTargetException, but didnt work the way I wanted. >>>>> >>>>> So I am a bit confused, I hope someone can clarify my issue. >>>>> >>>>> Thanks in advance, >>>>> Andr�s Liter >>>>> >>>>> On Sat, Sep 24, 2011 at 7:20 PM, Glen Mazza>>>> > wrote: >>>>> >>>>> >>>>> Feel free to ask your questions here. >>>>> >>>>> Glen >>>>> >>>>> >>>>> On 09/24/2011 06:49 AM, Andr�s Liter wrote: >>>>> >>>>> Dear CXF Users, >>>>> >>>>> >>>>> >>>>> I wonder if there is a separate mailing list for the >>>>> CXF-DOSGI subproject, >>>>> or can I write my question regarding CXF-DOSGI here? >>>>> >>>>> >>>>> >>>>> Thank you, >>>>> >>>>> Andr�s Liter >>>>> >>>>> >>>>> >>>>> -- >>>>> Glen Mazza >>>>> Talend - http://www.talend.com/ai >>>>> Blog - http://www.jroller.com/gmazza >>>>> Twitter - glenmazza >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >