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