This is usually not many, but
if you deploy with Rails integration, it might be more than one. The constructor of this class
takes an IRubyObject. You don??™t care what object that is; you just use it to get at the JRuby runtime,
so you can save it. You use the current number to save away the current instance in the
MBean server with a generated object name, based on the number this instance has. The
runner method implementation just calls evalScriptlet with the command as the argument,
CHAPTER 10 ?– AN EJB-BACKED RAILS APPLICATION 195
then invokes the Ruby method "inspect" on the result, and finally calls toString() on the
result. This results in something readable in all cases, because inspect should always return
readable String representations.
When you??™ve compiled these files and added them to the bbservice.jar file, there are
only two more things to do. First, open up the runjr file and add this setting somewhere in it:
export JAVA_OPTS=-Dcom.sun.management.jmxremote
That way there will be a JMX MBean server available for you. Finally, open config/
environment.rb, and add this at the bottom:
com.bb.rails.RailsOperation.new(self)
Because you don??™t care about which IRubyObject you send in to the constructor of
RailsOperation, you use the current self, which is bound to be an object that the JRuby runtime
won??™t automatically convert into something else. In this way, you make sure that the
MBean gets registered at startup of a new Rails instance, and that this will only happen once
for each Rails instance.
Pages:
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295