I'm having the same problem as this github issue.
On p. 110, the final version of Phoenix in Action 1.4 says,
You need to do one more thing before you can start up the server.
Phoenix requires you to let it know which library you’d like it to use
when processing data in JSON format. The default library that Phoenix
uses is called Jason, and it’s what you’ll use as well. In the top
level of your umbrella application, you need to configure the Phoenix
dependency to use Jason. In auction_umbrella/config/config.exs, add
the last line in the following listing:
use Mix.Config
import_config "../apps/*/config/config.exs"
config :phoenix, :json_library, Jason
I did that, but when I cd into the apps/auction_web dir, and try to start the server:
$ iex -S mix phx.server
I get the error:
Erlang/OTP 20 [erts-9.3] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:10] [hipe] [kernel-poll:false]
warning: failed to load Jason for Phoenix JSON encoding
(module Jason is not available).
Ensure Jason exists in your deps in mix.exs,
and you have configured Phoenix to use it for JSON encoding by
verifying the following exists in your config/config.exs:
config :phoenix, :json_library, Jason
(phoenix) lib/phoenix.ex:40: Phoenix.start/2
(kernel) application_master.erl:273: :application_master.start_it_old/4
Compiling 11 files (.ex)
== Compilation error in file lib/auction_web/endpoint.ex ==
** (ArgumentError) invalid :json_decoder option. The module Poison is not loaded and could not be found
(plug) lib/plug/parsers/json.ex:54: Plug.Parsers.JSON.validate_decoder!/1
(plug) lib/plug/parsers/json.ex:32: Plug.Parsers.JSON.init/1
(plug) lib/plug/parsers.ex:245: anonymous fn/3 in Plug.Parsers.convert_parsers/2
(elixir) lib/enum.ex:1899: Enum."-reduce/3-lists^foldl/2-0-"/3
(plug) lib/plug/parsers.ex:228: Plug.Parsers.convert_parsers/2
(plug) lib/plug/parsers.ex:224: Plug.Parsers.init/1
(plug) lib/plug/builder.ex:302: Plug.Builder.init_module_plug/4
(plug) lib/plug/builder.ex:286: anonymous fn/5 in Plug.Builder.compile/3
~/phoenix_apps/auction_umbrella/apps/auction_web$
Other info:
$ mix phx.new --version
Phoenix v1.4.0
Then I tried adding the jason dependency to both the mix.exs file for the umbrella app as well as the mix.exs file for the auction_web app, then I did mix deps.get in both directories containing the mix.exs file, and I still get the same error when I try to start the server.
I think you're followup answer states that you figured it out, but you add the dependency configuration to auction_umbrella/config/config.exs.
I added the :jason dependency to the auction_web mix.exs file, then did mix deps.get, then the server started.
Does this mean everything is working for you now?
Aargh! I mis-typed phoneix (should be phoenix) in the config file.
Then, I deleted the :jason dependencies from both mix.exs files, then I did mix deps.get (to rewrite the lock files), then mix deps.clean jason, and when I tried to start the server I got the same error.
So, to which mix.exs file should I add the :jason dependency? I added the :jason dependency to the auction_web mix.exs file, then did mix deps.get, then the server started.
Related
I'm trying to use the Kube OpenAPI tool openapi-gen to generate OpenAPI specs for Google's Config Connector.
I'm relatively new to Go, so I'm not sure whether this is a configuration error on my part or if I'm simply using it wrong.
I've cloned the Kube OpenAPI repo, and inside of that directory I've cloned the Config Connector repo, for simplicity.
This is what's happening when I try to generate an OpenAPI spec file.
$ go run cmd/openapi-gen/openapi-gen.go -i ./k8s-config-connector/pkg/apis/serviceusage/v1beta1 -p foo.com/foo -h ./boilerplate/boilerplate.go.txt
E0811 16:45:57.516697 22683 openapi.go:309] Error when generating: TypeMeta, TypeMeta invalid type
2021/08/11 16:45:57 OpenAPI code generation error: Failed executing generator: some packages had errors:
failed to generate default in ./k8s-config-connector/pkg/apis/serviceusage/v1beta1.Service: TypeMeta: not sure how to enforce default for Unsupported
exit status 1
What's going on here?
Here are some troubleshooting steps:
1 - GOROOT variable should be set and point to root of go installation
2- Operator-sdk depended on it being exported as an environment variable. Run the below command
export GOROOT=$(go env GOROOT)
when using the operator-sdk, it is necessary to either (a) set GOROOT in your environment, or (b) use the same GOROOT that was used to build the operator-sdk binary.
Refer to the link for additional information.
I am a newbie in go and go-swagger. I am following steps in Simple Server tutorial in goswagger.io.
I am using Ubuntu 18.04, swagger v0.25.0 and go 1.15.6.
Following the same steps, there are a few differences of the files generated. For instance, goswagger.io's has find_todos_okbody.go and get_okbody.go in models but mine does not. Why is that so?
Link to screenshot of my generated files vs
Link to screenshot of generated files by swagger.io
Starting the server as written in the tutorial go install ./cmd/todo-list-server/ gives me the following error. Can anyone please help with this?
# my_folder/swagger-todo-list/restapi
restapi/configure_todo_list.go:41:8: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
restapi/configure_todo_list.go:42:6: api.TodosGetHandler undefined (type *operations.TodoListAPI has no field or method TodosGetHandler)
The first step in goswagger.io todo-list is swagger init spec .... Which directory should I run this command in? I ran it in a newly created folder in my home directory. However, from the page, it shows the path to be ~/go/src/github.com/go-swagger/go-swagger/examples/tutorials/todo-list. I am not sure whether I should use go get ..., git clone ... or create those folders. Can someone advise me?
Thanks.
This is likely the documentation lagging behind the version of the code that you are running. As long as it compiles, the specific files the tool generates isn't so crucial.
This is a compilation error. When you do go install foo it will try to build the foo package as an executable and then move that to your GOPATH/bin directory. It seems that the generated code in restapi/configure_todo_list.go isn't correct for the operations code generated.
All you need to run this tutorial yourself is an empty directory and the swagger tool (not its source code). You run the commands from the root of this empty project. In order not to run into GOPATH problems I would initialise a module with go mod init todo-list-example before doing anything else.
Note that while the todo-list example code exists inside the go-swagger source, it's there just for documenting example usage and output.
What I would advice for #2 is to make sure you're using a properly released version of go-swagger, rather than installing from the latest commit (which happens when you just do a go get), as I have found that to be occasionally unstable.
Next, re-generate the entire server, but make sure you also regenerate restapi/configure_todo_list.go by passing --regenerate-configureapi to your swagger generate call. This file isn't always refreshed because you're meant to modify it to configure your app, and if you changed versions of the tool it may be different and incompatible.
If after that you still get the compilation error, it may be worth submitting a bug report at https://github.com/go-swagger/go-swagger/issues.
Thanks #EzequielMuns. The errors in #2 went away after I ran go get - u -f ./... as stated in
...
For this generation to compile you need to have some packages in your GOPATH:
* github.com/go-openapi/runtime
* github.com/jessevdk/go-flags
You can get these now with: go get -u -f ./...
I think it's an error of swagger code generation. You can do as folloing to fix this:
delete file configure_todo_list.go;
regenerate code.
# swagger generate server -A todo-list -f ./swagger.yml
Then, you can run command go install ./cmd/todo-list-server/, it will succeed.
I have a React application with ApolloClient with Apollo-Link-Schema. The application works fine locally but in our staging environment (using GOCD), we get the following error:
Uncaught Error: Cannot use e "__Schema" from another module or realm.
Ensure that there is only one instance of "graphql" in the node_modules
directory. If different versions of "graphql" are the dependencies of other
relied on modules, use "resolutions" to ensure only one version is installed.
https://yarnpkg.com/en/docs/selective-version-resolutions
Duplicate "graphql" modules cannot be used at the same time since different
versions may have different capabilities and behavior. The data from one
version used in the function from another could produce confusing and
spurious results.
at t.a (instanceOf.mjs:21)
at C (definition.mjs:37)
at _ (definition.mjs:22)
at X (definition.mjs:284)
at J (definition.mjs:287)
at new Y (definition.mjs:252)
at Y (definition.mjs:254)
at Object.<anonymous> (introspection.mjs:459)
at u (NominationsApprovals.module.js:80)
at Object.<anonymous> (validate.mjs:1)
Dependencies are installed with yarn, I've added the resolutions field to the package.json.
"resolutions": {
"graphql": "^14.5.8"
},
I've checked the yarn.lock and can only find one reference for the graphql package.
npm ls graphql does not display any duplicates.
I thought maybe its a build issue with webpack - I have a different build script for staging, but running that locally I am still able to get the react application to run with that bundle.
Can anyone suggest anything else to help me fix this?
I managed to find the cause of the issue, if this helps anyone else. The issue is not to do with duplicate instances of the package at all, this is a false positive triggered by us using webpack's DefinePlugin to set the process.env.NODE_ENV to staging for our staging build.
However, in webpack the mode (see https://webpack.js.org/configuration/mode/), which sets the process.env.NODE_ENV, only accepts none, development and production as valid values. This was triggering an env check in the graphql package to fail and trigger this error message.
In our case, we need to differentiate between staging and production as our API endpoint differs based on this, but the solution we implemented is to not rely on the process.env.NODE_ENV, but to assign a custom variable on build (e.g. process.env.API_URL)
I would try to replicate the error locally and debug it:
try this:
rm -rf node_modules yarn.lock
# also remove any lock files if you have package-lock.json too
yarn install
# build the project locally and see if you got the error
I got this problem one time where I was working with Gatsby and 2 different themes where using different versions of GraphQL. Also be more explicit with the version (without caret) and check if the error persist.
do you have a repo youc an share? that would also help us to help you :)
While changing NODE_ENV to production might solve the issue, if you have different variables for each environment and don't want to mess with your metrics this is not an ideal solution.
You said you use webpack. If the build with the issue uses some kind of source-map in your devtool, you might want to disable that to see if the problem persists. That's how I solved this without setting my NODE_ENV to production.
I had a similar problem when trying to run Apollo codegen and was able to fix it by deduping my npm packages. Run this:
rm -rf node_modules && npm i && npm dedupe
I was having this problem so I switched to yarn, and after deleting node_modules and npm lockfile, then running yarn, the problem went away :-).
I ended up here because I use the AWS CDK and the NodejsFunction Construct. I was also using bundling with minify: true.
Toggling minify to false resolved this for me.
I try to configure elm-coverage to be used in CI.
Installation was successful, installed using yarn as "elm-coverage": "0.2.0"
Our most recent command for running tests is
./node_modules/.bin/elm-test --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
app/frontend/ is there, because elm app is within repository of rails app.
When I try to use coverage
elm-coverage --elm-test ./node_modules/.bin/elm-test -- --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
in (ruby app's) root, it returns
MacBook-Pro-6:enectiva admin$ elm-coverage --elm-test ./node_modules/.bin/elm-test -- --compiler ./node_modules/.bin/elm app/frontend/elm/tests/
/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:33
throw err;
^
Error: does not exist.
at Object.notExist (/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:41:12)
at traverseAsync (/Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:163:28)
at /Users/admin/git.enectiva.cz/enectiva/node_modules/elm-coverage/node_modules/find/index.js:282:7
at _combinedTickCallback (internal/process/next_tick.js:131:7)
at process._tickCallback (internal/process/next_tick.js:180:9)
Otherwise, I tried
MacBook-Pro-6:enectiva admin$ elm-coverage app/frontend/elm/tests/ --elm-test ./node_modules/.bin/elm-test
[12:57:01.68] Instrumenting sources...
[12:57:01.89] Something went wrong:
I searched through issues in Github repository, it does not seem to be reported bug, so there must be something I missed.
Does anyone know, how to actually use it?
OK, I've had a bit more of a play with elm-coverage, as I've been able to get it to run on an Elm project of mine.
Firstly elm-coverage has a --verbose flag which adds extra logging, so try running with that.
I've had best results if I cd to the folder containing my elm.json file and run elm-coverage from there. In your case, this would look something like the following:
cd app/frontend/elm && elm-coverage [source folder] --elm-test ../../../node_modules/.bin/elm-test
[source folder] is the name of the folder containing your source files (not the tests). For me, [source folder] is src, but because that's the default I can omit it.
I'm trying to use JODConverter on top of jetty and sinatra. Whenever I fire up my Jetty server, which has the sinatra application deployed to it in a war. i get this exception (much cruft removed):
java.lang.IllegalStateException: invalid officeHome: it doesn't contain soffice.bin:
in my settings.yml file I have the following:
secret: Whatever_you_want_it_to_be
PARAMETER_OFFICE_PORT: 8100
PARAMETER_OFFICE_HOME: /Volumes/OpenOffice.org 3.3/OpenOffice.org.app/Contents/MacOS
PARAMETER_OFFICE_PROFILE: /Applications/OpenOffice.org.app/Contents/MacOS
and here are the contents of those last two directories:
>ls '/Volumes/OpenOffice.org 3.3/OpenOffice.org.app/Contents/MacOS'
about.png crashrep intro.png sbase sdraw simpress soffice sofficerc testtool unopkg urelibs
boot straprc fundamentalrc resource scalc setuprc smath soffice.bin swriter unoinfo unopkg.bin versionrc
>ls /Applications/OpenOffice.org.app/Contents/MacOS
about.png crashrep intro.png sbase sdraw simpress soffice sofficerc testtool unopkg urelibs
bootstraprc fundamentalrc resource scalc setuprc smath soffice.bin swriter unoinfo unopkg.bin versionrc
Notice that both ls's show "soffice.bin" in them
update:
I've also tried this:
> sudo chmod 777 '/Volumes/OpenOffice.org 3.3/OpenOffice.org.app/Contents/MacOS/soffice.bin'
Password:
chmod: Unable to change file mode on /Volumes/OpenOffice.org 3.3/OpenOffice.org.app/Contents/MacOS/soffice.bin: Read-only file system
I've also tried using the second directory for office_home and vice versa. no luck.
If anyone still has the same problem (as I did) the problem was, that the parameter OfficeHome for Mac has to specify the folder "Contents", not the folder "Contents/MacOs/".
The JODConverter is checking if the following exists:
new File(officeHome, "MacOS/soffice.bin")
So the OpenOffice home folder should have been /Applications/OpenOffice.org.app/Contents.
Sounds like you're either missing a JAR file or there may be a conflict in the JAR files being used. Although it's not JRuby, this post should shed some light: http://groups.google.com/group/jodconverter/browse_thread/thread/cdf6600288bfba5a/8ed4558cfde08e39