Bug 588507 - WAR file deployed against Tomcat shows an incorrect installation date.
Summary: WAR file deployed against Tomcat shows an incorrect installation date.
Alias: None
Product: RHQ Project
Classification: Other
Component: Plugins
Version: 4.4
Hardware: All
OS: Windows
Target Milestone: ---
: RHQ 4.5.0
Assignee: Jirka Kremser
QA Contact: Mike Foley
Depends On:
Blocks: ews1.0.2 jon24-ews jon24-content jon30-bugs
TreeView+ depends on / blocked
Reported: 2010-05-03 20:24 UTC by Corey Welton
Modified: 2013-08-31 10:14 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-08-31 10:14:59 UTC

Attachments (Terms of Use)
deploy content (168.26 KB, image/png)
2012-08-01 09:05 UTC, Armine Hovsepyan
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 564539 0 low CLOSED Tomcat plugin: WAR's Installation Date displays bogus value 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 589173 0 medium CLOSED for a newly created WAR resource, several of the package details (on the Content>Deployed subtab) are blank or incorrect 2021-02-22 00:41:40 UTC

Internal Links: 564539 589173

Description Corey Welton 2010-05-03 20:24:40 UTC
Description of problem:
Adter deploying a .war file, the installation date seems way off

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

How reproducible:

Steps to Reproduce:
1.  Inventory an EWS server and assure is has gone green.
2.  Navigate to your virtual host within the tree, and deploy something, i.e., counter.war
3.  Navigate to your war resource in the tree (i.e., counter/) and click the Content tab
4. View resulting table

Actual results:
I have an installation date of "14732 days, 20 hours ago"

Expected results:

* It probably shouldn't read "Installation Date" if it is a "how long ago" sort of measurement
* The installation time measure is way, way off.  Maybe this is package create date?

Additional info:

Comment 1 Simeon Pinder 2010-06-10 15:18:35 UTC
I've run into this problem and looked into it as well and it turns out that the Content -> Deployed Content list uses InstallledPackage.installationDate, while the actual Package Version(fixed in 589173) uses the PackageVersion.fileCreationTime.  

These appear to serve the same purpose but exist on two different objects and tables. Not completely sure why.

Proposed fix, change named query InstalledPackage.QUERY_FIND_PACKAGE_LIST_ITEM_COMPOSITE to use the PackageVersion details.

As a result of BZ 589173, almost all packages(excluding webapps deployed exploded before rhq) now have the fileCreated date set if it's obtainable.

Queries of rhq_package_version show almost full population of timestamp, excluding case above, while queries of rhq_installed_package are almost devoid of timestamp information.

This should fix many places in the code where timestamp simply displays epoch/computer zero time.

Comment 2 Paul Nittel 2011-01-13 22:17:30 UTC
This bug also manifests itself when EDS VDBs are deployed to a server. We're seeing 14987 days 22 hours, and the like.

Comment 3 Charles Crouch 2012-02-07 15:30:31 UTC
Speaking to Stefan, this is no related to his content fixes, so unassigning from that tracker BZ

Comment 4 Charles Crouch 2012-02-07 15:31:15 UTC
Reassigning to jon3.1.0. It would be good to fix, as per its priority

Comment 6 Jirka Kremser 2012-06-19 20:34:54 UTC

git log master
time:    Tue Jun 19 10:50:45 2012 +0200
commit:  f2ab06c2f62a77655d37ddcdce82eb16fe06fd91
author:  Jirka Kremser - jkremser@redhat.com
message: [BZ 588507 - WAR file deployed against Tomcat shows an incorrect installation date] Instalation date is now taken from InstalledPackage instance instead of PackageVersion instance

Comment 7 Armine Hovsepyan 2012-08-01 09:05:57 UTC
Created attachment 601691 [details]
deploy content


installation date under TomcatVirtualHost->localhost->deployedWar->Content is set correct.

Comment 8 Heiko W. Rupp 2013-08-31 10:14:59 UTC
Bulk close of old bugs in VERIFIED state.

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