On Wed, May 20, 2009 at 5:16 PM, Anbu Ponniah (JIRA) <[email protected]> wrote: > Component and Services not recognized from application composite of EAR used > in impl.jee > ---------------------------------------------------------------------------------------- > > Key: TUSCANY-3052 > URL: https://issues.apache.org/jira/browse/TUSCANY-3052 > Project: Tuscany > Issue Type: Bug > Components: Java SCA Misc Implementation Extensions > Affects Versions: Java-SCA-1.5 > Reporter: Anbu Ponniah > Priority: Blocker > > > When a application composite is included in the EAR that is used as component > implementation via implementation.jee, the component and service(s) within it > are not honored during build, causing client invocations to encountered a > javax.naming.NameNotFoundException on the component name. Also the promoted > service does not automatically resolve its interface from the backing service > and requires explicit inclusion of the interface in the promote element. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
This is an interesting one. I played with the code and the problem is that, in the case where the EAR has an application composite, the EAR model is not itself a composite and hence the promotion builders don't do their thing and process the application composite properly. There is a relatively simply fix for this case which is to make JEEImplementation a composite and this seems to work with the quick test change I made. However this does beg the question of what we should now do when there is no application composite. The right answer I think is to maintain the code as it in that case as the implementation is a concrete component implementation from the SCA runtime's point of view. If we were to represent this case as a composite it would mean fluffing up composite services/references and a component and promoting the real services/references that we have found. However that means that, if we don't go the completely composite route, we end up with two model objects that get switched in and out depending on whether there is an application composite or not. Again not difficult but a little unusual. I need to think a little more about the non-application composite case but if anyone (Vamsi?) has thoughts in the mean time I'd be interested to hear. Simon
