[jruby-dev] [jira] Created: (JRUBY-4892) multipart file upload failed
multipart file upload failed Key: JRUBY-4892 URL: http://jira.codehaus.org/browse/JRUBY-4892 Project: JRuby Issue Type: Bug Components: Rails WAR Deployment Affects Versions: JRuby 1.5 Environment: Windows, apache-tomcat-6.0.26, jruby 1.5, rails-2.3.8 Reporter: profiit Hi There, If we use WEBRICK (JRUBY script/server) everythig is working fine, but if the same code depolyed under APACHE it does't work. Could you let me know some instruction how we can deploy it under APACHE. THANKS GEZA HERE IS THE LOG: 2010.06.16. 18:15:16 org.apache.catalina.core.ApplicationContext log INFO: /!\ FAILSAFE /!\ Wed Jun 16 18:15:16 +0200 2010 Status: 500 Internal Server Error bad content body file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/vendor/rack-1.1.0/rack/utils.rb:467:in `parse_multipart' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/vendor/rack-1.1.0/rack/request.rb:268:in `parse_multipart' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/vendor/rack-1.1.0/rack/request.rb:146:in `POST' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/vendor/rack-1.1.0/rack/methodoverride.rb:15:in `call' C:/apache-tomcat/webapps/gfr/WEB-INF/gems/gems/actionpack-2.3.8/lib/action_controller/params_parser.rb:15:in `call' C:/apache-tomcat/webapps/gfr/WEB-INF/gems/gems/actionpack-2.3.8/lib/action_controller/session/cookie_store.rb:99:in `call' C:/apache-tomcat/webapps/gfr/WEB-INF/gems/gems/actionpack-2.3.8/lib/action_controller/failsafe.rb:26:in `call' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/vendor/rack-1.1.0/rack/lock.rb:11:in `call' C:/apache-tomcat/webapps/gfr/WEB-INF/gems/gems/actionpack-2.3.8/lib/action_controller/dispatcher.rb:106:in `call' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/rack/adapter/rails.rb:36:in `serve_rails' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/rack/adapter/rails.rb:41:in `call' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/jruby/rack/rails.rb:180:in `call' file:/C:/apache-tomcat/webapps/gfr/WEB-INF/lib/jruby-rack-1.0.1.jar!/rack/handler/servlet.rb:19:in `call' :1 -- 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
Re: [jruby-dev] Improving Ruby to Java call performance: no instance vars or singletons
I was sick and not reading this thread. I have code which uses both ivars and singleton objects. I can say in both instances I could mark the classes which would use these features because I know in-advance that those classes will add this behavior. For people who know JRuby already this is not a problem to make this change. My reservation on this is the fact that it violates least surprise. As a new user I will be pretty surprised when my stuff disappears. This is a hard problem and if we can at least reduce the scope by making ivars work then I can probably live with singletons not working as expected for new users. The number of people annotating ivars over creating singleton behavior is probably huge. -Tom On Tue, Jun 15, 2010 at 2:51 AM, Charles Oliver Nutter wrote: > Perhaps, though the opt-in wouldn't be per object, it would be per > class. You'd essentially specify that you want to use instance vars or > singletons with a given Java type. > > I will probably at least try to mock up the lazy ivar logic, which > seems like it could work. The singleton logic...that's tougher. > > On Mon, Jun 14, 2010 at 8:42 AM, Brandon Hauff > wrote: >> Could the opt-in be in the form of a command line opt or a require >> 'somenewlib' which would likely be a lot easier to port and more clean than >> calling a method per object? >> >>> -Original Message- >>> From: Charles Oliver Nutter [mailto:head...@headius.com] >>> Sent: Sunday, June 13, 2010 6:28 PM >>> To: dev@jruby.codehaus.org >>> Subject: Re: [jruby-dev] Improving Ruby to Java call performance: no >>> instance vars or singletons >>> >>> On Sun, Jun 13, 2010 at 11:19 PM, Charles Oliver Nutter >>> wrote: >>> > On Sun, Jun 13, 2010 at 2:54 AM, Wayne Meissner >>> wrote: >>> >> Could the weak ref wiring be done lazily, so the overhead is only >>> >> incurred when someone sets an ivar on a java object? >>> >> >>> >> e.g. when a java object enters jruby, it gets a new lightweight >>> >> wrapper, but when someone does an ivar get/set on it, it looks for >>> the >>> >> ivar holder for the java object in the weak map, and attaches it to >>> >> the wrapper (or creates one and adds it to the weak map if it is >>> >> missing). >>> >> >>> >> This way, java objects that are just passing through, don't take the >>> >> hit of wiring up a Reference, but when it is needed, it >>> automagically >>> >> works (with perhaps a bit more overhead than at present). >>> > >>> > I've tried to think of a way to do this, but we'd need to be able to >>> > trigger all in-flight references to a given object to start using the >>> > ivars from the wrapper where we just added ivars. >>> >>> Actually, I may have just thought of a way to do this. >>> >>> * Upon access or modification of an instance variable, a wrapper adds >>> itself to our tracking map >>> * Wrappers that have not yet been tracked will know they are not being >>> tracked, and when an instance variable access happens they'll first go >>> look in the tracking map for the "master" wrapper >>> * Objects that don't ever access instance variables will never lift >>> themselves into the tracking map and never incur the weakref costs >>> >>> I think this could work! >>> >>> A similar technique might be able to work for singletonized Java >>> objects, although it has a higher potential of "poisoning" all >>> instances of a given type: >>> >>> * All Java proxy types would have a bit indicating whether an instance >>> of them had ever been singletonized >>> * When the first object of a given Java type gets singletonized, we >>> flip this bit and add that singletonized wrapper to the tracking map. >>> From then on, non-tracked wrappers for the same object will go to the >>> "master" wrapper for their metaclass behavior, and future references >>> will use the same wrapper. >>> * The poisoning effect: future wrappers for the same type will either >>> need to constantly ping the tracking map or else all instance of that >>> type will have to go into the weak map once again. >>> >>> Note that in order to completely eliminate the wrappers (or completely >>> eliminate the use of the tracking map, for now), both features need to >>> be addressed. Any better suggestions for handling singletons (other >>> than turning them off, which has my vote!) >>> >>> - Charlie >>> >>> - >>> To unsubscribe from this list, please visit: >>> >>> http://xircles.codehaus.org/manage_email >>> >> >> > > - > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- blog: http://blog.enebo.com twitter: tom_enebo mail: tom.en...@gmail.com - To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
[jruby-dev] [jira] Created: (JRUBY-4893) Yecht fails to parse nested YAML with split newlines
Yecht fails to parse nested YAML with split newlines
Key: JRUBY-4893
URL: http://jira.codehaus.org/browse/JRUBY-4893
Project: JRuby
Issue Type: Bug
Affects Versions: JRuby 1.5
Environment: Java 1.6.0_20-b-02, Windows Server 2003
Reporter: Colin Strasser
Assignee: Thomas E Enebo
Attachments: nested.yml
In JRuby 1.3 (JvYAML), the attached file parses as expected:
{code:title=JRuby 1.3 parsing nested YAML}
irb(main):032:0> y = YAML::parse_file("C:\\nested.yml")
=> #
irb(main):033:0> py = YAML::parse(y.value)
=> #=>#, #<
YAML::JvYAML::Scalar:0x5e9f1 @value="x", @kind=:scalar, @style="\000",
@type_id="tag:yaml.org,2002:s
tr">=>#}, @kind=:map, @style=false, @type_id="tag:yaml.org,2002:map">],
@kind=:seq, @style=f
alse, @type_id="tag:yaml.org,2002:seq">
irb(main):034:0> py.display
---
- y: v2
x: v1
=> nil
irb(main):035:0>
{code}
But in JRuby 1.5 (probably 1.4+) using Yecht, the same file yields an error:
{code:title=JRuby 1.5 using Yecht can't parse the contents of the file}
>> y = YAML::parse_file("C:\\nested.yml")
=> #
>> py = YAML::parse(y.value)
ArgumentError: syntax error on line 2, col 4: `\ x: v1'
from yaml:177:in `parse'
from (irb):23
>>
{code}
I distilled the file from actual output of the yaml_db library. I was trying to
export data from a SQLite3 table, one column of which was YAML text. It appears
that some newlines (\n) were split across two lines of the resulting YAML and
Yecht doesn't like that.
--
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
[jruby-dev] [jira] Created: (JRUBY-4894) When using a JFormattedTextField calling preferred_size is not working as would a JButton object
When using a JFormattedTextField calling preferred_size is not working as would
a JButton object
Key: JRUBY-4894
URL: http://jira.codehaus.org/browse/JRUBY-4894
Project: JRuby
Issue Type: Bug
Components: Java Integration
Affects Versions: JRuby 1.5.1
Environment: Ubuntu / Windows
Reporter: Jean Lazarou
Using rubish notation for the method 'getPreferredSize' instead of the Java
name does not resolve the same way for JFormattedTextField as for other
components like JButton. Next example shows that for JFormattedTextField it
returns nil. As a workaround use 'get_preferred_size'.
include Java
comp = javax.swing.JButton.new("hello")
puts "#{comp.class} #{comp.preferred_size.nil?} /
#{comp.get_preferred_size.nil?}"
comp = javax.swing.JFormattedTextField.new("hello")
puts "#{comp.class} #{comp.preferred_size.nil?} /
#{comp.get_preferred_size.nil?}"
--
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
