[JBoss JIRA] (SRAMP-552) Support relationships with no target
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/SRAMP-552?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on SRAMP-552:
-----------------------------------
Hold off on this one. Asking the TC about removing no-target relationships. Unless I'm missing something, the use cases are completely covered by simple classifiers.
> Support relationships with no target
> ------------------------------------
>
> Key: SRAMP-552
> URL: https://issues.jboss.org/browse/SRAMP-552
> Project: S-RAMP
> Issue Type: Sub-task
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> 2.1.2
> "It is possible for a relationship of a given Relationship Type not to have a target, which is termed a "relationship with no targets". In this case there is only one relationship instance with that Relationship Type for a given Source. Such relationships have a target cardinality of "0". If there is a relationship instance with a given Relationship Type that does have a target, then there CANNOT also be a relationship instance with that Relationship Type which has no target."
> Currently, this causes:
> {code}
> Caused by: javax.jcr.PathNotFoundException: No item exists at path sramp:relationshipType relative to /s-ramp/artifacts/4a/97/7b/bd-ab9b-4f00-b7b5-25f62f04eb45/sramp-relationships:null in workspace "default"
> at org.modeshape.jcr.AbstractJcrNode.getProperty(AbstractJcrNode.java:346)
> at org.modeshape.jcr.AbstractJcrNode.getProperty(AbstractJcrNode.java:108)
> at org.overlord.sramp.repository.jcr.mapper.ArtifactToJCRNodeVisitor.updateGenericRelationships(ArtifactToJCRNodeVisitor.java:267)
> at org.overlord.sramp.repository.jcr.mapper.ArtifactToJCRNodeVisitor.visitBase(ArtifactToJCRNodeVisitor.java:128)
> at org.overlord.sramp.common.visitors.HierarchicalArtifactVisitorAdapter.visit(HierarchicalArtifactVisitorAdapter.java:209)
> at org.overlord.sramp.repository.jcr.mapper.ArtifactToJCRNodeVisitor.visit(ArtifactToJCRNodeVisitor.java:310)
> at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.overlord.sramp.common.visitors.ArtifactVisitorHelper.visitArtifact(ArtifactVisitorHelper.java:41)
> at org.overlord.sramp.repository.jcr.JCRArtifactPersister.persistArtifactPhase1(JCRArtifactPersister.java:138)
> at org.overlord.sramp.repository.jcr.JCRPersistence.persistArtifact(JCRPersistence.java:177)
> ... 47 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (SRAMP-612) Exceptions cleanup
by Brett Meyer (JIRA)
Brett Meyer created SRAMP-612:
---------------------------------
Summary: Exceptions cleanup
Key: SRAMP-612
URL: https://issues.jboss.org/browse/SRAMP-612
Project: S-RAMP
Issue Type: Enhancement
Reporter: Brett Meyer
Assignee: Brett Meyer
Cleanup our Exception approach. They're kind of spread everywhere and inconsistent. Re-evaluate their homes, their inheritance, HTTP response mappings, etc.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (RTGOV-613) Enhance query support for rest api
by Anton Giertli (JIRA)
Anton Giertli created RTGOV-613:
-----------------------------------
Summary: Enhance query support for rest api
Key: RTGOV-613
URL: https://issues.jboss.org/browse/RTGOV-613
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Components: Activity Server
Affects Versions: 2.0.0.Final
Reporter: Anton Giertli
Assignee: Gary Brown
activity/query method is deprecated as the query string was specific to the storage being used - which has switched from jpa to elasticsearch.
While I understand this, still, support for some generic filters should be added no matter what
currently in activity/event only from/to/context/value attributes are supported.
It would be nice if event type(requestreceived, responsesent...) would be added, ideally, most of the attributes of the ActivityType object should be query-able too.
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (RTGOV-612) Assigning situation and changing states produces new call traces
by Andrej Vano (JIRA)
Andrej Vano created RTGOV-612:
---------------------------------
Summary: Assigning situation and changing states produces new call traces
Key: RTGOV-612
URL: https://issues.jboss.org/browse/RTGOV-612
Project: RTGov (Run Time Governance)
Issue Type: Bug
Components: User Interface
Affects Versions: 2.0.0.Final
Environment: eap 6.3 + sy 2 + rtgov 2.0 Final
Reporter: Andrej Vano
Assignee: Gary Brown
Priority: Minor
Fix For: 2.1.0.Final
Assigning situation and changing states produces new non-persistent call traces in the call trace window
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month
[JBoss JIRA] (RTGOV-611) Reimplement rtgov UI situation notifications
by Gary Brown (JIRA)
Gary Brown created RTGOV-611:
--------------------------------
Summary: Reimplement rtgov UI situation notifications
Key: RTGOV-611
URL: https://issues.jboss.org/browse/RTGOV-611
Project: RTGov (Run Time Governance)
Issue Type: Task
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 2.1.0.Final
Current mechanism uses Errai bus to send situation created notifications to the RTGov UI. This has been disabled when moving from Errai RPC services to JAX-RS (RTGOV-610).
So this task will be to implement this same mechanism using an alternative approach (possibly websockets).
--
This message was sent by Atlassian JIRA
(v6.3.8#6338)
10 years, 1 month