[JBoss JIRA] (ARTIF-752) Change of the artificer datasource configuration does not change datasource name
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/ARTIF-752?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on ARTIF-752:
-------------------------------------
If you want to change the database being used, you will need to swap out the datasource file that is installed by default with one that is configured for the database you wish to test. The default datasource file is configured for H2. If you want to test using mysql, for example, you will need to remove the `artificer-h2-ds.xml` file and replace it with something like artificer-mysql-ds.xml.
Additionally, you will need to manually change some properties in the `artificer.properties` file. Specifically you will need to change these values:
https://github.com/ArtificerRepo/artificer/blob/master/installer/src/main...
The installer likely will never support anything but the default H2 configuration. So alternative DBs will always need to be configured manually.
> Change of the artificer datasource configuration does not change datasource name
> --------------------------------------------------------------------------------
>
> Key: ARTIF-752
> URL: https://issues.jboss.org/browse/ARTIF-752
> Project: Artificer
> Issue Type: Bug
> Affects Versions: 1.0.0.Final
> Reporter: Viliam Kasala
> Assignee: Brett Meyer
>
> Currently in S-RAMP 6.2 DR1, the datasource name is hardcoded in following install scripts:
> - *./artificer-1.0.0.Final-redhat-3/.temp/artificer-installer/scripts/jboss-eap-6.xml*
> - *./artificer-1.0.0.Final-redhat-3/.temp/artificer-installer/scripts/jboss-wildfly-8.xml*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ARTIF-752) Change of the artificer datasource configuration does not change datasource name
by Viliam Kasala (JIRA)
[ https://issues.jboss.org/browse/ARTIF-752?page=com.atlassian.jira.plugin.... ]
Viliam Kasala commented on ARTIF-752:
-------------------------------------
How would be possible to change database, when new installer (overlay) of S-RAMP will ready? There is a requirement to test all the possible supported database instances.
> Change of the artificer datasource configuration does not change datasource name
> --------------------------------------------------------------------------------
>
> Key: ARTIF-752
> URL: https://issues.jboss.org/browse/ARTIF-752
> Project: Artificer
> Issue Type: Bug
> Affects Versions: 1.0.0.Final
> Reporter: Viliam Kasala
> Assignee: Brett Meyer
>
> Currently in S-RAMP 6.2 DR1, the datasource name is hardcoded in following install scripts:
> - *./artificer-1.0.0.Final-redhat-3/.temp/artificer-installer/scripts/jboss-eap-6.xml*
> - *./artificer-1.0.0.Final-redhat-3/.temp/artificer-installer/scripts/jboss-wildfly-8.xml*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (ARTIF-752) Change of the artificer datasource configuration does not change datasource name
by Viliam Kasala (JIRA)
Viliam Kasala created ARTIF-752:
-----------------------------------
Summary: Change of the artificer datasource configuration does not change datasource name
Key: ARTIF-752
URL: https://issues.jboss.org/browse/ARTIF-752
Project: Artificer
Issue Type: Bug
Affects Versions: 1.0.0.Final
Reporter: Viliam Kasala
Assignee: Brett Meyer
Currently in S-RAMP 6.2 DR1, the datasource name is hardcoded in following install scripts:
- *./artificer-1.0.0.Final-redhat-3/.temp/artificer-installer/scripts/jboss-eap-6.xml*
- *./artificer-1.0.0.Final-redhat-3/.temp/artificer-installer/scripts/jboss-wildfly-8.xml*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (RTGOV-663) Nested SwitchYard service calls are not logged correctly
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-663?page=com.atlassian.jira.plugin.... ]
Gary Brown resolved RTGOV-663.
------------------------------
Resolution: Done
Thanks for the contribution.
> Nested SwitchYard service calls are not logged correctly
> --------------------------------------------------------
>
> Key: RTGOV-663
> URL: https://issues.jboss.org/browse/RTGOV-663
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Components: Activity Collector
> Affects Versions: 2.1.0.Beta1
> Environment: Tested on:
> JBoss FSW 6.0.0 with RTGov UI Version 2 and
> RTGov Distribution with SwithchYard 2 & JBoss EAP 6.4
> Reporter: Sascha Dirbach
> Assignee: Gary Brown
> Attachments: sy-sca-rtgov.zip
>
>
> When I have a SwitchYard Project with a nested service call in the same Thread (e.g. same-machine SCA service) the outer invocation information is lost in the activity collector, as the ActivityUnit is kept in a ThreadLocal member variable of org.overlord.rtgov.activity.collector.AbstractActivityCollector. By calling the nested service, the previous (outer) ActivityUnit is lost.
> The source code comments & documentation state that nested calls of startScope & endScope are not supported, but I think SwitchYard services with nested service calls in the same Thread are not uncommon.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months
[JBoss JIRA] (RTGOV-663) Nested SwitchYard service calls are not logged correctly
by Sascha Dirbach (JIRA)
[ https://issues.jboss.org/browse/RTGOV-663?page=com.atlassian.jira.plugin.... ]
Sascha Dirbach updated RTGOV-663:
---------------------------------
Git Pull Request: https://github.com/Governance/rtgov/pull/309
> Nested SwitchYard service calls are not logged correctly
> --------------------------------------------------------
>
> Key: RTGOV-663
> URL: https://issues.jboss.org/browse/RTGOV-663
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Components: Activity Collector
> Affects Versions: 2.1.0.Beta1
> Environment: Tested on:
> JBoss FSW 6.0.0 with RTGov UI Version 2 and
> RTGov Distribution with SwithchYard 2 & JBoss EAP 6.4
> Reporter: Sascha Dirbach
> Assignee: Gary Brown
> Attachments: sy-sca-rtgov.zip
>
>
> When I have a SwitchYard Project with a nested service call in the same Thread (e.g. same-machine SCA service) the outer invocation information is lost in the activity collector, as the ActivityUnit is kept in a ThreadLocal member variable of org.overlord.rtgov.activity.collector.AbstractActivityCollector. By calling the nested service, the previous (outer) ActivityUnit is lost.
> The source code comments & documentation state that nested calls of startScope & endScope are not supported, but I think SwitchYard services with nested service calls in the same Thread are not uncommon.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
9 years, 5 months