On a related note, the interface
org.jboss.kernel.spi.deployment.KernelDeployment
is the start of the M2 deployer code.
The method KernelDeployment.getBeans()
doesn't have to have a fixed list of BeanMetaData like in the abstract
implementation.
It can be "dynamically" generated from a more conv
I've written a simple XML deployer.
The implementation is in
org.jboss.kernel.plugins.deployment.xml.XMLKernelDeployer
It uses Alexey's new MappingObjectModel from JBossXB, very nice :-)
You can define your parser in just a few lines of code;
e.g. currently I have
| objectModelFactory =
The other use of the featuremetadata is to provide metadata to each context.
But I need to discuss this with Bill because he has two mechanisms for this:
1) getMetaData(...)
2) resolveAnnotation(...)
The annotation approach is obviously superior because it is type checked,
but we also need the me
anonymous wrote :
| 1) Do we need to create subclasses of the
org.jboss.metadata.pluings.AbstractXXX classes? If yes what's a suitable
package for them?
|
No, just use the current MetaData classes. Unless you see the need to
refine the metadata classes to better handle xml based initializa
What is the context for this starting point?
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3855733#3855733
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3855733
---
