Community
Participate
Working Groups
If running standalone, http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore, and it is not mapped though to e.g. platform:/plugin/org.eclipse.ocl.ecore/model/oclstdlib.ecore and Internet connection is attempted that eventually times out.
This can be worked around by adding URIConverter.URI_MAP.put(URI.createURI("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore"), URI.createPlatformPluginURI("/org.eclipse.ocl.ecore/model/oclstdlib.ecore", true)); to the DocumentationExamplesTest. Strangely resourceSet.getURIConverter().getURIMap().put(URI.createURI("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore"), URI.createPlatformPluginURI("/org.eclipse.ocl.ecore/model/oclstdlib.ecore", true)); does not work; why? Need to add something to the standalone init subroutine. Update documentation and example to show extra line. Does the mapping actually work, or does it just provide something that throws an exception within milliseconds accelerating the fallback to the built-in library?
(In reply to comment #1) > Strangely > > resourceSet.getURIConverter().getURIMap().put(URI.createURI("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore"), > URI.createPlatformPluginURI("/org.eclipse.ocl.ecore/model/oclstdlib.ecore", > true)); > > does not work; why? Probably because a temporary ResourceSetImpl was created to avoid polluting the working ResourceSet. All registrations should be copied across to the temporary! This bug is prevalent throughout EMF, UML2. Raise an EMF Bugzilla to provide a ResourceSetImpl copy constructor/EcoreUtil helper.
(In reply to comment #1) > This can be worked around by adding > > URIConverter.URI_MAP.put(URI.createURI("http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore"), > URI.createPlatformPluginURI("/org.eclipse.ocl.ecore/model/oclstdlib.ecore", > true)); > > to the DocumentationExamplesTest. A similar enhancement to OCLStandaloneSetup, as part of the GeneratePivotModel procedure for which platform: is suppoerted, completely breaks the Acceleo templates, that seem to have bad non-proxy values for OCLstdlib references.
(In reply to comment #3) > A similar enhancement to OCLStandaloneSetup, as part of the GeneratePivotModel > procedure for which platform: is supported, completely breaks the Acceleo > templates, that seem to have bad non-proxy values for OCLstdlib references. AbstractAcceleoGenerator.registerPackages does resourceSet.getPackageRegistry().put( "http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore", //$NON-NLS-1$ getOCLStdLibPackage()); with getOCLStdLibPackage() reusing the parent of the global OCLstdlib Bag type, which seems like a good idea, but actually provokes schizophrenia if oclstdlib.ecore is readable as a file, which is the current plugin policy. The Acceleo approach is better; oclstdlib.ecore should never be read as a file; it just wastes time and may trigger an Internet timeout. Therefore promote getOCLStdLibPackage() to the OCLStandardLibrary, probably as a dedicated EPackage so that it has an eINSTANCE and can be registered via a registered package rather than uri_mapping extension point. OCL.initialize should be updated to provide the missing init.
(In reply to comment #4) > Therefore promote getOCLStdLibPackage() to the OCLStandardLibrary, probably as > a dedicated EPackage so that it has an eINSTANCE and can be registered via a > registered package rather than uri_mapping extension point. OCL.initialize > should be updated to provide the missing init. Introducing an OCLStandardLibraryPackage is ridiculously easy; see Bug/364747 branch. Only problem is that all tests pass (as before) with URI mapping, or with no URI mapping, or with package registration rather than URI mapping. Is this 'API' safe? No APIs change, so yes. plugin.xml still provides a resolution of http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore so may be that's ok, even if detailed examination of registries will reveal a difference. The new registration has no genmodel, which is legal, but some bad package registry extension point scans may break. Would a bogus genmodel make things better or worse? The OCL.initialize() routine is better, but clearly different. --- Probably should do UML variant too.
-1. The reason that no tests are affected is that the changes only take place after the library has been loaded. The OCLStandardLibraryImpl.init algorithm is: create a new ResourceSet (i.e. use prevailing global registrations) init ResourceSet for *.ecore loading load http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore if loads ok use loaded content else // threw an exception 'the normal case' hand construct content So, there are three behaviours Normal case, with working internet connection - OCL init requires an Internet lookup failure that throws an exception relatively quickly Normal case, with broken internet connection - OCL init requires an Internet lookup failure that throws an exception after a timeout Smart case; user has mapped http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore to a file - OCL init loads file I'm not keen on changing this code, so perhaps the least dangerous solution is to install a mapping from http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore to no-such-protocol://this/does/not/exist so that the lookup failure throws the exception quickly without troubling the internet.
Looks good. Minor comments to optionally fix before merge: public interface OCLStandardLibraryPackage extends EPackage { should probably be formatted public interface OCLStandardLibraryPackage extends EPackage { Furthermore, the plugin.xml still has in a comment the old declaration. I suggest to either add a few words inside the comment why the commented version is still there or to remove the commented old version altogether. +1
The bug branch is the solution for comment #5. Further investigation in led me to -1 it in #6 and suggest a safer solution. I think this changes the URI mapping from a sometimes accessible file to an always bad file. Axel: you've +1'd my -1. I was after a comment on the conclusion of #6.
Sorry, I misread that then and thought that you were looking for a review of the current state of the bug branch. I have no particular opinion on the new solution proposed; at best a question only: will the "always-bad" URI lead to other nasty error messages down the line?
On further investigation, this is a problem solely for standalone users, who are expected to perform initialization correctly. Using Wireshark to watch Ecore and UML plugin tests shows no HTTP GETs. The corresponding standalone tests show one HTTP GET for Ecore on the standard library, and 4 HTTP GETs on the UML L2 Profile. The revised bug branch for approval conatins two small changes. a) OCL.java initialize for standalone users maps the library to a bad URL so that a MalformedURLException bypassses the Internet timeout and ensures that a libraty is builrt on the fly. b) plugin.xml for plugin users maps the library to a bad URL to give the same behaviour. This change has two justifications; a) it makes plugin and standalone libraries the same; b) it makes the code do what the OCLStandardLibraryImpl line 253 comment says: "normal case: the library file isn't there because we are generating it on the fly." However it is a change to legacy behaviour that had to get EMF to read the actual file. [Attempting to create a pseudo OCLStandardLibraryPackage doesn't work because the ResourceSet.loadResource must fail first while creating the package. So we must map the URI to a fast failure for optimum performance.]
Denis has come back with a figure of 7,800 hits per day, so I think we should try to react. The change to OCL.java would fix this if users were calling OCL.initialize, which wan't even available till Helios. So we need to be proactive in encouraging Acceleo, QVTo, Topcased, ... to implement the fix. The change to plugin.xml is optional. Axel: please +1/-1 independently for the two changes. This bug is currently built as the Hudson branch build, so you might like to take the built update site and check that it does no harm in a real industrial context. Laurent: you might like to try uriMap.put(URI.createURI(EcoreEnvironment.OCL_STANDARD_LIBRARY_NS_URI), URI.createURI("no-such-protocol:/this/does/not/exist")); in Acceleo's startup to see if it's better than your current pseudo library package.
As you found out (in comment 4), Acceleo explicitely registers the OCL stdlib whenever a generation is launched. This is done in our resource set's package registry to avoid polluting the global registry, but it is done nonetheless. We did this a good while ago as we did encounter these http requests trouble with the std lib (that's what triggered https://bugs.eclipse.org/bugs/show_bug.cgi?id=252600). We haven't seen any of these bugs since then, and I doubt Acceleo is the reason behind all of these daily HTTP hits (we use our own package registry, we try to register everything prior to the generations, and we make sure that we only have one resource set in use). I'll try and confirm whether Acceleo might be the culprit, but for now registering the OCL std lib works, and I am not that eager to change it without being sure that I am not breaking anything (it's been three years since we fixed this http request bug ... the scenario then was a standalone compilation through ant, but I no longer have the source to re-play this scenario and check its behavior).
Laurent: my first fix in Comment #5 emulated your standard package, but it doesn't actually work; the Internet access still occurs during the construction of your package. The behaviour of OCLStandardLibraryImpl.init() is very unhelpful. It would be nice to have Acceleo endorsement (as non-damaging) of the URI mapping to a guaranteed MalformedURLException before I post this as a standalone init recommendation on a variety of modeling newsgroups.
(In reply to comment #13) > I doubt Acceleo is the reason behind all of these > daily HTTP hits (we use our own package registry, we try to register everything > prior to the generations, and we make sure that we only have one resource set > in use). Indeed; it looks like you have at least provided a fix for Acceleo users, so the 6,700 a day could be even worse. I've cherry-picked the patch as bug/374797 on top of bug/378577 so that there is something current to review and run a branch-tests on. All tests pass. I think it is better to put this out in M7, announce the recommended URI map to no-such-protocol for other OCL users not using OCL.initialize to emulate and be prepared to retract it at RC1 if any trouble materialises.
Well, Not convinced about not using the oclsdtdlib.ecore model anymore, I don't currently see a reason about not to do it, so go ahead (+1). On the other hand: - I'm wondering if we are not going to maintain such a model anymore. - Should not the UML counterpart adopt the same approach ? Regards, Adolfo.
Pushed to master.
Hi, After careful examination of this change today, it appears that it breaks, in Acceleo, the compilation of all the operations from the standard and non-standard Acceleo library and all the previously built Acceleo generators which cannot run on OCL M7. We have detected this issue last week when Goulwen tried to build EEF M7 (they switched back to an older version of OCL). With Acceleo M7 and OCL M7 nothing works anymore (compilation of new generators with Acceleo operations or execution of old generators). Stephane Begaudeau
Hi Stephane, Thank you for the failure report. I'm not sure what's exactly your problem (a careful examination merits a precise diagnose or a suggestion :)), but I think I know what we have overlooked (therefore, the possible problem which is impacting you) Concerning OCLStandardLibrary API usage, the change is safe since a proper OCLStandardLibrary is built, regardless the oclstdlib.ecore model (via http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore nsuri) is available or it is not. However, clients could have been loading such a model the by their own (vi that nsuri ), and we have erroneously (and unnecessarily) removed its availability. In this sense, this could also be considered as API change. The map introduced in the OCL.initialize fixes the bug, and the map introduced in the plugin.xml conforms an API change which is not needed at all, IMO. So I'd do the following: 1. Re introduce the map http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore to platform:/plugin/org.eclipse.ocl.ecore/model/oclstdlib.ecore in the plugin.xml 2. As commented in comment15 introduce a map http://www.eclipse.org/ocl/1.1.0/oclstdlib.uml to "no-such-protocol:/this/does/not/exist" in the OCL.initialize for UML I'll create a new branch for it. Regards, Adolfo.
> 2. As commented in comment15 introduce a map > http://www.eclipse.org/ocl/1.1.0/oclstdlib.uml to > "no-such-protocol:/this/does/not/exist" in the OCL.initialize for UML Interestingly, UML.initialize already maps such that nsURI to the true model. For symmetry, in both initializations: a) either we map to the invented URI to make the standard library be built on the fly. b) or we map to the true model. Ed, what do you prefer ? Cheers, Adolfo.
> > Interestingly, UML.initialize already maps such that nsURI to the true model. > For symmetry, in both initializations: > > a) either we map to the invented URI to make the standard library be built on > the fly. > b) or we map to the true model. I was inclined to implement b) since it seems coherent to use the same alternative (use the true model) in both an Eclipse-based application and a stand-alone one. However, the stand-alone tests fail when mapping to the true model, while mapping to the invented URI the tests success. As commented in comment1 and comment2 it looks like that some sort of resourceSet initialization is required, because the plugin-based tests cases work. The point is, what could the OCLStdLib initialization be doing different to make the tests success, when constructing the the OCLStadLib on the fly (that is, when doing the mapping to the invented URI?)... we must be overlooking something. Cheers, Adolfo.
Stephane; can you post a zipped built Acceleo project with a launch configuration that fails; mine work with Java launch. Acceleo plugin launch doesn't but it never has for me.
> As commented in comment1 and comment2 it looks like that some sort of > resourceSet initialization is required, Yeah, The OclEcore metamodel needed to be registered in the ResourceSet package registry. I've also found that the UML OCLStandardLibraryImpl class is not using the created resourceSet when doing the OCL initialization (so that, it must be using the global package registry). I've also changed that. I've pushed the bug/364797 branch with the suggested solution. Tests cases passe in local. A test job is currently running. Regards, Adolfo.
The M7 commit had two changes: a) standalone: changing the exception to a for MalformedURL b) eclipse-running: essentially the same mapping. I have no trouble reverting b) since it was 'just cosmetic'. But I would like to understand why the failure is arising with a simple test case that works on M6 and fails on M7. The new code looks like a design change that lacks the necessary foundation and consequently risks multiplying the problems. In the absence of detailed understanding of why M7 fails, we must just revert.
(In reply to comment #21) > Stephane; can you post a zipped built Acceleo project with a launch > configuration that fails; mine work with Java launch. Acceleo plugin launch > doesn't but it never has for me. Trying to find something that works on M6, I've tried all three Acceleo examples, which lack documentation, launch configs, example files, ant scripts that reference them, correct factory registrations... and then we hit the com.google problem. For UML issues we need to be sure that the problem is not due to the UML 2.4.1 support and the associated registrations. We must have a defined test case to progress this.
Created attachment 215910 [details] Repro Attached Zipped Acceleo Hello World project locks up at 57% in the launching config. (Just load project and launch Generate HelloWorld.) Beware: this demonstrates an Acceleo bug in that the launch is not cancelable, so Eclipse will have to be killed the hard way. If the launch type is changed to Java Application and the missing com.google.guava dependency added, it works fine.
The repro reproduces directly in Eclipse, but does not reproduce in a nested Eclipse; except just once, I did get the debugger to allow me to suspend all the threads and they were all waiting. With 10 threads to choose from it wasn't clear which I should investigate. After instrumenting, it appears all the work is on a Worker-N thread and I'm pretty sure they were all idle, so the Acceleo/platform main program failed to spot that the worker had completed. I begin to suspect a timing issue and the inadequate launch synchronization reported in Bug 346233. Changed behaviour could be due to: - oclstdlib.ecore access failures are now synchronous and much faster - oclstdlib.ecore has additional operations - oclstdlib.ecore is built-in rather than read
(In reply to comment #22) > I've also found that the UML OCLStandardLibraryImpl class is not using the > created resourceSet when doing the OCL initialization (so that, it must be > using the global package registry). I've also changed that. > > I've pushed the bug/364797 branch with the suggested solution. This is a completely separate issue involving UML. Move to a separate bug if you're convinced it needs a change. Note that in practice the use of private ResourceSets for standalone usage is pretty dubious, and certainly did not work prior to Juno M7 when some bad Ecore2XML mapping registrations were fixed.
(In reply to comment #22) > I've pushed the bug/364797 branch with the suggested solution. > > Tests cases passe in local. A test job is currently running. Do you have any evidence that the changes resolve the reported problem?
(In reply to comment #26) > The repro ... does not reproduce in a nested Eclipse so I instrumented ResourceSetImpl.getEObject and deployed the plugin and poked it into my M7 installaton keeping the exact filename. Then using eclipsec.exe, instrumentation shows about 7 accesses during a launch that works fine. The most suspect is: Worker-5 getEObject AcceleoResourceSetImpl@cae744 http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore#/0/String_Class/+ => EOperationImpl@4a2dd since this operation did not exist prior to M7. Could an old oclstdlib.ecore be being loaded and then throwing an inappropriately caught exception; probably an NPE?
(In reply to comment #29) > The most suspect is: > > Worker-5 getEObject AcceleoResourceSetImpl@cae744 > http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore#/0/String_Class/+ => > EOperationImpl@4a2dd > > since this operation did not exist prior to M7. Could an old oclstdlib.ecore be > being loaded and then throwing an inappropriately caught exception; probably an > NPE? Changing String_Class/+ to String_Class/vacant indeed gives null returns and NPEs that appear in the error log; the launch terminates silently; A Pop-up might be expected, but that's a different Acceleo ergonmic nicety.
(In reply to comment #23) > The M7 commit had two changes: > > a) standalone: changing the exception to a for MalformedURL > > b) eclipse-running: essentially the same mapping. > > I have no trouble reverting b) since it was 'just cosmetic'. > That's the only change I feel is needed. Without a good diagnose of the Stephane's failure report I can only find a possible origin of the problem. Comments like "After careful examination of this change today, it appears that it breaks" doesn't make me be sure that this bug has provoked the Acceleo failure. It may be a different one. So what we need is to restore the mapping in the plugin.xml file. The other two changes were introduced to have the UML and the Ecore standard library initialization aligned (just cometic, as you said), with the pretentious idea that they won't hurt. Feel free not to include them, actually it's probably better not to it for the RC1 (tomorrow !). Regards, Adolfo.
(In reply to comment #28) > (In reply to comment #22) > > I've pushed the bug/364797 branch with the suggested solution. > > > > Tests cases passe in local. A test job is currently running. > > Do you have any evidence that the changes resolve the reported problem? Doing a branch build reverting the plugin URI mapping does _not_ cure the problem. It is now very unlikely that the access policy for oclstdlib.ecore is causing this problem. Further investigation in Bug 380078.
Resolved the reopen as invalid.
Hi Ed, Good work. If acceleo team doesn't provide more information about the failure (i.e. a test case) I guess it's quite difficult to find the origin of the problem. One last thing, I'm not sure if you agree/want to consider what I said at comment18: (In reply to comment #18) > > Concerning OCLStandardLibrary API usage, the change is safe since a proper > OCLStandardLibrary is built, regardless the oclstdlib.ecore model (via > http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore nsuri) is available > or it is not. However, clients could have been loading such a model the by their > own (vi that nsuri ), and we have erroneously (and unnecessarily) removed its > availability. In this sense, this could also be considered as API change. > Concerning this bug, I still believe that the mapping for an Eclipse Running application (the plugin.xml map) needs to be restored. P.S: I'll kick RC1 in the afternoon. Regards, Adolfo.
The problem for us is quite simple, Acceleo generators are compiled as EMF models. They are using lots of references to the URI "http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore". This URI was not resolved anymore with OCL M7 so issues appeared.
My own Acceleo templates recompile with M7 and have many http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore references, particularly String. These look identical before and after. The main difference is that String::+ now resolves to a primary 'additional' operation. So it isn't that the URI doesn't resolve; it perhaps resolves differently in some local ResourceSet. If so I want to understand the mechanism. I see that there is a new Acceleo master build, with probably only minor test failures. Can you provide a simple repro so that I can understand the problem?
The foregoing was addressing the wrong kind of access. Java-based access using OCL code seems fine. The problem is for model-based access. Repro: open /org.eclipse.acceleo.model/model/mtlstdlib.ecore with the Sample Ecore Editor and Validate. The http://www.eclipse.org/ocl/1.1.0/oclstdlib.ecore references bomb because the Sample Ecore Editor does not do programmatic library model construction. Therefore the plugin.xml URI mapping _must_ continue to reference a model. However the programmatic init can still set the bogus mapping so that a built model is used. Adolfo: This clearly merits an RC1a. ? of Core today at +2, with Tools going directly to RC1a at +3 tomorrow, or today if Xtext is prompt. Adolfo: would you care to review the bug/364797b branch.
Much more localized solution pushed to bug/364797b. No changes to OCL.java; eliminates the programmatioc no-such-protocol priming. No changes to plugin.xml; eliminates the model-access failures on no-such-protocol. Simple cherry pick of known URIs in OCLStandardLibraryImpl.init. null URI is the stndalone default. magic value is the pligin default. Either uses the builtin library.
Well, let's say that I'm glad you finally find necessary to recover the mapping plugin.xml :) +1. Minor suggestions: OCLStandardLibraryImpl line 200: EcoreEnvironment.OCL_STANDARD_LIBRARY_NS_URI -> NS_URI line 220: Resource load = rset.getResource(URI.createURI(NS_URI), true); -> Resource load = rset.getResource(libraryURI, true); Cheers, Adolfo.
Done. Pushed to master for RC1a.
CLOSED after a year in the RESOLVED state.
