3 Replies Latest reply on Mar 5, 2007 12:59 PM by starksm64

    Still have insufficient separation of metadata

    starksm64
    starksm64 Mar 2, 2007 2:58 AM

      (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.



      • 6147 Views
      • Tags:
        • 1. Re: Still have insufficient separation of metadata
          adrian.brock Mar 5, 2007 8:04 AM (in response to starksm64)

           

          "scott.stark@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, ObjectNames 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).

            • Actions
          • 2. Re: Still have insufficient separation of metadata
            adrian.brock Mar 5, 2007 8:10 AM (in response to starksm64)

            Also, there is no reason why the dependency name cannot be null.

            Ales added support for this to the MC metadata such that a null name
            means to match the interface of the property with a singleton implementator.
            (This is similar to the Nanocontainer approach to IOC).

            <property name="TransactionManager"><inject/></property>

or the equivalent annotation

@Inject
public void setTransactionManager(TransactionManager tm) {}


            But the same processing has not been added to the JMX injection handling.
            If it were, the error reporting would be better, e.g. cannot resolve
            the interface of the jmx attribute to a singleton.
            (Although that is not what was intended in this case :-)

              • Actions
            • 3. Re: Still have insufficient separation of metadata
              starksm64
              starksm64 Mar 5, 2007 12:59 PM (in response to starksm64)

              I don't know why I would have marked it transient unless there was a related serialization problem. I'll have to come back to it when we start working on mbean management.

                • Actions