-
1. Re: serializable KernelDeployment
bill.burke Jan 19, 2007 11:52 AM (in response to 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 Jan 19, 2007 12:32 PM (in response to 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 Jan 19, 2007 2:38 PM (in response to 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
adrian.brock Jan 22, 2007 8:14 AM (in response to bill.burke)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 Jan 22, 2007 12:12 PM (in response to 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 Jan 22, 2007 2:44 PM (in response to bill.burke)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
adrian.brock Jan 23, 2007 4:51 AM (in response to bill.burke)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
adrian.brock Jan 23, 2007 4:55 AM (in response to bill.burke)Jira issue for property replacement:
http://jira.jboss.com/jira/browse/JBMICROCONT-143 -
9. Re: serializable KernelDeployment
alesj Jan 23, 2007 5:43 AM (in response to bill.burke)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
adrian.brock Jan 23, 2007 6:13 AM (in response to bill.burke)"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 Jan 23, 2007 7:37 AM (in response to bill.burke)"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
adrian.brock Jan 23, 2007 7:43 AM (in response to bill.burke)"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 Jan 23, 2007 9:19 AM (in response to 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 Jan 23, 2007 9:38 AM (in response to bill.burke)"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