scala.reflect.BeanProperty

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

scala.reflect.BeanProperty

Judson, Ross
BeanProperty has the potential to be quite useful.  I'll sketch out a
JMX use case that might be helpful to the implementing team.

JMX Mbeans are the defacto standard for managing applications on the JVM
platform.  If a Scala application (or servlet) exhibits Mbeans, many
management platforms can interoperate with the Mbean with ease.

There are quite a few ways of putting together Mbeans, but one of the
simplest ways is to create an interface for a class that has "MBean" at
the end.  Java naming conventions are used within.  If we "write it all
out" in Scala, we end up with something like this:

trait ServerMBean {
  def isProcessing: boolean
  def getTransactionCount: int
  def setTarget(t: String): unit
  def getTarget: String

  def start: unit
  def stop: unit
}

class Server extends StandardMBean(null) with ServerMBean {
  var processing = false
  var transactionCount = 0
  var target = "server1"

  def start = { }
  def stop = { }

  def isProcessing = processing
  def getTransactionCount = transactionCount
  def setTarget(s: String) = target = s
  def getTarget = target
}

BeanProperty is somewhat limiting in that it appears to operate at the
class leve only.  So I can write a class like this:

class Server {
  [BeanProperty] var transactionCount = 0
}

The "getTransactionCount" and "setTransactionCount" will be generated
directly.  I think I would like to be able to write:

trait ServerMBean {
  [BeanProperty] var processing: Boolean;
  [BeanProperty] var transactionCount: int;
  [BeanProperty] var target: String;

  def start: unit
  def stop: unit
}

class Server extends StandardMBean(null) with ServerMBean {
  var isProcessing = false
  var transactionCount = 0
  var target = "server1"

  def start = { }
  def stop = { }
}

In order for the Mbean trait to work correctly, the "get" and "set"
methods need to be in the interface, not just in the class.  

Maybe we're all just better off writing these functions out...but I
figured this use case would help illustrate one important place Scala
needs to be able to interoperate easily.  It can, right now -- it's just
a little bit verbose to create the glue code.

One other thing -- the BeanProperty-generated "get" and "set" appear in
the .class file, but do not satisfy the compiler when implementing an
interface or trait -- even though the correctly typed methods are
generated the compiler views the type as incomplete and abstract.

RJ