Bug 734866 - [jboss-as-5] deployment of ManagedComponent (EAR/WAR/ZIP/etc) fails with NPE if deploymentConfiguration is missing an expected property
Summary: [jboss-as-5] deployment of ManagedComponent (EAR/WAR/ZIP/etc) fails with NPE ...
Alias: None
Product: RHQ Project
Classification: Other
Component: Plugins
Version: 4.2
Hardware: All
OS: All
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact: Mike Foley
Depends On: 754419
Blocks: jon30-bugs
TreeView+ depends on / blocked
Reported: 2011-08-31 17:02 UTC by Larry O'Leary
Modified: 2020-04-27 01:19 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
JON 2.4.1
Last Closed:

Attachments (Terms of Use)
Example CLI script demonstrating the problem (2.48 KB, application/x-javascript)
2011-08-31 17:02 UTC, Larry O'Leary
no flags Details

Description Larry O'Leary 2011-08-31 17:02:13 UTC
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 12:06:06 UTC
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 12:11:14 UTC
Take a look at bug 754419 for more general comments on the problem.

Note You need to log in before you can comment on or make changes to this bug.