July 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/SRAMP-474?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved SRAMP-474. ------------------------------- Resolution: Done Pushed to 0.6 > CLI: Add a log-to-file option > ----------------------------- > > Key: SRAMP-474 > URL: https://issues.jboss.org/browse/SRAMP-474 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently CLI batch files must be created by hand. This isn't too much of a hardship, but it might be convenient for the interactive console to help out with this by allowing the user to log all commands executed to a file. This could be the basis for a CLI batch file that the user could include in some sort of integration scenario. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-395) S-RAMP allows artifacts to be created with invalid characters in the Artifact Type

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-395?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on SRAMP-395: ----------------------------------------------- Brett Meyer <brmeyer(a)redhat.com> changed the Status of [bug 1114732|https://bugzilla.redhat.com/show_bug.cgi?id=1114732] from ASSIGNED to MODIFIED > S-RAMP allows artifacts to be created with invalid characters in the Artifact Type > ---------------------------------------------------------------------------------- > > Key: SRAMP-395 > URL: https://issues.jboss.org/browse/SRAMP-395 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Alpha1, 0.5.0 > > > There are two ways (I believe) that users can mistakenly create artifacts with an invalid artifact type. The first is via the CLI: > {code} > s-ramp:upload /path/to/file.ext "Invalid Type" > s-ramp:create "Invalid Type" "Valid Artifact Name" "Description goes here." > {code} > The other is via the s-ramp UI's Import Artifact dialog. This dialog allows the user to type in any Artifact Type they want, which is an opportunity to mess it up. > We need to make sure we have appropriate validation of any custom Artifact Type provided by the user on the server (probably in the REST layer). > For bonus points we can add validation to the UI and CLI to prevent the request from even being made to the server unless it's valid. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-517) Make context optional for ActivityStore.getActivityTypes

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-517?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-517: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/142 > Make context optional for ActivityStore.getActivityTypes > -------------------------------------------------------- > > Key: RTGOV-517 > URL: https://issues.jboss.org/browse/RTGOV-517 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > The query method is now deprecated due to tight binding to store backend. Unfortunately it means now it is not possible to get a list of ActivityTypes in a given timeframe. The method getActivityTypes provide such a functionality but it requires a knowledge of context. > It should be useful to make the context optionally. At the same time when the context is optional it has to be mandatory to provide time window to prevent dumping the whole db/index. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-458) ActivityServer integration test using deprecated query method

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-458?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-458. ------------------------------ Resolution: Done > ActivityServer integration test using deprecated query method > ------------------------------------------------------------- > > Key: RTGOV-458 > URL: https://issues.jboss.org/browse/RTGOV-458 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The JBossASActivityServerServiceTest tested the activity server query method via the REST API. The issue was it relied on the JPA query language - hence this method was deprecated as it exposed the implementation. > Need to add further tests for the getActivityTypes and getActivityUnit method, to replace the query methods. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-517) Make context optional for ActivityStore.getActivityTypes

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-517?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-517. ------------------------------ Resolution: Done > Make context optional for ActivityStore.getActivityTypes > -------------------------------------------------------- > > Key: RTGOV-517 > URL: https://issues.jboss.org/browse/RTGOV-517 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > The query method is now deprecated due to tight binding to store backend. Unfortunately it means now it is not possible to get a list of ActivityTypes in a given timeframe. The method getActivityTypes provide such a functionality but it requires a knowledge of context. > It should be useful to make the context optionally. At the same time when the context is optional it has to be mandatory to provide time window to prevent dumping the whole db/index. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-458) ActivityServer integration test using deprecated query method

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-458?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-458: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/142 > ActivityServer integration test using deprecated query method > ------------------------------------------------------------- > > Key: RTGOV-458 > URL: https://issues.jboss.org/browse/RTGOV-458 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The JBossASActivityServerServiceTest tested the activity server query method via the REST API. The issue was it relied on the JPA query language - hence this method was deprecated as it exposed the implementation. > Need to add further tests for the getActivityTypes and getActivityUnit method, to replace the query methods. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-519?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-519: ----------------------------- Reporter: Gary Brown (was: Marc Savy) > Intercept activity from Vertx app interactions and report as activity events > ---------------------------------------------------------------------------- > > Key: RTGOV-519 > URL: https://issues.jboss.org/browse/RTGOV-519 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Vertx has a simple core that is not going to be extended to support any form of intercept mechanism. > The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov. > Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received). > The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx. > One approach to be considered: > The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work. > Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply. > Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-518) Deploy RTGov server as a Vertx module

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-518?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-518: ----------------------------- Reporter: Gary Brown (was: Marc Savy) > Deploy RTGov server as a Vertx module > ------------------------------------- > > Key: RTGOV-518 > URL: https://issues.jboss.org/browse/RTGOV-518 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Enable the RTGov server to be used as a Vertx module. > Although the complete server could be encapsulated in a module, it may be better to separate out the main server components (e.g. ActivityStore, Event Process Network Manager, Active Collection Manager) as separate modules with appropriate inter-communication. > Also some of the existing REST services should be made available as modules. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-518) Deploy RTGov server as a Vertx module

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-518?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-518: ----------------------------- Reporter: Marc Savy (was: Gary Brown) > Deploy RTGov server as a Vertx module > ------------------------------------- > > Key: RTGOV-518 > URL: https://issues.jboss.org/browse/RTGOV-518 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Marc Savy > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Enable the RTGov server to be used as a Vertx module. > Although the complete server could be encapsulated in a module, it may be better to separate out the main server components (e.g. ActivityStore, Event Process Network Manager, Active Collection Manager) as separate modules with appropriate inter-communication. > Also some of the existing REST services should be made available as modules. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-519?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-519: ----------------------------- Reporter: Marc Savy (was: Gary Brown) > Intercept activity from Vertx app interactions and report as activity events > ---------------------------------------------------------------------------- > > Key: RTGOV-519 > URL: https://issues.jboss.org/browse/RTGOV-519 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Marc Savy > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Vertx has a simple core that is not going to be extended to support any form of intercept mechanism. > The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov. > Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received). > The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx. > One approach to be considered: > The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work. > Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply. > Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues July 2014