[
https://issues.apache.org/jira/browse/TUSCANY-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simon Laws resolved TUSCANY-3097.
---------------------------------
Resolution: Fixed
Fix Version/s: Java-SCA-Next
Test checked in at r787603 and change checked in at r787604 to stop nested
application composites from being processed.
> External ear contribution processes all composite files in a Java EE
> Application and its modules.
> -------------------------------------------------------------------------------------------------
>
> Key: TUSCANY-3097
> URL: https://issues.apache.org/jira/browse/TUSCANY-3097
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Misc Implementation Extensions
> Affects Versions: Java-SCA-1.5
> Environment: All
> Reporter: Anbu Ponniah
> Assignee: Simon Laws
> Fix For: Java-SCA-Next
>
>
> When a enterprise application archive is used as a component implementation,
> the ear is contributed to SCA domain. While the SCA-JEE integration
> specification says only the files named application.composite,
> ejb-jar.composite and web.composite will be honored, the contribution service
> is trying to resolve all .composite files.
> In runtimes which support SCA WARs as contribution, this causes
> ClassNotFoundException as CompositeProcessor.resolve() is unable to locate
> the classes associated with services/references in those composites. This
> limits the re-use of JEE modules if they already are contributions.
> When enterprise archives (or Java EE applications) are contributed, would it
> be feasible to not process composite files other than the EAR level
> META-INF/application.composite, module level ejb-jar.composite &
> web.composite alone be processed?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
