January 2015 - overlord-issues - Jboss List Archives

[JBoss JIRA] (ARTIF-610) Remove the old Deriver concepts

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-610?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-610: ------------------------------ Fix Version/s: 0.8.0.Final (was: 1.0) > Remove the old Deriver concepts > ------------------------------- > > Key: ARTIF-610 > URL: https://issues.jboss.org/browse/ARTIF-610 > Project: Artificer > Issue Type: Task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.8.0.Final > > > SRAMP-609 deprecated the old Deriver concepts and completely replaced it with ArtifactBuilder. Eventually remove the following: > org.overlord.sramp.common.derived.* > temp code in ArtifactBuilderFactory -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-612) Exceptions cleanup

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-612?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-612: ------------------------------ Fix Version/s: 0.8.0.Final (was: 1.0) > Exceptions cleanup > ------------------ > > Key: ARTIF-612 > URL: https://issues.jboss.org/browse/ARTIF-612 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.8.0.Final > > > 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.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-633) Work around RESTEasy issues affecting batch upload support in Wildfly

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-633?page=com.atlassian.jira.plugin.... ] Brett Meyer closed ARTIF-633. ----------------------------- Resolution: Out of Date For now, simply downgraded the RESTEasy dep versions > Work around RESTEasy issues affecting batch upload support in Wildfly > --------------------------------------------------------------------- > > Key: ARTIF-633 > URL: https://issues.jboss.org/browse/ARTIF-633 > Project: Artificer > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > > RESTEASY-1119 affects batch upload support in Wildfly. Part of the reason is that we're using deprecated code (ClientExecutor, etc.). As suggested, something like the following is a workaround: > {code} > ResteasyProviderFactory factory = ResteasyProviderFactory.getInstance(); > ResteasyProviderFactory.pushContext(javax.ws.rs.ext.Providers.class, factory); > ResteasyClientBuilder resteasyClientBuilder = new > ResteasyClientBuilder().providerFactory(factory); > ResteasyClient client = resteasyClientBuilder.build(); > {code} > But, that's only available in RE 3. We might have to pull the client-creation code into s-ramp-server/eap and s-ramp-server/wildfly (or upgrade wildfly in eap) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-625) Support Target#otherAttributes

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-625?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved ARTIF-625. ------------------------------- Fix Version/s: 0.8.0.Final Resolution: Done > Support Target#otherAttributes > ------------------------------ > > Key: ARTIF-625 > URL: https://issues.jboss.org/browse/ARTIF-625 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.8.0.Final > > > Target is currently mapped directly on the sramp:relationship node type, through the following: > {code} > - sramp:targetType (string) multiple > - sramp:relationshipTarget (weakreference) multiple < 'sramp:baseArtifactType' > {code} > Instead, that needs pulled out into a separate sramp:target type. Then, also include the following, necessary for Target#otherAttributes: > {code} > - * (string) > - * (string) multiple > {code} > Add support for storing Target#otherAttributes in the visitors. See Relationship#otherAttributes and SRAMP-622. > This needs to wait till 1.0 as it's a breaking change in the CND. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-625) Support Target#otherAttributes

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-625?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-625: ------------------------------ Fix Version/s: (was: 1.0) > Support Target#otherAttributes > ------------------------------ > > Key: ARTIF-625 > URL: https://issues.jboss.org/browse/ARTIF-625 > Project: Artificer > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Target is currently mapped directly on the sramp:relationship node type, through the following: > {code} > - sramp:targetType (string) multiple > - sramp:relationshipTarget (weakreference) multiple < 'sramp:baseArtifactType' > {code} > Instead, that needs pulled out into a separate sramp:target type. Then, also include the following, necessary for Target#otherAttributes: > {code} > - * (string) > - * (string) multiple > {code} > Add support for storing Target#otherAttributes in the visitors. See Relationship#otherAttributes and SRAMP-622. > This needs to wait till 1.0 as it's a breaking change in the CND. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ARTIF-627) Re-work the S-RAMP->JCR query visitor using ModeShape JCR-JQOM

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-627?page=com.atlassian.jira.plugin.... ] Brett Meyer resolved ARTIF-627. ------------------------------- Fix Version/s: 0.8.0.Final Resolution: Done > Re-work the S-RAMP->JCR query visitor using 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 > Fix For: 0.8.0.Final > > > 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 > 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

1
0
0 / 0

[JBoss JIRA] (ARTIF-627) Re-work the S-RAMP->JCR query visitor using 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 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 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} > Re-work the S-RAMP->JCR query visitor using 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 > 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

1
0
0 / 0

[JBoss JIRA] (ARTIF-627) Re-work the S-RAMP->JCR query visitor using ModeShape JCR-JQOM

by Brett Meyer (JIRA)

[ https://issues.jboss.org/browse/ARTIF-627?page=com.atlassian.jira.plugin.... ] Brett Meyer updated ARTIF-627: ------------------------------ Summary: Re-work the S-RAMP->JCR query visitor using ModeShape JCR-JQOM (was: New query parser: Antlr + ModeShape JCR-JQOM) > Re-work the S-RAMP->JCR query visitor using 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

1
0
0 / 0

[JBoss JIRA] (RTGOV-637) Kibana console not working on EAP with KeyCloak

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-637?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-637. ------------------------------ Resolution: Done > Kibana console not working on EAP with KeyCloak > ----------------------------------------------- > > Key: RTGOV-637 > URL: https://issues.jboss.org/browse/RTGOV-637 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-637) Kibana console not working on EAP with KeyCloak

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-637?page=com.atlassian.jira.plugin.... ] Gary Brown updated RTGOV-637: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/260 > Kibana console not working on EAP with KeyCloak > ----------------------------------------------- > > Key: RTGOV-637 > URL: https://issues.jboss.org/browse/RTGOV-637 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.3.11#6341)

9 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues January 2015