I am using the sunspot gem inside a mountable engine. I am creating an engine out of an existing Rails 3.2 app so I know that my setup works when in a standard rails app.
Basically, I can't get Sunspot in development (when using spec/dummy - I know that it's normally used to for testing but everything else works just fine) to load the sunspot.yml file and find the running version of Solr.
My gemspec has:
s.add_dependency 'sunspot_rails', '= 2.0.0.pre.120417'
s.add_development_dependency 'sunspot_solr', '~> 1.3.3'
s.add_development_dependency 'sunspot_test', '~> 0.4.0'
My mountable engine has a dummy rails app at spec/dummy for testing. My spec/dummy/config/sunspot.yml contains:
development:
solr:
port: 8080
path: /solr
hostname: localhost
When I run a rails console (from inside spec/dummy) with bundle exec rails console I get a normal rails console.
Running Sunspot.config produces:
> Sunspot.config
=> #<LightConfig::Configuration:0x007f864aeee8a0
#properties=
{:solr=>
#<LightConfig::Configuration:0x007f864aeed0b8
#properties=
{:url=>"http://127.0.0.1:8983/solr",
:read_timeout=>nil,
:open_timeout=>nil}>,
:master_solr=>
#<LightConfig::Configuration:0x007f864aefb398 #properties={:url=>nil}>,
:pagination=>
#<LightConfig::Configuration:0x007f864af06ae0
#properties={:default_per_page=>30}>,
:indexing=>
#<LightConfig::Configuration:0x007f864af0bf18
#properties={:default_batch_size=>50}>}>
Clearly Sunspot isn't picking up my sunspot.yml file because the port is running on 8983 instead of 8080 where it's actually running.
Starting the Solr server via bundle exec rake sunspot:solr:start (inside spec/dummy) or bundle exec rake app:sunspot:solr:start (from root of engine) starts the server correctly on port 8080 so I know that that is reading sunspot.yml
There are few other people with similar questions but I'm not using the sunspot_mongoid gem and feel like it's something to do with the fact it's running inside an engine.
If anyone could give me a hand it would be much appreciated!
I can't say what's wrong here, but I can tell you that I am doing the same thing -- making an engine out of rails app -- and that I have solr 2.0.0-pre-something and now 2.1.0 working in all environments locally and deployed. So, it can work.
I guess I would move forward by reading through the code involved in starting solr and how it goes about finding the config.
Not super helpful, overall -- but at least there's a reply now that suggests you're not doomed. :)
I eventually found the answer to this. Adding s.add_development_dependency 'sunspot_solr', '~> 1.3.3' adds sunspot_solr to the development profile only to the gem - not when you are running an application containing the gem in development mode. This makes sense for a 'normal' gem - I just wasn't thinking straight.
So in order to get the gem into your app containing the engine, you ether to have it as a normal add_dependency or include it in the app's Gemfile.
Sorry for wasting your time #ian
Dave
Related
Why does my spring gem load in the wrong (or all) environment(s)?
I have this in my Gemfile and spring gem is not listed anywhere else in the file:
group :development do
gem 'listen', '~> 3.1.5'
# Spring speeds up development by keeping your application running in the background. Read more: https://github.com/rails/spring
gem 'spring'
gem 'spring-watcher-listen', '~> 2.0.0'
end
When I ran bundle exec rails console test (for the test environment), spring processes started and the Listen module was loaded in the rails console. I made sure all spring processes were stopped beforehand.
To do a sanity check, I removed the whole development group above and bundled. Spring and listen gems were no longer loaded, as I expected.
I faced this misunderstanding in production.
Here's how I solved it:
You can also fix this issue permanently by upspringing (removing the spring gem from) your bin/ executables:
bin/spring binstub --remove --all
Or
spring binstub --remove --all
You can now run the command below to get into rails console in production
rails c --environment=production
Also, to avoid this from occurring in subsequent occasions endeavour to make sure that the spring gem is only present in development and test groups in your Gemfile.
Moreso, when you're in production make sure you always provide the --without development test argument to the bundle install command
bundle install --without development test
and not the usual or common
bundle install
Please note: As an indication, whenever you run the command rails c or rails console and you see the output below:
Running via Spring preloader in process 26651
WARNING: Spring is running in production. To fix this make sure the spring gem is only present in development and test groups in your Gemfile and make sure you always use bundle install --without development test in production
It's an indication that the spring gem is running in your production environment, and it should be stopped or removed entirely from your bin executables.
That's all.
I hope this helps
Spring is generally used through binstubs - did you install the binstubs? If so this is the file your rails command is running through.
#!/usr/bin/env ruby
begin
load File.expand_path('../spring', __FILE__)
rescue LoadError => e
raise unless e.message.include?('spring')
end
APP_PATH = File.expand_path('../config/application', __dir__)
require_relative '../config/boot'
require 'rails/commands'
As you can see it will load spring anytime you use the rails command. There is no check for the environment. If you do not want to load spring you can use DISABLE_SPRING=1 rails c test.
According the spring gem github page, it looks like rails console will load up spring:
rails console, rails generate, rails runner
These execute the rails command you already know and love. If you run
a different sub command (e.g. rails server) then spring will
automatically pass it through to the underlying rails executable
(without the speed-up).
Also, this is worrying:
You must not install Spring on your production environment. To
prevent it from being installed, provide the --without development
test argument to the bundle install command
rails console (development) would make sense, but not rails console test (or another environment). It seems buggy to me, and a reason now why I don't like the gem.
I have just scaffolded a Rails 5 app but the gemfile does not have any Mongodb gem or even the database.yml file does not even have any mongoDB. But when i run 'rails s' command it always outputs an error
Could not load 'active_record/connection_adapters/mongodb_adapter'. Make sure that the adapter in config/database.yml is valid. If you use an adapter other than 'mysql2', 'postgresql' or 'sqlite3' add the necessary adapter gem to the Gemfile.
Not able to understand how to even debug this as even google search does not point towards any meaningful solution
Any pointers would be greatly appreciated. Thank you in advance
I am using the following gems in my project
gem 'sunspot_rails'
group :development do
gem 'sunspot_solr'
end
I am trying to figure out why we shouldn't use sunspot gem by itself in production environment?
Most people recommend setting up a standalone solr service such as jetty+solr or tomcat+solr
There are several links that explain solr in production:
Setup sunspot solr with rails in production environment
http://outoftime.github.io/pivotal-sunspot-presentation.html
http://wiki.apache.org/solr/EmbeddedSolr
But they dont say why?
I tried putting all production data and creating indexes as i would need in production and faced no problem.
Is there anyone who has used the sunspot_solr in production and faced problems?
I installed Rails 4.2.0.beta2 per the instructions in RailsTutorial.org 3rd Edition (the one that just came out). I'm not using the cloudIDE and am instead using Ubuntu Trusty 32 via Vagrant on a Windows 7 host with RVM.
Did rails _4.2.0.beta2_ new hello_app and then pasted in his gemfile sample.
After that, I ran:
$ bundle install
$ rails s
Server starts fine, however when I try to connect to localhost:3000 I get "Server Not Found"
Weirder still, I have a couple other Rails starter projects I've been tinkering with that use Rails 4.0.3 and 4.1.6 and I'm able to connect to the server there just fine.
What am I missing here? Why can't my browser connect when I've created a new Rails project with the latest version, but it works fine with older versions?
Also, I tried wget http://0.0.0.0:3000 and while it connected and received a 200 response, the length was unspecified, whereas in another brand new Rails app under an old version, I would get the actual file size of whatever index.html was.
Regarding inaccessible server, from the Rails 4.2 release notes:
3.3 Default host for rails server
Due to a change in Rack, rails server now listens on localhost instead of 0.0.0.0 by default. This should have minimal impact on the standard development workflow as both http://127.0.0.1:3000 and http://localhost:3000 would continue to work as before on your own machine.
However, with this change you would no longer be able to access the Rails server from a different machine (e.g. your development environment is in a virtual machine and you would like to access it from the host machine), you would need to start the server with rails server -b 0.0.0.0 to restore the old behavior.
If you do this, be sure to configure your firewall properly such that only trusted machines on your network can access your development server.
127.0.0.1:3000 will only allow connections from that address on port 3000, whereas 0.0.0.0:3000 will allow connections from any address at port 3000.
Since Rails 4.2 only accepts connections from localhost by default, you can only access the server from localhost (eg. inside the VM); connections from another machine (eg. VM's host) will not work.
You must use the "old behavior" method described above to allow connections from the VM host.
Regarding unspecified content length, that depends on the web server in use. I assume it is using chunked encoding which does not send content length. Assets will have content length, but not HTML.
Rails 4.2 by default binds to 127.0.0.1:3000, instead of 0.0.0.0:3000 in earlier versions. If you have other Rails project working with your configuration, try to start a server with explicit host: rails s -b 0.0.0.0.
A guy named tostasqb posted a very interesting workaround on github to make the old behavior (Rails version < 4.2) the default.
Just edit your config/boot.rb file and add these lines:
require 'rubygems'
require 'rails/commands/server'
module Rails
class Server
alias :default_options_alias :default_options
def default_options
default_options_alias.merge!(:Host => '0.0.0.0')
end
end
end
Modify your gemfile to something like this and run bundle update. The versions you have specified are explicit. New hello_world worked for me if I did not paste in your gemfile.
gem 'rails', '~> 4.2.0.beta2'
gem 'pg'
gem 'bootstrap-sass', '~> 3.2.0'
gem 'sass-rails', '~> 5.0.0.beta1'
gem 'font-awesome-sass', '~> 4.2.0'
gem 'sprockets-rails', '~> 3.0.0.beta1'
gem 'coffee-rails', '~> 4.0.0'
gem 'uglifier', '>= 1.0.3'
Still diving into the interesting (but a bit confusing) world of developing my own gem/engine.
I have successfully deployed it to my (private) GitHub account, but as the gem is in continuous development, I don't want to deploy it again and again and then do bundle update, etc., so I found the option to require a gem by specifying a path like this:
gem 'my_gem', path: 'path/to/my/gem'
This works nicely when developing (it even seems to reload changed files from the gem when rails s is running [at least for helpers and views it seems to do it, didn't use controllers and models yet, but hoping this will be the case for them, too], which is niiiice for developing the engine while using it straight away in the host Rails app).
But when deploying to the production server, I'd like to get the gem from github:
gem 'my_gem', git: "git#github.com:my_company/my_gem"
Sadly, bundler doesn't allow to have a gem required more than once (even when they are in separate development/test and production groups), so I'm doing the following:
if File.directory?('../my_gem')
gem 'my_gem', path: '../my_gem'
else
gem 'my_gem', git: "git#github.com:my_company/my_gem.git"
end
This seems to work nicely so far (didn't test deployment using Capistrano yet, though). But it leaves some questions:
1) Is this the "right" way to solve my problem? Seems a bit odd that I didn't find a much simpler way yet, something like:
gem 'my_gem', path: '../my_gem', git: "git#github.com:my_company/my_gem.git"
...where I'd expect bundler to simply try the :path option first, and if it's not available, it's try the :git option. But as far as I see, when doing this, it only uses the :git option.
2) Is it good practice to develop gems like this? I'm extracting some functionality from my host app into an engine, and at the same time, I'm enhancing this functionality. So I have the engine gem loaded within my host app, and from within my host app I change the engine's codes which are (thank God!) reflected within my host app without having to restart the rails server. This feels quite "right", but as there is a dummy Rails app within the created engine, I'm a bit unsure whether I rather should develop my engine's strictly isolated from my host app, or not. I think this is a bit of a philosophical question, but maybe someone has an opinion about it and can post pros and contras?
3) How do I tell Capistrano to always update my own gem to the newest version from GitHub automatically?
You can do
if ENV['RAILS_ENV'] != "development"
gem 'my_gem', git: "git#github.com:my_company/my_gem.git"
else
gem 'my_gem', path: '../my_gem'
end
assuming that RAILS_ENV is being passed into the bundle command (which is so when using capistrano).
To update your gem to the latest, try making a capistrano task that essentially does this
/path/to/bundler update my_gem
I can't really comment on your other points. Just my 2 cents.