OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-j message

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


Subject: Re: [sca-j] Issue 94


Meeraj,
The resolution to issue 94 sets a minimum requirement for all
SCA runtimes and all incorrect annotations.  It would be valid
for an SCA runtime to go beyond this minimum reguirement.  For
example, an SCA runtime could refuse to deploy any component
containing any incorrect annotations.

If there are specific incorrect annotation cases that cause such
severe problems that the component cannot be deployed (e.g., your
example of an incorrect @Service annotation), these specific cases
would not be covered by the generic words from issue 94 but would
require specific words in the spec section for that annotation.
These cases should be considered under a new issue or issues.

If the resolutions to these issues create specific words that
require SCA runtimes to impose more stringent correctness
requirements in some cases than the issue 94 resolution (such as
not allowing a component with certain errors to be deployed),
this would not conflict with the generic words that we adopted
for issue 94.

   Simon

Meeraj Kunnumpurath wrote:
> Hi,
> 
> The resolution on issue 94 was that an SCA runtime must not run a 
> component with incorrect usage of annotations, though it doesn't 
> necessarily mean the runtime doesn't deploy it. There could be 
> scenarios, where it is not possible to deploy a component because of the 
> use of incorrect annotations, say for example incorrect usage of 
> @Service annotation that makes it impossible to deduce a component's 
> service contract. I would assume, a "deployed" component would have been 
> properly introspected to identify its properties, services and 
> references. If incorrect usage of annotations cause any of the 
> above characteristics from being identified, there may be subsequent 
> implications like resolving wires from and to the component. So should 
> we allow the component to be deployed at all?
> 
> Also, another point of discussion was wires from a component to another 
> component that was deployed but faulty because of incorrect use of 
> annotations. If the reference on the first component is a required one 
> and there is no serviceable component that is qualified to be target for 
> the wire, should the first component be able to service any requests. 
> i.e, Should an unresolved wire result in a runtime 
> ServiceUnavailableException or in the whole component being unable to 
> service any user requests? I can see why someone would want to make the 
> component available in test environments, where an invocation path may 
> not include the unresolved reference, however, you wouldn't want this 
> happen in live scenarios.
> 
> Thanks
> Meeraj




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