June 2013 - overlord-issues - Jboss List Archives

[JBoss JIRA] (RTGOV-207) Service overview gadget requires separate basic auth signin

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/RTGOV-207?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated RTGOV-207: -------------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/4, https://github.com/Governance/gadget-server/pull/8 > Service overview gadget requires separate basic auth signin > ----------------------------------------------------------- > > Key: RTGOV-207 > URL: https://issues.jboss.org/browse/RTGOV-207 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Eric Wittmann > Priority: Critical > Fix For: 1.0.0.Final > > > Security is now enabled on rtgov REST services, which has highlighted an issue with the service overview gadget. > After normal SSO signin, when the service overview gadget is added to the page, its first interaction with the server results in a login dialog being displayed. > On investigation, Eric found that the gadget's xml includes a direct request to the overlord-rtgov REST service to retrieve the SVG, which is bypassing the gadget IO layer. > Eric's suggestion is to create an SVG proxy servlet in gadget-web.war, which can deal with the authentication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-207) Service overview gadget requires separate basic auth signin

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/RTGOV-207?page=com.atlassian.jira.plugin.... ] Work on RTGOV-207 started by Eric Wittmann. > Service overview gadget requires separate basic auth signin > ----------------------------------------------------------- > > Key: RTGOV-207 > URL: https://issues.jboss.org/browse/RTGOV-207 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Eric Wittmann > Priority: Critical > Fix For: 1.0.0.Final > > > Security is now enabled on rtgov REST services, which has highlighted an issue with the service overview gadget. > After normal SSO signin, when the service overview gadget is added to the page, its first interaction with the server results in a login dialog being displayed. > On investigation, Eric found that the gadget's xml includes a direct request to the overlord-rtgov REST service to retrieve the SVG, which is bypassing the gadget IO layer. > Eric's suggestion is to create an SVG proxy servlet in gadget-web.war, which can deal with the authentication. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-215) Add services to MVEL predicate implementation

by Gary Brown (JIRA)

Gary Brown created RTGOV-215: -------------------------------- Summary: Add services to MVEL predicate implementation Key: RTGOV-215 URL: https://issues.jboss.org/browse/RTGOV-215 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Gary Brown Assignee: Gary Brown Fix For: 1.0.0.Final Enable services (in common component) to be configured with the MVEL predicate implementation, to enable derived collections to have predicates that can access services. This will need predicates to be initialized on registration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-154) Situation list filter

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-154?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-154: ---------------------------------- Refactored services (e.g. CacheManager) used by event processor to be available as a common component (RTGOV-214), to enable the active collection predicate to also be able to use it. Add a context parameter supplied to the predicates (used to filter derived active collections) to enable additional active collections and services to be used by the predicate. Current thoughts on solution are: a) have a second active collection (backed by an infinispan cache) to represent the list of components with known issues (i.e. not to be displayed) b) have a derived collection from the current Situations active collection, that will use the new active collection from (a) to filter out the situations that are related to known issues - as the result of the derived collection may change, based on the (a) active collection, we need a way to refresh the derived collection list. This could be achieved a couple of ways: (i) use active notifications from the (a) collection to update the list, but this would require some additional logic to be provided to understand the active notifications and apply the changes (ii) use active notifications to prompt a re-evaluation of the complete derived collection - may be ok in this case, although could generate alot of work if there any many changes to collection (a) (iii) enable the derived collection to be configured as not storing actual results (i.e. just use it as a proxy to generate notifications), and when the list is requested the parent collection is fully evaluated against the predicate - this should be ok if the complete list is only requested periodically. c) update gadget to use the derived Situations collection rather than the full list d) provide a REST service to enable components to be added and removed from the known issues list - possibly also a JMX action To support (b), we also need to pre-configure the derived collection as part of the top level collection's ActiveCollectionSource, and also mark the derived collection as permanent (i.e. it shouldn't be removed when no clients). Currently option (b) (iii) is most likely to be implemented. > Situation list filter > --------------------- > > Key: RTGOV-154 > URL: https://issues.jboss.org/browse/RTGOV-154 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Critical > Fix For: 1.0.0.Final > > > Situation events are created when an event processor detects a problem based on activity information generated by executing business transactions. > The situations are associated with a target component that indicates where the problem has arisen. In some situations, a particular component may be known to an administrator, and therefore they wish to temporarily ignore any problems being reported about it. > Although this filtering could be provided in the presentation layer, it may be better that it is centrally managed, to enable other applications that access the Situations list through the REST API to also be subject to the same filtering. > The issue is where to apply this filter, and where will it get the list of blacklisted entries from. In terms of the filter, should the overall list remain unchanged, and just have a derived list that applies the filter? > If the complete list is maintained, then the benefit is that when the component is removed from the blacklist, its associated Situations would then immediately re-appear within the displayed list. > The other point to consider is whether Situations associated blacklisted components should be persisted, or atleast marked to indicate that they were flagged as a known problem? > As this mechanism is primarily intended to de-clutter the UI, to avoid known problems overshadowing other Situations that may occur, it is likely that persisting Situation events would be unaffected by this mechanism. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-214) Refactor event processor service capability into common area for reuse by active collections

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-214?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-214. ------------------------------ Resolution: Done > Refactor event processor service capability into common area for reuse by active collections > -------------------------------------------------------------------------------------------- > > Key: RTGOV-214 > URL: https://issues.jboss.org/browse/RTGOV-214 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 1.0.0.Final > > > Move the service capability (CacheManager with inmemory and infinispan implementations) into the common area so they can be used by the active collection component. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-214) Refactor event processor service capability into common area for reuse by active collections

