OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified


Title: Message

 

The key concern here seems to be w.r.t. performance.  In my opinion, if there is only one definition of an artifact within a contribution (as I think _should_ be the case), then it should not be necessary for a human to point at it.  Searching is one of the things that computers are good at.  Quite a large body of data can be searched in a very short time.

 

Michael

 


From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Monday, October 08, 2007 9:48 AM
To: sca-assembly@lists.oasis-open.org
Subject: [sca-assembly] ISSUE 8: SCDL artifact resolution underspecified

 

-----Original Message-----
From: Blohm, Henning [mailto:henning.blohm@sap.com]
Sent: Friday, October 05, 2007 8:01 PM
To: sca-assembly@lists.oasis-open.org
Subject: [sca-assembly] NEW ISSUE: SCDL artifact resolution underspecified

TARGET: Assembly specification, section "SCA Artifact Resolution" (1.10.2.1)

DESCRIPTION: Resolution of SCDL artifacts is currently specified only as far as cross-contribution export/import is concerned. As far as QName to SCDL artifact resolution within a contribution is concerned the specification does not say what is the exact scope of such resolution nor how to extend/modify that scope.

Choosing the whole contribution as resolution scope may be prohibitive considering that contributions may be large and distributed (across different execution environments) so that deep traversal of all contribution resources for scdl artifacts may easily introduce a severe performance problem and easily get out of control from a developer perspective.

As an analogy, suppose the group would perceive a contribution format that would encompass java ee applications together with OSGi bundles. Chosing a contribution wide resolution scope would correspond to chosing a contribution wide class loading scheme (which I assume all agree is highly undesirable).

On the other hand, if the resolution scope is not the whole contribution, it is necessary to allow specification of locations within a contribution.

PROPOSAL:

- use sca-contribution / import as a means to implement a namespace -> location mapping also for contribution-local artifacts

- support an scaLocation attribute to be used for namespace -> location mapping from within SCDL artifacts



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]