I was trying to run a ballerina program on IntelliJ Idea. Then, Edit configuration appears and it says
Error: Main run kind is selected, but the file does not contain a main function.
What should I do ? And what should I select in Program Arguments.
source code:
import ballerina.net.http;
import ballerina.lang.messages;
#http:BasePath {value:"/helloservice"}
service helloService {
#http:GET {}
#http:PATH {value:"/hello?name={name}"}
resource hello (message m, #http:QueryParam {value:"name"} string name) {
string respStr = "Hello, World " + name + "!\n";
message responce = {};
messages:setStringPayload(response, respStr);
reply response;
}
}
Seems like the issue here is, you have manually created a main run configuration and trying to run a service using that. Please select the service run kind in configuration as shown below.
Also, you don't have to manually create a run configurations. IntelliJ IDEA plugin can automatically detect the run kind when you run a main function or services using gutter run icon like below.
Run configuration is automatically created.
If you first run a main and then run a service, the run configuration will be automatically changed according to that as well. So no manual intervention is needed.
On the side notes, the code seems to have much older Ballerina syntax and I would advice using the latest Ballerina syntax to avoid any issues with the latest IntelliJ IDEA plugin. Please refer Ballerina examples for latest syntax.
Related
I am using mobDebug. If run a lua script from command line everything works.
But when I run them from openresty the Idea doesn't stop. It only writes "Connected/ Disconnected"
Configs:
location / {
access_by_lua_block {
local client = require("client")
}
client.lua:
local mobdebug = require("mobdebug");
mobdebug.start()
local lfs = require("lfs")
print("Folder: "..lfs.currentdir())
modebug debug_hook is not invoked for needed lines, set_breakpoints don't invoked.
Idea Debug Logs, but nothing occures:
Idea catch debug from terminal client.lua; But it miss it from running nginx.
THIS IS NOT AN ANSWER. It's just that I am experiencing basically the same problem, and comment space is too small to fit all the relevant observations I would like to share:
I was actually able to stop immediately after mobdebug.start() in code running in nginx, and to step-debug - but only in code called directly from init_by_lua_block. This code of course executes once during the server startup or config reload.
I was never able to stop in worker code (e.g. rewrite_by_lua_*). mobdebug.coro() didn't help, and mobdebug.on() threw about "attempt to yield across C-call boundary"
I was only ever able to stop one time, on next statement after mobdebug.start(); once I hit |> (Resume program), it won't stop on any further breakpoints.
Using mobdebug.loop() is not a correct way to do this, as it's used for live coding, which is not going to work as expected with this setup. mobdebug.start() should be used instead.
Please see an example of how this debugging can be setup with ZeroBrane Studio here: http://notebook.kulchenko.com/zerobrane/debugging-openresty-nginx-lua-scripts-with-zerobrane-studio. All the details to how paths to mobdebug and required modules are configured should still be applicable to your environment.
The recommended testing framework for Meteor 1.7 seems to be meteortesting:mocha.
With Meteor 1.7.0.3 I created a default app (meteor create my-app), which has the following tests (in test/main.js)
import assert from "assert";
describe("my-app", function () {
it("package.json has correct name", async function () {
const { name } = await import("../package.json");
assert.strictEqual(name, "noteit");
});
if (Meteor.isClient) {
it("client is not server", function () {
assert.strictEqual(Meteor.isServer, false);
});
}
if (Meteor.isServer) {
it("server is not client", function () {
assert.strictEqual(Meteor.isClient, false);
});
}
});
I ran
meteor add meteortesting:mocha
meteor test --driver-package meteortesting:mocha
and with meteortesting:mocha#2.4.5_6 I got this in the console:
I20180728-12:06:37.729(2)? --------------------------------
I20180728-12:06:37.729(2)? ----- RUNNING SERVER TESTS -----
I20180728-12:06:37.729(2)? --------------------------------
I20180728-12:06:37.729(2)?
I20180728-12:06:37.730(2)?
I20180728-12:06:37.731(2)?
I20180728-12:06:37.737(2)? the server
✓ fails a test.753(2)?
I20180728-12:06:37.755(2)?
I20180728-12:06:37.756(2)?
I20180728-12:06:37.756(2)? 1 passing (26ms)
I20180728-12:06:37.756(2)?
I20180728-12:06:37.757(2)? Load the app in a browser to run client tests, or set the TEST_BROWSER_DRIVER environment variable. See https://github.com/meteortesting/meteor-mocha/blob/master/README.md#run-app-tests
=> Exited with code: 0
=> Your application is crashing. Waiting for file change.
Actually, it was repeated three times. Not pretty. And I wasn't expecting a passing test to crash my app.
Also in the browser I got this
I was expecting something more like the nice output, as per the Meteor testing guide:
As with most things Node.js, there are a multitude of forks of almost anything. So also with meteortesting:mocha.
cultofcoders:mocha seems to be a few commits ahead of practicalmeteor:mocha, which was at one point the recommended testing framework for Meteor.
If you run
meteor add cultofcoders:mocha
meteor test --driver-package cultofcoders:mocha
you'll get the nice output.
As a curiousity, I found that the version of cultofcoders:mocha I got (meteor list | grep mocha) was 2.4.6, a version that the github repo does not have...
The screenshot, you reference to, is made using practicalmeteor:mocha, but meteortesting:mocha is not (as the other answer claims) a fork of it but a separately developed package, aiming for the same goal, which is running of tests in Meteor.
The usage of the packages is very different and practicalmeteor:mocha might look a bit trickier to set up and this list only applies to it's version 1.0.1 and might change later.
But I have to admit that the documentation needs a refresh ... Anyways, here are some helpful tipps which I'll include in the documentation soon.
If you just want to get started, run this:
meteor add meteortesting:mocha
npm i --save-dev puppeteer#^1.5.0
TEST_BROWSER_DRIVER=puppeteer meteor test --driver-package meteortesting:mocha --raw-logs --once
Do you want to exit after the tests are completed or re-run them after file-change?
Usually, Meteor will restart your application when it exits (a normal exit or a crash), which includes the test-runner.
In case you want to use it in one of your CI or you just want to run the tests once, add --once to the meteor-command, otherwise set TEST_WATCH=1 before running this script. If you don't set the env variable, and don't define --once, Meteor will print these lines and restart the tests once they're finished:
=> Exited with code: 0
=> Your application is crashing. Waiting for file change.
As of now I haven't found a way to check if the flag --once is set, which would omit the env variable. The flexibility here to choose between CI and continuous testing is very useful.
Maybe you're currently working on a feature and want to run the tests as you work. If you have set TEST_WATCH=1 and are not using --once, Meteor will restart the tests once it registers that a file was changed. You can even limit the test collection using MOCHA_GREP.
Where and how do you want to see the results?
You currently have to choose between seeing all the test-results on the command-line or to show the server-tests in the commandline and the client-tests in the browser. Currently practicalmeteor:mocha does not support showing the result of the server- and client-tests in the browser, as your screenshot shows.
Please take a look at the package documentation for further details:
You should disable the Meteor timestamp to make it look better.
Tests might look quite gambled because of the timestamp added to every line. To avoid this, add --raw-logs to your command.
I hope this answers most of your question. I know that the documentation needs some improvements and would welcome if someone would take the time to take it into a more logical order for people who "just want to get started".
I understand from the documentation that the SourceDiskCache folder cannot be configured using the XML configuration file and is only available "through code installation". However I can't figure out how!
I need to configure a custom folder. I have tried a few different things, with different results (both in Application_Start):
This doesn't throw an error, but uses the default folder (/cache)
var sourceDiskCachePlugin = new SourceDiskCachePlugin {VirtualCacheDir = "~/App_Data/cache"};
Config.Current.Plugins.GetOrInstall(sourceDiskCachePlugin);
This (and most other variations I have tried) throws the error "SourceDiskCache settings may not be adjusted after it is started."
new SourceDiskCachePlugin().Install(Config.Current);
Config.Current.Plugins.Get<SourceDiskCachePlugin>().VirtualCacheDir = "~/App_Data/cache";
How can I configure this?
Also, the documentation states that SourceDiskCache is in beta - is this still the case, and will XML configuration ever be available?
This would be the normal way to configure and install it:
var plugin = new SourceDiskCachePlugin()
plugin.VirtualCacheDir = "~/App_Data/cache";
plugin.Install(Config.Current);
If your code is running more than once, use Config.Current.Plugins.GetOrInstall(plugin); It's best if you only install the plugin during Application_Start.
However, approach #1 from your question should work equally well, as long as you've set the right NTFS permissions on App_Data.
I'm trying to use groovy scripts in my application. The problem is that GroovyScriptEngine#run always compiles the script, even if it was compiled in previous runs and hadn't changed since. Even if I set a physical output folder to save compilation results in the configuration.
What is the best way of working around this? The optimum for me is that I'm able to send the script with a folder containing precompiled results and no compilation is done (unless the script is modified of course)
Grails 1.3.5 is using Groovy 1.7.5. In that Groovy version, GroovyScriptEngine.run(..) calls the following methods: createScript(String, Binding) --> loadScriptByName(String) --> isSourceNewer(ScriptCacheEntry).
isSourceNewer(ScriptCacheEntry) is defined as (unfortunately, I didn't find a matching source file on the web):
protected boolean isSourceNewer(ScriptCacheEntry entry)
throws ResourceException {
// ...
for (String scriptName : entry.dependencies) {
// ...
return true; // without any further condition!
}
return false;
}
Which implements the (queer) logic "if a script has dependencies, it is newer than the cached script (and needs to be re-compiled)". That's not what the code is supposed to do; it's supposed to decide by modification time.
In newer versions of GroovyScriptEngine, this has been corrected (there've been massive changes to the logic), but for now, you'd need to subclass GroovyScriptEngine and overwrite isSourceNewer(ScriptCacheEntry) to fix the logic yourself.
Edit: The bug has been reported and fixed in Groovy 1.7.6. - So try using Groovy 1.7.6 in your Grails lib folder.
The solution (hack) I used at last was to stream out the scriptCache variable using xstream and to read it back and set it in the object
Not sure if this helps you, but you can alter GroovyScriptEngine's behaviour using CompilerConfiguration (see GroovyScriptEngine.setConfig). There's an option CompilerConfiguration.setRecompileGroovySource, which can be used to set whether the sources will be reloaded and recompiled if they change. You can read more about CompilerConfiguration here (page 282).
I work on a complex, multi-module maven project. One of the modules is an executable jar that implements a command-line application. I need to integration test this application. I need to run it several times, with several different command-lines and validate the exit status and stdout/err. However, I can't find a plugin for maven that claims to support this, and also can't track down a JUnit library that supports testing command-line applications.
Before you say 'don't test the main method - instead do bla', in this case I really do mean to test the main method, not some subsidiary functionality. The whole point is to run the application as a user would in its own VM and environment, and validate that it is behaving itself - parsing command-line options correctly, exiting with the write status and hot-loading the right classes from the right plugin jars.
My current hack is to use apache-exec from within a junit test method. It appears to be working, but is quite fiddly to set up.
public void testCommandlineApp()
throws IOException
{
CommandLine cl = new CommandLine(resolveScriptNameForOS("./runme")); // add .sh/.bat
cl.addArgument("inputFile.xml");
exec.setWorkingDirectory(workingDir);
exec.setExitValues(new int[] { 0, 1, 2 });
int exitCode = exec.execute(cl);
assertEquals("Exit code should be zero", 0, exitCode);
}
Why not simply use a shell script, using the maven-exec-plugin to build your classpath?
STDOUT=$(mvn exec:java -DmainClass=yourMainClass --arg1 --arg2=value2)
RETURN_CODE=$?
# validate STDOUT
# validate RETURN_CODE
You can even use something like shunit2 if you prefer a more structured approach.