r6160 Tempfile implemenation breaks default Ruby 1.8.6 behavior
---------------------------------------------------------------
Key: JRUBY-2258
URL: http://jira.codehaus.org/browse/JRUBY-2258
Project: JRuby
Issue Type: Bug
Components: Application Error
Environment: JRuby trunk, Rails 1.2.6, attachment_fu plugin
Reporter: Martin Grund
Hi,
when using JRuby trunk together with Rails 1.2.6 and the attachment_fu plugin I
come across the following problem: The temp-file implementation of JRuby is
different from the one in Ruby 1.8.6 which leads to a problem when using the
attachment_fu Rails plugin.
In MRI when calling Tempfile.new this method calls make_tmpname with two
parameters basename and n (a counter), in JRuby revision r6160 the signature of
make_tmpname changed. Unfortunatly attachment_fu opens Tempfile and changes the
implementation of make_tmpname but with a different signature. When now the new
implementation of Tempfile.new calls the overwritten implementation of
make_tmpname this results in an error beacause of a different argument count.
The problem here is, that this is not easy solvable because of the following
reasons:
1.) MRI 1.8.6 uses Thread.critical to make sure that no other Thread is
scheduled, but this works only in a green threaded environment - that was the
reason why the source was changed I assume
2.) make_tmpname is a private method and should not be redefined, but the
redefinition is based on the private signature of MRI 1.8.6
3) Changing the implementation back to one using counters would not help since
this goes back to the problems of (1)
I am aware of the difficulty of this bug report but all I could do without
changing the whole source code was to revert back to version 6159 of JRuby
where everything worked fine.
Regards,
Martin
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
