Bug 856186 - NullPointerException when trying to deploy war on EAP 6 in domain mode using CLI and createPackageBackedResource method
NullPointerException when trying to deploy war on EAP 6 in domain mode using ...
Product: JBoss Operations Network
Classification: JBoss
Component: Plugin -- JBoss EAP 6, CLI (Show other bugs)
JON 3.1.0
Unspecified Unspecified
urgent Severity high
: ---
: JON 3.1.2
Assigned To: Jay Shaughnessy
Mike Foley
Depends On: 856819
  Show dependency treegraph
Reported: 2012-09-11 08:16 EDT by bkramer
Modified: 2013-09-11 07:04 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 856188
: 856188 856819 (view as bug list)
Last Closed: 2013-09-11 07:04:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 195573 None None None 2012-09-12 18:04:21 EDT

  None (edit)
Description bkramer 2012-09-11 08:16:40 EDT
Description of problem:
I tried to deploy war file on EAP 6 in domain mode using the following:

var deploymentResourceType = ResourceTypeManager.getResourceTypeByNameAndPlugin('DomainDeployment', 'JBossAS7');

var criteria = new ResourceCriteria();
var domain = ResourceManager.findResourcesByCriteria(criteria).iterator().next();

var domainProxy = ProxyFactory.getResource(domain.getId());

var deployConfig = new Configuration();
deployConfig.put(new PropertySimple("runtimeName", domainProxy.name));

var file = new java.io.File("/home/HelloWorld.war");
var inputStream = new java.io.FileInputStream(file);
var fileLength = file.length();
var fileBytes = java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, fileLength);
for (numRead=0, offset=0; ((numRead >= 0) && (offset < fileBytes.length)); offset += numRead ) {numRead = inputStream.read(fileBytes, offset, fileBytes.length - offset);}

var histo = ResourceFactoryManager.createPackageBackedResource(domain.getId(),deploymentResourceType.id, domainProxy.name, null, "kitchensink", "1.0", null, deployConfig, fileBytes, 500000)
There is no error reported back and I can see the following line in server.log file:

[Host Controller] 11:56:47,996 INFO  [org.jboss.as.repository] (HttpManagementService-threads - 2) JBAS014900: Content added at location /home/JBoss/jboss-eap-6.0/domain/data/content/7a/8d0d406226c5c578bca957af3669d397af7d00/content

but agent.log file contains the following exception:

2012-09-11 11:56:48,162 DEBUG [ResourceFactory.executor-1] (rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler)- Call to [org.rhq.modules.plugins.jbossas7.HostControllerComponent.createResource()] with args [[CreateResourceReport: ResourceType=[{JBossAS7}DomainDeployment], ResourceKey=[null]]] failed.
java.util.concurrent.ExecutionException: java.lang.NullPointerException
	at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:232)
	at java.util.concurrent.FutureTask.get(FutureTask.java:91)
	at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invokeInNewThreadWithLock(ResourceContainer.java:554)
	at org.rhq.core.pc.inventory.ResourceContainer$ResourceComponentInvocationHandler.invoke(ResourceContainer.java:542)
	at $Proxy72.createResource(Unknown Source)
	at org.rhq.core.pc.inventory.CreateResourceRunner.call(CreateResourceRunner.java:114)
	at org.rhq.core.pc.inventory.CreateResourceRunner.run(CreateResourceRunner.java:95)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	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)
Caused by: java.lang.NullPointerException
	at org.rhq.modules.plugins.jbossas7.BaseComponent.deployContent(BaseComponent.java:409)
	at org.rhq.modules.plugins.jbossas7.HostControllerComponent.createResource(HostControllerComponent.java:115)
	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:634)
	... 5 more

and "child history" will show unsuccessful attempt to create a child with the following:

2012-09-11 11:56:48,163 INFO  [ResourceFactory.executor-1] (rhq.core.pc.inventory.CreateResourceRunner)- Sending create response to server: CreateResourceResponse[RequestId=10121, Status=Failure]

and HelloWorld.war will not be visible.

Version-Release number of selected component (if applicable):
JON 3.1.0

How reproducible:
Every time.

Steps to Reproduce:
Actual results:
NPE is thrown and war file is not visible.

Expected results:
No exception is thrown and deployment is properly done.

Additional info:
Comment 1 Larry O'Leary 2012-09-12 18:19:26 EDT
Please note that invoking the same operation from the UI, no error occurs.
Comment 2 Jay Shaughnessy 2012-09-13 12:15:58 EDT
The problem fundamentally lies in the fact that the relevant rhq_package_version.file_name field is not set, and that downstream the AS7 plugin code assumes it is set, in BaseComponent.deployContent().

What needs to be determined is whether rhq_package_version.file_name should always be set or whether BaseComponent.deployContent() is making a false assumption.

The rhq_package_version.file_name field is optional in the db and in the entity but I'm not sure if that is correct.  Perhaps it should default to the package name.

Then again, perhaps the accessing code should handle an unset fileName and use the package name.

This works in the UI, and not in the CLI script above, because they take two different approaches to creating the PackageVersion that backs the resource.  The ResourceFactoryManager.createPackageBackedResource() method provides only file bytes as the backing content (it does provide a packageName, though).  The GUI first uploads the backing file, which allows initial PackageVersion creation while being able to provide file details, including the file name, since the file is actually provided by the upload.

I'll need to discuss this with Stefan and maybe othrs to determine how we should approach the issue.

As it stands now I don't see a workaround for the CLI, as there seems no way other than file upload to get the file_name set.
Comment 3 Jay Shaughnessy 2012-09-13 15:00:53 EDT
I think it is by design that PackageVersion.filename cam be null.  There really isn't any guarantee that the filename from which content is uploaded actually reflects anything valid about the content itself. It is the package name that must be unique, for example.  Content for a package could feasibly be entered via a text box, for example.  Or, the same filename could be used to upload content for multiple packages.

After talking with Stefan my current feeling is that we should not change the way that the PackageVersion code is working, and the SLSB layer should stay the same. 

The plugin code should remove its dependence on the filename value, in favor of the package name.  The question is whether there is some fundamental issue with that approach.

By changing the plugin code only we avoid any unintended impact on users of the content system.  And the patch is limited to a plugin upgrade.

Note that although code has changed in the relevant plugin method between 310GA and Master, the reliance on filename remains.

I will need to talk to Heiko about this and am requesting feedback from him...
Comment 5 Heiko W. Rupp 2012-09-14 05:18:35 EDT
I don't recall details, but Stefan is currently the ultimate source in content stuff :)
I think the requirement on filename came from the fact that in the UI you upload e.g. foo.war to and thus get foo.war passed as file name, which is then taken as name of the deployment without any need for further user interaction.

I do not pretend that this is correct.
Comment 6 Jay Shaughnessy 2012-09-14 15:03:54 EDT
Fixed upstream.
Comment 7 John Mazzitelli 2012-11-13 09:48:00 EST
cherry picked master commmit (123a951be3bd28161cdf7ccf3d45e59124d86489) :

Comment 8 Simeon Pinder 2012-11-21 16:56:09 EST
Moving to ON_QA as available for test with build : https://brewweb.devel.redhat.com//buildinfo?buildID=244662.
Comment 9 Filip Brychta 2012-11-27 07:31:02 EST
Verified on 3.1.2.ER2. Sucessfully deployed war using ResourceFactoryManager.createPackageBackedResource()

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