The parsing deployers are now almost entirely declaritive.
In many cases, you could consider that we don't need seperate classes
and the whole thing could be done with xml.
You no longer need to do
| public void deploy(...)
| {
| createMetaData(unit, null, "-ds.xml");
| }
|
Instead you can do
| public MyParsingDeployer
| {
| setSuffix("-ds.xml");
| }
|
The only reason for a class is if you need to do "after" processing.
Many deployers had overridden "random" parts of the api without
spotting that this callback already existed in init() and it already
does the "null" checking.
| public class BeanDeployer extends SchemaResolverDeployer<KernelDeployment>
| {
| /**
| * Create a new BeanDeployer.
| */
| public BeanDeployer()
| {
| super(KernelDeployment.class);
| setSuffix("-beans.xml");
| }
|
| @Override
| protected void init(VFSDeploymentUnit unit, KernelDeployment metaData, VirtualFile
file) throws Exception
| {
| String name = file.toURI().toString();
| metaData.setName(name);
| }
|
Some other deployers were also doing other checks besides the metadata
file existed. IMHO most of these are HACKs that should be fixed.
But to make this easier, I added the accepts() callback to the parsing deployers
so each deployer doesn't have to put this wiring in themselves.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4058861#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...