June 2013 - overlord-issues - Jboss List Archives

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

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-204?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-204: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/269 > 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

12 years, 9 months

1
0
0 / 0

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

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-204?page=com.atlassian.jira.plugin.... ] Eric Wittmann resolved SRAMP-204. --------------------------------- Resolution: Done Implemented as proposed in the comments. > 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (GADGETS-62) Json jar versions in gadget-web

by Nick Cross (JIRA)

Nick Cross created GADGETS-62: --------------------------------- Summary: Json jar versions in gadget-web Key: GADGETS-62 URL: https://issues.jboss.org/browse/GADGETS-62 Project: Gadget Server and Gadgets Issue Type: Bug Components: Gadget Server Affects Versions: 1.0.0.M5 Reporter: Nick Cross Assignee: Gary Brown In https://issues.jboss.org/browse/GADGETS-55 json 20090211 jar was removed. However https://github.com/Governance/gadget-server/commit/d905a6b7edbc2c28cb4bbd... means it is used in gadgets-web and this causes Error injecting constructor, org.json.JSONException: A JSONObject text must begin with '{' at character 1 -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-156) Create Deriver for Switchyard content (switchyard.xml)

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-156?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on SRAMP-156: ------------------------------------- For the policy requirement, see: https://docs.jboss.org/author/display/SWITCHYARD/Policy > Create Deriver for Switchyard content (switchyard.xml) > ------------------------------------------------------ > > Key: SRAMP-156 > URL: https://issues.jboss.org/browse/SRAMP-156 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Blocker > Fix For: 0.3.0 - JBPM6 Integration > > > Based on examples to be provided by Keith Babo. -- 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

12 years, 9 months

1
0
0 / 0

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

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-204?page=com.atlassian.jira.plugin.... ] Work on SRAMP-204 started by Eric Wittmann. > 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

12 years, 9 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 resolved RTGOV-154. ------------------------------ Resolution: Done > 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-112) Set href on all relationships in Atom layer

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-112?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-112: -------------------------------- Assignee: Kurt Stam (was: Eric Wittmann) > Set href on all relationships in Atom layer > ------------------------------------------- > > Key: SRAMP-112 > URL: https://issues.jboss.org/browse/SRAMP-112 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Atom Binding > Reporter: Eric Wittmann > Assignee: Kurt Stam > Fix For: 0.3.0 - JBPM6 Integration > > > The persistence layer only sets the UUID of the relationship targets (for all relationships). The Atom layer needs to visit the artifact and add the full HREF on the targets. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-219) Cleanup of parent 'Situations' collection causing npe when propagating to derived 'FilteredSituations'

by Gary Brown (JIRA)

