Jruby 1.7.x compatibility with Warbler gemjar - ruby-on-rails-3

I have an application using JRuby 1.6.7, Ruby 1.9.2, Rails 3.1.3 and Warbler 1.4.0.beta2
For a while now, I have been trying to update the application to use JRuby 1.7.x. Every time I tried (with versions 1.7.3, 1.7.4, and most recently 1.7.6) I would get the following error:
org.jruby.rack.RackInitializationException: No such file or directory - /home/production/var/tmp/Jetty_0_0_.war/webapp/WEB-INF/lib/gems.jar!/gems/activesupport-3.1.3/lib/active_support/locale/en.yml
After some help from this question here: Warble not including active support locale files, pin pointed that that issue was with the warbler configuration in my application. We had enabled the following configuration:
config.features = %w(gemjar executable compiled)
Specifically, the gemjar feature was the one causing the issue. With that feature disabled, everything works fine (the WAR deploys perfectly)
I am wondering, if anyone else has run into this, or if anyone knows what the issue might be?
And then more specifically, what are the disadvantages to disabling the gemjar feature of Warbler? From what I can tell, there shouldn't theoretically be anything devastating by disabling it... but I may be overlooking something.
(I do also wonder if the full warbler 1.4.0 release might fix this... but I can't find anything about when a release might be coming out)

there are none - actually running a .war with gemjar might have issues on some servers (esp. if they do not expand the deployed .war, since then it's quite hard to reference files/resources packaged in a .war while still inside a .jar). on the other hand it should roll fine if things are expanded (even with gemjar) ...
you should definitely report this with Warbler's repository (if not reported already).
it should not be hard to fix - likely a one liner, I know a PR would be most welcome :)
NOTE: on the other hand if it worked in a previous JRuby and updating 1.7.x is the issue, than it might be a "regression" on JRuby's side and they might actually fix this if they knew about it ...

Related

RVM stuck on version 2.3.3

I have several versions of Ruby installed via RVM. I have been using Ruby 2.5.0 for a while, but also working on projects at 2.3.3. Every time I open the terminal or a new tab, it switches to version 2.3.3. I have set the default to 2.5.0, but it doesn't respect this.
I finally pushed my last commit that needed 2.3.3 so I thought I could just nuke it and maybe that would fix my problem. One the one hand, it now correctly defaults to 2.5.0, but always with the error:
Required ruby-2.3.3 is not installed.
What does it take to make RVM switch to the default and stay there? Why would it be hung up on this specific version?
I had the same problem and it drove me nearly crazy. All symlinks and config files under /usr/local/rvm/config where pointing to 2.5.3, as I set it up to, but I got the same message as you. Turned out there was a .ruby-version file in the project directory that overrode all settings. Updating this file to the correct version did it for me. Hope it helps you too.

Custom precompilation location?

Can I change the default precompilation location to something different than ~/.perl6? I want to allow for using different versions of Rakudo-Star on my system without having to totally remove this directory each time I switch versions (i.e. to avoid precompilation issues).
There is absolutely no reason for you to remove ~/.perl6. The whole precompilation management system was specifically designed for being able to share installed modules between different versions of rakudo. Everything should just work fine without any user intervention.
If you do come across issues, that's bugs we want to fix. So please report those issues to rakudobug#perl.org or on the #perl6 IRC channel. Feel free to alert me (nine) on the IRC channel about those.

Strange application behavior when building a project with the latest xcode/OSX version

I have an OSX application written in Objective-C/Cocoa using xcode. The application is quite finished, tested and sold on the App Store.
I haven't worked on this application for some time and recently, I rebuilt it using xcode 4.3.3 on my OSX 10.7.4 and I noticed that while it builds just fine, there are some very strange visual glitches when running the application that were never seen before and occasionally, I get EXC_BAD_ACCESS when closing the application. All these seem to be related to the PDFKit framework I am using. I am unable to debug these problems since the glitches are just visual (nothing I can check in code) and EXC_BAD_ACCESS exception comes from internally allocated objects not related to my code.
The code itself haven't changed, I tried previous revisions of the code and they all exhibit the same strange behavior now. I tried running an old binary I have of the application (compiled couple of months ago) and it works just fine. Then I tried building it with previous versions of xcode, down to 4.2.1 (which I know was ok when I submitted the app to the app store) and the problems still occur.
Then I suspected this may be something specific to my environment so I built the project on different machine also with xcode 4.3.2 and OSX 10.7.4. Same results, the problems are still there.
So now I suspect that it has something to do with the OSX 10.7.4 update since this is the last thing that was changed between now and when I was able to produce a good build of the application. I am pretty puzzled to what to do next and how to identify the cause of this problem. I have an old binary that is working fine and I have a newly compiled binary of the same code revision that has problems.
Is there any useful information I can get from the difference of these binaries? What can I do to determine the cause of these problems? What can I try next?
Thanks!
NOTE (update): I stated it above but I want to make sure it is clear. This is a Mac OSX Cocoa application, not iOS.
just reset your simulator then try.
I hope you check the ARC information
go to your project Target set build settings --> Search Paths-->Always Search User Paths Set Yes.
And check your all class variables different from one another.
Xcode--> preferences-->Documentation check installed core Libraries (or) install it
like that
Xcode--> preferences-->Components check required component installed or not
check these things in your project.
Are you sure your customers are not having the same problem? Since you have tested the application on a different machine you probably do not have corrupt libraries installed (unless you did not install from scratch but used some migration tool?), so that is probably not the problem.
Most logical explanation to me would be that your customers also have this problem but they haven't reported it yet. In that case, you probably have a memory problem and there are techniques to attack that.
In any case, eliminate all the parameters that you can eliminate to simplify the problem. Deconstruct the application until the problem does not occur anymore or reconstruct the application in a different project until the problem occurs again.
It sounds like a nasty one, but you'll get there in the end, with patience and perseverance :)
First of all, you need check and verify the build log for suspicious compiler warnings.
For EXC_BAD_ACCESS, XCode analysis will give useful information.
You could try 10.6 or 10.5 (need manual installation) SDK. Or restrict the deployment target to 10.5 or 10.6.
I will answer my own question (since none of the above answers really answer it) so anyone with a similar problem might have a hint. I was not able to understand why exactly this happens but I'm pretty sure this is not a problem with my code but rather some glitch on Apple's side. And there is a workaround.
First, I compiled Apple's sample "PDF Annotation Editor" project on my Lion 10.7.4 and while the functionality is obviously different from my project, it also exhibited similar glitches with the PDFView display that my project does when compiled with 10.7.4
Then I proceeded to building a fresh clean system on new hard disk. Intalled Snow Leopard and upgraded to 10.6.8 and ONLY installed xcode. Compiled my project (the source code always stays exactly the same) and everything works fine. No problems seen in the compiled project.
Updated my OSX to Lion 10.7.4 and xcode 4.3.3, same source code. The problem is there after I compile it. I am pretty sure that if I tried 10.7.3 first, I would not see the problem as I remember it only starts with 10.7.4 but Apple doesn't provide any reasonable way to update to 10.7.3 first or downgrade to it after 10.7.4 is installed (shame on them, not very developer friendly!).
So, the problem appears in 10.7.4.
Then I installed the pre-release version of 10.7.5. This was the only thing that was changed, same source, same xcode. To my surprise, the compiled code works flawlessly now and the problems seen with 10.7.4 are now gone!
So my workaround - wait for 10.7.5 release before working on the project further. Hopefully Apple won't screw it in the future with Mountain Lion. I don't think I am going to try and debug it further or submit a ticket to Apple, going to be a tough case to explain.
Thanks for the responses.

Building .war with JRuby and warbler

I have been trying for hours to get a JRuby Rails application packaged as a war that actually works, without success... (JRuby 1.6.7, warbler 1.3.5, Rails 3.2.2)
Issue #1: Warbler seems to like to lump all libraries in one root folder rather than respecting the subdirectories they originally came from. For example, the Rails app itself runs fine but the war is broken when libraries are referenced as
require "lib/foo/bar.jar"
require "lib/baz.rb"
Mind you, foo/bar.jar and baz.rb are actually present in WEB-INF/lib, I just don't know how to configure Warbler to wire things up so the requires work right.
Issue #2: If I condescend to change all the requires to
require "bar.jar"
require "baz.rb"
, all is well if I build an executable war file, but if I try dropping the war into a Tomcat 6.0.20 installation, the application fails to initialize:
SEVERE: Error: application initialization failed
java.lang.NullPointerException
at org.jruby.RubyInstanceConfig$ArgumentProcessor.processArguments(RubyInstanceConfig.java:711)
No amount of Googling has shed light on what the problem is. Presumably the war is missing something or misconfigured somehow, but what is it?
I can't say for sure this would cause your error - however I remember that there was a known bug between Jruby and Rails 3.2.x - which was apparently fixed in Jruby 1.7.
I had tried using Rails 3.2 with Jruby 1.6.7 before and came across this:
JIRA-Ticket-JRUBY-3986
Hope that may at least help a little

Any luck with mod_libpq under Apache 2.2 and/or win32?

Has anyone had luck compiling mod_libpq for Apache 2? I know there were some fairly major changes so the source might have to be updated, but has it been done already by someone?
Also, has it been compiled for win32 (either version of Apache, or another web server altogether?)
I've written an updated version for Apache2.2 which can be downloaded from
http://asmith.id.au/source/mod_libpq2.c
However, it is my first attempt at writing a module for Apache2 and it is not debugged yet.
Previously I had no use for it as I was still using Apache1.3 but since I am now faced with retiring that old server I guess I'll have to finish off the new version.