Hi, 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.
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...) 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. 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? Plz discuss! Ralf Zahn ARS Computer und Consulting GmbH, http://www.ars.de Ridlerstrasse 55, 80339 Muenchen, Deutschland Handelsregister Muenchen, HRB 101829, USt-ID: DE 155 068 909 Geschaeftsfuehrer: Michael Arbesmeier, Kai-Uwe Rommel, Roland Schock, Joachim Gucker
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
