Singleton class setup in initializer, but seemingly reloaded later

I have a trivial Singleton class in my 'lib' folder, which has some
instance variables that I setup by calling a configure method from an
initializer. The initializer seems to execute just fine and sets up
the singleton instance. However, when I reference that same singleton
instance in a controller later, the instance variables are all nil, as
though the class was reloaded.

I've tried to do this in various forms using class variables, class
instance variables, but in every scenario, it seems the classes are
reloaded and all of the variables are nil.

Is there something special about how initializers run?

Environment -
Windows Vista
Ruby 1.8.6
Rails 2.3.4
WEBrick

-Nathan

Any suggestions on an alternative approach? I'm open to do anything
that works.

My use case is an Authentication adapter library. I want to load the
configuration once and construct the configured adapter once and then
use it again and again.

I want something akin to how Rails/ActiveRecord configure database
adapter.

Thoughts?

Nathan Beyer wrote:

My use case is an Authentication adapter library. I want to load the
configuration once and construct the configured adapter once and then
use it again and again.

If I understand you correctly I think you're looking for some like Ryan
Bates demonstrates here:

http://railscasts.com/episodes/85-yaml-configuration-file

Thanks for the tip.

I've changed the subject, as I think I'm honing in on the issues I'm
running into -- the loading semantics of files in the initializers
folder and files in the lib folder.

Is there anything to keep in mind when referencing classes in the lib
folder from an initializer? It seems like the files are loaded
multiple times, such that things like class variables and class
instance variables are re-initialized.

-Nathan

I've changed the subject, as I think I'm honing in on the issues I'm
running into -- the loading semantics of files in the initializers
folder and files in the lib folder.

Is there anything to keep in mind when referencing classes in the lib
folder from an initializer? It seems like the files are loaded
multiple times, such that things like class variables and class
instance variables are re-initialized.

I think I've figured out the issue. The problem seems to be that in
development, the class caching was disabled by default, so the classes
were reloaded on every request, but the initializers aren't re-run,
which is can be rather painful.

-Nathan

Nathan Beyer wrote:

I think I've figured out the issue. The problem seems to be that in
development, the class caching was disabled by default, so the classes
were reloaded on every request, but the initializers aren't re-run,
which is can be rather painful.

Yes, I would expect that class caching is disabled in development. It
would certainly be painful if it wasn't disabled. As I understand it the
disabling of the caching is done to support rapid turnaround. See a
problem, fix the code, refresh the page and see the fix. This should not
normally be a problem as long as you don't rely on global state, which I
think is good practice anyway.

Nathan Beyer wrote:
> I think I've figured out the issue. The problem seems to be that in
> development, the class caching was disabled by default, so the classes
> were reloaded on every request, but the initializers aren't re-run,
> which is can be rather painful.

Yes, I would expect that class caching is disabled in development. It
would certainly be painful if it wasn't disabled. As I understand it the
disabling of the caching is done to support rapid turnaround. See a
problem, fix the code, refresh the page and see the fix. This should not
normally be a problem as long as you don't rely on global state, which I
think is good practice anyway.

I meant, it can be rather painful to work in development mode with all
of you the classes getting reloaded EXCEPT for the initializers. That
can create some rather unpredictable behavior.

What's the problem with global state? Rails itself is full of it and
it seems a bit impractical to have no global state, or more
appropriately, state that's setup once per restart or some reload
event. What's the alternative? Sure, one could follow the trivial
example you linked to in that railscast, but at some point, it gets
painful to have all your config being hash structures.