|
If you were logged in you would be able to see more operations.
|
|
|
RHQ Project
Created: 02/Apr/08 10:53 AM
Updated: 30/Sep/08 09:49 AM
|
|
| Component/s: |
None
|
| Affects Version/s: |
0.1
|
| Fix Version/s: |
1.1
|
|
|
Issue Links:
|
Relation
|
|
|
|
This issue Is Related To:
|
|
RHQ-221
Weird configuration caching on resource create
|
|
|
|
|
|
|
| Resolution Date: |
29/Sep/08 04:33 PM
|
| Date of First Response: |
29/Sep/08 04:33 PM
|
| Tester: |
Jeff Weiss
|
| VCS Revision: |
1,648
|
|
To replicate:
- Attempt to create a new JMS queue. Use the same JNDI name as an existing queue so the request fails.
- Navigate back to the resource's Inventory tab.
- Click the Resubmit link for that failed request.
The configuration will be shown, populated with the values used in the initial submit. The JNDI name, however, is uneditable.
[11:51] <joseph> perhaps, but i'm think what happens is that it's now looking it up with the config def for that resource type, which marks that field as readonly
|
|
Description
|
To replicate:
- Attempt to create a new JMS queue. Use the same JNDI name as an existing queue so the request fails.
- Navigate back to the resource's Inventory tab.
- Click the Resubmit link for that failed request.
The configuration will be shown, populated with the values used in the initial submit. The JNDI name, however, is uneditable.
[11:51] <joseph> perhaps, but i'm think what happens is that it's now looking it up with the config def for that resource type, which marks that field as readonly |
Show » |
|
Bug
Resubmitting a failed configuration-backed resource create results in locked attributes