Bug 790075 - Various AS-5 plugin types have unset read-only plugin config props
Various AS-5 plugin types have unset read-only plugin config props
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Plugins (Show other bugs)
4.2
All All
medium Severity high (vote)
: ---
: JON 3.0.1
Assigned To: Jay Shaughnessy
Mike Foley
:
Depends On: 758503
Blocks: jon30-sprint9 jon30-sprint10/rhq43-sprint10
  Show dependency treegraph
 
Reported: 2012-02-13 10:46 EST by Charles Crouch
Modified: 2015-02-01 18:27 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 758503
Environment:
Last Closed: 2013-09-03 11:06:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2012-02-13 10:46:48 EST
+++ This bug was initially created as a clone of Bug #758503 +++

Minimally the following types in the AS-5 plugin have
plugin config properties that are unset:

  EAR
  WAR
  Embedded WAR

This is bad because when you navigate to the plugin config
you are immediately in error, the config editor demanding
values for the fields which you can not edit.  Although not
probable, it would make it impossible to actually edit and
save the plugin config.

The unset properties should be set at discovery or removed from
the plugin descriptor. The latter is probably ok since they
seem unused.

--- Additional comment from jshaughn@redhat.com on 2012-01-16 13:04:28 EST ---


Each unset property pretty much needs to be reviewed on a case-by-case
basis.  The offending properties re-occur in several components and
are one of:

  contextPath

  From what I can see an attempt is made in discovery to set this WAR
  property.  The context path is determined by calling the profile service
  for "contextRoot".  But it either doesn't work at all, or, if the
  app is stopped, is doc'd to return null.

  I don't think the property value is actually used anywhere in the
  plugin code, so not getting set seems to not be a problem, other than
  in the way described in this BZ.  The property could probably be removed
  but instead I'll just remove the read-only setting.

  filename

  From what I can see this property is never set/discovered on any of the
  several types on which it is declared.  Moreover, it seems it is never
  referenced in the plugin code.  As such, I'm removing all occurrences 
  of the property.

--- Additional comment from jshaughn@redhat.com on 2012-01-16 13:31:37 EST ---


Actually, mean to say, set contextPath required="false" in addition to
readOnly="false".

--- Additional comment from jshaughn@redhat.com on 2012-01-16 14:15:04 EST ---

master commit 13546f899490b333b4527ce963d1b39b3a097153

required/read-only contextPath and filename props were not being set
[reliably] at discovery time.  Removed filename props, which did not seem
to be used by the plugin.  Set contextPath props to required="false".
The value does not seem to be used by the plugin but the property is
at least defined in the code.


Test Notes
Import an EAP5 with deployed EAR/War/Embedded WAR and anything else you
see fit.  In the GUI visit connection settings for one of each type
of resource in its hierarchy. Ensure the config editor does not complain
when rendering the config.
Comment 1 Jay Shaughnessy 2012-02-13 14:00:33 EST
Cherry-pick from master:

release/jon3.0.x commit: 238435dfb011275596e27aae58fc54cdd15d2282
Comment 2 Simeon Pinder 2012-02-17 00:35:44 EST
Moving to ON_QA for testing with JON 3.0.1.GA RC5 or better:
https://brewweb.devel.redhat.com//buildinfo?buildID=199114
Comment 3 Sunil Kondkar 2012-02-21 05:36:03 EST
Verified on JON 3.0.1.GA RC5 (Build Number: dd8a001:fbca611)

Imported an EAP5 and verified that navigating to connection settings for deployed EAR/War/Embedded WAR displays plugin config without any error.
Comment 4 Heiko W. Rupp 2013-09-03 11:06:43 EDT
Bulk closing of old issues in VERIFIED state.

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