"scott.stark(a)jboss.org" wrote : For example, the ServiceMetaData contains ServiceInjectionValueMetaData which has a transient dependency that can be non-serializable (apparently, I cannot remember now why I marked it as transient): | The dependency object is just a "name". Making it transient, breaks the ServiceInjectionValueMetaData. When I created the MC api, I left open the possiblity that names could be something other than String, e.g. I anticapted that we might want to use ObjectName directly when integrating with JMX. As it turns out, that would be difficult to implement, since different contexts won't be able to compare each other's names. So in the actual code, ObjectName's are turned into their string canonical form. I still like the idea of being able to use a structured name/id when this is understood by all users. Like any serializable contract, if a user uses a name that is not serializable then they won't be able to serialize the metadata. But that doesn't mean I'm convinced that we should enforce a name to be serializable since the user may not want to serialize the metadata. So basically, I don't see why the dependency field should be transient? It isn't in AbstractDependencyValueMetaData in the MC metadata (it reuses the value field from the super class). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4025033#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...