Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 114605

Summary: support disabling auto-activation temporarily
Product: [Eclipse Project] Equinox Reporter: Rafael Chaves <eclipse>
Component: FrameworkAssignee: equinox.framework-inbox <equinox.framework-inbox>
Status: RESOLVED DUPLICATE QA Contact:
Severity: enhancement    
Priority: P3    
Version: 3.2   
Target Milestone: 3.3   
Hardware: PC   
OS: All   
Whiteboard:

Description Rafael Chaves CLA 2005-11-01 14:36:08 EST 
Support disabling auto-activation temporarily. This could be supported in the
form of an operation (a runnable). In the context of that operation, if a class
from a plug-in that is not active yet is to be loaded, and that would cause
auto-activation to kick in, don't load the class, just fail.

This would work well with the Eclipse-AutoStart header. 

Use cases:
- content type describers are all instantiated when the content type registry is
created. Content type providers are warned that content describers should not
cause auto-activation (through the use of Eclipse-AutoStart), but that is not
enforced.

- the adapter manager ignores factories for plug-ins that are not active. That
restriction could be changed to "adapter factories that would trigger
auto-activation will be ignored". 

I believe this could be used in the context of other extension points as well.

I understand that this mechanism would not help if the work that would cause
auto-activation ends up being done in a different thread.
Comment 1 Jeff McAffer CLA 2005-11-08 22:47:54 EST 
An interesting proposal.  Would it be bad for people to suddnely start getting 
ClassNotFoundErrors?
Comment 2 Thomas Watson CLA 2005-11-09 09:29:02 EST 
I'm not sure I understand what is being asked.  Are you requesting an 
enhancement to Eclispe-LazyStart to list a set of classes that should not 
cause the bundle to be started lazily AND should not be allowed to load unless 
the bundle is already started?

If that is the case who needs to be aware that a ClassNotFoundException will 
be thrown depending on if the bundle is active or not?
Comment 3 Rafael Chaves CLA 2005-11-10 13:28:05 EST 
Re: comment 1 - the exception message could contain an explanation why the
framework refused to load a class ("auto-activation is forbidden"). The client
of the proposed feature wants to make sure its clients are well-behaved. A class
not found exception here means a bug in the client code (that should not be
loading classes that would trigger auto-activation).

Re: comment 2 - what is being requested here is API for running runnables for
whose duration auto-activation is forbidden. I don't know about
Eclipse-LazyStart (did you mean Eclipse-AutoStart?), but no changes to manifest
headers are needed.

The implementation could be based on thread locals. Before running the client
provided runnable, an AUTO_ACTIVATION_FORBIDDEN thread local would be set to
true. Before starting a bundle, the EclipseClassLoader would check if auto
activation is forbidden. If it is, it should throw a ClassNotFoundException.

I am not familiar enough with Java classloading to be 100% sure this is
implementable. For instance, are missing classes always looked up, or if the
lookup fails for the first time, we don't bother doing the lookup again? If that
is the case, then I don't think this can be implemented.
Comment 4 Thomas Watson CLA 2006-04-10 13:41:13 EDT 
The problem you describe sounds very similar to bug 131966, although the solutions are different.  Rafael do you agree?  Can we dup this bug to bug 131966?
Comment 5 Rafael Chaves CLA 2006-04-10 13:53:46 EDT 
If that approach has better chances of being implemented, I am fine with this being marked as duplicate.
Comment 6 Thomas Watson CLA 2006-04-10 14:09:35 EDT 

*** This bug has been marked as a duplicate of 131966 ***