Downloading yaml, get an error in json

[Ayssti]

Since a few days we cannot get our yaml with the download button.
It prints an error in json inside :
you can see it here https://pastebin.com/y3xWj6Xm

Our api is /apis/304

The error isn't readable for us and the sources seem ok..

[EricWittmann]

Thanks for the report. Looks like a null pointer exception.

Are you using the Try Live version of Apicurio or are you running it locally?

[EricWittmann]

Nevermind - I can see the error in Try Live logs. :)

This is a bit alarming - it's failing to load the nashorn JS script engine. This will need some sleuthing...

[EricWittmann]

OK I've been able to reproduce this on Try Live using my own API. The problem seems to be that the Nashorn engine fails to load, but only on one of the servers. Apicurio is split into a number of modules, each running on its own Server (well, its own OpenShift pod anyway). The two primary back-end components are the REST API and the real-time editing API. These are running on separate pods, and only the API is failing to load Nashorn.

So a possible workaround for you right now is to edit your API (make a small change somewhere) and then make sure all users exit the editing session for the API. Make sure no one is looking at the Design API page (the editor). Once all users have left the editing session, you should be able to successfully download the API design.

The reason for this is that the live editing server will rollup all of the edits (using Nashorn to execute the edits) and store the final result (API definition) in the database. Then the API server will be able to deliver the YAML to you because it will not even try to load the script engine.

Now, WHY the API server can't load Nashorn is a bigger mystery that I need to figure out...

But please give the above workaround a try and let me know what happens. If it still doesn't work we'll try restarting the pod...

[Ayssti]

Thanks for the fast reply, the workaround worked 😃

[EricWittmann]

Great! That buys me some time. 🤪

…

On Wed, Feb 28, 2018 at 11:17 AM Ayssti ***@***.***> wrote: Thanks for the fast reply, the workaround worked 😃 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#252 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABzZj3Q-fg-cTNI9JslcHF5n9NdpTi2Kks5tZXj3gaJpZM4SWRlo> .

[EricWittmann]

For some reason, the nashorn script engine was not being loaded in the -api WF Swarm app. It was working fine in the -ws WF Swarm app. In Java, the script engine is loaded via a ServiceLoader, and the nashorn script engine factory service loader spec file was not being found by the TCCL of the -api swarm app. Still not sure why that is. :( I'm going to write up a WF Swarm bug for that.

For now, I've fixed this by adding a file to the Swarm app itself:

META-INF/services/javax.script.ScriptEngineFactory

This allows the classloader to find it and properly initialize the engine. Temporary fix only - we should figure out what's happening with the classloader in WF Swarm.

[EricWittmann]

Note: the fix for this has now been pushed to the Try Live version of Apicurio - so it should be working OK across the board now.