Exception in thread
"main" org.apache.poi.poifs.filesystem.OfficeXmlFileException: The supplied data appears to be in the Office 2007+ XML. You are calling the part of POI that deals with OLE2 Office Documents. You need to call a different part of POI to process this data (eg XSSF instead of HSSF)
How to solve this error?
As suggested in the thread you should use XSSF over HSSF or another higher version API.
Also can you share your code snippet.
Related
We are using Forge viewer version 3.2.x.
For Autodesk.Viewing.Document the function load(documentId,onSuccessCallback,onErrorCallback,accessControlProperties) the parameter accessControlProperties is listed as required (see Autodesk Forge Documentation). Not providing this parameter still works on Chrome / Firefox, but I discovered that missing the parameter causes problems on mobile devices. However, for this parameter there seems to be no example or specification available.
Maybe the problem is not the missing parameter itself but something else...? Getting the following exception in browser console:
Uncaught TypeError: Cannot read property 'id' of null
at PinchRecognizer.recognizeWith (viewer3D.js?v=3.2.*:2300)
at Array.forEach (<anonymous>)
at each (viewer3D.js?v=3.2.*:923)
at invokeArrayArg (viewer3D.js?v=3.2.*:903)
at PinchRecognizer.recognizeWith (viewer3D.js?v=3.2.*:2294)
at new Autodesk.Viewing.GestureHandler (viewer3D.js?v=3.2.*:16042)
at GuiViewer3D.Viewer3D.createControls (viewer3D.js?v=3.2.*:44685)
at GuiViewer3D.Viewer3D.initialize (viewer3D.js?v=3.2.*:44758)
at GuiViewer3D.initialize (viewer3D.js?v=3.2.*:50852)
at GuiViewer3D.Viewer3D.start (viewer3D.js?v=3.2.*:44555)
Using Viewer.loadDocument(documentId,onDocumentLoad,onLoadFailed,accessControlProperties) is not an option, because we must load multiple models into the viewer.
Apologies for the late response, we have a backlog in the queue due to the IFC issue this week.
According to my experience, the accessControlProperties is not a required parameter for using ViewingApplication.loadDocument(). Could you consider providing a reproducible case demonstrating this issue to forge.help#autodesk.com? I'm glad to help you check what happened.
A non-confidential reproducible case contains following items:
A short exact description of what you are trying to achieve.
The behavior you observe versus what you expect, and why this is a problem.
Some complete yet minimal sample models to run a test in. For example, Revit sample models here: https://knowledge.autodesk.com/support/revit-products/getting-started/caas/CloudHelp/cloudhelp/2016/ENU/Revit-GetStarted/files/GUID-61EF2F22-3A1F-4317-B925-1E85F138BE88-htm.html.
A complete yet minimal Forge viewer app that can run and debugged.
Detailed step-by-step instructions for reproducing the issue, e.g. which element to pick, what command to launch etc.
Thanks for your reply, Eason - isolating the issue from our whole application was quite difficult, but made me finally find the problem myself:
We had a conflict with another JavaScript library that is included in our minified js file. The GestureRecognizer classes are named similar as in the camunda library which we are using for modelling bpmn processes. Solved it by excluding that library from the global js and include it only where it is needed, same as how we are dealing with forge library.
So, I'm building a plugin for logstash and I can't seem to find any documentation on how I should handle exceptions thrown and or rescued. So far, and similar to grok, we're adding a event["tag"] = ["_filter_error"], but in regards to metadata like a stacktrace, error type, etc... where should those live, or should they be omitted?
This is sort of a case-by-case question, so admittedly hard to answer. But I'll share how we ended up doing it so it might help someone.
Rescue all the exceptions (LogStash will hang otherwise)
Add a tag to the event event["tags"] = ["_filter_error"] so these can be query-able down the road
Ignore the stacktrace and error message (our decision - basically use the tag instead)
Use a single field as metadata about the tag we added to the event. For instance, if our filter blew up altogether, honey-badger it and move on. If our filter failed 1/2 through filtering, add as much data to the event as you can, add the tag in step 2, then create a metadata field (i.e. event["unknown_tags"] = [1,6,7] where our filter blew up at tags 1,6,7 but passed for everything else)
When I develop an android app, I run into the exception which I do not have any clue; I have googled related topics but none of them helped.
Fatal Exception: java.util.ConcurrentModificationException
java.util.HashMap$HashIterator.nextEntry (HashMap.java:806)
java.util.HashMap$KeyIterator.next (HashMap.java:833)
com.android.internal.util.XmlUtils.writeSetXml (XmlUtils.java:298)
com.android.internal.util.XmlUtils.writeValueXml (XmlUtils.java:447)
com.android.internal.util.XmlUtils.writeMapXml (XmlUtils.java:241)
com.android.internal.util.XmlUtils.writeMapXml (XmlUtils.java:181)
android.app.SharedPreferencesImpl.writeToFile (SharedPreferencesImpl.java:596)
android.app.SharedPreferencesImpl.access$800 (SharedPreferencesImpl.java:52)
android.app.SharedPreferencesImpl$2.run (SharedPreferencesImpl.java:511)
java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1112)
java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:587)
java.lang.Thread.run (Thread.java:841)
Preferences are thread safe(!), but not process safe. The answer of
#mohan mishra simply not true, no need to synchronize everything. The problem here, as statet out in another question is, that per documentation you MUST NOT modify any instance that is returned by getStringSet and getAll
getStringSet()
Note that you must not modify the set instance returned by this call.
The consistency of the stored data is not guaranteed if you do, nor is
your ability to modify the instance at all.
getAll()
Note that you must not modify the collection returned by this method,
or alter any of its contents. The consistency of your stored data is
not guaranteed if you do.
To the other question
Documentation
Please ensure that you are not accessing the preferences from any type of background thread. Also all your methods to add to preference must be synchronised(if you have your own preference managing class)
I was wondering how to make it so the rest of the program runs when one component fails to (and therefor the rest of the path that relied on this component is incapacitated as well). In other languages, this is equivalent to "catching an exception," but the added issue here is that I'm afraid that even if such a feature existed (cant find if it does), then the rest of the program would still try to run... Any advice would be very much appreciated. Thanks in advance!
LabVIEW doesn't have exception handling, but handles error in a different way: (nearly) all VIs accept an error cluster as input (and so should yours); if it is positive (an error occurred), the VI will return immediately, passing error as output, and next will get it as input, etc. This is called error.
As all these VIs transmit this cluster between each others you will get it in your top-level VI, so if error occurs you just have to cleanup stuff correctly it and exit.
I have a DLL with some COM objects. Sometimes, this objects crashes and register an error event in the Windows Event Log with lots of hexadecimal informations. I have no clue why this crashes happens.
So, How can I trace those COM objects exceptions?
The first step is to lookup the Fail code's hex value (E.G. E_FAIL 0x80004005). I've had really good luck with posting that value in Google to get a sense of what the error code means.
Then, I just use trial and error to try to isolate the location in code that's failing, and the root cause of the failure.
If you just want a really quick way to find out what the error code means, you could use the "Error Lookup" tool packaged with Visual Studio (details here). Enter the hex value, and it will give you the string describing that error code.
Of course, once you know that, you've still got to figure out why it's happening.
A good way to look up error (hresult) codes is HResult Plus or welt.exe (Windows Error Lookup Tool).
I use logging internally in the COM-classes to see what is going on. Also, once the COM-class is loaded by the executable, you can attach the VS debugger to it and debug the COM code with breakpoints, watches, and all that fun stuff.
COM objects don't throw exceptions. They return HRESULTs, most of which indicate a failure. So if you're looking for the equivalent of an exception stack trace, you're out of luck. You're going to have to walk through the code by hand and figure out what's going on.