[JBoss JIRA] (ARTIF-16) Eclipse IDE: S-RAMP tooling
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-16?page=com.atlassian.jira.plugin.s... ]
Brett Meyer commented on ARTIF-16:
----------------------------------
Awesome, thanks guys -- will review ASAP!
> Eclipse IDE: S-RAMP tooling
> ---------------------------
>
> Key: ARTIF-16
> URL: https://issues.jboss.org/browse/ARTIF-16
> Project: Artificer
> Issue Type: Task
> Components: IDE Integration
> Affects Versions: 0.6.0.Final
> Reporter: Kurt Stam
> Assignee: Brett Meyer
> Attachments: UIMockup.gliffy, UImockup.gliffy
>
>
> Introducing IDE-based tooling, interacting with the S-RAMP repo, brings up several interesting use cases. For instance, allowing an app developer to search for a WSDL in S-RAMP, then pull it down into his/her project (all from within the IDE) would be powerful.
> One idea would be to look into writing this as a JBoss Forge plugin. Not only would we gain Eclipse support, but also any other Forge-supported environment. The unknown is how to integrate that plugin with an Eclipse view UI, as opposed to simply relying on the Forge shell.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARTIF-16) Eclipse IDE: S-RAMP tooling
by Stefan Bunciak (JIRA)
[ https://issues.jboss.org/browse/ARTIF-16?page=com.atlassian.jira.plugin.s... ]
Stefan Bunciak updated ARTIF-16:
--------------------------------
Git Pull Request: https://github.com/ArtificerRepo/artificer/pull/513
> Eclipse IDE: S-RAMP tooling
> ---------------------------
>
> Key: ARTIF-16
> URL: https://issues.jboss.org/browse/ARTIF-16
> Project: Artificer
> Issue Type: Task
> Components: IDE Integration
> Affects Versions: 0.6.0.Final
> Reporter: Kurt Stam
> Assignee: Brett Meyer
> Attachments: UIMockup.gliffy, UImockup.gliffy
>
>
> Introducing IDE-based tooling, interacting with the S-RAMP repo, brings up several interesting use cases. For instance, allowing an app developer to search for a WSDL in S-RAMP, then pull it down into his/her project (all from within the IDE) would be powerful.
> One idea would be to look into writing this as a JBoss Forge plugin. Not only would we gain Eclipse support, but also any other Forge-supported environment. The unknown is how to integrate that plugin with an Eclipse view UI, as opposed to simply relying on the Forge shell.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (RTGOV-641) Create quickstart that demostrates RTGOV-575
by ivan mckinley (JIRA)
ivan mckinley created RTGOV-641:
-----------------------------------
Summary: Create quickstart that demostrates RTGOV-575
Key: RTGOV-641
URL: https://issues.jboss.org/browse/RTGOV-641
Project: RTGov (Run Time Governance)
Issue Type: Feature Request
Components: Event Processor
Affects Versions: 2.2.0
Reporter: ivan mckinley
Assignee: ivan mckinley
Quick start demostarting the storing of custom business object into ES
- Purpose would be to take custom information in the event (defined by IP) and store in ES
- A simple event processor which utilises the ES repository
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARTIF-627) New query parser: Antlr + ModeShape JCR-JQOM
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-627?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-627:
------------------------------
Description:
SrampToJcrSql2QueryVisitor is extremely brittle and inflexible. See SRAMP-622 for an example. The following query is next to impossible:
/s-ramp/xsd/XsdDocument[relWithAttr[s-ramp:getRelationshipAttribute(., 'FooKey') = 'FooValue' and @FooProperty = 'FooValue']]
Note that the getRelationshipAttribute predicate function affects the relWithAttr *relationship* itself, while the @FooProperty check must go in the target artifact sub-query. Correctly handling this query will require a Builder pattern to be introduced.
Attempt to use ModeShape's JCR-JQOM:
https://docs.jboss.org/author/display/MODE40/JCR-JQOM
Also switch to using an Antlr grammar
ModeShape also has a builder class, but it's not public and may pose additional issues.
{quote}
(10:00:16 AM) rhauch: brmeyer: well, it's not public: https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/main... and https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/test...
(10:01:39 AM) rhauch: brmeyer: that builder is somewhat limited, and it is really meant for hard-coded code. For example, there are places where you'd have to build strings (e.g., using "AS" for aliases)
{quote}
was:
SrampToJcrSql2QueryVisitor is extremely brittle and inflexible. See SRAMP-622 for an example. The following query is next to impossible:
/s-ramp/xsd/XsdDocument[relWithAttr[s-ramp:getRelationshipAttribute(., 'FooKey') = 'FooValue' and @FooProperty = 'FooValue']]
Note that the getRelationshipAttribute predicate function affects the relWithAttr *relationship* itself, while the @FooProperty check must go in the target artifact sub-query. Correctly handling this query will require a Builder pattern to be introduced.
Attempt to use ModeShape's AST objects:
https://docs.jboss.org/author/display/MODE40/JCR-JQOM
ModeShape also has a builder class, but it's not public and may pose additional issues.
{quote}
(10:00:16 AM) rhauch: brmeyer: well, it's not public: https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/main... and https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/test...
(10:01:39 AM) rhauch: brmeyer: that builder is somewhat limited, and it is really meant for hard-coded code. For example, there are places where you'd have to build strings (e.g., using "AS" for aliases)
{quote}
> New query parser: Antlr + ModeShape JCR-JQOM
> --------------------------------------------
>
> Key: ARTIF-627
> URL: https://issues.jboss.org/browse/ARTIF-627
> Project: Artificer
> Issue Type: Enhancement
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> SrampToJcrSql2QueryVisitor is extremely brittle and inflexible. See SRAMP-622 for an example. The following query is next to impossible:
> /s-ramp/xsd/XsdDocument[relWithAttr[s-ramp:getRelationshipAttribute(., 'FooKey') = 'FooValue' and @FooProperty = 'FooValue']]
> Note that the getRelationshipAttribute predicate function affects the relWithAttr *relationship* itself, while the @FooProperty check must go in the target artifact sub-query. Correctly handling this query will require a Builder pattern to be introduced.
> Attempt to use ModeShape's JCR-JQOM:
> https://docs.jboss.org/author/display/MODE40/JCR-JQOM
> Also switch to using an Antlr grammar
> ModeShape also has a builder class, but it's not public and may pose additional issues.
> {quote}
> (10:00:16 AM) rhauch: brmeyer: well, it's not public: https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/main... and https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/test...
> (10:01:39 AM) rhauch: brmeyer: that builder is somewhat limited, and it is really meant for hard-coded code. For example, there are places where you'd have to build strings (e.g., using "AS" for aliases)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (RTGOV-640) Enable security context to be supplied when using RemoteInvoker
by Gary Brown (JIRA)
Gary Brown created RTGOV-640:
--------------------------------
Summary: Enable security context to be supplied when using RemoteInvoker
Key: RTGOV-640
URL: https://issues.jboss.org/browse/RTGOV-640
Project: RTGov (Run Time Governance)
Issue Type: Enhancement
Reporter: Gary Brown
Assignee: Gary Brown
RTGov uses the HTTP remote invoker to resubmit messages to a service. However if the service is protected by a client authentication policy, the retry mechanism does not work.
The remote invoker needs to be enhanced to enable optional authentication information to be provided.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (ARTIF-552) Support relationships with no target
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-552?page=com.atlassian.jira.plugin.... ]
Brett Meyer updated ARTIF-552:
------------------------------
Comment: was deleted
(was: SrampToJcrSql2QueryVisitor now assumes that all relationships have a target -- see the use of targetPredicateContext. Should definitely push back on this.)
> Support relationships with no target
> ------------------------------------
>
> Key: ARTIF-552
> URL: https://issues.jboss.org/browse/ARTIF-552
> Project: Artificer
> Issue Type: Feature Request
> 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.11#6341)
9 years, 11 months
[JBoss JIRA] (ARTIF-552) Support relationships with no target
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ARTIF-552?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on ARTIF-552:
-----------------------------------
SrampToJcrSql2QueryVisitor now assumes that all relationships have a target -- see the use of targetPredicateContext. Should definitely push back on this.
> Support relationships with no target
> ------------------------------------
>
> Key: ARTIF-552
> URL: https://issues.jboss.org/browse/ARTIF-552
> Project: Artificer
> Issue Type: Feature Request
> 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.11#6341)
9 years, 11 months