Jim,
I am concerned that the word "deploy"
is being used loosely here.
I have tried to distinguish between
the states
"Installed"
"Deployed"
"Running"
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:
From:
Jim Marino <>
To:
OASIS Assembly <>
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.
Jim
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
