mean.io fails to listen on localhost:3000 following steps in documentation
It stops with the messages below:
C:\meanio\myapp>node server.js
for real!
forking 0
forking 1
forking 2
forking 3
I followed steps from learn.mean.io:
It was working in version
{
"name": "mean",
"description": "MEAN.io: A fullstack JavaScript framework powered by MongoDB, ExpressJS, AngularJS, NodeJS.",
"version": "0.5.5",
"private": false,
"author": "Linnovate <mean#linnovate.net>",
"contributors": "https://github.com/linnovate/mean/graphs/contributors",
"mean": "0.5.5",
Now I am trying with version
{
"name": "mean",
"description": "MEAN.io: A fullstack JavaScript framework powered by MongoDB, ExpressJS, AngularJS, NodeJS.",
"version": "0.6.1",
"private": false,
"author": "Linnovate <mean#linnovate.net>",
"contributors": "https://github.com/linnovate/mean/graphs/contributors",
"mean": "0.6.1",
If any body know why it is getting stuck, please let me know.
instead of npm test start your dev server with gulp
Related
I have a Flutter UI (Web channel) app that is deployed as a bundled Spring-boot app ( build files dropped into the main/resources folder in the Spring-boot project). The issue I'm facing is that every time I load the app in Chrome and login I see a 401 error pointing to the manifest.json.
I don't face the same issue when I test my UI locally using Android Studio. This setup uses a modified version of the spring-boot app that is running in Docker.
My manifest.json file is :
{
"name": "ccccc",
"short_name": "ccccc",
"start_url": "/#/",
"display": "standalone",
"background_color": "#0175C2",
"theme_color": "#0175C2",
"description": "basicapp",
"orientation": "landscape-primary",
"prefer_related_applications": false,
"icons": [
{
"src": "icons/cd-16.png",
"sizes": "16x16",
"type": "image/png"
},
{
"src": "icons/cd-32png",
"sizes": "32x32",
"type": "image/png"
},
{
"src": "icons/cd-64.png",
"sizes": "64x64",
"type": "image/png"
},
{
"src": "icons/cd-256.png",
"sizes": "256x256",
"type": "image/png"
}
]
}
And the error that I see is :
{"timestamp":"2021-09-30T18:34:24.329+00:00","status":401,"error":"Unauthorized","message":"","path":"/manifest.json"}
I thought this problem was similar to this but that fix did not work.
I then removed the reference to manifest.json from my index.html
i e. <link rel="manifest" href="manifest.json"> and that got rid of the error but not sure if that is the right thing to do.
Not sure what the issue is here, it does not stop me from logging into the app but it's just an annoyance to see that as the first thing in the console log.
Any help/assistance to fix this is greatly appreciated.
You should try this solution where <link> must use crossorigin="use-credentials" tag. I was having the same problem that you and this solved it. Hope you too!
I am using Botium-CLI and WebdriverIO connector. I am unable to find any documentation which explains how to run the driver in headful mode (its headless by default) and also how can we modify the botium.json to trigger execution in Selenium Grid. I tried use this, didn't work :
"WEBDRIVERIO_OPTIONS": {
"capabilities": {
"browserName": "chrome"
}
"protocol": "http",
"host": "localhost",
"port": "4444",
"path": "/wd/hub"
}
Please note, I am looking for solutions for Botium CLI, not Botium Box.
With Botium Webdriver Connector, there are basically 4 ways to use Selenium.
As noticed in the question a headless Chrome can be used, see Github docs.
Botium can make use of Selenium Standalone to launch a local Selenium service on test execution, see Github docs. It requires some preparation to install the browser-specific webdrivers.
Botium can connect to your local Selenium server. You can launch your own with the help of Docker - there are instructions available for Botium Box in the Botium Box Wiki, but most of it applies to Botium CLI as well - you you have to configure the Selenium endpoint in the botium.json:
"WEBDRIVERIO_OPTIONS": {
"capabilities": {
"browserName": "chrome"
}
"protocol": "http",
"host": "my-selenium-server",
"port": "4444",
"path": "/wd/hub"
}
Finally, you can also connect to a cloud device service like Saucelabs - every provider with a public Selenium endpoint should work. Parameters are to be given in the botium.json:
"WEBDRIVERIO_OPTIONS": {
"capabilities": {
"deviceName": "Samsung Galaxy S6 GoogleAPI Emulator",
"platformName": "Android",
"platformVersion": "7.0",
"browserName": "Chrome",
"__browserName": "chrome",
"name": "Banking Chatbot Tests",
"tags": "botium, chatbot",
"username": "xxx",
"accessKey": "xxxxx"
},
"protocol": "https",
"hostname": "ondemand.saucelabs.com",
"port": 443
}
When attempting to run the debugger for the Microsoft Office Add-In Debugger extension for VS Code, I get this error when clicking the 'Play' button:
I have seen this question asked multiple times before for Chrome, but nothing specifically for Microsoft Office Add-Ins.
I have tried:
Restarting VS Code and restarting my machine
Running netstat -an | find /i "listening" to view which ports are listening on my machine, and tried replacing port 9222 with each of these ports for the "port" value in launch.json
Tried updating the port key to target port 4200, (the port which my application is hosted on, https://localhost:4200)
Verifying that the webRoot is the correct path.
Removing the port key in launch.json entirely
For reference, I am running this web add-in in Outlook native on Windows 10 version 1903.
From what I can tell, my launch.json seems okay:
{
// Use IntelliSense to learn about possible attributes.
// Hover to view descriptions of existing attributes.
// For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
"version": "0.2.0",
"configurations": [
{
"name": "Launch index.html",
"type": "office-addin",
"request": "launch",
"file": "${workspaceRoot}/index.html",
"browserTarget": "Edge"
},
{
"name": "Launch localhost with sourcemaps",
"type": "office-addin",
"request": "launch",
"url": "http://localhost/mypage.html",
"sourceMaps": true,
"webRoot": "wwwroot",
"webviewTarget": "Edge"
},
{
"type": "office-addin",
"request": "attach",
"name": "Attach to Office Add-ins",
"port": 53483,
"trace": "verbose",
"url": "https://localhost:4200/index.html?_host_Info=Outlook$Win32$16.01$en-US$$$$0",
"webRoot": "${workspaceFolder}/app",
"timeout": 45000
}
]
}
I've walked through the documentation here several times but no luck. Does anyone have any idea on how to get around this so that I can run the debugger for my Outlook web Add-In?
If you worked this out, please come back here and post an explanation so you can help us, as well as us helping you.
Note: you need to tag your office-js questions with office-js (that's what the Office JS Microsoft employees listen to and reply on)
Meanwhile - this workaround seems useful to me:
Put this into your taskpane.html:
<textarea id="out" rows=10 cols=46>debug info here</textarea>
And then instead of using console.log() you can use something like this:-
document.getElementById("out").value += "Ready...\n";
Also - it looks like you can install DevTools and the old EdgeHTML engine (by installing JavascriptBrowser) as per my comments here: Can someone from Microsoft please write a working instruction for how to debug Microsoft-365 Apps now-days (post-August-2021)
So we are using Azure Service Fabric and gets a weird behavior when trying to run API tests against my local development cluster.
Every time I start the test the app gets terminated, sometimes it gets restarted again but most often it just stays terminated (and even deleted from the cluster).
I guess its somehow connected against that when I run the API test it will run and build stuff that the service fabric is using, but since the outcome is different depending on something (maybe the sun?) it feels like I am either missing something or experience a bug with service fabric.
Do anyone have any idea? Consider me as a noob and assume that I have done something wrong myself (I am doing that atleast).
UPDATE
There was a question on how we do run our tests:
Starts 2 instances of Visual Studio
Open the same .sln in both of them
Start the Service Fabric project.
Wait until cluster reports OK.
Run api test through a unit test (both service bus tests and REST tests) with Resharper test runner
Now we get the messages that is attached in diagnostics.
Diagnostics:
Event #1
{
"Timestamp": "2018-10-16T08:14:03.0590414+02:00",
"ProviderName": "Microsoft-ServiceFabric",
"Id": 23083,
"Message": ApplicationHostTerminated: ApplicationId=fabric:/<MyService>, ServiceName=fabric:/<MyService>, ServicePackageName=<MyPackage>, ServicePackageActivationId=8f36ac97-9271-4a49-94ce-dd296aebffa5, IsExclusive=True, CodePackageName=Code, EntryPointType=Exe, ExeName=MyExe, ProcessId=24568, HostId=d2a820b5-5b4d-42af-ae87-350028a3fa72, ExitCode=3221225786, UnexpectedTermination=False, StartTime=10/16/2018 08:12:14. ",
"ProcessId": 22660,
"Level": "Informational",
"Keywords": "0x4000000000000001",
"EventName": "Hosting",
"ActivityID": null,
"RelatedActivityID": null,
"Payload": {
"eventInstanceId": "\"07f15452-2f75-49e3-ad5d-d16ea49bdc8f\"",
"applicationName": "MyAppName",
"ServiceName": "fabric:/MyServiceName",
"ServicePackageName": "MyPackageName",
"ServicePackageActivationId": "8f36ac97-9271-4a49-94ce-dd296aebffa5",
"IsExclusive": true,
"CodePackageName": "Code",
"EntryPointType": 1,
"ExeName": "MyExe",
"ProcessId": 24568,
"HostId": "d2a820b5-5b4d-42af-ae87-350028a3fa72",
"ExitCode": 3221225786,
"UnexpectedTermination": false,
"StartTime": "\"\/Date(1539670334917)\/\""
}
}
Event #2
{
"Timestamp": "2018-10-16T08:14:02.3557708+02:00",
"ProviderName": "Microsoft-ServiceFabric",
"Id": 29625,
"Message": "Application deleted: Application = fabric:/MyApp, Application Type = MyServiceType ",
"ProcessId": 22660,
"Level": "Informational",
"Keywords": "0x4000000000000001",
"EventName": "CM",
"ActivityID": null,
"RelatedActivityID": null,
"Payload": {
"eventInstanceId": "\"ca608cec-8d55-4606-a331-8ebfcfff8fa6\"",
"applicationName": "fabric:/MyAppName",
"applicationTypeName": "MyAppTypeName",
"applicationTypeVersion": "1.0.0"
}
}
I think you can experience a side effect of Application Debug Mode set for your .sfproj.
By default Application Debug Mode is set to Refresh Application (which if you are using 5-node cluster is automatically changed to Remove Application) or Remove Application debug mode. This instructs Visual Studio to recreate the application for each debugging session and remove it when session ends.
Changing it to Keep Application should prevent the Visual Studio from recreating the application during debugging session.
I am trying to see why my Sensu Client does not connect to my Sensu Server.
How can I see the status of the client and whether it tried, succeeded, failed in connecting with the server?
I have installed Sensu Server on CentOS using docker. I can connect to it, the RabbiMQ and Uchiwa panel from my host.
I have installed Sensu Client on Windows host.
I have added following configs:
C:\etc\sensu\conf.d\client.json
{
"client": {
"name": "DanWindows",
"address": " 192.168.59.3",
"subscriptions": [ "all" ]
}
}
C:\etc\sensu\config.json
{
"rabbitmq": {
"host": "192.168.59.103",
"port": 5671,
"vhost": "/sensu",
"user": "sensu",
"password": "password",
"ssl": {
"cert_chain_file": "C:/etc/sensu/ssl/cert.pem",
"private_key_file": "C:/etc/sensu/ssl/key.pem"
}
}
}
I have installed and started the Sensu Client service using following command:
sc create sensu-client binPath= C:\Tools\sensu\bin\sensu-client.exe DisplayName= "Sensu Client"
On the Uchiwa panel I do not see any clients.
The "sensu-client.err.log" and "sensu-client.out.log" are empty, while "sensu-client.wrapper.log" contains this:
2015-01-16 13:41:51 - Starting C:\Tools\sensu\embedded\bin\ruby C:\Tools\sensu\embedded\bin\sensu-client -d C:\etc\sensu\conf.d -l C:\Tools\sensu\sensu-client.log
2015-01-16 13:41:51 - Started 3800
How can I see the status of the Windows client and whether it tried, succeeded, failed in connecting with the server?
Question on the docker, is this one you built yourself? I recently built my own as well only using Ubuntu instead of CentOS.
Recent versions of sensu require the following two files in the /etc/sensu/conf.d directory:
/etc/sensu/conf.d/rabbitmq.json
/etc/sensu/conf.d/client.json
The client.json file will have contents similar to this:
{ "client": {
"name": "my-sensu-client",
"address": "192.168.x.x",
"subscriptions": [ "ALL" ] }
}
The only place I have heard of needing a config.json file is on the sensu-server. But I have only recently been looking at sensu so this may be an older sensu requirement.