GCH 2006.10.18 Here we throw a local exception. If we do not do this, objexp does not work properly any more. But things should be different. The problem is that I did not understand what happens upstream this call if I do not throw the exception. In practice the only bad effect of throwing the exception are error traces in the console that probably should not be there.
this method still returns null in case of errors and only throws AcsJNoPermissions or a couple of runtime exceptions. Needs to be refactored or, probably better, deprecated.
Now the Manager interface does not use exceptions in many methods when there is a failure, but it returns a nil object. This class will have to be refactored when the Manager implementation (only used internally) will be changed.
GCH 2006.10.11 notice that we can get a ComponentStatus != COMPONENT_ACTIVATED also if the component is properly returned. There is an incoherence here in the interfaces that shall be resolved. We have to cleanup here or go back to return a status to the caller. My point is: the caller is interested in more than just getting the component of an indication of failure if not? Is it interesting to know that the component was not activated, presumably because already active?
