Rails core - Mar 2006 - reloadable classes for other base classes than the built-ins

I''m working on the plugin for RBatis and a new little thing
I''m toying
around with called ActiveMessaging (sorry, David I stole the name from
you from the TW AwayDay ;-)). Anyway, in both these applications I
want to be able to have reloadable classes that don''t extend any of
the standard built in ones.

So, I don''t mean to offend the Eminent Core Members by digging up
their little skeletons but this code in dispacher.rb is.... well,
let''s settle with saying it''s not very extendable:
    def reset_application!
      Controllers.clear!
      Dependencies.clear
      ActiveRecord::Base.reset_subclasses
      Dependencies.remove_subclasses_for(ActiveRecord::Base,
ActiveRecord::Observer, ActionController::Base)
      Dependencies.remove_subclasses_for(ActionMailer::Base) if
defined?(ActionMailer::Base)
    end

In ActiveMessaging I need to reset the application from a non-web
scenario. (I have a polling process that receive messages from a
messaging infrastructure and I want reloading to happen in between
messages.) So ideally I would like to keep this outside ActionPack
(ActionPack might not even be loaded for a lot of messaging
applications!).

So I was thinking maybe an ApplicationResetter that you could add
stuff to, like so:
in ActiveRecord:
ApplicationResetter.on_reset do
      ActiveRecord::Base.reset_subclasses
      Dependencies.remove_subclasses_for(ActiveRecord::Base)
end
in ActionPack:
ApplicationResetter.on_reset do
      Controllers.clear!
      ActiveRecord::Base.reset_subclasses
      Dependencies.remove_subclasses_for(ActionController::Base)
end
And when you reset it you would go:
ApplicationResetter.reset!

Thoughts?

I guess I could create a patch for this but as it''s a pretty crucial
part of Rails it would require a lot of testing so there''s use for me
spending time on it unless I get help testing. I also suspect there
might be some interesting issues, like for example why are controllers
cleared before dependencies are?

Cheers,
Jon

On 3/2/06, Jon Tirsen <jon@tirsen.com> wrote:
> I''m working on the plugin for RBatis and a new little thing
I''m toying
> around with called ActiveMessaging (sorry, David I stole the name from
> you from the TW AwayDay ;-)). Anyway, in both these applications I
> want to be able to have reloadable classes that don''t extend any
of
> the standard built in ones.
Please give more info on this ''Active Messaging'', 
we''re currently
evaluating some options for reliable async messaging for Joyent, 
perhaps we can avoid duplicating effor.

> So, I don''t mean to offend the Eminent Core Members by digging up
> their little skeletons but this code in dispacher.rb is.... well,
> let''s settle with saying it''s not very extendable:
>     def reset_application!
>       Controllers.clear!
>       Dependencies.clear
>       ActiveRecord::Base.reset_subclasses
>       Dependencies.remove_subclasses_for(ActiveRecord::Base,
> ActiveRecord::Observer, ActionController::Base)
>       Dependencies.remove_subclasses_for(ActionMailer::Base) if
> defined?(ActionMailer::Base)
>     end
Which is why we ripped it out a few weeks ago :)

    # Reset the application by clearing out loaded controllers, views, actions,
    # mailers, and so forth. This allows them to be loaded again without having
    # to restart the server (WEBrick, FastCGI, etc.).
    def reset_application!
      Dependencies.clear
      ActiveRecord::Base.reset_subclasses
      Class.remove_class(*Reloadable.reloadable_classes)
    end

Plus, see reloadable.rb in ActiveSupprt.   Does this give you the
flexibility you need, or is there still a need for a more generic hook
into the ''reset'' code?.


--
Cheers

Koz

Jon,

do the new Reloadable and Reloadable::Subclasses modules in edge  
rails (and I assume to be included in 1.1) help you?

Regards,
Trevor

--
Trevor Squires
http://somethinglearned.com



