I would like to make HTTP requests from Rails code running on top of JRuby.
How can I make it to re-use http.proxyHost, http.proxyPort and http.nonProxyHosts settings, given to JVM running it ?
To pass JVM flags through JRuby, use -J.... In this case:
jruby -J-Dhttp.proxyHost=foo -J-Dhttp.proxyPort=1234 -J-Dhttp.nonProxyHosts="*.bar.com" ...
This is explained in JRuby's help text.
-J[java option] pass an option on to the JVM (e.g. -J-Xmx512m)
use --properties to list JRuby properties
run 'java -help' for a list of other Java options
I have had the same issue. I found that java or net::http doesn't obey the nonProxyHosts option. The best way to get around this is to modify the ENV_JAVA settings to account for this.
The steps I took to ensure nonProxyHosts was used were the following:
1) JAVA_OPTS="-Dhttp.proxyHost=192*** -Dhttp.proxyPort=1234 -Dhttp.nonProxyHosts=local|127.0.0.1"
OR
1) JRUBY_OPTS="-J-Dhttp.proxyHost=192*** -J-Dhttp.proxyPort=1234 -J-Dhttp.nonProxyHosts=local|127.0.0.1"
Keep in mind that at least for java1.7 the nonProxyHosts should not have quotations see here.
Now I find that either net::http or java itself doesn't actually honour the nonProxyHosts option.
However you can get around this by doing the following in JRuby
a = URI("http://someurl")
Net::HTTP.new(a).proxy?.should == true
regex = /$#{ENV_JAVA["http.nonProxyHosts"]}/ #dollar needed to behave as expected
if a.hostname.match(regex)
ENV_JAVA["http.proxyHost"]=nil
end
Net::HTTP.new(a).proxy?.should == false
Hope that helps.
Related
We have a maven plugin that runs selenium with scala. The arguments passed are formatted as such:
<argLine>-Dbrowser=chrome -Dwebdriver.chrome.driver=${project.basedir}/browser/drivers/chrome/2.25/mac64/chromedriver</argLine>
I've tried adding
-DmaxInstances=5
, as well as using
-browser="browserName=chrome,maxInstances=5,chromeDriver=theDriver"
however they have returned errors.
Does anyone know the correct command line argument using the -D... format?
An example execution would be:
java -Dwebdriver.chrome.driver=theDriver -jar selenium-standalone-server-3.0.1.jar ${SE_OPTS}
where ${SE_OPTS} are the options that selenium takes. the options depend on which role you are running.
Options for Standalone
Options for Hub
Options for Nodes
(see the #Parameter's)
Since version 3.0, we are using JCommander, so ensure that your -D... options are specified before -jar
I'm trying to write a plugin for ohai. It seems like a pretty straightforward task:
Ohai.plugin(:Uname) do
provides 'uname'
depends 'kernel'
collect_data do
uname Mash.new
uname[:message] = `uname -a`
end
end
To me this looks like the online examples provided by Opscode, O'Reilly and others. But here's what happens when I try to test it:
% irb -rohai
irb(main):001:0> Ohai::Config[:plugin_path] << "."
=> ["/home/ll0359/.rbenv/versions/2.2.1/lib/ruby/gems/2.2.0/gems/ohai-8.3.0/lib/ohai/plugins", "."]
irb(main):002:0> o = Ohai::System.new
=> #<Ohai::System:0x007fed82e43078 #plugin_path="", #data={}, #provides_map=#<Ohai::ProvidesMap:0x007fed82e42fd8 #map={}>, #v6_dependency_solver={}, #d82e42f38 #controller=#<Ohai::System:0x007fed82e43078 ...>, #v6_plugin_classes=[], #v7_plugin_classes=[]>, #runner=#<Ohai::Runner:0x007fed82e42ec0 #prp:0x007fed82e42fd8 #map={}>, #safe_run=true>>
irb(main):003:0> o.all_plugins
And here's where the fun begins. I get this output, over and over and over:
[2015-05-20T03:13:09+00:00] WARN: Plugin Definition Error: <./ohai_uname.rb>: collect_data already defined on platform default
[2015-05-20T03:13:09+00:00] WARN: [DEPRECATION] Plugin at ./test_ohai.rb is a version 6 plugin. Version 6 plugins will not be supported in future releases....
your plugin to version 7 plugin syntax. For more information visit here: docs.chef.io/ohai_custom.html
(the text on my second line was clipped by my screen but you get the idea)
I've tried running this code with and without the 'depends' line. Same result.
I've tried running this code with and without the Mash line, substituing 'uname uname -a' for the assignment line. Same result.
I've tried running with and without passing ":linux" as a parameter to collect_data. The only difference is I get a warning about collect_data(:linux) already being defined instead of :default.
I've tried renaming the plugin to a random 8 character identifier just in case it was tripping over being called :Uname. Same result.
I've tried passing "uname" (capital and lower) as a parameter to o.all_plugins. Same result.
So my questions are:
Why does ohai (8.3, running under Ruby 2.2.1) think this is a version 6 plugin? I can't see anything in it that would make it look like it's not version 7.
How can I get this working?
Thanks
Note to self: Next time you do this, don't try to test from the directory your plugin is in and add "." to your plugin_path. Moving to a different directory and adding the absolute path to the plugin solved the problem.
I plan to leave this up in case someone else has this happen to them.
I have been using Thin to run my ruby Sinatra applications but I am now switching over to Puma. Thin creates its own log log/thin.log which I use. I noticed that Puma doesn't produce a log file (not that I can see). I have tried googling for documentation around this but not really found anything.
I was wondering if/how you can specify a log path in Puma.
Any help would be much appreciated.
Alex
Check the example config.rb as recommended on the repo's README.
As shown there:
# Redirect STDOUT and STDERR to files specified. The 3rd parameter
# (“append”) specifies whether the output is appended, the default is “false”.
stdout_redirect '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr'
stdout_redirect '/u/apps/lolcat/log/stdout', '/u/apps/lolcat/log/stderr', true
I am testing some code that pulls its configuration from environment variables (set by Heroku config vars in production, for local development I use foreman).
What's the best way to test this kind of code with RSpec?
I came up with this:
before :each do
ENV.stub(:[]).with("AWS_ACCESS_KEY_ID").and_return("asdf")
ENV.stub(:[]).with("AWS_SECRET_ACCESS_KEY").and_return("secret")
end
If you don't need to test different values of the environment variables, I guess you could set them in spec_helper instead.
You also can stub the constant:
stub_const('ENV', {'AWS_ACCESS_KEY_ID' => 'asdf'})
Or, if you still want the rest of the ENV:
stub_const('ENV', ENV.to_hash.merge('AWS_ACCESS_KEY_ID' => 'asdf'))
That would work.
Another way would be to put a layer of indirection between your code and the environment variables, like some sort of configuration object that's easy to mock.
This syntax works for me:
module SetEnvVariable
def set_env_var(name, value)
# Old Syntax
# ENV.stub(:[])
# ENV.stub(:[]).with(name).and_return(value)
allow(ENV).to receive(:[]) # stub a default value first if message might be received with other args as well.
allow(ENV).to receive(:[]).with(name).and_return(value)
end
end
As Heroku suggests, you can use Foreman's .env file to store environment variables for development.
If you do that, you can use foreman run to run your specs:
foreman run bundle exec rspec spec
If you're using dotenv to setup your environment during tests but need to modify an env variable for a specific test then following approach can be useful.
A simpler method than stubbing ENV is to replace the environment for the duration of the test, and then restore it afterwards like so:
with_environment("FOO" => "baz") do
puts ENV.fetch("FOO")
end
Using a helper like this:
module EnvironmentHelper
def with_environment(replacement_env)
original_env = ENV.to_hash
ENV.update(replacement_env)
yield
ensure
ENV.replace(original_env)
end
end
By using ensure the original environment is restored even if the test fails.
There's a handy comparison of methods for setting & modifying environment variables during tests including stubbing the ENV, replacing values before / after the test, and gems like ClimateControl.
I'd avoid ENV.stub(:[]) - it does not work if other things are using ENV such as pry(you'll get an error about needing to stub DISABLE_PRY).
#stub_const works well as already pointed out.
You can use https://github.com/littleowllabs/stub_env to achieve this. It allows you to stub individual environment variables without stubbing all of them as your solution suggested.
Install the gem then write
before :each do
stub_env('AWS_ACCESS_KEY_ID', 'asdf')
stub_env('AWS_SECRET_ACCESS_KEY','secret')
end
What you want is the dotenv gem.
Running tests under foreman, as #ciastek suggests, works great when running specs from CLI. But that doesn't help me run specs with Ruby Test in Sublime Text 2. Dotenv does exactly what you, transparently.
Currently I'm only able to say:
test.using(:scalatest)
Buildr documentation says that class Buildr::Scala::ScalaTest supports the following options:
:properties - Hash of system properties available to the test case.
:environment - Hash of environment variables available to the test case.
:java_args - Arguments passed as is to the JVM.
But those are parameters to test cases and JVM only, not to ScalaTest ?
D:\>buildr --version
C:/Ruby186/lib/ruby/gems/1.8/gems/buildr-1.4.4-x86-mswin32/lib/buildr/java/packaging.rb:62: warning: parenthesize argument(s) for future version
Buildr 1.4.4
See my discussion on Twitter with Alex: http://twitter.com/#!/boia01/status/27605157764145153
If you still need this, please open an issue in Buildr's bug tracker, and we'll address it :)