Bug 1000637 - Tomcat discovery fails to find version
Tomcat discovery fails to find version
Status: NEW
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
  Show dependency treegraph
Reported: 2013-08-23 18:23 EDT by Elias Ross
Modified: 2013-08-28 20:54 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Elias Ross 2013-08-23 18:23:04 EDT
TomcatDiscoveryComponent class calls the version.sh script. In my case, we repackaged the server to not include version.sh so my server version is 'Unknown Version'.

The version can also be obtained through JMX and is more reliable this way.

The suggestion (request) is to use the JMX obtained version when possible.
Comment 1 Heiko W. Rupp 2013-08-28 15:56:39 EDT
We are facing here the challenge that discovery is one phase and in many cases, the credentials can only be provided when the server is already in inventory, which means, discovery had happened.
While it may be true that the version can change on subsequent discovery runs (I'd need to check that), at least for the start we can only return "unknown" here.

We are thinking for the future of introducing a 2-phase discovery, where phase 1 only does the discovery and reports to the discovery Q, where the user can then give credentials if needed. Then 2nd phase kicks in and does the real discovery with name finding etc.
Comment 2 Elias Ross 2013-08-28 20:54:44 EDT
In some cases you want to be able to access the database/JMX/whatever connection to find the name, version, etc., so having a facet that's part of the resource itself, not part of the discovery class, would be ideal. I suppose it could be called after a start(), or be added as a method part of the resource's context.

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