Description of problem: It is not possible to retrieve the package bits of the deployments - i.e. you cannot download the deployed WAR file from our CLI using warResource.retrieveBackingContent() method. Version-Release number of selected component (if applicable): 4.4.0-SNAPSHOT How reproducible: always Steps to Reproduce: 1. Deploy a WAR file to AS7 2. Let RHQ discover it and its content (content tab lists the WAR file) 3. in CLI try: PackageFactory.getResource(<ID_OF_THE_WAR_RESOURCE>).retrieveBackingContent() Actual results: Error message along the lines of: sun.org.mozilla.javascript.internal.WrappedException: Wrapped javax.ejb.EJBException: [Warning] java.lang.RuntimeException: Unable to retrieve package bits for resource: 11094 and package: 10241 before timeout. Expected results: package bits successfully retrieved Additional info: The error message is highly misleading, because the timeout is not the reason for the failure - in the agent log, you can see an NPE being the culprit, caused by DeploymentComponent.retrievePackageBits() method return null.
Message when a file is deployed: [15:22:44] <pilhuhn> lkrejci 15:22:28,406 INFO [org.jboss.as.repository] (management-handler-thread - 5) JBAS014900: Content added at location /devel/jboss-eap-6.0/standalone/data/content/ee/38293159b29dfc69aa9f140e578a2e6b606eb0/content [15:23:40] <lkrejci> pilhuhn: yep, saw that.. the content file is actually the deployed file - i.e. the war or ear, so as long as we can get that path from the API, we're goog [15:23:42] <lkrejci> good [15:24:31] <pilhuhn> [standalone@localhost:9999 deployment=test-simple.war] :read-resource(include-runtime=true) [15:27:00] <pilhuhn> lkrejci otherwise we need a way to upload the bits within the create-child to the server [15:28:16] <lkrejci> pilhuhn: don't we assume an agent on every host? but it could be tricky to route the bits to the correct agent if the stuff gets deployed through the domain controller [15:31:47] <pilhuhn> Here we would only retrieve it once from the DC. No need to deploy a 20 MB ear and then pull it from 100 managed nodes into our database [15:32:47] <lkrejci> pilhuhn: that's gonna be tricky [15:43:59] <lkrejci> pilhuhn: the path can be deduced from the hash attribute of the API-deployed deployment [15:44:16] <lkrejci> or from the relative-to + path if hash is not present [15:44:48] <pilhuhn> how so? is content/ee/ fixed ? [15:44:58] <lkrejci> content is fixed [15:45:07] <lkrejci> ee is the first byte of the hash [15:45:11] <lkrejci> in hex [15:45:13] <pilhuhn> now i see it [15:45:47] <pilhuhn> right .. strip off 0x , paste everything together and we have the path [15:45:54] <lkrejci> exactly [15:46:00] <pilhuhn> omg - so easy, but I have never seen it
commit git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=d3927476f7f8f4f6172a1d92ee636ee853f931f7 Author: Lukas Krejci <lkrejci> Date: Fri Apr 27 22:16:26 2012 +0200 [BZ 816593][BZ 816587] - Deployments now correctly advertise their content packages (we only support archived deployments for now). Also added support for retrieving the package bits.
master http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=7b9476c940c210207378d01f96bbf2b27a858d5c Author: Lukas Krejci <lkrejci> Date: Tue May 15 18:05:36 2012 +0200 [BZ 816593][BZ 816587] - Adding unit tests for content retrieval and detection in standalone server.
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.