Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 909895

Summary: Datasource after creation is in a peculiar state
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Jakub Cechacek <jcechace>
Component: Web ConsoleAssignee: Stefano Maestri <smaestri>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1.0CC: brian.stansberry, jkudrnac, rhatlapa, rsvoboda
Target Milestone: ER3   
Target Release: EAP 6.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: the default for enabled attribute was set to true to have same default in xsd and DMR. Note it's a regression in latest EAP Consequence: it's hard to add a datasource and effective bound it (i requires a disable, add properties, and re-enable) Fix: enabled default for DMR is now false, while xsd still true Result: xml parser take care of explicit enable datasources, while ones created from console are disabled by default, permitting properties addition and then require an explicit enable.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-07-23 18:37:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jakub Cechacek 2013-02-11 12:21:28 UTC
Most likely regression of https://bugzilla.redhat.com/show_bug.cgi?id=900447

Comment 1 Radim Hatlapatka 2013-02-26 13:03:04 UTC
There is one more issue connected to this:

when you create a datasource, there is xa-datasource-properties undefined, but when you try to enable the datasource, you get error, that you need to have at least one xa-datasource-property defined.

I think that defining this property shouldn't be required (I can fill it with any kind of data without any meaning to make enabling work, but it makes no sense putting it here just because of making possible to enable the datasource)

Comment 2 Radim Hatlapatka 2013-02-26 13:18:53 UTC
Steps to reproduce the issue with not defined xa-datasource-properties (the same goes for non XA datasource), the steps are for CLI:

1) start EAP 6 (6.1.0.DR4.1) in standalone mode
2) connect to it via CLI
3) create datasource: /subsystem=datasources/xa-data-source=testXA:add(xa-datasource-class=org.h2.jdbcx.JdbcDataSource, jndi-name=java:jboss/datasources/testXA,driver-name=h2)
4) run /subsystem=datasources/xa-data-source=testXA:read-resource and see that enabled is set to true and xa-datasource-properties is undefined
5) disabling the datasource: /subsystem=datasources/xa-data-source=testXA:disable (this is successful)
6) enable datasource: /subsystem=datasources/xa-data-source=testXA:enable (causes this error:
{
    "outcome" => "failed",
    "failure-description" => "JBAS010469: At least one xa-datasource-property is required for an xa-datasource",
    "rolled-back" => true,
    "response-headers" => {"process-state" => "reload-required"}
}



Additional Info:

But if I add a property even though it is absolutely meaningless:
/subsystem=datasources/xa-data-source=testXA/xa-datasource-properties=someProp:add(value=someValue)
{
    "outcome" => "success",
    "response-headers" => {"process-state" => "reload-required"}
}

It suddenly works:
[standalone@localhost:9999 /] /subsystem=datasources/xa-data-source=testXA:enable
{
    "outcome" => "success",
    "response-headers" => {"process-state" => "reload-required"}
}
[standalone@localhost:9999 /]

Comment 3 Stefano Maestri 2013-02-26 13:47:20 UTC
(In reply to comment #1)

> I think that defining this property shouldn't be required (I can fill it
> with any kind of data without any meaning to make enabling work, but it
> makes no sense putting it here just because of making possible to enable the
> datasource)

You are wrong on this. For an xa-data-source at least one property is required because it's the only place where you can define connection parameters for xa-datasource. We can't check properties content because they are all database's vendor specific.

Comment 4 Radim Hatlapatka 2013-02-26 14:33:58 UTC
Ok, that makes sense. That clarifies my comment.

But the issue with enabled state set in default even though it cannot work (as the properties can be via CLI only added after the xa-datasource is created) remains

Comment 7 Jakub Cechacek 2013-03-21 15:17:40 UTC
Verified 6.1.0.ER3