[Design the new POJO MicroContainer] - Precedence
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote : How do you define precedence rules for deployer ordering? For example, let's take a hypothetical Seam deployer that needs to augment an EJB deployment based on additional metadata within the deployment unit. It needs to happen after EJB XML and Annotation processing, but before component processing.
|
| I liked the install/uninstall approach (see below if you dont' know what I'm talking about) because we could have added precedence metadata to the addDeployer method. Precendence metadata like, I have to come before the EJB component processing, but after the XML/annotation processing.
|
|
| | <install bean="MainDeployer" method="addDeployer">
| | <parameter><this/></parameter>
| | </install>
| | <uninstall bean="MainDeployer" method="removeDeployer">
| | <parameter><this/></parameter>
| | </uninstall>
| |
|
|
See the part where I describe attachment flows.
For your example (assuming JMX components) you would do something like:
| public MySeamDeployer extends AbstractSimpleRealDeployer<SeamMetaData.class>
| {
| public MySeamDeployer()
| {
| // We are after everything that creates and modifies SeamMetaData
| super(SeamMetaData.class);
|
| // We need the EJB deployment and Annotation metadata
| setInputs(EJB3Deployment.class, AnnotationCache.class);
| // We output a -service.xml description so we are before that deployer
| setOutputs(ServiceDeploymentMetaData.class);
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059100#4059100
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059100
17 years, 6 months
[Design the new POJO MicroContainer] - In callback
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote :
| | <bean name="StructuralDeployers" class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl">
| | <!-- Accept any implementor of structure deployer -->
| | <incallback method="addDeployer"/>
| | <uncallback method="removeDeployer"/>
| | </bean>
| |
|
|
| So the incallback means that any bean that implements the interfaces of VFSStructuralDeployersImpl will automatically incur an addDeployer(this) call on the StructuralDeployer's bean? Or the parameter type of the addDeployer method?
|
It is the parameter type of the methods.
anonymous wrote :
| incallback is a HORRIBLE name for this. Please define something that is easier to understand. Thanks.
I agree. But I don't really care what it is called, I care what does.
Ales, maybe you can come up with a better name, e.g.
installCallback and uninstallCallback?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059098#4059098
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059098
17 years, 6 months
[Design the new POJO MicroContainer] - Re: New Deployer changes - overview
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote : How do you define precedence rules for deployer ordering? For example, let's take a hypothetical Seam deployer that needs to augment an EJB deployment based on additional metadata within the deployment unit. It needs to happen after EJB XML and Annotation processing, but before component processing.
|
| I liked the install/uninstall approach (see below if you dont' know what I'm talking about) because we could have added precedence metadata to the addDeployer method. Precendence metadata like, I have to come before the EJB component processing, but after the XML/annotation processing.
|
|
| | <install bean="MainDeployer" method="addDeployer">
| | <parameter><this/></parameter>
| | </install>
| | <uninstall bean="MainDeployer" method="removeDeployer">
| | <parameter><this/></parameter>
| | </uninstall>
| |
|
|
See the part where I describe attachment flows.
For your example (assuming JMX components) you would do something like:
| public MySeamDeployer extends AbstractSimpleRealDeployer<SeamMetaData.class>
| {
| public MySeamDeployer()
| {
| // We are after everything that creates and modifies SeamMetaData
| super(SeamMetaData.class);
|
| // We need the EJB deployment and Annotation metadata
| setInputs(EJB3Deployment.class, AnnotationCache.class);
| // We output a -service.xml description so we are before that deployer
| setOutputs(ServiceDeploymentMetaData.class);
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059097#4059097
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059097
17 years, 6 months
[Design the new POJO MicroContainer] - Re: MainDeployer changes
by adrian＠jboss.org
"bill.burke(a)jboss.com" wrote :
| | <bean name="StructuralDeployers" class="org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl">
| | <!-- Accept any implementor of structure deployer -->
| | <incallback method="addDeployer"/>
| | <uncallback method="removeDeployer"/>
| | </bean>
| |
|
|
| So the incallback means that any bean that implements the interfaces of VFSStructuralDeployersImpl will automatically incur an addDeployer(this) call on the StructuralDeployer's bean? Or the parameter type of the addDeployer method?
|
It is the parameter type of the methods.
anonymous wrote :
| incallback is a HORRIBLE name for this. Please define something that is easier to understand. Thanks.
I agree. But I don't really care what it is called, I care what does.
Ales, maybe you can come up with a better name, e.g.
installCallback and uninstallCallback?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059094#4059094
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059094
17 years, 6 months