Gary Brown created RTGOV-219: -------------------------------- Summary: Cleanup of parent 'Situations' collection causing npe when propagating to derived 'FilteredSituations' Key: RTGOV-219 URL: https://issues.jboss.org/browse/RTGOV-219 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 1.0.0.Final NPE being caused by evaluation of mvel based predicate associated with derived collection, when an item in the parent map is being removed. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-219) Cleanup of parent 'Situations' collection causing npe when propagating to derived 'FilteredSituations'

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-219?page=com.atlassian.jira.plugin.... ] Gary Brown commented on RTGOV-219: ---------------------------------- The exception is: {noformat} 13:47:59,475 SEVERE [org.overlord.rtgov.active.collection.AbstractActiveCollectionManager] (Timer-1) Failed to perform cleanup on active collection 'Situations': java.lang.RuntimeException: cannot invoke method: containsKey at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.getValue(MethodAccessor.java:63) [mvel2-2.1.3.Final.jar:] at org.mvel2.optimizers.impl.refl.nodes.VariableAccessor.getValue(VariableAccessor.java:37) [mvel2-2.1.3.Final.jar:] at org.mvel2.optimizers.dynamic.DynamicGetAccessor.getValue(DynamicGetAccessor.java:73) [mvel2-2.1.3.Final.jar:] at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:108) [mvel2-2.1.3.Final.jar:] at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:38) [mvel2-2.1.3.Final.jar:] at org.mvel2.ast.Negation.getReducedValueAccelerated(Negation.java:48) [mvel2-2.1.3.Final.jar:] at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:38) [mvel2-2.1.3.Final.jar:] at org.mvel2.ast.ReturnNode.getReducedValueAccelerated(ReturnNode.java:53) [mvel2-2.1.3.Final.jar:] at org.mvel2.MVELRuntime.execute(MVELRuntime.java:85) [mvel2-2.1.3.Final.jar:] at org.mvel2.compiler.CompiledExpression.getDirectValue(CompiledExpression.java:123) [mvel2-2.1.3.Final.jar:] at org.mvel2.compiler.CompiledExpression.getValue(CompiledExpression.java:119) [mvel2-2.1.3.Final.jar:] at org.mvel2.MVEL.executeExpression(MVEL.java:922) [mvel2-2.1.3.Final.jar:] at org.overlord.rtgov.active.collection.predicate.MVEL.evaluate(MVEL.java:96) [active-collection-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.overlord.rtgov.active.collection.ActiveCollection$ActiveCollectionAdapter.removed(ActiveCollection.java:505) [active-collection-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.overlord.rtgov.active.collection.ActiveCollection.removed(ActiveCollection.java:387) [active-collection-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.overlord.rtgov.active.collection.ActiveList.remove(ActiveList.java:277) [active-collection-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.overlord.rtgov.active.collection.ActiveList.cleanup(ActiveList.java:394) [active-collection-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.overlord.rtgov.active.collection.AbstractActiveCollectionManager.cleanup(AbstractActiveCollectionManager.java:303) [active-collection-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at org.overlord.rtgov.active.collection.AbstractActiveCollectionManager$HouseKeeper.run(AbstractActiveCollectionManager.java:390) [active-collection-1.0.0-SNAPSHOT.jar:1.0.0-SNAPSHOT] at java.util.TimerThread.mainLoop(Timer.java:555) [rt.jar:1.7.0_07] at java.util.TimerThread.run(Timer.java:505) [rt.jar:1.7.0_07] Caused by: java.lang.RuntimeException: unable to invoke method: org.overlord.rtgov.analytics.situation.Situation.getSubject: target of method is null at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:66) [mvel2-2.1.3.Final.jar:] at org.mvel2.optimizers.dynamic.DynamicGetAccessor.getValue(DynamicGetAccessor.java:73) [mvel2-2.1.3.Final.jar:] at org.mvel2.ast.ASTNode.getReducedValueAccelerated(ASTNode.java:108) [mvel2-2.1.3.Final.jar:] at org.mvel2.compiler.ExecutableAccessor.getValue(ExecutableAccessor.java:42) [mvel2-2.1.3.Final.jar:] at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.executeAll(MethodAccessor.java:140) [mvel2-2.1.3.Final.jar:] at org.mvel2.optimizers.impl.refl.nodes.MethodAccessor.getValue(MethodAccessor.java:48) [mvel2-2.1.3.Final.jar:] ... 20 more Caused by: java.lang.NullPointerException at sun.reflect.GeneratedMethodAccessor221.invoke(Unknown Source) [:1.7.0_07] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_07] at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_07] at org.mvel2.optimizers.impl.refl.nodes.GetterAccessor.getValue(GetterAccessor.java:43) [mvel2-2.1.3.Final.jar:] ... 25 more {noformat} > Cleanup of parent 'Situations' collection causing npe when propagating to derived 'FilteredSituations' > ------------------------------------------------------------------------------------------------------ > > Key: RTGOV-219 > URL: https://issues.jboss.org/browse/RTGOV-219 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 1.0.0.Final > > > NPE being caused by evaluation of mvel based predicate associated with derived collection, when an item in the parent map is being removed. -- 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-112) Set href on all relationships in Atom layer

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-112?page=com.atlassian.jira.plugin.... ] Eric Wittmann commented on SRAMP-112: ------------------------------------- I started looking into this and realized that I actually can't create hrefs for generic relationships because I don't know the *type* of the target. When creating custom relationships, the user is not required to indicate the type of the target. Thus we are unable to store it in the persistence store. Thus when we get it back out again we don't have the type and can therefore not create an href to it. I'm not sure how to get around this. If the above problem were solved, the approach to implementing this might be something like: 1) Update the JCRNodeToArtifactVisitor to set a preliminary "href" on *every* instance of Target created. It can use information in the relationship JCR node to determine the type. It will set a value of something like: "/s-ramp/core/Document/UUID". It should have the model and type and UUID at this point. But it will *not* have the baseUrl at this point. 2) Update the ArtifactToFullAtomEntryVisitor to prepend the baseUrl (which it has) to every 'href' property of every Target in the artifact being visited. Note: alternatively a new visitor is needed that will *just* do the baseUrl prepending. This might be better but requires that the new visitor is run appropriately everywhere that the current ArtifactToFullAtomEntryVisitor is run. > Set href on all relationships in Atom layer > ------------------------------------------- > > Key: SRAMP-112 > URL: https://issues.jboss.org/browse/SRAMP-112 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Atom Binding > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.3.0 - JBPM6 Integration > > > The persistence layer only sets the UUID of the relationship targets (for all relationships). The Atom layer needs to visit the artifact and add the full HREF on the targets. -- 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

12 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues June 2013