Re: [equinox-dev] [sec] questions about EE for security

[Thomas Watson <tjwatson@xxxxxxxxxx>]

Both John and Rem are correct.

Bundles which want to run on a smaller EE than J2SE-1.4 and have access to the javax.security.auth packages should use import-package (e.g. Import-Package: javax.security.auth). You should not make J2SE-1.4 your required EE only because other bundles you depend on use the EE.

Equinox is a broad community. A large number of our bundles do run on Foundation 1.1/1.0 (and even down to the minimum OSGi EE). But there are some extra features which require higher EEs. Currently parts of the security work in the incubator can only run on J2SE-1.4 or higher. For example, the core extension bundles (org.eclipse.equinox.security.boot.jre14x or org.eclipse.equinox.security.boot.jre15x) are installed into the extension classloader of the VM. This is required because we need to make the our security provider available to the VM and it will only search for providers on the boot classpath or the extension class loader. Unfortunately at that level the code will only have access to classes that are provided by the EE. They do not have the option to import additional packages which may come from other bundles installed in a Framework running on Foundation 1.1 EE.

I opened a couple of bugs against the security bundles. All Equinox bundles should use Import-Package to access packages outside the java.* namespace. We could also split some of the bundles to allow parts of it to run on a Foundation EE.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=208399
https://bugs.eclipse.org/bugs/show_bug.cgi?id=208400

Tom



John Arthorne ---10/31/2007 09:30:11 PM---I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you

From:	John Arthorne <John_Arthorne@xxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	10/31/2007 09:30 PM
Subject:	Re: [equinox-dev] [sec] questions about EE for security

---

I think the right approach is to set your bundle's EE to reflect the EE dependencies of *your* bundle, and not the bundles you depend on. I.e., if your bundle doesn't directly depend on 1.4, you could still specify an EE of Foundation 1.1 for your bundle.  If it turns out that the JAAS bundle requires 1.4, then your bundle will transitively fail to resolve anyway. That way you're not building assumptions into your bundle about the EE of downstream bundles that may change in the future. 

John

Scott Lewis <slewis@xxxxxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/31/2007 05:53 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	[equinox-dev] [sec] questions about EE for security

Hi Folks,

Some questions:  I thought I understood (from Equinox Summit) that the 
recently approved minimum EE for Equinox 3.4 (Ganymede) was CDC 
1.1/Foundation 1.1.

I see from looking at the equinox JAAS integration bundles (e.g. 
org.eclipse.equinox.security.auth) that the runtime environment minimum 
for those bundles is set to JRE 1.4.  I understand this, as the JAAS 
work depends upon packages like javax.security.auth, and 
javax.security.auth.login, etc.  which do not seem to be in CDC 
1.1/Foundation 1.1.

So maybe I just answered my own question:  it seems that the JAAS 
security bundles/plugins must assume JRE 1.4 (and can't/won't run on CDC 
1.1/Foundation 1.1).  So the implicit (to me anyway) idea here is that 
bundles that use/extend/depend upon the JAAS security integration also 
obviously must assume JRE 1.4 and not just CDC 1.1.  Correct?

Scott


_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev