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 2008/04/02 21:19:24 UTC

[jira] Created: (TUSCANY-2189) Problems building the wire for a service implemented by Composite

Problems building the wire for a service implemented by Composite
-----------------------------------------------------------------

                 Key: TUSCANY-2189
                 URL: https://issues.apache.org/jira/browse/TUSCANY-2189
             Project: Tuscany
          Issue Type: Bug
          Components: Java SCA Core Runtime
            Reporter: Scott Kurz
             Fix For: Java-SCA-Next
         Attachments: test.2189.jar

Take something like this:

<composite name="OuterComposite">
    <component name="OuterCalculatorComponent">
      <service name="OuterCalculatorService">
        <binding.ws wsdlElement="...."/>
      </service>
      <implementation.composite name="calc:InnerComposite"/>
    </component>
</composite>


<composite name="InnerComposite">
    <service name="OuterCalculatorService" promote="CalculatorComponent/CalculatorService"/>

    <component name="CalculatorComponent">
        <service name="CalculatorService"/>
        <implementation.java class="calculator.CalculatorServiceImpl"/>
    </component>
</composite>


------------------------------------------

I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget
with a Composite impl.     This causes a problem when RuntimeWireImpl.initInvocationChains()  calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain.

Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services?

I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet.

In the cases it does work, with binding.sca, we must somehow be connected to the "inner"-layer wire from the component in the nested Composite.


-- 
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-2189) Problems building the wire for a service implemented by Composite

Posted by "Raymond Feng (JIRA)" <tu...@ws.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585707#action_12585707 ] 

Raymond Feng commented on TUSCANY-2189:
---------------------------------------

I'm getting the NPE as the implemention invoker is in the invocation chain:

Caused by: java.lang.NullPointerException
	at org.apache.tuscany.sca.core.databinding.wire.DataTransformationInterceptor.invoke(DataTransformationInterceptor.java:78)
	at org.apache.tuscany.sca.core.invocation.RuntimeWireInvoker.invoke(RuntimeWireInvoker.java:110)
	... 29 more

> Problems building the wire for a service implemented by Composite
> -----------------------------------------------------------------
>
>                 Key: TUSCANY-2189
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2189
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Core Runtime
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>         Attachments: test.2189.jar
>
>
> Take something like this:
> <composite name="OuterComposite">
>     <component name="OuterCalculatorComponent">
>       <service name="OuterCalculatorService">
>         <binding.ws wsdlElement="...."/>
>       </service>
>       <implementation.composite name="calc:InnerComposite"/>
>     </component>
> </composite>
> <composite name="InnerComposite">
>     <service name="OuterCalculatorService" promote="CalculatorComponent/CalculatorService"/>
>     <component name="CalculatorComponent">
>         <service name="CalculatorService"/>
>         <implementation.java class="calculator.CalculatorServiceImpl"/>
>     </component>
> </composite>
> ------------------------------------------
> I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget
> with a Composite impl.     This causes a problem when RuntimeWireImpl.initInvocationChains()  calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain.
> Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services?
> I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet.
> In the cases it does work, with binding.sca, we must somehow be connected to the "inner"-layer wire from the component in the nested Composite.

-- 
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-2189) Problems building the wire for a service implemented by Composite

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

Raymond Feng reassigned TUSCANY-2189:
-------------------------------------

    Assignee: Raymond Feng

> Problems building the wire for a service implemented by Composite
> -----------------------------------------------------------------
>
>                 Key: TUSCANY-2189
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2189
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Core Runtime
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>         Attachments: test.2189.jar
>
>
> Take something like this:
> <composite name="OuterComposite">
>     <component name="OuterCalculatorComponent">
>       <service name="OuterCalculatorService">
>         <binding.ws wsdlElement="...."/>
>       </service>
>       <implementation.composite name="calc:InnerComposite"/>
>     </component>
> </composite>
> <composite name="InnerComposite">
>     <service name="OuterCalculatorService" promote="CalculatorComponent/CalculatorService"/>
>     <component name="CalculatorComponent">
>         <service name="CalculatorService"/>
>         <implementation.java class="calculator.CalculatorServiceImpl"/>
>     </component>
> </composite>
> ------------------------------------------
> I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget
> with a Composite impl.     This causes a problem when RuntimeWireImpl.initInvocationChains()  calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain.
> Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services?
> I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet.
> In the cases it does work, with binding.sca, we must somehow be connected to the "inner"-layer wire from the component in the nested Composite.

-- 
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-2189) Problems building the wire for a service implemented by Composite

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

Scott Kurz updated TUSCANY-2189:
--------------------------------

    Attachment: test.2189.jar

Sorry this doesn't exactly match the SCDL pasted it the JIRA text but it's the same idea

> Problems building the wire for a service implemented by Composite
> -----------------------------------------------------------------
>
>                 Key: TUSCANY-2189
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2189
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Core Runtime
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>         Attachments: test.2189.jar
>
>
> Take something like this:
> <composite name="OuterComposite">
>     <component name="OuterCalculatorComponent">
>       <service name="OuterCalculatorService">
>         <binding.ws wsdlElement="...."/>
>       </service>
>       <implementation.composite name="calc:InnerComposite"/>
>     </component>
> </composite>
> <composite name="InnerComposite">
>     <service name="OuterCalculatorService" promote="CalculatorComponent/CalculatorService"/>
>     <component name="CalculatorComponent">
>         <service name="CalculatorService"/>
>         <implementation.java class="calculator.CalculatorServiceImpl"/>
>     </component>
> </composite>
> ------------------------------------------
> I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget
> with a Composite impl.     This causes a problem when RuntimeWireImpl.initInvocationChains()  calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain.
> Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services?
> I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet.
> In the cases it does work, with binding.sca, we must somehow be connected to the "inner"-layer wire from the component in the nested Composite.

-- 
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-2189) Problems building the wire for a service implemented by Composite

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

Raymond Feng resolved TUSCANY-2189.
-----------------------------------

    Resolution: Fixed

Fixed under r644934.

> Problems building the wire for a service implemented by Composite
> -----------------------------------------------------------------
>
>                 Key: TUSCANY-2189
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2189
>             Project: Tuscany
>          Issue Type: Bug
>          Components: Java SCA Core Runtime
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>         Attachments: test.2189.jar
>
>
> Take something like this:
> <composite name="OuterComposite">
>     <component name="OuterCalculatorComponent">
>       <service name="OuterCalculatorService">
>         <binding.ws wsdlElement="...."/>
>       </service>
>       <implementation.composite name="calc:InnerComposite"/>
>     </component>
> </composite>
> <composite name="InnerComposite">
>     <service name="OuterCalculatorService" promote="CalculatorComponent/CalculatorService"/>
>     <component name="CalculatorComponent">
>         <service name="CalculatorService"/>
>         <implementation.java class="calculator.CalculatorServiceImpl"/>
>     </component>
> </composite>
> ------------------------------------------
> I'm noticing that the wireTarget that ends up getting built for the wire from the OuterCalculatorService service-side WS binding into the impl has a wireTarget
> with a Composite impl.     This causes a problem when RuntimeWireImpl.initInvocationChains()  calls addImplementationInterceptor(); we need a non-composite impl (Java impl) at this point to set up the interceptor on the chain.
> Might it be appropriate to do something like what's done in CompositeWireBuilderImpl.connectComponentReferences(), where we drill down recursively to unwrap the Composite impl services?
> I looked at the 'recursive' itest and didn't see anything besides binding.sca... so maybe we don't think we've gotten to this yet.
> In the cases it does work, with binding.sca, we must somehow be connected to the "inner"-layer wire from the component in the nested Composite.

-- 
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