Question

I have a jruby/rails app using:

jruby 1.4.0
Rails 2.3.5
ActiveMQ 5.3.0
Mule ESB 2.2.1

Currently in our environment.rb file we start up Mule in the initializer. This becomes a big pain when we go to do normal rake tasks that don’t require JMS/Mule such as db:migrate as it takes a long time to startup/shutdown Mule everytime.

The code is similar to this:

APP_CONTEXT = Java::our.company.package.service_clients.Initializer.getAppContext(MULE_CONFIG_PATH)

And we use APP_CONTEXT to fetch the bean to connect to the appropriate service.

I’m trying to figure out some mechanism by which APP_CONTEXT could be lazily instantiated (not in initialize) to avoid all of the pains of having to startup Mule on initialize.

Currently we have a few ruby client classes that are instantiated as a before_filter in application_controller such as @data_service = DataService.new(APP_CONTEXT) that initialize the proper java client for each request for use in our controllers.

I’m open to all suggestions. I’m having a hard time trying to find the right place to put this lazy instantiation.

Answer 1

In the end, (and i don’t know why i didn’t think of this) I’ve just made a class App that has a class method returning

@context ||= Java::our.company.package.service_clients.Initializer.getAppContext(MULE_CONFIG_PATH)

I’m not sure what was going through my head but I thought maybe if this was referenced by two functions at the same time, I’d have two different instantiations of the AppContext, forgetting that in Ruby a class is really just a singleton object, so this will always return the one context.

class App

  def self.context
    @context ||= Java::our.company.package.service_clients.Initializer.getAppContext(MULE_CONFIG_PATH)
  end
end