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(); criteria.addFilterResourceKey("/home/JBoss/jboss-eap-6.0/domain"); 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);} 500238 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: 1. 2. 3. Actual results: NPE is thrown and war file is not visible. Expected results: No exception is thrown and deployment is properly done. Additional info:
Please note that invoking the same operation from the UI, no error occurs.
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.
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...
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.
Fixed upstream.
cherry picked master commmit (123a951be3bd28161cdf7ccf3d45e59124d86489) : a6336be9a1c8859a5e511214cc4e01e417b62c4f
Moving to ON_QA as available for test with build : https://brewweb.devel.redhat.com//buildinfo?buildID=244662.
Verified on 3.1.2.ER2. Sucessfully deployed war using ResourceFactoryManager.createPackageBackedResource()