[JBoss JIRA] (SRAMP-570) Improve s-ramp commands for Fuse/Fabric
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-570?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on SRAMP-570:
-----------------------------------
[~virchete], not sure that we need new Fabric commands at all. The overlay zip, provided by the fsw-fuse project, will continue to be the installation method. Your original ConfigureFabricProfilesCommand should be all that's needed. I'd vote to simply leave that as-is.
> Improve s-ramp commands for Fuse/Fabric
> ---------------------------------------
>
> Key: SRAMP-570
> URL: https://issues.jboss.org/browse/SRAMP-570
> Project: S-RAMP
> Issue Type: Enhancement
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> For Fuse:
> 1.) Make the password argument optional
> 2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided
> 3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available
> 4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values
> Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (RTGOV-564) Discriminate between Service Responsetime and component Responsetime in Kibana dashboard
by ivan mckinley (JIRA)
[ https://issues.jboss.org/browse/RTGOV-564?page=com.atlassian.jira.plugin.... ]
ivan mckinley commented on RTGOV-564:
-------------------------------------
Ok, Let me try this out.
if the gateway flag works perhaps its makes to mark this part of the default dashboard
> Discriminate between Service Responsetime and component Responsetime in Kibana dashboard
> ------------------------------------------------------------------------------------------
>
> Key: RTGOV-564
> URL: https://issues.jboss.org/browse/RTGOV-564
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Components: User Interface
> Affects Versions: 2.0.0.Final
> Reporter: ivan mckinley
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> Kibana ui
> The current kibana dashboard shows the response times for all component response times. It was observed that this is not optimal and clear to end-users. Endusers would initially be most interested in the response times on the promoted interface “soap binding” for example. Independent to the switchyard world, this would mean only displaying the response time for the entire serviceTX (and ignoring the components response times) or as its know the activityUnit
> Proposal,
> that the landing kibana dashboard shows the response times for the entire serviceTX in a dedicated table and the response times for the components in another.
> View the response of components could be another widget. i would not suggest another dashboard as this would mean users could not drill down into a service’s components
> Example, in the default dashboard, the table LIST OF SERVICES TABLE.
> This table displays the service tx response time but also the component response time. to the end user this not exactly clear
> {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService
> {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/FundsService
> {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/InventoryService
> {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/LogisticsService
> howto,
> Perhaps a flag will be required on the response time object to discriminate component response time and service tx response times
>
>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-570) Improve s-ramp commands for Fuse/Fabric
by David virgil naranjo (JIRA)
[ https://issues.jboss.org/browse/SRAMP-570?page=com.atlassian.jira.plugin.... ]
David virgil naranjo commented on SRAMP-570:
--------------------------------------------
I suggested the prefix fabric, because the normal command is overlord:s-ramp:configure.
> Improve s-ramp commands for Fuse/Fabric
> ---------------------------------------
>
> Key: SRAMP-570
> URL: https://issues.jboss.org/browse/SRAMP-570
> Project: S-RAMP
> Issue Type: Enhancement
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> For Fuse:
> 1.) Make the password argument optional
> 2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided
> 3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available
> 4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values
> Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-570) Improve s-ramp commands for Fuse/Fabric
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/SRAMP-570?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on SRAMP-570:
----------------------------------
Not sure I like adding 'fabric' to the command - it makes it very long. Are there are alternatives?
> Improve s-ramp commands for Fuse/Fabric
> ---------------------------------------
>
> Key: SRAMP-570
> URL: https://issues.jboss.org/browse/SRAMP-570
> Project: S-RAMP
> Issue Type: Enhancement
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> For Fuse:
> 1.) Make the password argument optional
> 2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided
> 3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available
> 4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values
> Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (RTGOV-560) Accessing the ActiveCollection REST service fails
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/RTGOV-560?page=com.atlassian.jira.plugin.... ]
Eric Wittmann commented on RTGOV-560:
-------------------------------------
My guess is that RESTEasy is failing to find its providers. The reason is likely because it locates them using a ServiceLoader approach. To work around this, we include the providers spec in the s-ramp server WAR:
https://github.com/EricWittmann/s-ramp/blob/master/s-ramp-server/fuse61/s...
This is just a copy/paste of the file included by RESTEasy, but when running in Fuse it of course can't find it.
> Accessing the ActiveCollection REST service fails
> -------------------------------------------------
>
> Key: RTGOV-560
> URL: https://issues.jboss.org/browse/RTGOV-560
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Gary Brown
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> Accessing the Active Collection REST service within Fuse causes the following error: Error 400 Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json
> Previously the QuerySpec was passed via the REST API as a string, and converted to a QuerySpec class within the REST service. However to make the REST API docs more descriptive, the method was updated to pass in a QuerySpec object - which works fine in EAP, but is failing in Fuse.
> The exception in the log is:
> {noformat}
> 21:52:58,747 | ERROR | qtp988607914-80 | SynchronousDispatcher | 309 - org.jboss.resteasy.resteasy-jaxrs - 2.3.7.Final | Failed executing POST /acm/query
> org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json
> at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:153)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:136)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:159)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0]
> at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031]
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031]
> at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:238)[300:org.overlord.overlord-commons-auth:2.0.8.Final]
> at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:220)[300:org.overlord.overlord-commons-auth:2.0.8.Final]
> at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-570) Improve s-ramp commands for Fuse/Fabric
by David virgil naranjo (JIRA)
[ https://issues.jboss.org/browse/SRAMP-570?page=com.atlassian.jira.plugin.... ]
David virgil naranjo updated SRAMP-570:
---------------------------------------
Description:
For Fuse:
1.) Make the password argument optional
2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided
3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available
4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values
Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure
was:
1.) Make the password argument optional
2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided
3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available
4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values
Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure
> Improve s-ramp commands for Fuse/Fabric
> ---------------------------------------
>
> Key: SRAMP-570
> URL: https://issues.jboss.org/browse/SRAMP-570
> Project: S-RAMP
> Issue Type: Enhancement
> Reporter: David virgil naranjo
> Assignee: David virgil naranjo
>
> For Fuse:
> 1.) Make the password argument optional
> 2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided
> 3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available
> 4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values
> Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-570) Improve s-ramp commands for Fuse/Fabric
by David virgil naranjo (JIRA)
David virgil naranjo created SRAMP-570:
------------------------------------------
Summary: Improve s-ramp commands for Fuse/Fabric
Key: SRAMP-570
URL: https://issues.jboss.org/browse/SRAMP-570
Project: S-RAMP
Issue Type: Enhancement
Reporter: David virgil naranjo
Assignee: David virgil naranjo
1.) Make the password argument optional
2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided
3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available
4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values
Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (SRAMP-569) Create maven plugin to merge .properties files
by David virgil naranjo (JIRA)
[ https://issues.jboss.org/browse/SRAMP-569?page=com.atlassian.jira.plugin.... ]
David virgil naranjo updated SRAMP-569:
---------------------------------------
Git Pull Request: https://github.com/Governance/s-ramp/pull/490, https://github.com/Governance/overlord-commons/pull/111
> Create maven plugin to merge .properties files
> ----------------------------------------------
>
> Key: SRAMP-569
> URL: https://issues.jboss.org/browse/SRAMP-569
> Project: S-RAMP
> Issue Type: Enhancement
> Reporter: Brett Meyer
> Assignee: David virgil naranjo
> Fix For: 0.6.0
>
>
> SRAMP-566 removes Fuse from s-ramp-installer. Instead, Fuse configuration is scripted through s-ramp-karaf-commands. That project currently controls its own versions of sramp.properties, sramp-ui.properties, etc. This was originally done since some of the values are static and *specific* to Fuse.
> However, several values remain unchanged when compared to the other platforms. It would be better if s-ramp-karaf-commands/pom.xml was able to pull ../s-ramp-installer/**/*.properties and merge it with .properties still controlled in s-ramp-karaf-commands. However, the s-ramp-karaf-commands version would contain *only* the Fuse specific values.
> Essentially, we're relying on s-ramp-installer's versions during buildtime, but overriding with any necessary Fuse values in s-ramp-karaf-commands. A custom Maven plugin to support this should be incredibly easy. Use Java's Properties, load the first version, then load and override with the 2nd. See http://beardedgeeks.googlecode.com/svn/docs/maven-merge-properties-plugin... for inspiration.
> Note that this is also needed for overlord-commons-karaf-commands (configure.dtd, overlord.properties, etc.)
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months
[JBoss JIRA] (RTGOV-532) Path for Elasticsearch node data is relative
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-532?page=com.atlassian.jira.plugin.... ]
Gary Brown resolved RTGOV-532.
------------------------------
Resolution: Done
> Path for Elasticsearch node data is relative
> --------------------------------------------
>
> Key: RTGOV-532
> URL: https://issues.jboss.org/browse/RTGOV-532
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Affects Versions: 2.0.0.Final
> Reporter: Jiri Pechanec
> Assignee: Gary Brown
> Fix For: 2.0.0.Final
>
>
> When RTGov is installed into EAP it sets path.data config property to "../elasticsearch". This is incorrect as the value
> - should not be relative as it depends on the directory from which the server is started
> - should use ${jboss.server.data.dir}/elasticsearch as it a place where all data files for EAP are stored
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 9 months