Hi Simon,
I guess what I meant by “the runtime
silently ignoring this issue” is how the user perceives what happens.
From your updated wording, it is clear
that the SCA Runtime would not invoke the method as it is invalid. I guess what
I am hinting at is that a poorly implemented SCA Runtime could be specification
compliant as it does not invoke the method but does not log an error since the
specification does not mandate that it does log an error. Therefore, from a
user’s perspective, this SCA Runtime is ignoring the error.
Having said that, a good implementation of
a SCA Runtime would not invoke the operation but it would also log an error in
some way so that the user has some feedback about the error.
Simon said:
“I
think in general the specs should be fairly flexible about how and when errors
are reported, though in some cases it may be appropriate to require them to be
reported (or not reported) at deployment time. (I wasn't proposing
specifying that here.) However, I think it's important for the spec to
say whether the @Init method MAY/MUST/SHOULD (NOT) be called in this error
case, as this changes the semantics of the component implementation.
“
I think your words above are the counter argument
to my point. We could make the specification be very specific about when and
how it logs errors. However, this would make the specification rather
cumbersome.
Perhaps, as you say, this is just one of
those cases where the specification is fairly flexible about how and when
errors are reported. Good SCA Runtimes will do it well and poor ones will not.
I think I have now convinced myself that I
am happy with your wording.
Thanks,
Mark
Mark Combellack| Software Developer| Avaya | Eastern Business Park | St. Mellons | Cardiff |
CF3 5EA | Voice: +44 (0) 29 2081 7624 | mcombellack@avaya.com
From:
Simon Nash [mailto:NASH@uk.ibm.com]
Sent: 08 May 2008 16:47
To: sca-j@lists.oasis-open.org
Subject: RE: [sca-j] NEW ISSUE:
Runtime behaviour not specified for incorrect @Init/@Destroy signature
Mark,
Please
can you clarify what you mean by "the runtime silently ignoring the
issue". Does this mean that the runtime would just not call the
@Init method without producing any kind of error message?
I'd
like to clarify that this this is not what I intended by my proposal. I
was intending to propose that an error would be reported, and the method would
not be called. If the words in my proposal don't clearly state this, they
should be changed. I thought the need for an error message was implied by
the MUSTs in "The method MUST have a void return value and no arguments.
The
annotated method MUST be public." There's nothing that says whether
the error would be reported at deployment time or runtime, so I'd take that as
allowing runtime implementations to make a choice.
I
think in general the specs should be fairly flexible about how and when errors
are reported, though in some cases it may be appropriate to require them to be
reported (or not reported) at deployment time. (I wasn't proposing
specifying that here.) However, I think it's important for the spec to
say whether the @Init method MAY/MUST/SHOULD (NOT) be called in this error
case, as this changes the semantics of the component implementation.
Simon
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM
Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
"Mark Combellack"
<mcombellack@avaya.com>
08/05/2008 15:54
|
To
|
Simon Nash/UK/IBM@IBMGB,
<sca-j@lists.oasis-open.org>
|
cc
|
|
Subject
|
RE: [sca-j] NEW ISSUE: Runtime behaviour not
specified for incorrect @Init/@Destroy signature
|
|
Hi Simon,
A quick question on usability from the user’s point of
view for this change.
If, as a user, I use @Init on a method that does not quite
match the spec – e.g. returns a value rather than of type void –
the runtime silently ignoring this issue will make it harder for me as the user
to identify what went wrong.
Perhaps the error should not be silently ignored?
There are a couple of options on how to help the user
diagnose these problems. These include:
- Make the runtime log
the error at deployment time so the user can at least see the error in the
logs – should the specification dictate this?
- Fail deployment
– I feel this will not be a popular option
- Say that it is not a
runtime issue. It is the responsibility of the user or of the tools that
they use to ensure that they don’t do this.
- Not worry about the
ease of use for the end user in the Specification. It would be the
responsibility of the SCA Runtime implementation to assist the user.
Any thoughts?
Thanks,
Mark
Mark Combellack| Software Developer| Avaya | Eastern Business
Park | St. Mellons | Cardiff | CF3 5EA | Voice: +44 (0) 29 2081 7624 | mcombellack@avaya.com
From: Simon Nash
[mailto:NASH@uk.ibm.com]
Sent: 08 May 2008 14:59
To: sca-j@lists.oasis-open.org
Subject: [sca-j] NEW ISSUE: Runtime behaviour not specified for
incorrect @Init/@Destroy signature
RAISER: Simon Nash
TARGET: SCA Java Common Annotations and APIs
DESCRIPTION:
The Java Common Annotations and APIs spec
says that @Init and @Destroy methods must be public, with a void return type
and no arguments. It does not specify the runtime behaviour if this rule
is violated. The specification should say whether or not the SCA runtime
will invoke methods annotated with @Init and @Destroy that don't conform to the
specification rules.
PROPOSAL:
The SCA runtime MUST invoke these methods if they conform to the stated rules,
and MUST NOT invoke these methods if they don't conform to these rules.
Replace the following paragraph in section 8.10 of the 2/28 JavaCAA spec draft:
1116 The @Init annotation type is used to annotate a Java class
method that is called when the scope
1117 defined for the local service implemented by the class starts.
The method must have a void return
1118 value and no arguments. The annotated method must be
public. The annotated method is called
1119 after all property and reference injection is complete.
by the following text:
The @Init annotation is used to denote a Java class method that is called when
the scope defined for the
local service implemented by the class starts. The method MUST have a void
return value and no arguments.
The annotated method MUST be public.
If there is a method that matches these criteria, the SCA runtime MUST call the
annotated method after all
property and reference injection is complete. A method annotated with
@Init that does not match these
criteria MUST NOT be called by the SCA runtime.
Replace the following paragraph in section 8.7 of the 2/28 JavaCAA spec draft:
1054 The @Destroy annotation type is used to annotate a Java
class method that will be called when
1055 the scope defined for the local service implemented by the
class ends. The method must have a
1056 void return value and no arguments. The annotated method
must be public.
by the following text:
The @Destroy annotation is used to denote a Java class method that is called
when the scope defined for the
local service implemented by the class ends. The method MUST have a void return
value and no arguments.
The annotated method MUST be public.
If there is a method that matches these criteria, the SCA runtime MUST call the
annotated method. A method
annotated with @Destroy that does not match these criteria MUST NOT be called
by the SCA runtime.
Simon C. Nash, IBM Distinguished Engineer
Member of the IBM
Academy of Technology
Tel. +44-1962-815156 Fax +44-1962-818999
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
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