RE: [sca-j] JAVA-53 - what happens if init() throws a runtime exception

Hi Jim,

Thanks for starting the discussion. I’ll add some more comments <mcc></mcc> inline.

Jim, on a slight tangent, are you planning to attend or dial into the face to face meeting next week?

Mark

From: Jim Marino [mailto:jim.marino@gmail.com]
Sent: 03 November 2008 16:31
To: Mark Combellack
Cc: sca-j@lists.oasis-open.org
Subject: Re: [sca-j] JAVA-53 - what happens if init() throws a runtime exception - a proposal

Hi Mark,

I figured I would comment inline here to start discussions.

Jim

On Nov 3, 2008, at 6:11 AM, Mark Combellack wrote:

Hi,

I’ve written the following proposal with the intent of starting discussions on this issue before the next SCA-J Face to face.

http://www.osoa.org/jira/browse/JAVA-53

@Init throws an exception

The @Init method will be called when the scope is started. This is typically in response to some other code wanting to use a new instance of the scope. Since the @Init method has failed, the Component will be in an invalid state. This needs to be signalled back to the calling code so the SCA Runtime should throw an Exception.

Proposed new wording:

Insert the following new paragraph before line 1275 in section 8.12 @Init

“If the method marked as @Init throws an exception, the SCA Runtime MUST catch this exception and MUST throw a ServiceRuntimeException to the calling code. The service operations MUST NOT be called on the Component.”

My view on @Init methods is that they are a contract between the implementation and the SCA container and do not involve the client. For example, eager initialized composite scoped components will have their init methods called when the composite context becomes active, which is before any client request. Consequently, in many cases there may not be any client to report an exception to and we should not make this requirement.

I do think it would be useful to describe what happens with respect to component state when an exception is raised by an @Init method. This would tie in with the issue of component lifecycle that has been brought up in the past.

<mcc>

I agree that the @Init method is the contract between the implementation and the SCA Runtime. However, the SCA Runtime typically calls the @Init method in response to an operation action triggered by client code.

Thanks for pointing out that @Init is also called for @EagerInit components and in this case, there is no client code. I had missed that.

</mcc>

@Destroy throws an exception

The @Destroy method will be called when the SCA Runtime is disposing of instances that it has finished with. There is not really any calling code that wants to continue using the instance so there seems little point in propagating the exception onwards. Therefore the SCA Runtime should handle the fact that the exception has been thrown but not prevent continued code execution.

Proposed new wording:

Insert the following new paragraph before line 1199 in section 8.9 @Destroy

“If the method marked as @Destroy throws an exception, the SCA Runtime MUST catch this exception but MUST NOT prevent continued code execution”

Again, I think we should define what happens to the component lifecycle and we shouldn't mandate that the runtime catches all exceptions. For example, the runtime probably should not catch errors such as OutOfMemoryError.

<mcc>

Interesting point about catching all exceptions… My intention was that if an exception is thrown in the @Destroy method, it should not prevent the application from continuing to run.

Perhaps some better wording might be:

“If the method marked as @Destroy throws an exception, the SCA Runtime SHOULD handle this exception but MUST NOT prevent continued code execution”

</mcc>

@EagerInit throws an exception

The @EagerInit method can only be applied to Composite Scoped Components. Therefore, it will only be called at deployment time. Since something has failed to initialise, the deployment should fail.

Proposed new wording:

Insert the following new paragraph after line 1219 in section 8.10 @EagerInit

“If the method marked as @EagerInit throws an exception, the SCA Runtime MUST fail the deployment of the SCA Contribution”

Unless it has changed, @EagerInit is only placed on types and is only valid for composite scoped components to denote that they should be initialized when the composite scope is activated. Also, while I agree it is valid behavior for a runtime to raise a deployment error if a composite scoped eager init implementation fails my own opinion would be to leave it to the runtime to decide what to do. For example, some runtimes may decide to continue deploying other deployables in a contribution and giving the administrator the option of retrying the errored component (maybe a resource was temporarily unavailable).

<mcc>

You are right, @EagerInit goes on the type and the @Init method is called.

Your point of “some runtimes may decide to continue deploying other deployables in a contribution and giving the administrator the option of retrying the errored component” is an interesting one. It has highlighted an assumption that I had made that a SCA Contribution is the smallest unit of deployment. From your statement, it sounds as though you would like to deploy something smaller than a SCA Contribution”. Am I correct in my assumption?

A slight tweak of the wording for this would be:

“If a Composite Scoped Implementation is marked with @EagerInit throws an exception from its @Init method, the SCA Runtime MUST fail the deployment of the SCA Contribution”

</mcc>

<mcc>

I was hoping that this issue would be relatively easy to resolve. However, I’m beginning agree with Jim that perhaps we need to resolve the lifecycle model first and then it should be easier to handle these exceptions. This is covered by http://www.osoa.org/jira/browse/JAVA-65

</mcc>

Thanks,

Mark

sca-j message