[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?
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? |
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]