Re: [sca-assembly] [NEW ISSUE] Assembly specification unclear onContribution vs Deployment - when can errors in artifacts be reported?

[Simon Nash <oasis@cjnash.com>]

Jim Marino wrote:
> 
>>
>>
>>
>>
>>> > >> in sca-contribution.xml files within a Contribution. If an 
>>> artifact   > >> is deployed which has dependencies
>>> > >> on other artifacts, then those dependent artifacts are also 
>>> deployed.
>>> > >> When the SCA runtime has one or more deployable artifacts, the 
>>>   > >> runtime attempts to put those artifacts
>>> > >> and any artifacts they depend on into the Running state.  This 
>>> can   > >> fail due to errors in one or more of the artifacts
>>> > >> or the process can be delayed until all dependencies are available.
>>> > >> 11.3.1
>>> > >> Checking for errors in artifacts MUST NOT be done for artifacts 
>>> in   > >> the Installed state (ie where the artifacts are
>>> > >> simply part of installed contributions] {ASM120xx]
>>> > > This seems over-restrictive.  For example, what about malformed 
>>>   > > artifacts
>>> > > such as .composite files with XML syntax errors?  It might be 
>>> useful   > > to
>>> > > inform the user about such problems when the artifacts are   > > 
>>> installed, but
>>> > > the proposed rule would apparently prohibit an SCA runtime from even
>>> > > discovering these problems at installation time.  I think a 
>>> better   > > rule
>>> > > would be to allow such errors to be detected as long as this does not
>>> > > prevent any artifacts from being deployed.  For example: Any 
>>> errors in
>>> > > artifacts in the Installed state (i.e., where the artifacts are 
>>> part   > > of
>>> > > installed contributions and have not been deployed) MUST NOT 
>>> prevent   > > the
>>> > > SCA runtime from deploying artifacts.
>>> > >
>>> >
>>> > I agree with the general statement that runtimes should be allowed 
>>> to   > detect syntactic errors upfront since that is what users would 
>>> expect   > and want (i.e. contributions should not be installed if 
>>> they contain   > invalid artifacts). However, I don't follow the part 
>>> about not   > preventing artifacts from being deployed. Is it the 
>>> case that an error   > in some random contribution artifact A, does 
>>> not prevent a composite C   > in the same contribution from being 
>>> deployed? Many users would want to   > prevent that scenario. For 
>>> example, I would expect most users would   > only want "clean" 
>>> contributions in a production environment.
>>> >
>>> I think (I hope) what Simon means is that it's ok for a runtime to
>>> detect errors at install time (if possible and reasonable) as long as
>>> it's also possible to go ahead and deploy those artifacts even when
>>> the deployment engine knows there are errors in the artifacts.
>> In Jim's scenario above, if A has a known error but C does not have
>> a known error, I think compliant runtimes should be allowed to deploy
>> C if requested.  I am leaning towards going further and saying that
>> compliant runtimes should be required to deploy C if requested.
>>
> 
> I think requiring runtimes to deploy artifacts from contributions that 
> contain known errors would be very a bad thing to do. Here's why:
> 
> 1. Most users have stringent regulation over production environments and 
> do not permit application artifacts containing detectable errors to be 
> deployed. In most cases I have seen, this also goes for development 
> environments. For example, good development environments have mechanisms 
> in place to verify artifacts such as integration tests that fail a build 
> if an error is detected. This avoids accumulating broken artifacts and 
> cruft in source repositories.  Requiring a compliant runtime to make a 
> contribution containing detectable errors available in a domain would 
> negate being able to lock down a production or development environment 
> in this way.  
> 
> 2. The random artifact A could be exported by the contribution. It is 
> possible for a composite contained in another contribution to be 
> deployed at some later date that references artifact A. The error in A 
> will surface at that later point. I think most people would prefer the 
> error to be raised at the time the contribution containing A was 
> "installed" in the domain. 
> 
> 3. It's very difficult to calculate with absolute certainty that 
> contribution C does not indirectly reference A, particularly if A can be 
> located dynamically in code. Providing fail-fast behavior avoids runtime 
> errors from surfacing where they can cause more damage. 
> 
> I do agree compliant runtimes should be allowed to deploy contributions 
> containing invalid artifacts. However, they should not be required to do 
> so.  
> 
>  
> 
>> A more interesting question is if another composite B has a known
>> error, should compliant runtimes be required or allowed to deploy B
>> if requested?  I think this depends on the kind of error.  Some
>> errors might be severe enough to prevent the deployment from
>> succeeding.  Some errors might be less severe so that it would be
>> possible to allow deployment, even though some of the resulting
>> components would not be executable.  The SCA specs should define
>> which errors fall into which of these categories.
>>
> 
> How can a runtime be certain an error in B will not cause a serious 
> problem if B is deployed? Can you provide examples of such errors? 
> 
> Jim
> 
An example would be a misplaced Java annotation.  In this case, the
JavaCAA spec says that the SCA runtime MUST NOT run the component
which uses the invalid implementation code.  This implies to me that
other components in the same contribution can be deployed and run.

   Simon