Bug 323964 - Support osgi.ee capabilities for execution environments
Summary: Support osgi.ee capabilities for execution environments
Status: RESOLVED FIXED
Alias: None
Product: Equinox
Classification: Eclipse Project
Component: Framework (show other bugs)
Version: 3.7   Edit
Hardware: PC Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.7 M2   Edit
Assignee: equinox.framework-inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 529085
  Show dependency tree
 
Reported: 2010-08-30 09:07 EDT by Thomas Watson CLA
Modified: 2017-12-21 08:51 EST (History)
5 users (show)

See Also:


Attachments
patch (17.17 KB, patch)
2010-09-01 23:44 EDT, Thomas Watson CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Watson CLA 2010-08-30 09:07:28 EDT
With the new Provide/Require capability headers OSGi is looking to replace/deprecate the Bundle-ReqiuredExecutionEnvironment header with something more expressive.
Comment 1 Thomas Watson CLA 2010-08-30 09:21:08 EDT
New launching properties are also being defined to express the capabilities provided by the framework (similar to o.o.f.system.packages and o.o.f.system.packages.extra)

org.osgi.framework.system.capabilities

The capabilities that should be provided from the System Bundle. If not set,
the framework must provide a reasonable default for the current VM.


org.osgi.framework.system.capabilities.extra

Capabilities specified in this property are added to the
org.osgi.framework.system.capabilities property and therefore have the same
syntax. This allows the configurator to only define the additional capabilities
and leave the standard VM capabilities to be defined by the framework.

The java profiles included in equinox will need to be updated to include the  org.osgi.framework.system.capabilities set for the various VMs.  The resolver will also need to be updated to handle the osgi.ee namespace as it does the Bundle-RequiredExecutionEnvironment.  Right now I think we should handle this namespace separately from the other namespaces to filter out the unresolvable bundles ahead of time like we do for the BREE header. 

The osgi.ee namespace capability has the following attributes:

- osgi.ee: the value is a string and names the execution environment (e.g. JavaSE, J2SE, CDC/Foundation)
- version: value is of type Version and defines the version of the execution environment:

The system bundle must provide all the osgi.ee capabilities for the running JRE

Examples.

For a framework running on a CDC-1.1/Foundation-1.1 JRE, the system bundle must
provide the following capabilities.

Provide-Capability: 
 osgi.ee; osgi.ee="OSGi/Minimum"; version:List<Version>="1.0,1.1,1.2", 
 osgi.ee; osgi.ee ="CDC/Foundation", version:List<Version>="1.0,1.1"

A bundle that requires at least CDC-1.1/Foundation-1.1 JRE can require the
following capability. 

Require-Capability: 
 osgi.ee; filter="(&(osgi.ee~=cdc/foundation)(version>=1.1))"

For a framework running on a JavaSe 6 JRE, the system bundle must provide the
following capabilities.

Provide-Capability: 
 osgi.ee; osgi.ee="OSGi/Minimum"; version:List<Version>="1.0,1.1,1.2", 
 osgi.ee; osgi.ee="J2SE"; version:List<Version>="1.2,1.3,1.4,1.5", 
 osgi.ee; osgi.ee="JavaSE"; version:Version="1.6"

A bundle that requires at least OSGi/Minimum-1.2 can require the following
capability.

Require-Capability osgi.ee; filter="(&(osgi.ee~=osgi/minimum)(version>=1.2))"

A bundle that requires at least J2SE 1.4 and less than JavaSE 6 can require the
following capability.

Require-Capability:
 osgi.ee;
   filter="(&(|(osgi.ee=J2SE)(osgi.ee=JavaSE))(version>=1.4)(!(version>=1.6)))"

The filter attribute allows for more expressive matching of the EEs.
Comment 2 Thomas Watson CLA 2010-09-01 23:44:24 EDT
Created attachment 178014 [details]
patch

