Bug 311579

Comment 1 Stoyan Boshev 2010-05-13 07:56:32 EDT

Created attachment 168371 [details]
proposed patch

Comment 2 Thomas Watson 2010-05-13 09:51:43 EDT

Too late for RC1, we need an additional reviewer for RC2 besides me.

Comment 3 Thomas Watson 2010-05-13 09:52:47 EDT

John, I will review first and then can walk you through it for RC2.

Comment 4 Thomas Watson 2010-05-13 15:10:39 EDT

Stoyan, can you explain the fix a bit?

I understand that we need to dispose the component configuration on exception if a component configuration got created.  But I don't understand the other part of the patch that is checking !isImmediate()

if (instance == null && !newSCP.isImmediate()) {
	// finally build an instance if not done yet
	instance = InstanceProcess.staticRef.buildComponent(
           null, newSCP, null, Activator.security);
}
if (instance == null) {
	//the instance could not be build because the component 
	//cannot be activated
	//throw exception to notify the user
	throw new ComponentException(Messages.COULD_NOT_CREATE_NEW_INSTANCE);
}

Is this needed for cases where the component IS immediate but there was some exception that got thrown while creating the instance "immediately" when we created the newSCP and we should not attempt to create the instance again?

Comment 5 Stoyan Boshev 2010-05-14 03:30:18 EDT

(In reply to comment #4)
> Is this needed for cases where the component IS immediate but there was some
> exception that got thrown while creating the instance "immediately" when we
> created the newSCP and we should not attempt to create the instance again?

Yes. This is exactly what is needed for.

Comment 6 Thomas Watson 2010-05-14 08:56:54 EDT

Stoyan, I am wondering if this could be deferred until 3.6.1.  The issue does not seem major.  Also, do you know if the same issue existed in 3.5 (is this a regression?).

Comment 7 Stoyan Boshev 2010-05-14 10:05:06 EDT

(In reply to comment #6)
> Stoyan, I am wondering if this could be deferred until 3.6.1.  The issue does
> not seem major.  Also, do you know if the same issue existed in 3.5 (is this a
> regression?).
I guess it could be deferred until 3.6.1. The issues existed in 3.5. It exists since the very beginning of the DS implementation.

Comment 8 Thomas Watson 2010-05-17 08:30:10 EDT

Lets defer to 3.6.1.

Comment 9 Stoyan Boshev 2010-07-08 02:58:38 EDT

The patch is committed in HEAD and R3_6_maintenance branch.