You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <tu...@ws.apache.org> on 2007/09/10 17:30:29 UTC

[jira] Created: (TUSCANY-1679) PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs

PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs
------------------------------------------------------------------------------------------------------------

                 Key: TUSCANY-1679
                 URL: https://issues.apache.org/jira/browse/TUSCANY-1679
             Project: Tuscany
          Issue Type: Bug
          Components: Java SCA Data Binding Runtime
    Affects Versions: Java-SCA-1.0
            Reporter: Scott Kurz


First, the easier issue:   PBVInvoker doesn't handle faults.    For a checked/business exc on a remotable intf,  wouldn't we want the exc to get copied too?   We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right?   

Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ).   While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above).

I might, for example, want to use a client-side classloader to deserialize the copied objects into.     Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader.

I'm not sure how to fix this...  

Note this JIRA, as I could imagine the fixes to these two issues intersecting:
https://issues.apache.org/jira/browse/TUSCANY-1678



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Resolved: (TUSCANY-1679) PBVInvoker doesn't handle checked/business excs

Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raymond Feng resolved TUSCANY-1679.
-----------------------------------

    Resolution: Fixed

A fix is checked in under r630333.

> PBVInvoker doesn't handle checked/business excs
> -----------------------------------------------
>
>                 Key: TUSCANY-1679
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1679
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Data Binding Runtime
>    Affects Versions: Java-SCA-1.0
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>
> First, the easier issue:   PBVInvoker doesn't handle faults.    For a checked/business exc on a remotable intf,  wouldn't we want the exc to get copied too?   We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right?   
> Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ).   While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above).
> I might, for example, want to use a client-side classloader to deserialize the copied objects into.     Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader.
> I'm not sure how to fix this...  
> Note this JIRA, as I could imagine the fixes to these two issues intersecting:
> https://issues.apache.org/jira/browse/TUSCANY-1678

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Updated: (TUSCANY-1679) PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs

Posted by "ant elder (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ant elder updated TUSCANY-1679:
-------------------------------

    Fix Version/s: Java-SCA-Next

> PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1679
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1679
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Data Binding Runtime
>    Affects Versions: Java-SCA-1.0
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>
> First, the easier issue:   PBVInvoker doesn't handle faults.    For a checked/business exc on a remotable intf,  wouldn't we want the exc to get copied too?   We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right?   
> Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ).   While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above).
> I might, for example, want to use a client-side classloader to deserialize the copied objects into.     Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader.
> I'm not sure how to fix this...  
> Note this JIRA, as I could imagine the fixes to these two issues intersecting:
> https://issues.apache.org/jira/browse/TUSCANY-1678

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Assigned: (TUSCANY-1679) PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs

Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raymond Feng reassigned TUSCANY-1679:
-------------------------------------

    Assignee: Raymond Feng

> PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1679
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1679
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Data Binding Runtime
>    Affects Versions: Java-SCA-1.0
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>
> First, the easier issue:   PBVInvoker doesn't handle faults.    For a checked/business exc on a remotable intf,  wouldn't we want the exc to get copied too?   We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right?   
> Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ).   While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above).
> I might, for example, want to use a client-side classloader to deserialize the copied objects into.     Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader.
> I'm not sure how to fix this...  
> Note this JIRA, as I could imagine the fixes to these two issues intersecting:
> https://issues.apache.org/jira/browse/TUSCANY-1678

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Updated: (TUSCANY-1679) PBVInvoker doesn't handle checked/business excs

Posted by "Scott Kurz (JIRA)" <tu...@ws.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Kurz updated TUSCANY-1679:
--------------------------------

    Summary: PBVInvoker doesn't handle checked/business excs  (was: PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs)

> PBVInvoker doesn't handle checked/business excs
> -----------------------------------------------
>
>                 Key: TUSCANY-1679
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1679
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Data Binding Runtime
>    Affects Versions: Java-SCA-1.0
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>
> First, the easier issue:   PBVInvoker doesn't handle faults.    For a checked/business exc on a remotable intf,  wouldn't we want the exc to get copied too?   We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right?   
> Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ).   While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above).
> I might, for example, want to use a client-side classloader to deserialize the copied objects into.     Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader.
> I'm not sure how to fix this...  
> Note this JIRA, as I could imagine the fixes to these two issues intersecting:
> https://issues.apache.org/jira/browse/TUSCANY-1678

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org


[jira] Commented: (TUSCANY-1679) PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs

Posted by "Scott Kurz (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570742#action_12570742 ] 

Scott Kurz commented on TUSCANY-1679:
-------------------------------------

The implications of some other discussions we've had on the list suggest that it would be the binding's job to switch classloaders in a case like the one I had in mind.   That is, if the client uses CL 1 and the service impl uses CL 2, the binding should not rely on the PBVInterceptor to switch the data into the correct CL.

So I take back stating that as a problem.

I'll see if I can rename the JIRA to focus on the need to copy faults.  

> PBVInvoker always uses service-side classloader to deserialize ... also doesn't handle checked/business excs
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-1679
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-1679
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Data Binding Runtime
>    Affects Versions: Java-SCA-1.0
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>
> First, the easier issue:   PBVInvoker doesn't handle faults.    For a checked/business exc on a remotable intf,  wouldn't we want the exc to get copied too?   We wouldn't want some piece of data making its way into the exception to end up unexpectedly modified, right?   
> Second, I have the problem that the service-side classloader is used to do the copy (e.g.. to do the deserialize in JavaBeansDataBinding.copy() ).   While this is what I want when copying the inputs, it is not necessarily what I want when copying the outputs (or the faults which I want to copy above).
> I might, for example, want to use a client-side classloader to deserialize the copied objects into.     Maybe it wouldn't matter if I was going to do a data transform anyway, but if my outputs/faults are going to go back to the client untransformed, then I'm going to get a ClassCastExc if they're not in the client classloader.
> I'm not sure how to fix this...  
> Note this JIRA, as I could imagine the fixes to these two issues intersecting:
> https://issues.apache.org/jira/browse/TUSCANY-1678

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org