tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws (JIRA)" <...@tuscany.apache.org>
Subject [jira] [Assigned] (TUSCANY-3907) ASM90005 error when a deployable composite is used as the implementation of another deployable composite
Date Thu, 04 Aug 2011 11:21:27 GMT

     [ https://issues.apache.org/jira/browse/TUSCANY-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Simon Laws reassigned TUSCANY-3907:
-----------------------------------

    Assignee: Simon Laws

> 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

        

Mime
View raw message