Forum: Ruby on Rails "singleton can't be dumped," but not using singleton

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Fritz A. (Guest)
on 2008-12-06 00:26
An action handler (select_person_by_name) in my controller class assigns
into session, and then does a redirect_to. I get the error "TypeError
(singleton can't be dumped):" followed by a stack trace that doesn't
cross my code.

Google tells me this is ordinarily caused by assigning a singleton
instance into session, but what I'm assigning is an ordinary String.
This is verified by logging the value and its class.

Further, the log shows a "Redirected to" line to the URL I expect from
by redirect_to. The TypeError is reported from a SECOND attempt to
process the select_person_by_name handler.

The parameters for both invocations of select_person_by_name are as I
expect from what I did in the view.

select_person_by_name appears in my source twice: Once to def it, and
once as the :action in the form that invokes it.

Could someone please give me a further lead?

    -- F

===
fritzanderson:calert2 fritza$ ruby -v
ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0]
fritzanderson:calert2 fritza$ rails --version
Rails 1.2.6
===

Here is the code, boiled down. Values, classes, etc., are verified by
logger calls (omitted):
===
class AdminController < ApplicationController
    def select_person_by_name
        # Here @people is set to be an Array with one element
        case @people.size
        # Other branches omitted
        when 1
            person = @people[0]
            session[:focused_cnetid] = person.principal.cnetid
            # person.principal.cnetid is as expected, it's a String,
            # and it's generated from external data. ("fritza", nothing
special)
            redirect_to :controller => :people, :action => :show, :id =>
person
            # person.id is as expected.
        end #case
    end # select_person_by_name
end # class
Fritz A. (Guest)
on 2008-12-06 00:42
A further development: If I log
person.principal.cnetid.singleton_methods, I get "ber_identifier," which
I assume comes from the string's originating in ruby-net-ldap. What's
the best way to strip that out?

    -- F
Frederick C. (Guest)
on 2008-12-06 01:01
(Received via mailing list)
On Dec 5, 10:42 pm, Fritz A. <removed_email_address@domain.invalid>
wrote:
> A further development: If I log
> person.principal.cnetid.singleton_methods, I get "ber_identifier," which
> I assume comes from the string's originating in ruby-net-ldap. What's
> the best way to strip that out?
>
Just dup the string or something like that ?

Fred
Fritz A. (Guest)
on 2008-12-08 17:22
Frederick C. wrote:
> On Dec 5, 10:42�pm, Fritz A. <removed_email_address@domain.invalid>
> wrote:
>> A further development: If I log
>> person.principal.cnetid.singleton_methods, I get "ber_identifier," which
>> I assume comes from the string's originating in ruby-net-ldap. What's
>> the best way to strip that out?
>>
> Just dup the string or something like that ?

That in fact was the solution. Thank you.

My own attempt (it succeeded) was
("%s" % person.principal.cnetid)
which is insane.

Further note: Another approach I found via Google involved this:

===
class String
   def strip_ber_identifier
      class << self; undef :ber_identifier; end
   end
end
===

This gets into the singleton-method space and undefines the offending
method. The problem with this is that Strings that populate LDAP-return
objects from ruby-net-ldap derive their value from ber_identifier.
Stripping the method cuts them loose from the underlying LDAP record and
they come out nil.

    -- F
This topic is locked and can not be replied to.