by Gary Brown (JIRA)

Gary Brown created RTGOV-214: -------------------------------- Summary: Refactor event processor service capability into common area for reuse by active collections Key: RTGOV-214 URL: https://issues.jboss.org/browse/RTGOV-214 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 1.0.0.Final Move the service capability (CacheManager with inmemory and infinispan implementations) into the common area so they can be used by the active collection component. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-213) Document email and jpa event processors

by Gary Brown (JIRA)

Gary Brown created RTGOV-213: -------------------------------- Summary: Document email and jpa event processors Key: RTGOV-213 URL: https://issues.jboss.org/browse/RTGOV-213 Project: RTGov (Run Time Governance) Issue Type: Task Components: Documentation Reporter: Gary Brown Assignee: Gary Brown Fix For: 1.0.0.Final -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-204) Identical UUIDs are possible for s-ramp artifacts

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-204: ----------------------------------- Summary: Identical UUIDs are possible for s-ramp artifacts Key: SRAMP-204 URL: https://issues.jboss.org/browse/SRAMP-204 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: Core, Persistence Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.3.1 - jBPM - bugfix 1 Currently if an artifact with the same UUID is added to the s-ramp repository, it will fail *only* if the artifact is also the same *type*. In other words, this is currently *not* a conflict: POST /s-ramp/core/Document/12345 POST /s-ramp/core/XmlDocument/12345 This is because we use the type and model in the JCR path. So the two artifacts above result in different, non-conflicting paths. GET'ing the artifacts will work just fine: GET /s-ramp/core/Document/12345 GET /s-ramp/core/XmlDocument/12345 Alas, query will result in two artifacts for this query: /s-ramp[@uuid = '12345'] I suggest we remove the model and type information from the JCR path. Perhaps put artifacts here: /s-ramp/artifacts/<btreepath> And put ontologies here: /s-ramp/ontologies/<uuid> And put stored queries here: /s-ramp/queries/<uuid> Etc... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-203) Ensure the not() function works with classifiers

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-203: ----------------------------------- Summary: Ensure the not() function works with classifiers Key: SRAMP-203 URL: https://issues.jboss.org/browse/SRAMP-203 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Eric Wittmann Priority: Minor Fix For: 0.3.1 - jBPM - bugfix 1 Not sure if this is working or not (I expect not): /s-ramp/core/Document[xp2:not(classifiedByAnyOf(., '#blue', '#red'))] It shouldn't be too hard to support - but not sure if it's working ATM. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-202) The not() function doesn't quite work with relationships

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-202: ----------------------------------- Summary: The not() function doesn't quite work with relationships Key: SRAMP-202 URL: https://issues.jboss.org/browse/SRAMP-202 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Eric Wittmann Priority: Minor Fix For: 0.3.1 - jBPM - bugfix 1 The not() function works well with properties, but not quite with relationships. An example of what doesn't work: /s-ramp/wsdl/Part[not(element)] That should return all Parts that do *not* have an element relationship. Since relationships are found by doing a JOIN, it's actually tricky to invert. Right now I think the query engine will produce something that would return all Parts that have some *other* relationship - but it won't return Parts without any relationships at all. I'm not sure how to do the latter other than by using an IN with a subquery (which is supported by ModeShape but is non-standard). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues June 2013