> I have read David's blog post about the latest draft from the EEG ( > http://osgithoughts.blogspot.de/2012/10/new-osgi-eeg-early-access-draft.html
> ). Thanks for the JavaEE Contracts proposal. This aims a good > solution for that to solve the versioning problem. But I think, > contracts could be used in a wider scope. The osgi.contracts capability/requirement namespace was specifically design for this purpose. See 135.3 in the Enterprise R5 spec. We have other namespaces to address other concerns. A single namespace is not to solve all issues. > > 1. The solution is for JavaEE, the problem may occur in SE > environments too. Of course, the original cause was the Servlet API > as discussed in https://bugs.eclipse.org/bugs/show_bug.cgi?id=360245 > , and, of course, positioning the solution within the Enterprise > Specification leads to the fact the OSGi runtimes can optionally > implement the feature, it's not mandatory. (Maybe this is not a good > thing to say that OSGi Enterprise solutions are optional whereas > OSGi Core solutions are mandatory - but this is another topic...) The RFC is about contracts for Java EE API sets. The way the Java EE APIs are designed (JSRs) lend themselves to some obvious sets. Other contracts can be defined in the future for other API sets. > > 2. Especially, in managed environments (as JEE containers are), > there could be other contracts than a single API - e.g. a couple of > APIs and some functionality that cannot get addressed on the package > level. If you write a web service, you are not only dependent from > the javax.ws package, and you are not dependent from the JAX-WS API, > you are dependent from the JAX-WS runtime which would include that a > HTTP port is available that allows to receive requests (in parallel) > and to send responses. Maybe, the QoS could be expressed by a > contract, e.g. if XML-Encryption should be a condition to run the web service. We already have namespaces to describe dependencies on runtimes such as osgi.extender. See 135.2 in the Enterprise R5 spec. We are also discussing a namespace for whiteboard style services to express a dependency of the whiteboard service on its consumer. > > 3. Could the contract mechanism be used to cover the dependencies to > Java Execution Environments? We have the fact the a dependency to > JavaSE-1.5 can be resolved within a JavaSE-1.7 environment. So this > resolution, that OSGi runtimes already contain, might be a special > use case for contracts, right? We already have a namespace for this called osgi.ee. See 8.2 in the Core R5 spec. Also note that Java 8 has proposed a set of profiles for Java SE: http://openjdk.java.net/jeps/161. For Java 8, OSGi will need to define execution environment names for any such specified profiles. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
