4 Replies Latest reply on May 20, 2008 10:45 AM by Adrian Brock

    JBMICROCONT-288 - Invalid feature request and invalid protoc

    Adrian Brock Master

      PROTOCOL

      I don't know how you manage your projects, but in mine
      things get discussed and decided on BEFORE JIRA issues get raised.
      That way we can decide what is the best way to implement it (if it all)
      and which project it should be in.

      We certainly don't break the build with bogus tests that fail
      especially when there is no way we are going support the feature
      because it doesn't make sense.

      DO ONE THING WELL

      Basic facts:
      * The Microcontaner kernel is NOT serializable.
      * There can be many kernels liviing in the same JVM at the same time.
      * The MC couldn't care less about serialization, it isn't its job.
      * Serialization is not injection

      To make JBMICROCONT-288 work (which it can't do in general)
      would require two processes.
      1) Some mechanism to regain the reference to the relevant MC kernel
      instance. i.e. probably some singleton mechanism or in general something
      more complicated
      2) A hook to (re)inject references during deserialization

      This cannot work in general
      * As above, how do you know which kernel to use? In the appserver
      there's certainly a singleton you access by doing ServiceController.getKernel();
      but that is a property of the host environment not a feature of the MC.
      * After deserialization you have two instances of the same bean.
      One registered and managed with the MC, the other not.
      Deserialization creates a whole new object
      * Beans will do things with the objects injected, e.g. register themselves in the injected object

      public void setRegistry(Registry registry)
      {
       this.registry = registry;
      }
      
      public void create()
      {
       registry.register(this);
      }
      

      In general they can do arbitrary things which would mean serialization/deserialzation
      would have to invoke the entire lifecyle. i.e. it would become like ejb passivation
      Which almost certainly isn't what you want. You don't want the service
      torn down because somebody wants to serailze the state.
      It's ok to do that for pooled EJB instances, but not for singleton services.

      My conclusion from this request would be;
      YOU'RE DOING SOMETHING WRONG
      What that is depends upon what your real feature request/requirements are,
      rather than what you wrongly think they are in JBMICROCONT-288

        • 1. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
          Carlo de Wolf Master

          I agree, the test is wrong in the fact that it serializes a MC bean.

          Yes there can be multiple kernels within one VM, that still does not preclude a serializable reference to one particular kernel.

          In actuality I should create a seriailizable object which has both the serializable kernel reference and the name of the service I want to invoke upon. Then after deserialization I can invoke that service via the kernel bus.

          But I would still need a serializable kernel reference to be able to do that.

          Maybe a KernelReferenceRegistry which functions similar to the NonSerializableFactory? So I can do KernelReferenceRegistry.getKernelReference(kernel)? But then why not make the Kernel externalizable with it's own lookup map?

          • 2. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
            Adrian Brock Master

             

            "wolfc" wrote:

            In actuality I should create a seriailizable object which has both the serializable kernel reference and the name of the service I want to invoke upon. Then after deserialization I can invoke that service via the kernel bus.

            But I would still need a serializable kernel reference to be able to do that.

            Maybe a KernelReferenceRegistry which functions similar to the NonSerializableFactory? So I can do KernelReferenceRegistry.getKernelReference(kernel)? But then why not make the Kernel externalizable with it's own lookup map?


            Because people will (ab)use it (see Al's post in the MC forum).

            I don't understand why you need to "serialize" a reference to the KernelBus
            so I can't explain what you are doing wrong.

            One of my laws of programming/debugging;
            "Don't confuse the user's chosen solution with the problem"


            • 3. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
              Carlo de Wolf Master

              The use case is using a MC bean from a registry which is by nature not MC aware. For example JNDI and Remoting (ServerInvocationHandler).

              Other use cases are passivation of objects which might contain references to MC beans. For example I might have a reference to a MC bean in a web session.
              (I think this translates to being able to have a serialized reference to a MC bean itself. But to facilitate that the MC bean would need a serialized reference to the Kernel.)

              • 4. Re: JBMICROCONT-288 - Invalid feature request and invalid pr
                Adrian Brock Master

                 

                "wolfc" wrote:

                (I think this translates to being able to have a serialized reference to a MC bean itself. But to facilitate that the MC bean would need a serialized reference to the Kernel.)


                No, that's the wrong place like I said above.

                If the problem is passivation then it is the job of the container to remove implementation
                details that are not serializable and re-instate them later. i.e. its EJB3's job

                Equally, you can't put non-serializable stuff in a web session and expect it to be serializable
                without extra work.

                I don't see what the issue is really.

                These must be internal implementation details so you know how to implement
                this "externalization", you're just being lazy. i.e. you're expecting the MC
                to do something that is not its job and will likely lead to other problems
                when others don't want, expect this behaviour or want to do something else.

                DON'T MIX IMPLEMENTATION AND POLICY