| [cross-project-issues-dev] Spurious http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore network accesses |
|
Hi This message is only of concern to direct and indirect MDT/OCL users. As part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=364797, it was discovered that eclipse.org is receiving about 6700 hits a day on http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore, which is the URI of the OCL Standard Library and which has no corresponding file so the access is a 404. This access occurs if a standalone application has not arranged some URI mapping or registration to satisfy the URI access. The default OCL standalone initialisation routine had no such provision. This routine was first provided in Helios, so there are probably a variety of applications with earlier handcrafted initialisation and the same deficiency. As a consequence, a first standalone OCL evaluation starts with an internet access failure, which may take many seconds on a poor connection. As from M7, MDT/OCL provides a URI mapping from http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore to no-such-protocol:/this/does/not/exist which ensures that the access fails locally on an unknown protocol without troubling an external network. (This change involves the smallest change to control flow and so minimizes impact.) Applications not using org.eclipse.ocl.ecore.OCL.initialize(ResourceSet) are encouraged to do so, or at least to copy the URI mapping. The same URI mapping is provided in plugin.xml, so that plugin usage now uses the built-in Java coded copy of the library as documented, rather than reading an external EMF file. These changes should make no difference to functionality; they just eliminate some bad slow I/O interactions. Regards Ed Willink |