[
https://issues.apache.org/jira/browse/TUSCANY-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718974#action_12718974
]
Anbu Ponniah commented on TUSCANY-3097:
---------------------------------------
Either avoid processing additional composites or an SPI/extensionpoint must be
used to acquire the right module classloader to resolve those classes.
> 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
>
> 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.
