RE: [sca-assembly] ISSUE 24: textual sca:include not sufficient

["Blohm, Henning" <henning.blohm@sap.com>]

Hi Jim,

  you wrote

<quote>
"in the resolution scope of the included composite" does that apply  
to wires and autowire as well? I think the scope of the resolution  
should be the target composite, particularly at the domain level.
</quote>

The scope of resolution of the wire target <em>within the SCA model</em>
should indeed be target composite, the resolution scope of artifacts
required to evaluate the included composite, i.e. XSDs, Java classes,
.bpel, ... should be the resolution scope of the included composite
(e.g. the contribution or more specifically the bundle+classloader
[OSGi], the META-INF+more [EAR],...).

Sorry for the late reply. 

Thanks,
  Henning



-----Original Message-----
From: Jim Marino [mailto:jmarino@bea.com] 
Sent: Dienstag, 13. November 2007 21:51
To: Scott Vorthmann
Cc: OASIS Assembly
Subject: Re: [sca-assembly] ISSUE 24: textual sca:include not sufficient


On Nov 11, 2007, at 10:02 AM, Scott Vorthmann wrote:

>
> http://www.osoa.org/jira/browse/ASSEMBLY-24
>
> On Nov 7, 2007, at 6:54 AM, Blohm, Henning wrote:
>
>> TARGET:
>>
>> Assembly Specification, section "Using Composites through Inclusion"
>>
>> DESCRIPTION:
>>
>> SCA's include mechanism for SCDL artefacts is described as a  
>> textual inlining of the included composite's body into the  
>> including composite.
>>
>> That leads to a set of problems:
>>
>> a) XML name spaces are ignored
>>
>> An included composite may make use of namespace prefices that  
>> become meaningless (or change meaning) when considered within the  
>> including composite.
>>
>> b) artefact resolution moves to the includer
>>
>> On the one hand SCDL artefacts may be re-used across contributions  
>> (see SCA deployment) and SCA's domain concept relies on inclusion  
>> to implement a cross-contribution assembly mechanism, on the other  
>> hand many SCDL declarations refer to artefacts that may not be  
>> resolvable within the includer's resolution scope.
>>
>> For example, implementation type declarations such as  
>> <implementation.java/>, <implementation.bpel/>,  
>> <implementation.spring/> refer to artefacts such as Java classes,  
>> bpel process descriptions, and application context XML files, that  
>> may not resolvable across contributions and much less on the domain.
>>
>> PROPOSAL:
>>
>> Describe sca:include over the assembly model of SCA rather than a  
>> textual operation - similarly to how <implementation.composite/>  
>> is described today.
>>
>> For example (simplified and using terminology that requires more  
>> explanation)
>>
>> All services, references, properties, and component elements of  
>> the included composite lead to services, references, properties,  
>> and component elements by the same name (resp.) in the including  
>> composite. Any other content of the included composite is ignored.  
>> Resulting component elements are opaque to the includer, that is,  
>> all artefact resolution required to evaluate the component  
>> declaration must be performed in the resolution scope of the  
>> included composite. This algorithm is recursively applied in a  
>> depth-first traversal.
>>
>>
>
"in the resolution scope of the included composite" does that apply  
to wires and autowire as well? I think the scope of the resolution  
should be the target composite, particularly at the domain level.

Jim


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php