[jboss-user] [Microcontainer] - MC picking up irrelevant deployers

jaikiran do-not-reply at jboss.com
Tue Jun 9 05:09:51 EDT 2009


Consider this deployer:


  | public class MyDeployer extends AbstractVFSRealDeployer
  | {
  |    
  |    public MyDeployer()
  |    {
  |       addInput("MyRequiredInput");
  |    }
  | 
  |    @Override
  |    public void deploy(VFSDeploymentUnit unit) throws DeploymentException
  |    {
  |       // do some expensive thing here...
  |    }
  | ...
  | 

This MyDeployer expects to be called when a deployment unit has an attachment named "MyRequiredInput". Let's assume that adding the attachment with this name to the unit is the responsibility of some ABCDeployer. Based on this, i would expect that if ABCDeployer does *not* add the "MyRequiredInput" attachment to the unit or the ABCDeployer is absent in the runtime environment, then the MyDeployer (which internally does expensive stuff) should *never* be called.


However, based on what i see currently this deployer gets called for most of the deployments even when the input attachment is not present in the unit. Effectively this deployer ends up doing unnecessary expensive stuff.

Looking at the code in the DeployersImpl (the isRelevant(...) method), i see that this deployer is considered relevant because of the following code:


  | protected boolean isRelevant(Deployer deployer, DeploymentUnit unit, boolean isTopLevel, boolean isComponent)
  |    {
  | ...// some code removed intentionally
  | 
  |       if (deployer.isAllInputs() == false)
  |       {
  |          // No attachment for the input type
  |          Class<?> input = deployer.getInput();
  |          if (input != null && unit.getAttachment(input) == null)
  |             return false;
  |       }
  |       return true;
  |    }
  | 

deployer.getInput() returns null and ultimately this method returns true - marking this deployer as relevant, even though it is not.



  |    public Class<?> getInput()
  |    {
  |       return input;
  |    }
  | 
When an addInput is invoked by a deployer i see this in AbstractDeployer:


  |    public void addInput(String input)
  |    {
  |       if (input == null)
  |          throw new IllegalArgumentException("Null input");
  |       
  |       if (inputs == null)
  |          inputs = new HashSet<String>();
  |       
  |       inputs.add(input);
  |    }
  | 

Nowhere in this call to addInput, does the "input" get set, unlike in setInput:


  |    public void setInput(Class<?> input)
  |    {
  |       addInput(input);
  |       this.input = input;
  |    }
  | 

Questions:

1) What's the difference between a addInput and setInput? I had assumed that addInput would add it to an existing set of inputs whereas setInput would overwrite the entire set with a new set. Am i wrong (based on the current behaviour, i think i am wrong)

2) Shouldn't the deployer be marked as irrelevant unless all its required inputs are available?

3) Note that this issue applies to almost all deployers which rely on addInput - which means that those deployers too might be doing unnecessary expensive stuff which can be avoided.

P.S: The MyDeployer in this example is actually a simplified version of EJB3Deployer. And one of the other deployers which seems to be running into this issue is MergedJBossMetaDataDeployer. 



View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236283#4236283

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236283



More information about the jboss-user mailing list