Nashorn JavaScript implementation for Vert.x
License: Apache License 2.0
This project provides the JavaScript API implementation for Vert.x using the Nashorn JavaScript engine built into Java 8.
As with all Vert.x 3 language implementations they are generated from a Java API using templates - this allows us to maintain just the canonical Java APIs which is a lot less work than maintaining them manually.
This project provides a verticle factory implementation which knows how to deploy verticles with the prefix, or file
extension js.
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "dependabot[bot]")
See reproducer here: https://github.com/chefhoobajoob/npm-verticle-reproducer
If a js verticle has a dependency on an npm module, and that module implementation includes require statements for other scripts within the module, the module's require statements will fail to resolve unless the verticle's require statement explicitly specifies the full relative path to the module script that is required. This breaks module encapsulation, forcing clients to be dependent on the internal structure of the module's file system.
For example, assume a js verticle includes this require statement:
var m = require('myModule');
And, assume that there is a node_modules folder containing a myModule folder. In the myModule folder is a package.json file which includes this line:
"main": "myMain.js",
And, assume that myMain.js includes this require statement:
var l = require('./util')
Where 'util.js' is another file in the myModule folder. vertx-lang-js 3.2.1 will correctly resolve require('myModule') to that module's main script, myMain.js, but in evaluating myMain.js, vertx-lang-js will fail to resolve its require('./util') statement, and an exception will be thrown preventing the verticle from launching.
The only available workaround at the moment is for the verticle implementation to change its require statement to:
var m = require('myModule/myMain')
This is not the case when running the verticle on Linux or on OS/X, as far as I can tell. On those operating systems, vertx-lang-js correctly resolves module require statements when the verticle's require statement only names the module and not the full path to the module's main script.
I'm not sure how deep this behavior goes. For example, a module can have its own node_modules folder which contains yet more dependency implementations, which can each have their own require statements, and this nesting could be arbitrarily deep.
It would be good to know that these nested module dependencies will each correctly resolve their respective require statements in the right scope on all supported operating systems.
Hello
This may be a bug with vertx-lang-js.
Reproducer
In a new directory:
npm init
npm install bignumber.js
npm install web3
in a test javascript file, try:
require('web3') // or
require('bignumber.js') // or
var BigNumber = require('node_modules/bignumber.js/bignumber.js');
Summary
It appears that relatively common npm modules have a .js suffix in their module name (!)
e.g. bignumber.js
I wouldn't normally want to use the above module, except that other modules, that I do want to use, require it
e.g. ethereum web3
Hence, given ...
var Web3 = require('web3')
...vertx-lang-js throws with:
java.lang.RuntimeException: java.io.FileNotFoundException: /Users/Fuzz/tmp/vertx-js-demo/node_modules/web3/node_modules/bignumber.js (Is a directory)
Detail
What's interesting is that web3 itself has embedded its dependencies as a full copy within its distribution.
This seems to almost work with vertx-lang-js, failing only because it interprets a path ending with .js as being a javascript file (quite reasonably, but not the way node.js is resolving it, it seems).
So, looking at vertx-lang-js, I found the following in jvm-npm.js
Require.resolve = function (id, modParent) {
var roots = findRoots(modParent);
for (var i = 0; i < roots.length; ++i) {
var root = roots[i];
var result = resolveClasspathModule(id, root) ||
resolveAsFile(id, root, '.js') ||
resolveAsFile(id, root, '.json') ||
resolveAsDirectory(id, root) ||
resolveAsNodeModule(id, root);
if (result) {
return result;
}
}
return false;
};
In contrast, node appears to prefer module and directory resolution before file resolution.
regards
Fuzz.
With milestone6 I get the following error:
javax.script.ScriptException: TypeError: Cannot call undefined in src/main/resources/vertx-js/util/jvm-npm.js at line number 121
at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:56)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:212)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:184)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:171)
at jdk.nashorn.internal.runtime.Undefined.lookupTypeError(Undefined.java:128)
at jdk.nashorn.internal.runtime.Undefined.lookup(Undefined.java:100)
at jdk.nashorn.internal.runtime.linker.NashornLinker.getGuardedInvocation(NashornLinker.java:98)
at jdk.internal.dynalink.support.CompositeTypeBasedGuardingDynamicLinker.getGuardedInvocation(CompositeTypeBasedGuardingDynamicLinker.java:176)
at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124)
at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:144)
at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:232)
at jdk.nashorn.internal.scripts.Script$jvm_npm._L27(src/main/resources/vertx-js/util/jvm-npm.js:121)
at jdk.nashorn.internal.scripts.Script$jvm_npm.runScript(src/main/resources/vertx-js/util/jvm-npm.js:27)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:498)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:206)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:378)
at jdk.nashorn.internal.runtime.Context.evaluateSource(Context.java:885)
at jdk.nashorn.internal.runtime.Context.load(Context.java:563)
at jdk.nashorn.internal.objects.Global.load(Global.java:857)
at jdk.nashorn.internal.scripts.Script$\^eval\_.runScript(<eval>:1)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:498)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:206)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:378)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:546)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:528)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:524)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:194)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at io.vertx.test.lang.js.JSRunner.load(JSRunner.java:56)
at io.vertx.test.lang.js.JSRunner.run(JSRunner.java:35)
at io.vertx.test.lang.js.JSRunner.run(JSRunner.java:28)
at io.vertx.test.lang.js.JSTestBase.runTest(JSTestBase.java:15)
at io.vertx.test.lang.js.TimeoutTest.testClearInterval(TimeoutTest.java:31)
The problem points to the following line
var synchronizedDoRequire = Java.synchronized(doRequire, verticleFactoryClass);
In milestone5 everything worked correctly.
This also happens if I just run mvn test so it seems it's not my code causing this issue. I use JDK 1.8.0_31 by the way. Maybe there's some Nashorn feature that has been added in 1.8.0_40?
Thanks,
Michel
Simplified example project HERE
TestService.createProxy = function(vertx, ebAddress) {
var __args = arguments;
// The `__args[0]._jdel` object is `undefined`...
if (__args.length === 2 && typeof __args[0] === 'object' && __args[0]._jdel && typeof __args[1] === 'string') {
if (closed) {
throw new Error('Proxy is closed');
}
j_eb.send(j_address, {"vertx":__args[0], "ebAddress":__args[1]}, {"action":"createProxy"});
return;
} else throw new TypeError('function invoked with invalid arguments');
};Regardless of what I have tried, the __args[0]._jdel object is always undefined.
This module is pruned in Vert.x 4, as alternative https://reactiverse.io/es4x/ should be used
Currently two tests are failing:
testBasicReturn(io.vertx.test.lang.js.FunctionParamTCKTest) Time elapsed: 0.32 sec <<< ERROR!
java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.Byte (java.lang.Integer and java.lang.Byte are in module java.base of loader 'bootstrap')
at io.vertx.codegen.testmodel.FunctionParamTCKImpl.methodWithBasicReturn(FunctionParamTCKImpl.java:105)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$22680$9654AAAAAAAAA$jvm_npm.L:1#FunctionParamTCK#methodWithBasicReturn(testmodel-js/function_param_tck.js:282)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$22679$4368$function_param_tck_test.testBasicReturn(src/test/resources/function_param_tck_test.js:177)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$22678$function_param_tck_test$cu1$restOf.:program(src/test/resources/function_param_tck_test.js:319)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.evaluateSource(Context.java:1438)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.load(Context.java:962)
at jdk.scripting.nashorn/jdk.nashorn.internal.objects.Global.load(Global.java:1719)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$22604$\^eval\_/0x0000000800b80c40.:program(<eval>:1)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at io.vertx.test.lang.js.JSRunner.load(JSRunner.java:75)
at io.vertx.test.lang.js.JSRunner.run(JSRunner.java:46)
at io.vertx.test.lang.js.JSRunner.run(JSRunner.java:34)
at io.vertx.test.lang.js.JSTestBase.runTest(JSTestBase.java:15)
at io.vertx.test.lang.js.FunctionParamTCKTest.testBasicReturn(FunctionParamTCKTest.java:84)
testTypeVarParam(io.vertx.test.lang.js.ExtraTest) Time elapsed: 0.777 sec <<< ERROR!
java.lang.ClassCastException: class java.lang.Integer cannot be cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in module java.base of loader 'bootstrap')
at io.vertx.test.codegen.impl.ClassParamOverloadImpl.typeVarParam(ClassParamOverloadImpl.java:45)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$338$jvm_npm$cu1$restOf.L:1#ClassParamOverload#typeVarParam(src/test/resources/extra-js/class_param_overload.js:76)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$329$557$extra_test$cu1$restOf.testTypeVarParam(src/test/resources/extra_test.js:23)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$322$extra_test$cu1$restOf.:program(src/test/resources/extra_test.js:30)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.evaluateSource(Context.java:1438)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.Context.load(Context.java:962)
at jdk.scripting.nashorn/jdk.nashorn.internal.objects.Global.load(Global.java:1719)
at jdk.scripting.nashorn.scripts/jdk.nashorn.internal.scripts.Script$Recompilation$251$\^eval\_/0x0000000800434c40.:program(<eval>:1)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:655)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:513)
at jdk.scripting.nashorn/jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:527)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:456)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:413)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:409)
at jdk.scripting.nashorn/jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:162)
at java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at io.vertx.test.lang.js.JSRunner.load(JSRunner.java:75)
at io.vertx.test.lang.js.JSRunner.run(JSRunner.java:46)
at io.vertx.test.lang.js.JSRunner.run(JSRunner.java:34)
at io.vertx.test.lang.js.JSTestBase.runTest(JSTestBase.java:15)
at io.vertx.test.lang.js.ExtraTest.testTypeVarParam(ExtraTest.java:35)
DataObject support the io.vertx.core.buffer.Buffer type.
The conversion of a ruby object should convert the buffers to a B64 encoded string before constructing the data object.
This context variable is misleading and does not resolve to the Verticle context. Developers should use Vertx.currentContext() to get the right verticle context and this context variable does not encourage to do it.
It is not clear what context should evaluate to as this variable is shared by several Verticles as it is then cached by the factory once the Nashorn engine has been initialized.
In addition the context variable set by the JSVerticleFactory#init method evaluates the current context provided by Vert.x in VerticleFactory#createVerticle call. At this moment the Context is a temporary context created by the DeploymentManager when it invokes the executeBlocking method wrapping the VerticleFactory#createVerticle method.
A lot of popular npm packages (i.e. react, superagent) are accessing process.env.NODE_ENV in order to deduce if and how they should handle debugging related tasks. Apparently you are using jvm-npm. Based on my experience with vert.x 2, it would suffice to define process.env before loading jvm-npm. In vert.x 2 it would look like this:
var process = {env: {}};
load('./jvm-npm.js');
var React = require('react');
It would probably be even better, if we could read out the actual value of NODE_ENV. But the API for accessing environment variables was changed and the new one is not documented yet.
Java.synchronized is used in jvm-npm.js to sychronize concurrent access to require but this is only available in JDK 8u45 or later.
We should explicitly check for Java.synchronized is undefined and log a helpful warning e.g. "please upgrade to 8u45 or later" rather than the cryptic error that now occurs.
We should also mention in the documentation that 8u45 or later is required for JS.
We don't yet have a simple reproducer for this problem, but maybe I can describe what we are doing and the problem we are seeing, and somebody can help understand whether our expectations are wrong.
We have a javascript verticle whose scripts we are packaging up into a jar. The verticle makes use of several different node module dependencies, which we are staging into a node_modules directory.
So, the jar layout is like this:
META-INF/MANIFEST.MF
verticle-name/verticle-impl.js
verticle-name/some-helper-script.js
verticle-name/node_modules/rql
verticle-name/node_modules/rxjs
verticle-name/node_modules/...<various other node dependencies>
verticle-impl.js uses a require statement to use functions from some-helper-script.js, and the some-helper-script.js uses require statements to pull in its node module dependencies.
We then make this jar available to dependent projects that want to launch the js verticle. We do this using the service factory, where the value of the main property of the service descriptor is set to: verticle-name/verticle-impl.js.
We have verified that the jar with the layout above is in the classpath of the dependent project at runtime.
However, while the dependent project is able to successfully locate the verticle and invoke its start method, and the require statements in verticle-imple.js are successfully finding some-helper-script.js, we are finding that when evaluation gets to the require statements in some-helper-script.js for the node modules in the node_modules directory, Nashorn complains that it can't find the required module.
Assuming no other problems in our implementation, should this organization be able to successfully resolve these require statements in some-helper-script.js?
Fixed by: 877dd54
I've created a reproducer repo for this problem here.
urijs is a popular and self-contained (I believe) npm package that I'm trying to use with vertx version 3.4.1, but which I've also tested with 3.5.3 and versions earlier than 3.4.1, all yielding the same results:
The require statement fails, complaining about hitting an unexpected eof in URI.js. Of course, there is no such problem with URI.js, but what seems to be some parsing or handling bug in jvm-npm or Nashorn.
I couldn't find any mention of a problem with this package in the issue history for vertx-lang-js, but I did find these issues from back in 2014 - so these may not help much in this specific case, but just in case:
medialize/URI.js#170
vert-x/mod-lang-nashorn#5
node_module/a/b/c.js
node_module/a/lib/index.js
c.js:
require('../lib')
// MOAR CODE...these kinds of relative imports fail because jvm-npm.js fails to check for ../lib/index.js which is a valid possibility for node style file resolution
Patching it right now on my end
Hi! I have js verticle and package.json contains:
{
"name" : "npm-test",
"dependencies" : {
"figlet" : "1.1.1"
}
}npm-test.js file contains:
var figlet = require('figlet');
exports.vertxStart = function() {
figlet('Hello World!!', function(err, data) {
if (err) {
console.log('Something went wrong...');
console.dir(err);
return;
}
console.log(data)
});
};After npm install I'm trying to run vertx run npm-test.js but this puts "Cannot find module fs" error in my console.
Of course my $NODE_PATH points to the right node's installation dir.
What should I do to resolve this issue?
From @rtv2222 on June 11, 2016 19:11
The Javascript example for vertx mongo auth just does not work.
https://groups.google.com/forum/#!topic/vertx/AfjHVJy4wtk has already raised the issue. I am repeating it here to see if it helps.
Just follow the documentation to create a JS vertx mongo auth client. Call to authenticate fails with a TypeErrpr. https://github.com/markus-simon/auth example is linked from the Google Groups link above
Copied from original issue: vert-x3/vertx-auth#68
Multiple concurrent calls to the 'require' method (e.g. when deploying a JS Verticle which uses require with the '-instances x' argument) result in some of the instances receiving an empty object instead of the expected dependency.
I have started looking into the issue and I've written a test that replicates it here: edit removed this branch there is a new one with the fixes related to #20
Result of the above test:
test_multiple_concurrent_requires: failed: Property is null
test_multiple_concurrent_requires: ok
test_multiple_concurrent_requires: ok
test_multiple_concurrent_requires: ok
test_multiple_concurrent_requires: ok
test_multiple_concurrent_requires: failed: Property is null
test_multiple_concurrent_requires: failed: Property is null
test_multiple_concurrent_requires: failed: Property is null
test_multiple_concurrent_requires: failed: Property is null
test_multiple_concurrent_requires: failed: Property is null
test_multiple_concurrent_requires: 6
java.lang.AssertionError: Failure count must be 0
--- End of issue specific text ---
I haven't submitted it as a pull request as I will attempt to implement a fix on the same branch; however, this being my first public commit I wanted to ensure I was doing everything properly before submitting. I know my naming convention is probably too long, I've put an integration test in the require test where a simpler one would probably suffice, I've left log statements in (just to more easily show the issue) etc so I apologise for that in advance. If I should be doing anything at all differently please feel free to critique it and I will sort it out.
I also wasn't sure whether I should be posting this here or on the Eclipse Bugzilla, so apologies if this is incorrect.
BTW: This is excellent work... I am very excited about the VertX 3 release and the Nashorn integration provided by this module.
Do we still use the method filter:
if (methodFilter != null) {
List<MethodInfo> methodTmpl = methodList;
methodList = new ArrayList<>();
for (MethodInfo method : methodTmpl) {
if (methodFilter.test(method)) {
methodList.add(method);
}
}
}
if not we should remove this…
The current JS docs theme: http://vertx.io/docs/jsdoc/ which is REALLY hard to read and traverse...
Each method name seems to mix in with the "Returns" header, and the nav on the right is really messy to read.
😢 hurts the brain to read it...
Any plans to update this to something more usable?
Currently if you run console.log(vertx.deploymentIDs()) it will print null in the stdout.
If you add JSON.stringify around vertx.deploymentIDs it's the same thing.
But if you use print(vertx.deploymentIDs()) the values are property printed.
The current api is not at all similair right now
here is my example repo:
https://github.com/cinterloper/vertx-tinkering
according to this documentation:
http://vertx.io/docs/vertx-web/js/#_sockjs_event_bus_bridge
i should be able to add 'headers' (username, etc) to a message coming across the sockjs bridge
sockJSHandler.bridge(options, function (be) {
if (be.type() === 'PUBLISH' || be.type() === 'SEND') {
// Add some headers
var headers = {
"header1" : "val",
"header2" : "val2"
};
be.rawMessage().headers = headers;
}
be.complete(true);
}
however, when receiving the message (in the same vertical or in other verticals) i am unable to retrieve the headers
If a user disables caching using the system property as per documentation, and the js runner is loaded this user choice is overruled with always cache file system.
Hi:
We try to change the .vertx file to another directory e.g. "user.home/com/company/temp_directory"
and we use the way of setting CACHE_DIR_BASE_PROP_NAME to our default directory
it works OK
but the vert.x still created the .vertx directory
so we investigated this problem and found in the file:
io.vertx.lang.js.ClasspathFileResolver.java
the DEBUG_JS_SOURCE_DIR is fixed to ".vertx/debug-js"
private static File DEBUG_JS_SOURCE_DIR = new File(".vertx/debug-js");
and there is no way to change it
thus if the vertx has no right to access this directory then it will cause the whole system failed
so we suggest to use CACHE_DIR_BASE_PROP_NAME to replace ".vertx" prefix
make it like:
new File(System.getProperty(CACHE_DIR_BASE_PROP_NAME, DEFAULT_CACHE_DIR_BASE) + System.getProperty("file.separator") + "debug-js");
then put the debug files into out preset temp directory
Build a fat jar with the following project: https://github.com/StephenOTT/js-vertx-fatjar
Have some deployment code such as:
function deployRubyVerticle() {
var classloader = java.lang.Thread.currentThread().getContextClassLoader();
var bundleFolderResource = classloader.getResource('ruby_gems')
console.log('ruby_gems absolute path: ' + bundleFolderResource.getPath())
var rubyOptions = {
"config": {
"GEM_PATH": bundleFolderResource.getPath() + "/vendor/bundle/jruby/2.3.0/"
},
"worker" : true
}
vertx.deployVerticle('verticles/ruby-working-hours/working-hours-vert.rb', rubyOptions)
}If you dont have the classloader based path, and just use the regular GEM_PATH = "./my/relative/path", its not using the root of the project/jar. The typical error would be "File not found" as the path could not be found.
The classloader stuff was required because when GEM_PATH is used in a config its loading from what appears to be current working directory ( ? ) This problem does not occur when using the Docker stack cli, because the CWD is set during the image build.
I used: d432388#diff-a5533d7f2941dd2c95a4d7a28f1106afR294 and #30 and #29 as my logic trail to come up with this solution.
This seems like it would be a change for Ruby lang to have better support? Or is just this a "fact" of building JS/Nashorn Laucher.class based builds (fatjars, etc)
Another option could be to add additional config options for GEM_PATH that would indicate to use classloader context, or ENV var VERTICLE_HOME rather than cwd ?
@edewit and me believe that the import generated for a @VertxGen @proxygen which references another is wrong - we've run into this in https://github.com/vorburger/minecraft-storeys-maker/issues/53.
@pmlopes do you know what we mean, or would you need a simple standalone reproducer project, or (broken) PR here with a beginning of a test further illustrating the problem to be able to fix this?
E.g. here I've written for https://github.com/vorburger/minecraft-storeys-maker/issues/76 a @ProxyGen using Java enum (in that example both for an argument, see HandType; as well as for the return type, see ItemType) like this:
void getItemHeld(String code, HandType hand, Handler<AsyncResult<ItemType>> handler);
and in the generated TypeScript signature (in minecraft-storeys-maker/api/build/classes/java/main/Minecraft-ts/minecraft-proxy.ts) this turned into:
getItemHeld(code: string, hand: string, handler: (err: any, result: any) => any) : void {
where, in an ideal world, it could be more "strongly typed" with a TypeScript enum :
getItemHeld(code: string, hand: HandType, handler: (err: any, result: ItemType) => any) : void {
@edewit FYI.
The module (vertx-rx-js) is not longer supported in Vert.x 4
When a Vertx application is run for the first time, the debug-js directory is not present and an ugly exception is shown. Before deleting the directory, the class should first check for the directory presence.
I posted this query on the vertx group and was directed here.
Consuming nodejs modules in verticles seems problematic.
Having had a look at jvm-npm.js, I can see that it is possible somehow, but the following block is confusing me:
Require.paths() lines 194-201:
if (Require.NODE_PATH) {
r = r.concat(parsePaths(Require.NODE_PATH));
} else {
var NODE_PATH = java.lang.System.getenv.NODE_PATH;
if (NODE_PATH) {
r = r.concat(parsePaths(NODE_PATH));
}
}
Require.NODE_PATH is set to undefined earlier on, and from what I can tell, java.lang.System.getenv.NODE_PATH will always return undefined.
To give you more context, I have npm installed the colors module and am trying to use it with the following code below.
var colors = require('colors');
console.log('hello'.green); // outputs green text
console.log('i like cake and pies'.underline.red) // outputs red underlined text
console.log('inverse the color'.inverse); // inverses the color
console.log('OMG Rainbows!'.rainbow); // rainbow
console.log('Run the trap'.trap); // Drops the bass
When I run, I get the following exception:
javax.script.ScriptException: Error: Cannot find module colors in at line number 125 at column number 6
at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:455)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:439)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:397)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:152)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
.
.
.
Currently the generation of a JavaScript class generates the wrapping code when a parent declares a class. There are two cases:
class Foo {
void m();
}
class Bar extends Foo {
}
in this case, we method should be wired directly with the parent method
class Foo {
void m();
}
class Bar extends Foo {
void m(String s);
}
in this case as we have to switch over the overload, when the method is not found, instead of throwing an error, it should dispatch to the parent method
if (arguments == [String]) {
// delegate to m(String)
} else {
// call the super method that will eventually fail
}
utils.convParamTypeUnknown should return param._jdel if possible, instead of param
For example, trying to send a Buffer over the event bus ends with:
GRAVE: io.vertx.core.impl.ContextImpl - Unhandled exception
java.lang.IllegalArgumentException: No message codec for type: class jdk.nashorn.api.scripting.ScriptObjectMirror
at io.vertx.core.eventbus.impl.CodecManager.lookupCodec(CodecManager.java:90)
at io.vertx.core.eventbus.impl.EventBusImpl.createMessage(EventBusImpl.java:229)
at io.vertx.core.eventbus.impl.EventBusImpl.send(EventBusImpl.java:110)
at io.vertx.core.eventbus.impl.EventBusImpl.send(EventBusImpl.java:95)
at jdk.nashorn.internal.scripts.Script$Recompilation$147$2809AA$jvm_npm.L:1#EventBus#send(vertx-js/event_bus.js:76)
at jdk.nashorn.internal.scripts.Script$Recompilation$143$576AA$event_bus_test.testSendBuffer#L:20(src/test/resources/event_bus_test.js:22)
at jdk.nashorn.internal.scripts.Script$Recompilation$142$5785A$jvm_npm.L:1#MessageConsumer#completionHandler#L:188(vertx-js/message_consumer.js:190)
at io.vertx.core.Handler$$NashornJavaAdapter.handle(Unknown Source)
at io.vertx.core.eventbus.impl.HandlerRegistration.lambda$completionHandler$1(HandlerRegistration.java:97)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$2(ContextImpl.java:345)
at io.netty.util.concurrent.AbstractEventExecutor.safeExecute(AbstractEventExecutor.java:163)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:403)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:445)
at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
at java.lang.Thread.run(Thread.java:748)
See reproducer here: https://github.com/chefhoobajoob/npm-verticle-reproducer
I have not been able to reproduce this problem on Mac or Linux variants, but it appears to be consistently failing on Windows systems.
I have a JS verticle with a single require statement referencing an expected npm dependency (rql in the example). I also have a launch script that ensures that NODE_PATH is set to the npm node_modules folder of the project so that the rql package is found.
On both Linux and Windows systems, Vertx successfully resolves the rql/js-array require statement in the verticle's JS file, but the rql/js-array module itself contains another require statement for ./parser, which is a JS file within the node_modules/rql folder.
On Linux systems, the require statement for ./parser resolves successfully, on Windows systems, it fails with an exception:
javax.script.ScriptException: Error: Cannot find module ./parser in <eval> at line number 141 at column number 6
at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:455)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:439)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:397)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:152)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at io.vertx.lang.js.JSVerticleFactory$JSVerticle.start(JSVerticleFactory.java:109)
at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$159(DeploymentManager.java:429)
at io.vertx.core.impl.DeploymentManager$$Lambda$27/694010685.handle(Unknown Source)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$16(ContextImpl.java:335)
at io.vertx.core.impl.ContextImpl$$Lambda$26/1498977954.run(Unknown Source)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
at java.lang.Thread.run(Thread.java:745)Caused by: <eval>:141:6 Error: Cannot find module ./parser
at jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:137)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:102)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:106)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:110)
at jdk.nashorn.internal.objects.NativeError.constructor(NativeError.java:129)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:141)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33$Require(null:120)
at jdk.nashorn.internal.scripts.Script$Recompilation$20$2109A$\^eval\_.L:33$Module$require(null:68)
at jdk.nashorn.internal.scripts.Script$Recompilation$135$271AA$\^eval\_#88\!17\^eval\_.L:1$define(C:\Users\hoobajoob\Documents\GitHub\NpmVerticle\node_modules\rql\js-array.js:6)
at jdk.nashorn.internal.scripts.Script$Recompilation$134$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(C:\Users\hoobajoob\Documents\GitHub\NpmVerticle\node_modules\rql\js-array.js:6)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:646)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.internal.scripts.Script$Recompilation$16$2235AAAAA$\^eval\_.L:33$_load(null:113)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:154)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33$Require(null:120)
at jdk.nashorn.internal.scripts.Script$Recompilation$20$2109A$\^eval\_.L:33$Module$require(null:68)
at jdk.nashorn.internal.scripts.Script$Recompilation$128$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(verticle.js:1)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:666)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.internal.scripts.Script$Recompilation$16$2235AAAAA$\^eval\_.L:33$_load(null:113)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:154)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$126$4168AAZ$\^eval\_.L:33$RequireNoCache(null:124)
at jdk.nashorn.internal.scripts.Script$125$\^eval\_.:program(<eval>:1)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:437)
... 13 moreFailed in deploying verticle javax.script.ScriptException: Error: Cannot find module ./parser in <eval> at line number 141 at column number 6
at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:455)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:439)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:397)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:152)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at io.vertx.lang.js.JSVerticleFactory$JSVerticle.start(JSVerticleFactory.java:109)
at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$159(DeploymentManager.java:429)
at io.vertx.core.impl.DeploymentManager$$Lambda$27/694010685.handle(Unknown Source)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$16(ContextImpl.java:335)
at io.vertx.core.impl.ContextImpl$$Lambda$26/1498977954.run(Unknown Source)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
at java.lang.Thread.run(Thread.java:745)Caused by: <eval>:141:6 Error: Cannot find module ./parser
at jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:137)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:102)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:106)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:110)
at jdk.nashorn.internal.objects.NativeError.constructor(NativeError.java:129)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:141)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33$Require(null:120)
at jdk.nashorn.internal.scripts.Script$Recompilation$20$2109A$\^eval\_.L:33$Module$require(null:68)
at jdk.nashorn.internal.scripts.Script$Recompilation$135$271AA$\^eval\_#88\!17\^eval\_.L:1$define(C:\Users\hoobajoob\Documents\GitHub\NpmVerticle\node_modules\rql\js-array.js:6)
at jdk.nashorn.internal.scripts.Script$Recompilation$134$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(C:\Users\hoobajoob\Documents\GitHub\NpmVerticle\node_modules\rql\js-array.js:6)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:646)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.internal.scripts.Script$Recompilation$16$2235AAAAA$\^eval\_.L:33$_load(null:113)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:154)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33$Require(null:120)
at jdk.nashorn.internal.scripts.Script$Recompilation$20$2109A$\^eval\_.L:33$Module$require(null:68)
at jdk.nashorn.internal.scripts.Script$Recompilation$128$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(verticle.js:1)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:666)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.internal.scripts.Script$Recompilation$16$2235AAAAA$\^eval\_.L:33$_load(null:113)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:154)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$126$4168AAZ$\^eval\_.L:33$RequireNoCache(null:124)
at jdk.nashorn.internal.scripts.Script$125$\^eval\_.:program(<eval>:1)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:437)
... 13 more
javax.script.ScriptException: Error: Cannot find module ./parser in <eval> at line number 141 at column number 6
at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:455)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:439)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:397)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:152)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at io.vertx.lang.js.JSVerticleFactory$JSVerticle.start(JSVerticleFactory.java:109)
at io.vertx.core.impl.DeploymentManager.lambda$doDeploy$159(DeploymentManager.java:429)
at io.vertx.core.impl.DeploymentManager$$Lambda$27/694010685.handle(Unknown Source)
at io.vertx.core.impl.ContextImpl.lambda$wrapTask$16(ContextImpl.java:335)
at io.vertx.core.impl.ContextImpl$$Lambda$26/1498977954.run(Unknown Source)
at io.netty.util.concurrent.SingleThreadEventExecutor.runAllTasks(SingleThreadEventExecutor.java:358)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:357)
at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:112)
at java.lang.Thread.run(Thread.java:745)
Caused by: <eval>:141:6 Error: Cannot find module ./parser
at jdk.nashorn.internal.objects.NativeError.initException(NativeError.java:137)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:102)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:106)
at jdk.nashorn.internal.objects.NativeError.<init>(NativeError.java:110)
at jdk.nashorn.internal.objects.NativeError.constructor(NativeError.java:129)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:141)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33$Require(null:120)
at jdk.nashorn.internal.scripts.Script$Recompilation$20$2109A$\^eval\_.L:33$Module$require(null:68)
at jdk.nashorn.internal.scripts.Script$Recompilation$135$271AA$\^eval\_#88\!17\^eval\_.L:1$define(C:\Users\hoobajoob\Documents\GitHub\NpmVerticle\node_modules\rql\js-array.js:6)
at jdk.nashorn.internal.scripts.Script$Recompilation$134$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(C:\Users\hoobajoob\Documents\GitHub\NpmVerticle\node_modules\rql\js-array.js:6)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:646)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.internal.scripts.Script$Recompilation$16$2235AAAAA$\^eval\_.L:33$_load(null:113)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:154)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$3$4049AAA$\^eval\_.L:33$Require(null:120)
at jdk.nashorn.internal.scripts.Script$Recompilation$20$2109A$\^eval\_.L:33$Module$require(null:68)
at jdk.nashorn.internal.scripts.Script$Recompilation$128$57AAAAA$\^eval\_#88\!17\^eval\_.L:1(verticle.js:1)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:666)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.internal.scripts.Script$Recompilation$16$2235AAAAA$\^eval\_.L:33$_load(null:113)
at jdk.nashorn.internal.scripts.Script$Recompilation$4$4376AAAA$\^eval\_.L:33$doRequire(null:154)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:644)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptFunction.invokeSync(ScriptFunction.java:999)
at jdk.nashorn.internal.scripts.Script$Recompilation$126$4168AAZ$\^eval\_.L:33$RequireNoCache(null:124)
at jdk.nashorn.internal.scripts.Script$125$\^eval\_.:program(<eval>:1)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:437)
... 13 more
Currently it's not possible to obtain directly the verticle context in JavaScript like the vertx object
I am occasionally getting unit test failures with a filenotfound exception inside the js jar in the local maven repo dir. When I run the tests once more, it usually disappears. This shows on 2 different CI systems (vertx jenkins and drone.io)
https://gist.github.com/alexlehm/3948f0f71114e23dd064
the unit test is this file: https://github.com/vert-x3/vertx-mail-service/blob/master/src/test/java/io/vertx/ext/mail/JavascriptTest.java
Changes applied on the file system to Javascript files included as modules using "require(...)" by a main javascript verticle are not effective until vert.x is restarted.
It could be usefull to have "hot reload" of Javascript files on modules as it happens for the main Javascript verticle using the "-redeploy" option.
See this link for the details: https://groups.google.com/d/msg/vertx/nG_HxfzrLW4/75cXB8aJ_g8J
It seems that the Require.resolve resolution mechanism only works on the file system. Are there any plans for adding support for resolution of provided node modules within a (self-contained) zip archive? This draft diff will make the npm example at https://github.com/vert-x3/vertx-examples/tree/master/core-examples/src/main/js/npm example work if distributed and launched as zip archive:
jvm-npm.js.diff (against version/tag 3.0.0)
78a79
>
248c249,250
< (root ? resolveAsNodeModule(id, new File(root).getParent()) : false);
---
> (root ? resolveAsNodeModule(id, new File(root).getParent()) : false) ||
> resolveAsClasspathNodeModule(id);
290a293,303
> function resolveAsClasspathNodeModule(name) {
> name = 'node_modules/' + name;
> var main = name + '/index.js';
> var classloader = java.lang.Thread.currentThread().getContextClassLoader();
> if (classloader.getResource(name + '/package.json')) {
> var package = JSON.parse(readFile(name + '/package.json', true));
> if (package.main) main = (name + '/' + package.main).replace(/\.\//g,'');
> }
> if (classloader.getResource(main)) return {path: main, core: true};
> }
>
As JavaScript as a language is inherently single threaded (and implementations such as NodeJS and all Browser environments are all single threaded), the majority of Javascript Libraries are not designed to be accessed in a multi threaded environment. Having a single global context for all Javascript Verticles (and Verticle instances) and their dependencies (of which VertX states compatibility with NPM) is extremely likely to introduce race conditions on either access to global variables or even instance variables within a self contained script that is not designed to provide atomic updates (e.g. for internal state).
The JVM NPM library itself (which is used by VertX for NPM/CommonJS support) contains a serious race condition for its internal require cache, where multiple concurrent access (e.g. vert run service.js -instances 10) causes the return value from the 'require' call to be undefined for an indeterminate number of the instances. This patch fixes that issue among potentially many others. Reported originally under #19 (the attached pull request fixes that one).
Each Verticle should have an isolated scope that can not be corrupted by other Verticles/Libraries on other threads.
All Javascript Verticles share a single Global scope. Instances of libraries (e.g. NPM modules) are shared across all deployed Verticles.
The attached pull request contains two tests showing failures caused by the shared global scope - one with the 'require' method provided by JVM NPM and one a contrived leaked global variable example.
reproducer: create 2 @VertxGen interfaces, each one depending on each other (for instance method return type)
issue: each type needs a require on each other, the underlying module system can only honour one and the other is undefined, see https://nodejs.org/api/modules.html
When the verticle is deployed from the HA manager, it fails to load the verticle file as it tries to rely on the TCCL that is null (not set in this context).
See https://groups.google.com/d/msgid/vertx/ae3171ae-e30b-4e59-a662-ed03534ba51e%40googlegroups.com?utm_medium=email&utm_source=footer for more information.
It may be related to a HA misbehavior that should somehow inherit from the classpath set by the Launcher or from the TCCL set when the vertx instance is created, and use this classloader when the verticle is deployed.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.