Bug 734866

Summary: [jboss-as-5] deployment of ManagedComponent (EAR/WAR/ZIP/etc) fails with NPE if deploymentConfiguration is missing an expected property
Product: [Other] RHQ Project Reporter: Larry O'Leary <loleary>
Component: PluginsAssignee: Lukas Krejci <lkrejci>
Status: ASSIGNED --- QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: medium    
Version: 4.2CC: hrupp, lkrejci
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: All   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
JON 2.4.1
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On: 754419    
Bug Blocks: 625146    
Description Flags
Example CLI script demonstrating the problem none

Description Larry O'Leary 2011-08-31 13:02:13 EDT
Created attachment 520864 [details]
Example CLI script demonstrating the problem

Description of problem:
deploy method of ManagedComponentDeployer will throw NullPointerException if deployment configuration is missing expected parameters.

Version-Release number of selected component (if applicable):
RHQ 3.0.1
JBoss AS 5 Plug-in

How reproducible:

Steps to Reproduce:
1. Add one or more AS5 instances to a compatible group named MyEAPGroup
2. Create a WAR (or obtain a WAR) for deployment named SomeWAR.war
3. Run test.js CLI script using CLI tool
Actual results:
Deployment of WAR using CLI will fail and agent log will contain a NullPointerException and error similar to:
ERROR [ResourceContainer.invoker.nonDaemon-1] (rhq.plugins.jbossas5.deploy.ManagedComponentDeployer)- Error deploying application for request [CreateResourceReport: ResourceType=[ResourceType[id=0, category=Service, name=Web Application (WAR), plugin=JBossAS5]], ResourceKey=[null]].


	at org.rhq.plugins.jbossas5.deploy.ManagedComponentDeployer.deploy(ManagedComponentDeployer.java:95)

	at org.rhq.plugins.jbossas5.helper.CreateChildResourceFacetDelegate.createContentBasedResource(CreateChildResourceFacetDelegate.java:129)

	at org.rhq.plugins.jbossas5.helper.CreateChildResourceFacetDelegate.createResource(CreateChildResourceFacetDelegate.java:61)

	at org.rhq.plugins.jbossas5.ApplicationServerComponent.createResource(ApplicationServerComponent.java:310)

	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

	at java.lang.reflect.Method.invoke(Method.java:597)

	at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)

	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)

	at java.util.concurrent.FutureTask.run(FutureTask.java:138)

	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

	at java.lang.Thread.run(Thread.java:619)

Expected results:
WAR should have been deployed and no exception should have occurred

Additional info:
This issue is due to the deploy method attempting to obtain the Java type of properties provided in the deployment configuration. However, if a configuration property is not present in the deployment configuration, null is returned and we are attempting to invoke a method on the return. This occurs multiple times in the method:

            boolean deployExploded = deployTimeConfig.getSimple("deployExploded").getBooleanValue();
            boolean deployFarmed = deployTimeConfig.getSimple("deployFarmed").getBooleanValue();

It would be expected that a default should be used. The default sohuld most likely be "false". Otherwise, at minimum, if these are required properties and we do not want to default them, a meaningful exception should be thrown.
Comment 1 Lukas Krejci 2011-11-16 07:06:06 EST
This is a general problem that I can imagine being a common place in our codebase. The general rule we follow just about anywhere is that if a configuration property is defined as required, it is going to be present in the supplied configuration instance.

Or at least that's what the agent plugins assume.

This should therefore be fixed on the PluginContainer or even the server's remote API level where we should ensure that all publicly accessible methods do "sanitize" the configuration objects.
Comment 2 Lukas Krejci 2011-11-21 07:11:14 EST
Take a look at bug 754419 for more general comments on the problem.