1 2 Previous Next 15 Replies Latest reply on Jan 23, 2007 3:15 PM by starksm64

    serializable KernelDeployment

    bill.burke

      I was experimenting with serializing a KernelDeployment, unserializing it and trying to deploy it. I have been unsuccessful so far and would like some hints. Here's what i do right now:

       AbstractKernelDeployer deployer = new AbstractKernelDeployer(kernel);
       ObjectInputStream ois = new ObjectInputStream(url.openStream());
       KernelDeployment deployment = (KernelDeployment)ois.readObject();
       Field field = AbstractKernelDeployment.class.getDeclaredField("installedContexts");
       field.setAccessible(true);
       field.set(deployment, new CopyOnWriteArrayList<KernelControllerContext>());
       ois.close();
       deployer.deploy(deployment);
      


      The "installedContexts" field of AbstractKernelDeployment is transient so I had to instantiate a new one and set the field or otherwise I would get an NPE. Now, I'm finding that most of the beans, but not all, are NOT getting installed. They are getting processed, but the state is ERROR condition. The weird thing is that some of the beans are being installed correctly. Any hints?



        • 1. Re: serializable KernelDeployment
          bill.burke

          Very simple testcase to reproduce:

          <deployment xmlns="urn:jboss:bean-deployer:2.0">
           <bean name="Two" class="org.jboss.embedded.test.SimpleBean">
           <property name="kernel">
           <inject bean="jboss.kernel:service=Kernel"/>
           </property>
           </bean>
          </deployment>
          
          


          Upon validation I get:

          Exception in thread "main" java.lang.IllegalStateException: Incompletely deployed:
          
          *** DEPLOYMENTS MISSING DEPENDENCIES: Name -> Dependency{Required State:Actual State}
          Two -> jboss.kernel:service=Kernel{Configured:**ERROR**}
          
           at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.internalValidate(AbstractKernelDeployer.java:252)
           at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.validate(AbstractKernelDeployer.java:163)
           at org.jboss.embedded.test.BeanCompilerTester.deploy(BeanCompilerTester.java:65)
           at org.jboss.embedded.test.BeanCompilerTester.main(BeanCompilerTester.java:101)
          



          • 2. Re: serializable KernelDeployment
            bill.burke

            Well, I found one problem. org.jboss.dependency.spi.ControllerState is being compared with identity ==. When it is deserialized, you a readResolve isn't done.

            Lets see if this fixes the problem.

            • 3. Re: serializable KernelDeployment
              bill.burke

              That fixed the problem. I updated ControllerState with the change. The final problem I have is that SystemProperty substitution doesn't happen after serialization (or before depending how you look at it). Looking into this now.

              • 4. Re: serializable KernelDeployment

                There are currenly no tests of the MetaData serialization, I've raised a JIRA issue:
                http://jira.jboss.com/jira/browse/JBMICROCONT-142

                • 5. Re: serializable KernelDeployment
                  bill.burke

                  I guess SystemProperty substitution happens at XML parsing? Shouldn't SystemProperty substitution happen when the actual injection happens instead?

                  • 6. Re: serializable KernelDeployment
                    starksm64

                    It would have to be changed at the existing xml processing layers to avoid duplicate substituion issues like we have seen when property replacement was introduced to Properties editor. I would agree that property substitution should be an aspect of setters rather than a paticular property data path.

                    • 7. Re: serializable KernelDeployment

                      The property replacement during the parsing is coming from JBossXB.

                      This is redundant since the microcontainer does do property replacement during
                      the setter, see ValueConvertor.convertValue() invoked indirectly from the
                      StringValueMetaData.

                      To turn off the JBossXB processing we need to change the schema bindings:
                      e.g. in BeanSchemaBinding20

                      public static void init(SchemaBinding schemaBinding)
                      {
                      + schemaBinding.setReplacePropertyRefs(false);
                      initDeployment(schemaBinding);
                      initBean(schemaBinding);
                      initBeanFactory(schemaBinding);
                      initArtifacts(schemaBinding);
                      }

                      • 8. Re: serializable KernelDeployment

                        Jira issue for property replacement:
                        http://jira.jboss.com/jira/browse/JBMICROCONT-143

                        • 9. Re: serializable KernelDeployment
                          alesj

                          serialize method in AbstractTestCase class only takes Serializable as parameter.
                          So if our returned MetaData is non-Serializable, we should throw exception (since we want all our MD to be serializable, right?)?

                          ps: this thread was hijacked with property replacement :-)

                          • 10. Re: serializable KernelDeployment

                             

                            "alesj" wrote:

                            So if our returned MetaData is non-Serializable, we should throw exception (since we want all our MD to be serializable, right?)?


                            Correct.

                            This is a candidate for AbstractTestCase in the jboss-test project.

                             /**
                             * Check we have the expected type
                             *
                             * @param <T> the expected type
                             * @param o the object
                             * @param expectedType the excepted class of the exception
                             * @return the expected type
                             */
                             protected <T> T assertInstanceOf(Object o, Class<T> expectedType)
                             {
                             return assertInstanceOf(o, expectedType, true);
                             }
                            
                             /**
                             * Check we have the expected type
                             *
                             * @param <T> the expected type
                             * @param o the object
                             * @param expectedType the excepted class of the exception
                             * @param allowNull whether the object can be null
                             * @return the expected type
                             */
                             protected <T> T assertInstanceOf(Object o, Class<T> expectedType, boolean allowNull)
                             {
                             if (expectedType == null)
                             fail("Null expectedType");
                            
                             if (o == null && allowNull)
                             return null;
                            
                             try
                             {
                             return expectedType.cast(o);
                             }
                             catch (ClassCastException e)
                             {
                             fail("Object " + o + " of class " + o.getClass().getName() + " is not an instanceof " + expectedType.getName());
                             }
                             }
                            


                            • 11. Re: serializable KernelDeployment
                              alesj

                               

                              "adrian@jboss.org" wrote:
                              "alesj" wrote:

                              So if our returned MetaData is non-Serializable, we should throw exception (since we want all our MD to be serializable, right?)?


                              Correct.


                              Ok, for MetaData there is no problem.
                              What do we do with JavaBeans (which now fail - since with wildcard test's we use plain java.lang.Object)?


                              This is a candidate for AbstractTestCase in the jboss-test project.

                               /**
                               * Check we have the expected type
                               *
                               * @param <T> the expected type
                               * @param o the object
                               * @param expectedType the excepted class of the exception
                               * @return the expected type
                               */
                               protected <T> T assertInstanceOf(Object o, Class<T> expectedType)
                               {
                               return assertInstanceOf(o, expectedType, true);
                               }
                              
                               /**
                               * Check we have the expected type
                               *
                               * @param <T> the expected type
                               * @param o the object
                               * @param expectedType the excepted class of the exception
                               * @param allowNull whether the object can be null
                               * @return the expected type
                               */
                               protected <T> T assertInstanceOf(Object o, Class<T> expectedType, boolean allowNull)
                               {
                               if (expectedType == null)
                               fail("Null expectedType");
                              
                               if (o == null && allowNull)
                               return null;
                              
                               try
                               {
                               return expectedType.cast(o);
                               }
                               catch (ClassCastException e)
                               {
                               fail("Object " + o + " of class " + o.getClass().getName() + " is not an instanceof " + expectedType.getName());
                               }
                               }
                              


                              Cool.
                              I added this code to test project.
                              Will use it in MC once I update test snapshot.

                              • 12. Re: serializable KernelDeployment

                                 

                                "alesj" wrote:

                                Ok, for MetaData there is no problem.
                                What do we do with JavaBeans (which now fail - since with wildcard test's we use plain java.lang.Object)?


                                Just change the test to use something like the following class:

                                package org.jboss.test.....;
                                
                                import java.io.Serializable;
                                
                                public class SerializableObject implements Serializable
                                {
                                 private static final long serialVersionUID = -1L;
                                }
                                


                                • 13. Re: serializable KernelDeployment
                                  bill.burke

                                   

                                  "adrian@jboss.org" wrote:
                                  The property replacement during the parsing is coming from JBossXB.

                                  This is redundant since the microcontainer does do property replacement during
                                  the setter, see ValueConvertor.convertValue() invoked indirectly from the
                                  StringValueMetaData.


                                  Thats not the behavior I saw.



                                  • 14. Re: serializable KernelDeployment
                                    alesj

                                     

                                    "bill.burke@jboss.com" wrote:
                                    "adrian@jboss.org" wrote:
                                    The property replacement during the parsing is coming from JBossXB.

                                    This is redundant since the microcontainer does do property replacement during
                                    the setter, see ValueConvertor.convertValue() invoked indirectly from the
                                    StringValueMetaData.


                                    Thats not the behavior I saw.



                                    Let's move this property replacement discussion here:
                                    - http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4005331#4005331

                                    1 2 Previous Next