Community
Participate
Working Groups
If we try to create a component configuration using a ComponentFactory.newInstance() and the activation of the new instance fails for some reason, the newInstance() method correctly throws a ComponentException but forgets to dispose the newly created configuration. This configuration may be activated later by SCR if it is still satisfied.
Created attachment 168371 [details] proposed patch
Too late for RC1, we need an additional reviewer for RC2 besides me.
John, I will review first and then can walk you through it for RC2.
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?
(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.
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?).
(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.
Lets defer to 3.6.1.
The patch is committed in HEAD and R3_6_maintenance branch.
