(Reposted after cleaning up the confused thoughts) Even after the attempt to cleanup the DeploymentUnit attachment transient vs trasient managed object attachments by putting non-serializable attachments into the transient bucket, while looking into JBMICROCONT-152 even serializable metadata is too aggregate to be able to make this distinction. 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): | public class ServiceInjectionValueMetaData extends AbstractMetaDataVisitorNode | implements ServiceValueMetaData, Serializable | { | private static final long serialVersionUID = 1; | | /** The dependency */ | private transient Object dependency; | | /** The property */ | private String property; | | /** The required state of the dependency */ | private ControllerState dependentState = ControllerState.INSTALLED; | This was not a valid transformation to a Serializable because the dependency cannot be restored, and its a neccessary attribute. A similar problem exists with ServiceConstructorMetaData as this generally contains arbitrary non-serializable/non-managed metadata needed to construct the underlying service instance. So, the default attachment bucket is going to have to be the transient one. Only if a deployer knows its metadata can be used as a serializable transient managed object would it use the transient managed object bucket explicitly. Generally it looks like the existing metadata is going to have to be refactored to allow for externalizable managed objects that can be persisted. We need to come back to this post the jboss5 beta2 release when the work done by Adrian has been integrated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4024558#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...