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] [NEW ISSUE] Assembly specification unclear onContribution vs Deployment - when can errors in artifacts be reported?


I am concerned that the word "deploy" is being used loosely here.

I have tried to distinguish between the states


and my issue is about what it is valid for a runtime to do with artifacts in each of these states.

I *THINK* you are arguing that it should be *ALLOWABLE* for an SCA runtime to check artifacts
in a Contribution as it is installed - and refuse to install the contribution if it finds artifacts with errors.

I am arguing the opposite - ie it should be REQUIRED that an SCA runtime installs a contribution
even if it contains artifacts with errors.  I have no problem with a runtime that reports the errors - but
I do have a problem with one that refuses to install the contribution.

One big concern that I have over this install error reporting process is any hint that errors involving multiple
artifacts will be reported (eg involving comparison of a component declaration in a composite with
the componentType of the artifact providing the implementation).  I don't think that this should be allowed.

All such errors are game for deployment time, but not before.

I note that the error checking process will have to be done at deployment time anyway, so doing some
checking ahead of time will probably not save very much.

Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

From: Jim Marino <jim.marino@gmail.com>
To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date: 01/06/2009 19:42
Subject: Re: [sca-assembly] [NEW ISSUE] Assembly specification unclear on Contribution vs Deployment - when can errors in artifacts be reported?

Comment below.


On May 28, 2009, at 1:12 PM, David Booz wrote:

I do not intend these words to eliminate the possibility of one action
which does both install and deploy.

> >> 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.

I agree with you Jim, that in a production environment one would not
want to allow deployment of artifacts with any known errors, but
in development environments it it often useful to allow this so that
testing can proceed.  Of course, if the runtime stumbles across one
of these errors, it should not run the component.  We have language
to this effect already in the spec.

I can see someone maybe wanting to deploy a contribution containing errors in a test environment but even then I think many people would want the deployment process to fail. In any event, my original point was we shouldn't require a runtime to support deploying contributions containing errors, although this behavior should be allowed. So I think we agree.

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

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