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_contr开发者_JS百科oller 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.
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
精彩评论