[Microcontainer] - Re: MC picking up irrelevant deployers
by jaikiran
"emuckenhuber" wrote : Yes, setInput() marks the Input as required and addInput() is just used for ordering.
|
So this raises the next question - what is setInputs() for? I believe for marking multiple inputs as "required". For example ABCDeployer requires InputA *and* InputB for it to be considered relevant:
public ABCDeployer()
| {
| setInputs("InputA","InputB");
|
| ...
| }
|
and internally AbstractDeployer.setInputs() does this:
| public void setInputs(Set<String> inputs)
| {
| this.inputs = inputs;
| }
So going by the code of isRelevant(...) that i posted earlier, this deployer will be considered relevant even when none of InputA or InputB are available.
As for the EJB3Deployer i tried as you suggested:
public Ejb3Deployer()
| {
| setInput(JBossMetaData.class); // additional constraint
| addInput(MergedJBossMetaDataDeployer.EJB_MERGED_ATTACHMENT_NAME);
|
and it works (i.e. the irrelevant deployments are no longer picked up). But i have to do bit more testing to ensure that this deployer is picked at the right time/order (i.e. after the MergedJBossMetadataDeployer is run for the deployment unit)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236301#4236301
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236301
17 years, 1 month
[JBoss Portal] - JSR 286 event model
by dorothy
Hi
I am trying to understand the event architecture in JSR286. Could you please provide some insight into how the pub/sub model works in case of JSR 286? My understanding is that public render parameters and eventing are the exactly the same architecture wise since they both follow a pub-sub model. Only difference being the complexity of payload and the callback mechanism that exists in the events. Having said that there must be an EventListener implemented by the portal vendor (not container) that will deliver or service the published events to their subscribers using the wiring admin tool. The EventListener will parse the portlet.xml file to get the information.
Please validate if my understanding is correct?
Regards
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4236284#4236284
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4236284
17 years, 1 month
[Microcontainer] - MC picking up irrelevant deployers
by jaikiran
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
17 years, 1 month