[jira] [Issue Comment Edited] (TUSCANY-3907) ASM90005 error when a deployable composite is used as the implementation of another deployable composite

["Greg Dritschler (JIRA)" <de...@tuscany.apache.org>]

    [ https://issues.apache.org/jira/browse/TUSCANY-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079375#comment-13079375 ] 

Greg Dritschler edited comment on TUSCANY-3907 at 8/4/11 1:37 PM:
------------------------------------------------------------------

Composites are being cloned so this alleviates some of my concerns about the builder reprocessing the previously deployed composite.  However it appears to me that ServiceImpl doesn't clone the binding elements.  Maybe the solution is to clone the bindings and clear the @uri attribute. (I'm not sure it's safe to just change ServiceImpl.clone() to do this.  I don't know if anyone could be cloning services and assuming the bindings remain intact.) 

      was (Author: gregdritschler):
    Composites are being cloned so this alleviates some of my concerns about the builder reprocessing the previously deployed composite.  However it appears to me that ServiceImpl doesn't clone the binding elements.  Maybe the solution is to clone the bindings and clear the @uri attribution. (I'm not sure it's safe to just change ServiceImpl.clone() to do this.  I don't know if anyone could be cloning services and assuming the bindings remain intact.) 
  
> ASM90005 error when a deployable composite is used as the implementation of another deployable composite
> --------------------------------------------------------------------------------------------------------
>
>                 Key: TUSCANY-3907
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-3907
>             Project: Tuscany
>          Issue Type: Bug
>    Affects Versions: Java-SCA-2.0
>            Reporter: Greg Dritschler
>            Assignee: Simon Laws
>            Priority: Minor
>         Attachments: TUSCANY-3907-testbinaries.zip, TUSCANY-3907-testcase.patch
>
>
> I have attached a test case with 2 contributions.
> Contribution export1 contains a deployable composite with a java component.
> Contribution import1 contains a deployable composite with a component that uses export1's composite as its implementation.
> This test fails with message
> SEVERE: [ASM90005] The SCA binding Helloworld on component HelloworldImplJavaComponent service Helloworld should not have a URI and the URI is currently set to /HelloworldImplJavaComponent/Helloworld
> Here is what is happening:
> 1) Contribution export1 is built.  BindingURIBuilderImpl computes and sets the binding uri in its component services.
> 2) Contribution import1 is built.  ComponentBuilderImpl processes export1's composite again, sees the binding uri is set, and issues the error because binding.sca does not permit external specification of @uri.
> So the code is confusing a runtime update to the model for an external error.
> This may be the tip of the iceberg of what could go wrong.  export1 is deployed and could be active.
> If subsequent contributions are going to reprocess export1, a lot of care needs to be taken to not modify the model in a way that breaks active operations.  It looks to me like the builder code thinks it has free reign to rebuild export1.
> In other words, this validation error may be the least of the problem.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira