Community
Participate
Working Groups
One way to reproduce this one is to go to Recorded Simulations and rename one of the folders underneath. When done (it takes a while to complete, that's probably a bug too), the project explorer closes everything down. When I try to open anything, "Decorators", "Recorded Simulations" etc. it opens momentarily then it closes again. Sometimes if I click on the project first I'm able to open up the container. I see this on Mac, not sure about other OS's.
I've noticed this before. Every time I've seen it it's related to an uncaught exception while reading/parsing the files in the container. I know we implemented a fix for this on Mac where the .DS_Store files were getting parsed and throwing exceptions, but not sure it was a complete fix. Looking at the error log or running STEM with -consoleLog could help identify the error?
Hi Matt, can you take a look at this one? I'll take a look at 311294.
I can't duplicate this exact bug. I also see where it collapses the children after a rename on Recorded Simulations (which is an Eclipse thing) but I am able to expand the Decorators, Scenarios, Recorded Simulations, etc after. Can you provide an error log? Most often when an item fails to expand (does so momentarily then re-collapses) there's an uncaught exception (in my experience). I'm also looking at the slow rename time (for Recorded Simulations). It may be related to the workspace refresh that happens after the rename. If done with the debugger attached, it locks up both STEM and Eclipse because it's spawning thousands child threads. I'm able to do a rename immediately after opening STEM very quickly (instantly), but after first expanding a scenario/model it becomes slow. May be linked to reloading identifiables in the hierarchy that contain other nested identifiables. Not sure yet.
I'm having problems reproducing this one now too. But I did see it occuring when there was a problem loading a disease model that used an old invalid model and the error log had lots of errors like this in it: org.eclipse.emf.ecore.resource.impl.ResourceSetImpl$1DiagnosticWrappedException: org.eclipse.emf.ecore.xmi.FeatureNotFoundException: Feature 'iscale' not found. (file:/home/edlund/runtime-stem.product/IsrSIRflu/decorators/Flu.standard, 2, 797) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.handleDemandLoadException(ResourceSetImpl.java:315) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLoadHelper(ResourceSetImpl.java:274) at org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResource(ResourceSetImpl.java:397) at org.eclipse.stem.ui.Utility.getIdentifiable(Utility.java:126) at org.eclipse.stem.ui.Utility.getIdentifiable(Utility.java:105) at org.eclipse.stem.ui.views.explorer.IdentifiableContentProvider.getChildren(IdentifiableContentProvider.java:77) It takes a long time to generate those errors in the log and while that is happening I can't expand anything in the tree. Eclipse is probably doing the right thing locking down the tree when processing errors, but I'm not sure why there's so many of the errors showing up in the log. You might be right there could be some nesting of identifiables going on.
Thanks Stefan. This log is useful. The exception thrown from getidentifiable() is not caught (we're catching CoreException, DiagnosticWrappedException is not a child of that). I'll commit a fix. The fix is going to catch Throwable because no exception or error here should break the Project Explorer / UI from displaying the contents of a project.
I think this was fixed already...
Fixed a while back.
Closed.
