We have recently updated to the latest forge-api-java-client jar.
There are currently issues when calling /modelderivative/v2/designdata/{urn}/metadata during a PDF upload.
As the request object cannot be mapped into the Manifest response due to errors with unknown enums being returned for ManifestChildren.RoleEnum
Manifest -> ManifestDerivative -> ManifestChildren -> RoleEnum
I have been able to work around this issue by adding the four missing enums (leaflet, leaflet-zip, pdf-strings, pdf-page) to the jar and building it locally.
I have searched and cannot find any release notes around these new enums/response objects, and was wondering if I could get pointed in the right location for these changes so I can keep an eye on future updates.
Also I would like to confirm that there are not other changes in the recent updates that may affect other Manifest responses we have not yet seen.
Thank you for any help.
Thank you for bringing that up. The leaflet/pdf roles have been around for a while but I don't see them documented anywhere, either. I'll talk to the Model Derivative team and make sure that the roles are documented.
As for the Java SDK, please submit a Github issue or a pull request to https://github.com/Autodesk-Forge/forge-api-java-client and we'll take a look at it.
Related
I am trying to handle keyword policy violation error in google ads api. I am trying the given example. https://github.com/googleads/google-ads-php/blob/main/examples/ErrorHandling/HandleKeywordPolicyViolations.php
They say the error will be thrown in GoogleAdsException and it can be handled with the googleAdsException object. But I always get the error in ApiException.
Can anyone help me? Thank you in advance.
it's been a while, but I just stumbled across this. I had implemented it exactly as Google suggested. It worked just fine.
Now it no longer works. The only difference is that now I don't have grpc and protobuf compiled as an extension for PHP, but have pulled the packages in via composer as PHP source. And look, there is only the GoogleApiException. However, this contains all the necessary data, only I have to write a different handling.
Conclusion: I suspect it's because the PHP packages via composer give different results than the compiled PHP extensions.
I can't tell more precisely at the moment, because I can't test compiled extensions here right now.
I've read up about this error but the proposed solutions don't seem to work for .doc/.docx files.
I am building a web app which involves displaying pdf/doc files. The files are stored in a google storage bucket, and I am using Firebase's getDownloadURL() method to get a link which I can use as the source in an <iframe>. This works fine for PDF files directly. However, given that this direct display is not possible for doc/docx files, I tried displaying them through Google Docs Viewer by taking the generated URL and appending as follows:
https://docs.google.com/gview?url=https://firebasestorage.googleapis.com/v0/b/project-name.appspot.com/o/filename?alt=media&token=a-b-c-1-2-3
This yields a Refused to display <URL> in a frame because it set X-Frame-Options to same origin error. I have also tried adding an &embedded=true to the URL as has been suggested in other similar queries, but that yields another error: Unchecked runtime.lastError: Could not establish connection. Receiving end does not exist.
I thought this could be an issue with parsing the URL due to the "&", so I changed it to "%26", but the "sameorigin" error persists.
I'm not sure how to tackle this, and any guidance on how to resolve this issue (or alternative ways of solving the problem) would be greatly appreciated.
Google docs creates its own storage objects, and will only serve those objects. It won't display other objects that happen to be in doc/docx format from other repositories.
It sounds like you need a way to render objects you uploaded (using Firebase) to GCS. I don't have experience doing that specific thing but I suggest you try to find some software that does it. For example from a quick web search I found Render docx file in a browser.
With the latest ForgeARKit-update-6-2018.1, I was trying to load my model in Unity, with the sample Unity scene 'loadAtStartup'. I can successfully load the sample models from 'Sandbox', but I couldn't load my model, which was uploaded through script 'test-2legged'.
Error message shows 504, it seems not reaching the service:
AsyncRequestCompleted The remote server returned an error: (504) Gateway Time-out.
UnityEngine.Debug:Log(Object)
Autodesk.Forge.ARKit.RequestQueueMgr:AsyncRequestCompleted(Object, AsyncCompletedEventArgs) (at Assets/Forge/CodeBase/RequestQueue.cs:322)
UnityEngine.UnitySynchronizationContext:ExecuteTasks()
Model URN:
dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6bWFvbGlua3ppOHM3cnlvZWx4bjVndnR4bjcyZWc2N2l0dGp0a2MvMmZsb29yX0FyYy5pZmM=
[Update 23/4/2019]
I found that I can successfully load the same model with ForgeARKit-update-3-2017.1.2f1. I compare the Forge code in Unity. I think it has something to do with the service URL. The version 6 is fetching models from 'https://developer-api-beta.autodesk.io' while version 3 is fetching from 'https://developer-api.autodesk.io'. Meanwhile the shell script 'test-2legged' is uploading to the latter one ('https://developer-api.autodesk.io'). That is why it counldn'd find the resource. Question here is how can I upload model to the 'beta' ARKit? I tried modifying the URL in script 'test-2legged' but it doesn't work. Below screen-shot is the output of script 'test-2legged' when fetching from 'beta' ARkit. It seems model is uploaded successfully, but some parsing post-work failed. I guess the response format is also changed in the beta version. Is there a beta version of 'test-2legged' scripts (and other Scene Preparation scripts)?
Please comments, Thanks.
This is correct. My apologizes for this, I know we did not documented very well on the server changes.
This update6 assumes you are using the new server under beta right now. The scripts and update 3 are using the legacy server. Note that the 2 servers are not necessarily compatible and store the data in different places, so make sure to always use the same server in Unity as the one you used to prepare the scene. When we will switch everyone to the new server, we will transfer the data from the legacy server to the new server cloud storage.
The Update3 package will still be able to read scenes from the new server, as we make sure the old Unity code stays compatible.
Note as well you need to use SafeBase64 encoded string everywhere. I saw in your description that you are using base64 encoded (not safe). The new server will be more strict of parameters and format, so I encourage you to test your scripts/code on the beta server.
Last, I am working on a new Unity code update, and documentation which will be released next week. Make sure to use this version - it adds support for 3legged, automatic 2/3legged token refresh, and more. If you got scenes failing, please contact me directly and share your models and URN. I'll either test it on my development environment, or look into our log files for the reason to fail. My email address is my first name at autodesk.com
Thank you Cyrille for your help!! I am replying you here as it's easier to insert images.
I replaced the function 'xbase64encode()' with 'xbase64safeencode()', and now it works! However it seems for some model it still responds some error and in that case it cannot be loaded in Unity. (as the image below). I checked the script and I think all the encoding are using SafeBase64. Any clue of that? Or is that caused by my model?
BTW, the loading performance is greatly improved than the legacy version!! It looks almost the same as the web client. Huge Thanks for that!
Good to know that there is going to be an update next week. Yes I will test it and get back to you later.
I'm trying to add some functionality to an internal Access database that will automatically create tasks on Asana.
My VBA experience is somewhat limited but by examining various code samples online and tinkering I've been able to POST tasks with all the necessary data and GET info back.
But I'm now struggling with being able to upload file attachments to a task. I'm not sure how to go about it.
Leaving the content type as application/x-www-form-urlencoded which works for the normal POST statements when creating tasks and just pointing the send command to a file location using doesn't work and results in an error of "file is not an object", I'm guessing this is because all that's contained in the send command is a file=path pair.
Do I need to encode the file at all, if so how?
I'm hoping someone can point me in the right direction.
Thanks.
You can check out how curl does it, but I believe it needs to be multipart/form-data - I would strongly recommend using a library rather than doing the encoding manually, since there are often subtle gotchas.
Basically, it works a lot like a standard form upload from a web browser.
Hope that helps!
I have a Java applet related problem and I would appreciate your help. Here's the story:
I tried creating an applet, that would try to connect to digg.com and by using it's API, show the 100 most popular stories (also include some options to sort and filter the results).
Anyway, the applet opens and shows the GUI just fine in the browser, but when I press the button that loads the news, it won't load them, BUT the news are loaded, when I run the applet in Eclipse.
I thought, that maybe the problem is related to creating the runnable jar from eclipse, since I have some referenced libraries (Google GSON for handling JSON from digg.com). Here are the settings I used for creating the runnable jar (I also tried "Package required libraries into generated JAR):
http://img816.imageshack.us/img816/417/exportjar.png
Here's a picture of the applet (ran from eclipse), when the news have been loaded:
http://img841.imageshack.us/img841/9121/applet.png
I would appreciate any ideas on how to get loading the news to work in the web browser.
I think torah is right. Applets should be able to connect only to their own server. You can try and trick the browser, sending request back to your server asking it to retrieve the data and to return it to applet.
What happens when you attempt to open the connection to digg? Is there a security exception? I wouldn't be surprised to learn that the JVM inside the browser was implementing a same origin policy. If this is the case there should be some kind of Exception (SecurityException I think) being raised when you try to connect to digg.com.
A quick search for "same origin policy java" found the following article which both seems to confirm that this could be your problem.
http://www.zdnet.com/blog/security/defeating-the-same-origin-policy-part-1/946