I try to deploy my process and I have wrong rest endpoint,I can't press the deploy button
what is my problem?
Well there are two basic problems that come to my mind.
You didn't start camunda. If you are connecting to camunda through an app make sure that it's running. Try deploying again after your app is running successfully.
You are using the wrong port. Make sure that camunda is running on port 8081 as you stated on your endpoint. You can check whether the port is used or not by entering the netstat -an command to windows cmd. Something with :8081 should show up if it's used.
If you using an unmodified recent Camunda version then your REST endpoint URL is:
http://localhost:8080/engine-rest
Of course the server needs to be started / have started without errors.
Please also see:
How to deploy a Camunda modeled diagram into Camunda Tomcat
Related
I'm having trouble with setting up ACORE API's and then having them work on a website.
Background:
Azerothcore running 3.3.5 on a debian standalone server, this has the Database, Core files and runs both the world and auth server basically a standard setup that is shown in the how-to wiki.
I also have a standalone web server, on the same subnet, but it's a separate server running linux and normal web server stuff, this has a wordpress installation with azerothcore plugin for user signup etc.
I'm trying to add the player map (https://github.com/azerothcore/playermap) and the ACORE-API set of functions (server status, arenastats, BG que and wow statistics) (https://github.com/azerothcore/acore-api)
Problem:
I understand the acore-api must be run in a container (docker or whatever) on the server, which I have done and it binds to port 3000, I can then go to the local ip:3000 and it brings up this error. (all db's etc are connecting and soap is working)
error 404 when navigating to IP:3000
I do get a few errors when running NPM install seen here: I'm not sure if they would be causing any issues or not.
screenshot of NPM errors on install
But further that, when I put say 'serverstatus' on the webserver (separate server) and configure the config.ts file I can't seem to get anything to display.
I'm not sure what I'm doing wrong but is the same scenario for all of the different functions for the acore-api
How are these meant to be installed and function? I feel I'm missing a vital step.
Likewise, with PLAYERMAP I have edited the comm_conf.php and set the realmd_id, but when loading the page, I do get the map, but the uptime is missing and no players are shown?
Could someone assist if possible?
Seems like an issue with NodeJS version. Update your NodeJS to latest LTS version 16.13.0 (https://nodejs.org)
Hey this is my first question on here, so go easy.
I set up a Nextcloud server on my homelab in an ubuntu server 20.04 vm using the snap install. I have a seperate vm running nginx as a reverse proxy to my Nextcloud instance. Everything works flawlessly as intended, except that when I try and install apps on Nextcloud, I get a curl error #7. I've tried using my lan ip through the web ui, my public domain name through the web ui, and the commandline using the nextcloud.occ app:install command. I always get the same error. I tried to find the appropriate log file to get more information but looking in /var/snap/nextcloud/current/log/ I couldn't find any relevant info in any of the logs. Running php -m comes up with php not installed, I guess because php is installed via the Nextcloud snap? Obviously php is installed somewhere because Nextcloud is running, but I don't know how to look and see what modules are enabled, or how to install new ones using the snap. Any help on what to do is much appreciated!
enter image description here
Update: I fixed it. I think I had improperly configured my firewall, and turning it off (in proxmox)/making some changes to my /etc/netplan/*.yaml file to properly configure the static IP fixed it. GL
Another reason can be a wrongliy configured network. I forgot to set the gateway/proxy for IPv4, so github.com was unreachable. Most other services I use seem to resolve IPv6 first, so I did not have any other problems besides updating nextcloud apps.
I have an API in a .NET project that I'm running with Visual Studio Mac (8.4.3). I run it in release mode, and it opens a browser window with localhost:5000. The browser window says "ok". However, when I try to hit endpoints in that API, it fails very quickly. When I ran this API (ie. same code) from another server and accessed it via proxy, it ran fine. For example, when I ran it on a server whose IP was 162.250.198.98 and proxied into it, I would hit an endpoint like 162.250.198.98:3000/api/user and it would work, but now when I try to run localhost:5000/api/user, either from my app or from Postman, it fails almost instantaneously. When running it in Postman, I tried what it suggested by turning off 'SSL certificate verification' in Settings, but no change.
Can anyone advise me on how to approach troubleshooting this?
Wait, so You are saying that while trying to call API on 162.250.198.98:3000/api/user You are fine but while trying to do the same thing on localhost:5000/api/user You are getting an error? Would it might be possible You have Your API configured to receive calls at 3000? :)?
No, but really - please chech it out, maybe it is that simple, I'm couting on it :).
You can change/check it in Visual Studio: main project > Properties > Debug > App URL.
I am running the BrowserStackTunnel.jar by the grunt plugin grunt-exec
(Have been using node's child_process.exec, but same results)
with the command java -jar BrowserStackTunnel.jar -force APIKEY localhost,8000,false
What the Java file actualy does is connecting via ssh to an Amazon instance of Browserstack and opening a port on 45691, the website of browserstack is polling that port on localhost where the Java application serves a small snippet containing the params passed.
If i run the command from the CLI it works fine and i see the port beeing open on netstat. In the browserstack website i get the success screen.
But if i run the command from grunt-exec it shows only the SYN request.
The output to the command line is the same, both show success
I am not so sure what is causing this. I am running on windows7, node v0.10.12, grunt-cli v0.1.9, grunt v0.4.1 and grunt exec v0.4.2
Any idea what is causing this or how to debug it? I thought about a permission problem, but i am kind of clueless
I had the same problem and I realized, better if I use the BrowserStackLocal binary files for creating a tunel. I solved a quite complex configuration here: Ember.js - CircleCI - BrowserStack
BrowserStackLocal files are here: http://www.browserstack.com/local-testing (Binaries)
Have you tried using the Browserstack Chrome Plugin? It was launched this january and allows you to test local files without running the cli tunnel.
As soon as the child process is created, grunt moves on to the next command. If there is nothing, the grunt process terminates and takes the child with it.
Try adding a grunt-contrib-watch task after the grunt-exec call. It should keep the grunt process alive, and the child process with it.
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.