Re: CXF-DOSGI subproject ML?

Tue, 27 Sep 2011 07:36:33 -0700

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 Beryozkin<[email protected]>wrote:


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<[email protected]**

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<[email protected]
<mailto:[email protected]>>   wrote:

    Hi

    Here is the way it's handled on the client side:

    
http://svn.apache.org/repos/__****asf/cxf/dosgi/trunk/dsw/cxf-**__**<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<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-****<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<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/**__**<http://svn.apache.org/repos/__**asf/cxf/dosgi/trunk/samples/__**>
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<http://svn.apache.org/repos/__asf/cxf/dosgi/trunk/samples/__greeter/client/src/main/java/__org/apache/cxf/dosgi/samples/__greeter/client/Activator.java>



    
<http://svn.apache.org/repos/****asf/cxf/dosgi/trunk/samples/****<http://svn.apache.org/repos/**asf/cxf/dosgi/trunk/samples/**>
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<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<[email protected]
        <mailto:[email protected]>>    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








































					Reply via email to