programmatically creation of metadata

[tom.baeyens]

i want to create the metadata programmatically and then instantiate a bean.

the test runs ok. i just want to know if this is normal API usage or if i'm doing silly things or wether there is a simpler alternative that i'm missing.

public static class MyTestBean {
 }

 public void testProgrammaticMetaData() throws Throwable {
 AbstractBeanMetaData beanMetaData = new AbstractBeanMetaData();
 beanMetaData.setBean("org.jbpm.env.JBossMcTest$MyTestBean");

 String beanClassName = beanMetaData.getBean();
 ClassLoader classLoader = JBossMcTest.class.getClassLoader();
 KernelConfig kernelConfig = KernelConfigFactory.newInstance();
 ClassAdapterFactory classAdapterFactory = new ReflectClassAdapterFactory();
 ClassAdapter classAdapter = classAdapterFactory.getClassAdapter(beanClassName, classLoader);
 BeanInfo beanInfo = new AbstractBeanInfoFactory().getBeanInfo(classAdapter);
 Object instantiatedBean = Configurator.instantiateAndConfigure(kernelConfig, beanInfo, beanMetaData);

 assertEquals(MyTestBean.class, instantiatedBean.getClass());
 }

regards, tom.

[adrian.brock]

Not quite. You should just be able to do:

BeanMetaData bmd = ...
KernelConfig config = new PropertyKernelConfig(System.getProperties());
BeanInfo beanInfo = config.getBeanInfo(bmd.getName(), Thread.currentThread().getContextClassLoader());
Object result = Configurator.instantiateAndConfigure(config, beanInfo, bmd);

See the config tests for more info (although it is hidden in an abstract test class).

I am currently working on a simplification of the api
so you don't have to do so many steps to override the implementation
(you show the entire construction path).

JBossXB, Hibernate (and hopefully jboss serialization, if I can persusade Clebert ;-)
have a similar requirement in terms of taking advantage of the ClassInfo reflection
optimizations (both caching and the performance of the reflection object).

[tom.baeyens]

ok. good to see that i'm on the right track.

i don't care much about the many construction steps... but if you're simplifying that, even better.

next is the XML parsing. in barcelona you mentioned that there are multiple parsers for the beaninfo. if i recall correctly, i could add a parser based on org.w3c.dom and add that somewhere in the kernel module so that it 'automaticall' would be maintained.

is that what i should do ? or should i just do the xml parsing based on plain J2SE in my own project ?

regards, tom.

[adrian.brock]

next is the XML parsing. in barcelona you mentioned that there are multiple parsers for the beaninfo.

I'll only maintain stuff that has tests. :-)
In fact, there is only one xml parsing routine now (previously there were two).

I'd prefer you persuaded Alex to do whatever it is you want to do at the JBossXB level.
That is the place to deal with XML issues within JBoss.

I don't want any direct dependency on xml/implementation/features in the MC code.

In Barcelona, I said I was thinking of writing a property file -> BeanMetaData parser.
i.e. like log4j has the option to use a .properties or a .xml

[adrian.brock]

I'd prefer you persuaded Alex to do whatever it is you want to do at the JBossXB level.
That is the place to deal with XML issues within JBoss.

In fact, the xml parser within the MC code is likely to disappear once the
schema annotation issues have been resolved.

[tom.baeyens]

i'll dig into the jaxb parsing issue that introduced a dependency on xerces. also i'll also have to dig a bit in jaxb... walking a dom tree seems much easier to me.

"adrian" wrote:
I'll only maintain stuff that has tests. :-)

great ! then you can maintain jBPM while i learn about jaxb :)

thanks, regards, tom.