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

Bug 163444

Summary: Associate access restrictions with execution environments
Product: [Eclipse Project] JDT Reporter: Gunnar Wagenknecht <gunnar>
Component: DebugAssignee: Michael Rennie <Michael_Rennie>
Status: VERIFIED FIXED QA Contact:
Severity: enhancement    
Priority: P3 CC: frederic_fusier, gorkem.ercan, jeffmcaffer, philippe_mulet, t.p.ellison, tjwatson, wassim.melhem
Version: 3.3   
Target Milestone: 3.3 M4   
Hardware: All   
OS: All   
Whiteboard:
Attachments:
Description Flags
patch
none
patch none

Description Gunnar Wagenknecht CLA 2006-11-04 10:27:59 EST 
(Note, there is no launching component so I'm reporting it against core.)

Eclipse has the meaning of execution environments to allow decoupling the JRE classpath container from a specific JDK/JRE. This concept should be enhance to also allow applying access rules to the JRE container to allow filter of certain types.

For example, I'd like to contribute an execution environment where only a really small subset of type would be accessible but the underlying JDK/JRE can be a 1.4 or 1.5.

The only way I could implement it right now is by providing something like an "Update classpath" action that would set the access rules. However, this is suboptimal because it requires additional user interaction.
Comment 1 Darin Wright CLA 2006-11-06 09:54:27 EST 
Similar to bug 116656
Comment 2 Darin Wright CLA 2006-11-14 15:19:18 EST 
We are investigating this for M4. The high level plan is to allow an execution environment to specify a default set of access rules (via runtime code/delegate). We would also need to support access rule "participants" for execution environments (for example, PDE may need to enhance the set of default access rules for an environment, based on plug-in project settings).
Comment 3 Darin Wright CLA 2006-11-14 15:21:55 EST 
*** Bug 116656 has been marked as a duplicate of this bug. ***
Comment 4 Wassim Melhem CLA 2006-11-14 23:39:14 EST 
Darin, the EE extensions and analyzer that currently reside in PDE could, as we discussed earlier, be pushed down to JDT to enable people to use an EE-based JRE with the dependency on PDE.

Let me know when you want to proceed with that.  It should be a trivial exercise.
Comment 5 Darin Wright CLA 2006-11-16 13:05:57 EST 
Wassim, we should push down the EE definitions to JDT launching in the next I-build. Could you point me to the appropriate plug-in to "move" the code from. We'll just have to co-ordinate the release, so we don't get duplicates.
Comment 6 Wassim Melhem CLA 2006-11-16 13:17:24 EST 
sounds good. I will give you a patch to jdt.launching later on today and will remove the pde counterpart as soon as you release.
Comment 7 Wassim Melhem CLA 2006-11-16 19:59:43 EST 
Created attachment 54044 [details]
patch

Here is the patch for execution environments for jdt.launching.
Comment 8 Darin Wright CLA 2006-11-17 09:37:50 EST 
Thanks Wassim, I have released the patch.
Comment 9 Darin Wright CLA 2006-11-27 11:58:29 EST 
We want to associate access rules with execution environments. At the implementation level, this means creating a classpath container for an EE with access rules. However, there seems to be a limitation in JCore:

When the classpath container initializer is called to initialize a container, the initializer is to call back to JavaCore.setClasspathContainer(IPath containerPath, IJavaProject[] affectedProjects, IClasspathContainer[] respectiveContainers, IProgressMonitor monitor). This does not allow access rules to be created when a container is initialized. It is possible to create rules on the entries in side the container, but for the case of the EE, this is not what we want - the rules are associated with the EE, not its libraries.
Comment 10 Darin Wright CLA 2006-11-28 19:05:50 EST 
Created attachment 54683 [details]
patch 

initial API - work in progress
Comment 11 Darin Wright CLA 2006-11-28 23:35:06 EST 
Released new API to head. Wassim/Tom, I'll need a description of the access rules, or a patch that adds them to JDT launching support (I assume the base rules should be defined with the execution environments in JDT lanuching).

The API allows for multiple access rule participants. An EE can contribute a participant specific to the EE, which is considered first. After than any participant can add rules to an EE (based on project, VM, & libraries).
Comment 12 Darin Wright CLA 2006-11-30 16:45:05 EST 
I've re-ordered the 'access rule participant' order. The default participant is now considered last such that other participants can override the default rules.
Comment 13 Darin Wright CLA 2006-12-01 12:14:56 EST 
Updated execution environments with default access rules based on OSGi profiles. Filed bug 166519 so the build path page will display the rules for JRE containers.

Fixed.
Comment 14 Darin Wright CLA 2006-12-01 12:15:17 EST 
Please verify, Mike.
Comment 15 Wassim Melhem CLA 2006-12-01 13:44:36 EST 
Darin, the code seems to generate new access rules all the time.

Philippe would be much happier if you had an 'access rule recycling program' like PDE.
Comment 16 Darin Wright CLA 2006-12-04 16:06:03 EST 
I added a cache of access rules per execution environment, such that the rules can be re-used across projects.
Comment 17 Michael Rennie CLA 2006-12-08 10:19:16 EST 
verified, I did notice though that there is no way remove access rules defined for the container itself (the user addable ones)
Comment 18 Michael Rennie CLA 2006-12-08 10:35:40 EST 
filed bug 167241 with JDT UI about not being able to remove custom access rules on the container
Comment 19 Darin Wright CLA 2007-01-29 20:17:58 EST 
*** Bug 137393 has been marked as a duplicate of this bug. ***