On 1-Mar-06, at 8:00 PM, Jon Tirsen wrote:
> I''m working on the plugin for RBatis and a new little thing
I''m toying
> around with called ActiveMessaging (sorry, David I stole the name from
> you from the TW AwayDay ;-)). Anyway, in both these applications I
> want to be able to have reloadable classes that don''t extend any
of
> the standard built in ones.
>
> So, I don''t mean to offend the Eminent Core Members by digging up
> their little skeletons but this code in dispacher.rb is.... well,
> let''s settle with saying it''s not very extendable:
>     def reset_application!
>       Controllers.clear!
>       Dependencies.clear
>       ActiveRecord::Base.reset_subclasses
>       Dependencies.remove_subclasses_for(ActiveRecord::Base,
> ActiveRecord::Observer, ActionController::Base)
>       Dependencies.remove_subclasses_for(ActionMailer::Base) if
> defined?(ActionMailer::Base)
>     end
>
> In ActiveMessaging I need to reset the application from a non-web
> scenario. (I have a polling process that receive messages from a
> messaging infrastructure and I want reloading to happen in between
> messages.) So ideally I would like to keep this outside ActionPack
> (ActionPack might not even be loaded for a lot of messaging
> applications!).
>
> So I was thinking maybe an ApplicationResetter that you could add
> stuff to, like so:
> in ActiveRecord:
> ApplicationResetter.on_reset do
>       ActiveRecord::Base.reset_subclasses
>       Dependencies.remove_subclasses_for(ActiveRecord::Base)
> end
> in ActionPack:
> ApplicationResetter.on_reset do
>       Controllers.clear!
>       ActiveRecord::Base.reset_subclasses
>       Dependencies.remove_subclasses_for(ActionController::Base)
> end
> And when you reset it you would go:
> ApplicationResetter.reset!
>
> Thoughts?
>
> I guess I could create a patch for this but as it''s a pretty
crucial
> part of Rails it would require a lot of testing so there''s use for
me
> spending time on it unless I get help testing. I also suspect there
> might be some interesting issues, like for example why are controllers
> cleared before dependencies are?
>
> Cheers,
> Jon
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core

On 3/2/06, Michael Koziarski <michael@koziarski.com>
wrote:
> On 3/2/06, Jon Tirsen <jon@tirsen.com> wrote:
> > I''m working on the plugin for RBatis and a new little thing
I''m toying
> > around with called ActiveMessaging (sorry, David I stole the name from
> > you from the TW AwayDay ;-)). Anyway, in both these applications I
> > want to be able to have reloadable classes that don''t extend
any of
> > the standard built in ones.
>
> Please give more info on this ''Active Messaging'', 
we''re currently
> evaluating some options for reliable async messaging for Joyent,
> perhaps we can avoid duplicating effor.
I''ve just started playing with this but it works something like this:
messaging.yml sets up connections to messaging infrastructure per
environment (think database.yml).
subscriptions.rb enlists what queues you''re interested in and what
processor should process messages from what queue (think routes.rb).
You start one or more poller.rb which does a "receive" on the
connection and blocks until a new message comes in, sends it off to
the processor (through Dispatcher). Only one message is processed at a
time in the poller.rb process, if you want more throughput start
another poller.rb. (Threads suck!)
There''s a bit of an adapter framework to potentially support multiple
messaging infrastructures. Currently supports STOMP (gem install
stomp) which is a lightweight protocol supported by ActiveMQ
(activemq.codehaus.org). It works *amazingly* well for being a Java
product. ;-) Download the .zip, unzip, uncomment STOMP listener in
conf/activemq.xml, start bin/activemq, done!
An IBM MQ Series adapter should be relatively easy to implement on top
of the XMS C api, this would make it dead easy to build Rails apps on
top of sucky mainframes.
Also for the purist it should be really easy to implement a
lightweight messaging implementation on top of ActiveRecord. This
would likely primarily be for intra-application messaging, but would
enable async processing without taking up a FastCGI process such as
credit card processing and so on.

It''s not rocket science but nice, easy and relatively Railsesque.
> Which is why we ripped it out a few weeks ago :)
Ha! Suits me for not being on edge! :-)
>     def reset_application!
>       Dependencies.clear
>       ActiveRecord::Base.reset_subclasses
>       Class.remove_class(*Reloadable.reloadable_classes)
>     end
>
> Plus, see reloadable.rb in ActiveSupprt.   Does this give you the
> flexibility you need, or is there still a need for a more generic hook
> into the ''reset'' code?.
It is probably enough for ActiveMessaging as I''m not doing clever
stuff like ActiveRecord there. For RBatis it might not be as I might
need to do something to clean out old SQL statements before reloading.
Not sure. I will investigate and get back to you.