overload option-params
recalcitrant opened this issue · comments
Hi,
overloading the host-option does not seem to work:
"sling-content": {
root: "bin",
options: {
host: "192.168.111.123",
port: 8181,
user: "admin",
pass: "admin"
}
}
Still, everything is posted to localhost.
Which version of the task are you using?
If you have a local clone of this project, would you mind to pull the latest version, use the blog example application and try your configuration there? Please also invoke grunt --verbose to print debugging information about host, port and user.
Thanks for your suggestions, I've just cloned your project and in
examples/blog/Gruntfile.js
I placed the following:
module.exports = function (grunt) {
grunt.initConfig({
"sling-content": {
options: {
host: "192.168.171.118",
port: 8181,
user: "admin",
pass: "admin"
},
root: "root"
}
});
grunt.loadTasks("../../tasks");
grunt.registerTask("default", ["sling-content"]);
};
running:
grunt --verbose
yields:
Verifying property sling-content.root exists in config...OK
Files: root -> root
Host: 192.168.171.118
Port: 8181
User: admin
Dir : root/BAR
Dir : root/FOO
Reading root/BAR/blog.json...OK
Parsing root/BAR/blog.json...OK
Dir : root/BAR/blog
Dir : root/FOO/blog
Dir : root/FOO/blog/page
Dir : root/FOO/blog/post
Reading root/BAR/blog/first-post.json...OK
Parsing root/BAR/blog/first-post.json...OK
Node: root/BAR/blog/first-post.json
File: root/FOO/blog/page/GET.esp
File: root/FOO/blog/post/GET.esp
Done, without errors.
But still everything is being posted to jcr-repo on localhost intead of the provided IP.
Even without overloading the options and just replacing "localhost" with the above IP in:
/tasks/sling-content.js
everything is posted to localhost.
Odd, maybe I am missing something?
If I understand correctly, the files are pushed to the Sling instance at 192.168.171.118:8181, and if you access those resources from that Sling instance everything works as expected.
When you say that everything is being posted to the JCR repository on localhost, does this mean that you are checking directly the JCR repository with some other tool? Please note that the IP and port must refer to the Sling instance, not to the JCR repository.
By the way, are you sure that localhost is not 192.168.171.118?
No, I can even put "nonexistant" in the options-array and the content will still be posted to the sling-servlet on localhost:
var options = this.options({
host: "nonexistent",
port: 8181,
user: "admin",
pass: "admin"
});
So no matter what I put into the host-section (an IP, an existing hostname or any other string) the post will be made to localhost.
From the code you sent, I can see you changed the default values that the task provides. Please don't change the task implementation code, use grunt.initConfig() inside the Gruntfile.js in the root of your project to configure the task.
Ok, as you can see in my first comment I am already doing that:
module.exports = function (grunt) {
grunt.initConfig({
"sling-content": {
options: {
host: "192.168.171.118",
port: 8181,
user: "admin",
pass: "admin"
},
root: "root"
}
});
with the ip-address NOT being my localhost, it just happens to be that I have sling running on 3 different hosts - including localhost.
Can you actually post to a different server than your local machine without any issues? If so there must be some configuration problem on my side which is weird enough.
As long as the host is reachable and the POST servlet is installed, there is no problem in pushing your local files to the remote Sling instance.
Can you please check how Sling is configured? I tried to reproduce the problem, but everything works fine for me.
Closing this issue, as it is not reproducible.
After all the hostname is not being set correctly by the library - wireshark tells me that all requests are made to
http://undefined/path/to/resource
So no wonder everything gets deployed to localhost
Patching "self.host" to be "self.uri.host"
instead of "self.uri.hostname" in index.js of the request module
everything works as expected.
Weird that this works for you out of the box but nevermind.
Let's try another time. I made a small change to the task to better integrate with the request module.
In addition, I also added support for proxying: if you set an environment variable called http_proxy to a full URL (e.g. http://localhost:8888), the module will use it as a proxy for every HTTP request it sends. If you use a software like Charles, it will be easier to spot the issue.
Wow, that last commit fixed the issue for me - I no longer have to patch the request module and I can post to different hosts now.
Thanks a lot!
Thank you for your effort in debugging with me. Feel free to close the issue.