Implementation of new osgi.ee capability.  I updated all the profiles to include the property org.osgi.framework.system.capabilities.  This is where the EE capabilities are listed that the system bundle should provide for the various JREs.
Comment 3 Thomas Watson CLA 2010-09-01 23:49:47 EDT
Patch released.
Comment 4 Thomas Watson CLA 2010-09-07 15:31:31 EDT
(In reply to comment #1)
> For a framework running on a JavaSe 6 JRE, the system bundle must provide the
> following capabilities.
> 
> Provide-Capability: 
>  osgi.ee; osgi.ee="OSGi/Minimum"; version:List<Version>="1.0,1.1,1.2", 
>  osgi.ee; osgi.ee="J2SE"; version:List<Version>="1.2,1.3,1.4,1.5", 
>  osgi.ee; osgi.ee="JavaSE"; version:Version="1.6"
> 


> 
> A bundle that requires at least J2SE 1.4 and less than JavaSE 6 can require the
> following capability.
> 
> Require-Capability:
>  osgi.ee;
>    filter="(&(|(osgi.ee=J2SE)(osgi.ee=JavaSE))(version>=1.4)(!(version>=1.6)))"
> 
> The filter attribute allows for more expressive matching of the EEs.

This filter will not provide you with what you expect.  It will match the following capability provided by the framework on JavaSE 6

 osgi.ee; osgi.ee="J2SE"; version:List<Version>="1.2,1.3,1.4,1.5"

Even with the presence of the following capability

 osgi.ee; osgi.ee="JavaSE"; version:Version="1.6"


I am discussing this issue with OSGi.  If it is proven that the new osgi.ee cannot be more expressive than the current BREE header then I am proposing that the osgi.ee namespace is not defined by the OSGi specification.  If that happens the code changes associated with this bug should be reverted.
Comment 5 Thomas Watson CLA 2010-09-10 10:17:48 EDT
Since the osgi.ee capability is new OSGi has decided to combine all the variations of the SE platform into one alias that is simply JavaSE.  For example, when running on a JavaSE 1.6 VM the following will be available as capabilities from the framework:

 osgi.ee; 
    osgi.ee="OSGi/Minimum"; 
    version:List<Version>="1.0, 1.1, 1.2"
 osgi.ee; 
    osgi.ee="JavaSE"; 
    version:List<Version>="1.2, 1.3, 1.4, 1.5, 1.6"

Since we no longer split the SE space between J2SE and JavaSE this allows you to specify requirements on osgi.ee like this:


Require-Capability:
 osgi.ee; filter="(&(osgi.ee=JavaSE)(version>=1.3)(!(version>=1.5)))"

This requirement allows a bundle to resolve on JavaSE 1.3 and 1.4 but not any JavaSE version 1.5 or greater.  I have released updated java profiles to org.eclipse.osgi to reflect this.
Comment 6 Thomas Schindl CLA 2013-01-24 13:55:08 EST
Just for those who come to this bug and try above filter above it has to be:

Require-Capability:
 osgi.ee; filter:="(&(osgi.ee=JavaSE)(version>=1.3)(!(version>=1.5)))"

Notice the additonal :
Comment 7 Thomas Watson CLA 2013-01-24 16:48:05 EST
(In reply to comment #6)
> Just for those who come to this bug and try above filter above it has to be:
> 
> Require-Capability:
>  osgi.ee; filter:="(&(osgi.ee=JavaSE)(version>=1.3)(!(version>=1.5)))"
> 
> Notice the additonal :

Thanks Tom.  Yes, filter is a directive and requires the additional := when specifying it.
Comment 8 Yogesh Bitake CLA 2017-05-03 06:04:12 EDT
It Means JRE 1.9 is not supported by Eclipse 3.8 right ?
what is the workaround to run JRE 1.9 on eclipse 3.8?
Comment 9 Thomas Watson CLA 2017-05-03 09:04:40 EDT
(In reply to Yogesh Bitake from comment #8)
> It Means JRE 1.9 is not supported by Eclipse 3.8 right ?
> what is the workaround to run JRE 1.9 on eclipse 3.8?

There are many changes that needed to be made to eclipse to get it to run on Java 9.  Neon.3 has most of them, but Oxygen will be the first release that actually supports Java 9.  3.8 is very old and I expect it to have several issues that may not be able to be worked around to run on Java 9.  I have not tried to run it on Java 9, have you tried it?  What issues are you seeing?
Comment 10 Yogesh Bitake CLA 2017-05-11 04:31:05 EDT
(In reply to Thomas Watson from comment #9)
> (In reply to Yogesh Bitake from comment #8)
> > It Means JRE 1.9 is not supported by Eclipse 3.8 right ?
> > what is the workaround to run JRE 1.9 on eclipse 3.8?
> 
> There are many changes that needed to be made to eclipse to get it to run on
> Java 9.  Neon.3 has most of them, but Oxygen will be the first release that
> actually supports Java 9.  3.8 is very old and I expect it to have several
> issues that may not be able to be worked around to run on Java 9.  I have
> not tried to run it on Java 9, have you tried it?  What issues are you
> seeing?

1st problem- Unable to launch Eclipse/RCP Application.

java.lang.reflect.InaccessibleObjectException: Unable to make protected void java.net.URLClassLoader.addURL(java.net.URL) accessible: module java.base does not "opens java.net" to unnamed module @7b69c6ba

Workaround-
This is known issue with JRE 9.
Use VM argument --add-opens java.base/java.net=ALL-UNNAMED or --permit-illegal-access 

2nd problem- 
The Bundle org.eclipse.equinox.common_3.6.100.v20120522-1841 could not be resolved. Reason: Missing Constraint: Bundle-RequiredExecutionEnvironment: CDC-1.1/Foundation-1.1,J2SE-1.4
also org.eclipse.equinox.ds_1.4.0.v20120522-1841,org.eclipse.update.configurator_3.3.200.v20120523-1742 etc.

Workaround- 
Modify the org.eclipse.osgi_3.8.0.v20120529-1548.jar plugin and add JavaSE-1.8.profile and JavaSE-9.profile file (copy this files from the eclipse 4.6) and also add this entries in profile.list.

3rd problem- 
My RCP Application using the JAXB api for login. and getting following error during login.
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

Workaround- use vm argument --add-modules=java.se.se, -Dorg.osgi.framework.bundle.parent=app , -Dorg.osgi.framework.bootdelegation=javax.* 


4th problem-
ERROR 2017-05-04 17:02:16,963 - A marshalling error occurred while processing XML for Core-2011-06-Session.login.
Failed to serialize the XML document.
2 counts of IllegalAnnotationExceptions: A marshalling error occurred while processing XML for Core-2011-06-Session.login.
Failed to serialize the XML document.
2 counts of IllegalAnnotationExceptions
com.teamcenter.soa.client.SoaRuntimeException: A marshalling error occurred while processing XML for Core-2011-06-Session.login.
Failed to serialize the XML document.
2 counts of IllegalAnnotationExceptions

Note- i am not getting 2nd problem and 4th problem in Eclipse 4.6. i dont want to use this many WA, what is your suggestion?
refer my blog for more info-  https://yogeshbitake.blogspot.in/