NPE with new parsing in aop-mc-int tests

[alesj]

I get a bunch of NPEs while testing aop-mc-int.
The exception comes from

java.lang.NullPointerException
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployment.getBeans(AbstractKernelDeployment.java:227)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:304)
 at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:133)
 at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76)
 at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88)
 at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:158)
 at org.jboss.test.kernel.junit.MicrocontainerTestDelegate.deploy(MicrocontainerTestDelegate.java:294)
 at org.jboss.test.kernel.junit.MicrocontainerTest.deploy(MicrocontainerTest.java:325)

which is this line

 for (BeanMetaDataFactory factory : factories)
 {
XXX List<BeanMetaData> beans = factory.getBeans();

Debuging the thing showed that normal mc beans are there as factories, it's the aop specfic stuff that is put there as a null.

Who matches/produces this null?

[adrian.brock]

"alesj" wrote:

Who matches/produces this null?

It's a long standing bug in JBossXB. It basically means it didn't figure out how
to create the object.

But we shouldn't be throwing an NPE there. We should have something more
informative.

[alesj]

It's a long standing bug in JBossXB. It basically means it didn't figure out how
to create the object.

Yup.
I've traced it down to not understanding aop:lifecycle-configure.
Or any aop:lifecycle-(state) for that matter.

Kabir, I thought you said the new jbossxb+aop_mc is a superset of previous schema initializers? ;-)

But we shouldn't be throwing an NPE there. We should have something more
informative.

Definitely. :-)
But this should be already handled in JBossXB.
Otherwise we can add all sorts of NPE checks throughout our metadata classes, if we cannot trust JBossXB to deal with them before.

[adrian.brock]

"alesj" wrote:

But we shouldn't be throwing an NPE there. We should have something more
informative.

Definitely. :-)
But this should be already handled in JBossXB.
Otherwise we can add all sorts of NPE checks throughout our metadata classes, if we cannot trust JBossXB to deal with them before.

What does JBossXB have to do with the following code?

KernelDeployment dep = new AbstractKernelDeployment("test");
dep.setBeans(Arrays.asList((BeanMetaDataFactory) null));

which produces the same error.

[alesj]

What does JBossXB have to do with the following code?

KernelDeployment dep = new AbstractKernelDeployment("test");
dep.setBeans(Arrays.asList((BeanMetaDataFactory) null));

which produces the same error.

Good point. :-)

I'll fix/handle this together with this:

| Then in the part where the deployment/bean are checked for classloader
| AbstractKernelDeployer::deploybean()

While I am on this subject.

I originally put all the deployment defaults in this method, but other
defaults have been added in the AbstractKernelDeployment::getBeans().

I think the AbstractKernelDeployment is the correct place for this code,
so we should look at moving all the logic that is AbstractKernelDeployer::deployBean()
into there.

Especially since the AbstractKernelDeployer is not always used,
e.g. the BeanMetaDeployer in the deployers project.

[kabirkhan]

I haven't changed anything in that area, so most likely this is caused by the upgrade to JBoss XB? That upgrade would use the org.jboss.aop.microcontainer.beans.metadata.AOPDeployment class as the root of JAXB parsing instead of the aop bean schemainitializer. Since AOPDeployment does not exist in mc trunk, how does the aop stuff even get parsed at the moment?

I can switch to use the JAXB stuff later today:
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4140727#4140727

[alesj]

Since AOPDeployment does not exist in mc trunk, how does the aop stuff even get parsed at the moment?

I've got this

package org.jboss.aop.microcontainer.beans.beanmetadatafactory;

import java.util.List;

import javax.xml.bind.annotation.XmlAnyElement;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlElements;
import javax.xml.bind.annotation.XmlNsForm;
import javax.xml.bind.annotation.XmlRootElement;
import javax.xml.bind.annotation.XmlType;

import org.jboss.beans.metadata.spi.BeanMetaDataFactory;
import org.jboss.kernel.plugins.deployment.AbstractKernelDeployment;
import org.jboss.managed.api.annotation.ManagementObject;
import org.jboss.managed.api.annotation.ManagementProperties;
import org.jboss.xb.annotations.JBossXmlSchema;

/**
 *
 * @author <a href="[e-mail]">Kabir Khan</a>
 * @version $Revision: 1.1 $
 */
@ManagementObject(properties = ManagementProperties.EXPLICIT) // TODO - explicitly add props we want to manage
@JBossXmlSchema(namespace="urn:jboss:aop-beans:1.0", elementFormDefault=XmlNsForm.QUALIFIED)
@XmlRootElement(name="aop")
@XmlType(propOrder={"annotations", "classLoader", "beanFactories", "create", "start", "stop", "destroy", "aliases"})
public class AOPDeployment extends AbstractKernelDeployment
{
 private static final long serialVersionUID = 1L;


 @XmlElements
 ({
 @XmlElement(name="aspect", type=AspectBeanMetaDataFactory.class),
 @XmlElement(name="interceptor", type=InterceptorBeanMetaDataFactory.class),
 @XmlElement(name="bind", type=BindBeanMetaDataFactory.class),
 @XmlElement(name="stack", type=StackBeanMetaDataFactory.class),
 @XmlElement(name="typedef", type=TypeDefBeanMetaDataFactory.class),
 @XmlElement(name="cflow-stack", type=CFlowStackBeanMetaDataFactory.class)
 })
 @XmlAnyElement
 public void setBeanFactories(List<BeanMetaDataFactory> beanFactories)
 {
 super.setBeanFactories(beanFactories);
 }
}

Looks like old stuff (see diff package):

 addJaxbSchema("urn:jboss:aop-beans:1.0", "org.jboss.aop.microcontainer.beans.metadata.AOPDeployment");

Why is it still there? :-)

If the metadata class is not there, you get this ignore in SingletonSchemaResolverFactory:

 public boolean addJaxbSchema(String namespace, String reference)
 {
 try
 {
 resolver.addClassBinding(namespace, reference);
 if (log.isTraceEnabled())
 log.trace("Mapped '" + namespace + "' to '" + reference + "'");
 return true;
 }
 catch (Exception ignored)
 {
 if (log.isTraceEnabled())
 log.trace("Ignored: ", ignored);
 return false;
 }
 }

And then you get the null in beanfactories - a jbossxb problem Adrian mentioned.

[kabirkhan]

 addJaxbSchema("urn:jboss:aop-beans:1.0", "org.jboss.aop.microcontainer.beans.metadata.AOPDeployment");

is correct, I moved this out for the release 2 weeks ago as mentioned on another thread. The org.jboss.aop.microcontainer.beans.beanmetadatafactory stuff is old and uses the AOPBeanSchemaInitializer. The way it uses the JAXB annotations is wrong as used on another thread.

My question was mainly a warning that I will introduce the beans.metadata package again and switch to doing it that way.

What is in mc trunk will only work with JBossXB 2.0.0.CR7

What I want to put in will only work with JBossXB 2.0.0.CR8

The "old" way and the "new" way can probably live side by side for a while, but if the target version of JBossXB in AS trunk is 2.0.0.CR8 I might as well get rid of the "old" way once and for all.