From issues at jboss.org Wed Oct 1 01:19:02 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Wed, 1 Oct 2014 01:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-585) Fuse: Sending {"amount":400, "customer":"Fred"} results in Unrecognized field "amount" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007521#comment-13007521 ] Andrej Vano commented on RTGOV-585: ----------------------------------- Hello Gary, I was using http://docs.jboss.org/overlord/rtgov/2.0.0.Beta4/userguide/html_single/ and there isn't the right URL mentioned. Maybe we can change this to documentation bug? > Fuse: Sending {"amount":400,"customer":"Fred"} results in Unrecognized field "amount" > ------------------------------------------------------------------------------------- > > Key: RTGOV-585 > URL: https://issues.jboss.org/browse/RTGOV-585 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Based on the documentation I'm sending the request {"amount":400,"customer":"Fred"} but the response is: > Unrecognized field "amount" (Class org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order), not marked as ignorable > at [Source: java.io.ByteArrayInputStream at 822005f; line: 1, column: 14] (through reference chain: org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order["amount"]) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 03:48:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 1 Oct 2014 03:48:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-585) Fuse: Sending {"amount":400, "customer":"Fred"} results in Unrecognized field "amount" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reopened RTGOV-585: ------------------------------ Yes, its a documentation bug. > Fuse: Sending {"amount":400,"customer":"Fred"} results in Unrecognized field "amount" > ------------------------------------------------------------------------------------- > > Key: RTGOV-585 > URL: https://issues.jboss.org/browse/RTGOV-585 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Based on the documentation I'm sending the request {"amount":400,"customer":"Fred"} but the response is: > Unrecognized field "amount" (Class org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order), not marked as ignorable > at [Source: java.io.ByteArrayInputStream at 822005f; line: 1, column: 14] (through reference chain: org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order["amount"]) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 03:49:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 1 Oct 2014 03:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-585) Fuse: Sending {"amount":400, "customer":"Fred"} results in Unrecognized field "amount" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-585: ----------------------------- Component/s: Documentation > Fuse: Sending {"amount":400,"customer":"Fred"} results in Unrecognized field "amount" > ------------------------------------------------------------------------------------- > > Key: RTGOV-585 > URL: https://issues.jboss.org/browse/RTGOV-585 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: Documentation > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Based on the documentation I'm sending the request {"amount":400,"customer":"Fred"} but the response is: > Unrecognized field "amount" (Class org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order), not marked as ignorable > at [Source: java.io.ByteArrayInputStream at 822005f; line: 1, column: 14] (through reference chain: org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order["amount"]) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 04:26:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 1 Oct 2014 04:26:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-585) Use Karaf Commands to include UI Headers in the Fabric deployment In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-585: ------------------------------------------ Summary: Use Karaf Commands to include UI Headers in the Fabric deployment Key: SRAMP-585 URL: https://issues.jboss.org/browse/SRAMP-585 Project: S-RAMP Issue Type: Bug Reporter: David virgil naranjo Assignee: David virgil naranjo The UI Headers are not getting loaded in the Fuse Fabric installation. THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. The solution proposed is to use the karaf commands to include the header information in the overlord.properties. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 05:26:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 1 Oct 2014 05:26:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-583) Activities posted via REST not processed by EPN on Beta4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-583: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/215 > Activities posted via REST not processed by EPN on Beta4 > -------------------------------------------------------- > > Key: RTGOV-583 > URL: https://issues.jboss.org/browse/RTGOV-583 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Posting this set of activities (http://pastebin.test.redhat.com/236190) to /overlord-rtgov/activity/store will result in storing activities to elastic and not processing them by EPN on Beta4. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 05:26:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 1 Oct 2014 05:26:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-583) Activities posted via REST not processed by EPN on Beta4 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-583. ------------------------------ Resolution: Done Thanks for finding this Andrej. > Activities posted via REST not processed by EPN on Beta4 > -------------------------------------------------------- > > Key: RTGOV-583 > URL: https://issues.jboss.org/browse/RTGOV-583 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Posting this set of activities (http://pastebin.test.redhat.com/236190) to /overlord-rtgov/activity/store will result in storing activities to elastic and not processing them by EPN on Beta4. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 05:44:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 1 Oct 2014 05:44:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-585) Fuse: Sending {"amount":400, "customer":"Fred"} results in Unrecognized field "amount" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-585: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/216 > Fuse: Sending {"amount":400,"customer":"Fred"} results in Unrecognized field "amount" > ------------------------------------------------------------------------------------- > > Key: RTGOV-585 > URL: https://issues.jboss.org/browse/RTGOV-585 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: Documentation > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Based on the documentation I'm sending the request {"amount":400,"customer":"Fred"} but the response is: > Unrecognized field "amount" (Class org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order), not marked as ignorable > at [Source: java.io.ByteArrayInputStream at 822005f; line: 1, column: 14] (through reference chain: org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order["amount"]) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 05:44:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 1 Oct 2014 05:44:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-585) Fuse: Sending {"amount":400, "customer":"Fred"} results in Unrecognized field "amount" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-585. ------------------------------ Resolution: Done Thanks for finding this Andrej > Fuse: Sending {"amount":400,"customer":"Fred"} results in Unrecognized field "amount" > ------------------------------------------------------------------------------------- > > Key: RTGOV-585 > URL: https://issues.jboss.org/browse/RTGOV-585 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: Documentation > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Based on the documentation I'm sending the request {"amount":400,"customer":"Fred"} but the response is: > Unrecognized field "amount" (Class org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order), not marked as ignorable > at [Source: java.io.ByteArrayInputStream at 822005f; line: 1, column: 14] (through reference chain: org.overlord.rtgov.quickstarts.demos.ordermgmt.model.Order["amount"]) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 05:46:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 1 Oct 2014 05:46:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-585) Use Karaf Commands to include UI Headers in the Fabric deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-585: --------------------------------------- Description: The UI Headers are not getting loaded in the Fuse Fabric installation. https://github.com/Governance/s-ramp/pull/496 THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. The solution proposed is to use the karaf commands to include the header information in the overlord.properties. was: The UI Headers are not getting loaded in the Fuse Fabric installation. THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. The solution proposed is to use the karaf commands to include the header information in the overlord.properties. Git Pull Request: https://github.com/Governance/overlord-commons/pull/114, https://github.com/Governance/s-ramp/pull/496 (was: https://github.com/Governance/overlord-commons/pull/114) > Use Karaf Commands to include UI Headers in the Fabric deployment > ----------------------------------------------------------------- > > Key: SRAMP-585 > URL: https://issues.jboss.org/browse/SRAMP-585 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > The UI Headers are not getting loaded in the Fuse Fabric installation. > https://github.com/Governance/s-ramp/pull/496 > THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. > The solution proposed is to use the karaf commands to include the header information in the overlord.properties. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 05:46:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 1 Oct 2014 05:46:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-585) Use Karaf Commands to include UI Headers in the Fabric deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-585: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/114 > Use Karaf Commands to include UI Headers in the Fabric deployment > ----------------------------------------------------------------- > > Key: SRAMP-585 > URL: https://issues.jboss.org/browse/SRAMP-585 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > The UI Headers are not getting loaded in the Fuse Fabric installation. > THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. > The solution proposed is to use the karaf commands to include the header information in the overlord.properties. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 06:28:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 1 Oct 2014 06:28:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-587) Upgrade to SwitchYard 2.0.0.Alpha3 In-Reply-To: References: Message-ID: Gary Brown created RTGOV-587: -------------------------------- Summary: Upgrade to SwitchYard 2.0.0.Alpha3 Key: RTGOV-587 URL: https://issues.jboss.org/browse/RTGOV-587 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Quickstarts are no longer part of the build, so need to fix tests that use them. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 09:16:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 1 Oct 2014 09:16:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-585) Use Karaf Commands to include UI Headers in the Fabric deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-585. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > Use Karaf Commands to include UI Headers in the Fabric deployment > ----------------------------------------------------------------- > > Key: SRAMP-585 > URL: https://issues.jboss.org/browse/SRAMP-585 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > The UI Headers are not getting loaded in the Fuse Fabric installation. > https://github.com/Governance/s-ramp/pull/496 > THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. > The solution proposed is to use the karaf commands to include the header information in the overlord.properties. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 09:18:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 1 Oct 2014 09:18:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-585) Use Karaf Commands to include UI Headers in the Fabric deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-585: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > Use Karaf Commands to include UI Headers in the Fabric deployment > ----------------------------------------------------------------- > > Key: SRAMP-585 > URL: https://issues.jboss.org/browse/SRAMP-585 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > The UI Headers are not getting loaded in the Fuse Fabric installation. > https://github.com/Governance/s-ramp/pull/496 > THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. > The solution proposed is to use the karaf commands to include the header information in the overlord.properties. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 12:16:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 1 Oct 2014 12:16:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-152) Add support for 'configfile' in generated features.xml file In-Reply-To: References: Message-ID: Eric Wittmann created OVERLORD-152: -------------------------------------- Summary: Add support for 'configfile' in generated features.xml file Key: OVERLORD-152 URL: https://issues.jboss.org/browse/OVERLORD-152 Project: Overlord Issue Type: Feature Request Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: Overlord-Commons-2.0.11.Final Add the ability to include configfile elements in the generated features.xml file created by the overlord-commons maven plugin. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 12:18:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 1 Oct 2014 12:18:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-152) Add support for 'configfile' in generated features.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated OVERLORD-152: ----------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/commit/b87b90f058415188e66afe0163caf4bc7b62a2be > Add support for 'configfile' in generated features.xml file > ----------------------------------------------------------- > > Key: OVERLORD-152 > URL: https://issues.jboss.org/browse/OVERLORD-152 > Project: Overlord > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.11.Final > > > Add the ability to include configfile elements in the generated features.xml file created by the overlord-commons maven plugin. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 12:19:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 1 Oct 2014 12:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-152) Add support for 'configfile' in generated features.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved OVERLORD-152. ------------------------------------ Resolution: Done Example from apiman. See "configFile" in the markup below (from the apiman-distro-fuse6-dt module's pom.xml): {code} org.overlord overlord-commons-maven-plugin ${version.org.overlord.overlord-commons.overlord-commons-maven-plugin} generate-resources generate-features-xml ${project.build.directory}/features.xml true apiman-dependencies ${project.version} All API Management Dependencies war org.overlord.apiman:apiman-*:* apiman-dt ${project.version} API Management Runtime apiman-dependencies ${project.version} /etc/apiman-dt.cfg mvn:org.overlord.apiman/apiman-distro-fuse6-dt/${project.version}/cfg org.overlord.apiman:apiman-*:* {code} > Add support for 'configfile' in generated features.xml file > ----------------------------------------------------------- > > Key: OVERLORD-152 > URL: https://issues.jboss.org/browse/OVERLORD-152 > Project: Overlord > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.11.Final > > > Add the ability to include configfile elements in the generated features.xml file created by the overlord-commons maven plugin. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 12:19:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 1 Oct 2014 12:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-152) Add support for 'configfile' in generated features.xml file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed OVERLORD-152. ---------------------------------- > Add support for 'configfile' in generated features.xml file > ----------------------------------------------------------- > > Key: OVERLORD-152 > URL: https://issues.jboss.org/browse/OVERLORD-152 > Project: Overlord > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.11.Final > > > Add the ability to include configfile elements in the generated features.xml file created by the overlord-commons maven plugin. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 14:40:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 1 Oct 2014 14:40:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-586) Empty custom property query not quite working In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-586: ----------------------------------- Summary: Empty custom property query not quite working Key: SRAMP-586 URL: https://issues.jboss.org/browse/SRAMP-586 Project: S-RAMP Issue Type: Bug Components: UI Affects Versions: 0.5.0.Final Reporter: Eric Wittmann Assignee: Brett Meyer If a query is done like this: {code} /s-ramp/core/Document[ @foo ] {code} then the assumption is that it should return all artifacts with property "foo" defined, regardless of the *value* of "foo". However, if an artifact has the property defined but no value for the property, this query is failing to return it. To reproduce: 1) add an artifact to s-ramp 2) add a custom property "foo" to the artifact, with no value (this can easily be done via the UI) 3) execute the s-ramp query: /s-ramp[@foo] 4) observe that the artifact is not returned -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 14:41:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 1 Oct 2014 14:41:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-587) Not possible to add a property with no value via S-RAMP CLI In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-587: ----------------------------------- Summary: Not possible to add a property with no value via S-RAMP CLI Key: SRAMP-587 URL: https://issues.jboss.org/browse/SRAMP-587 Project: S-RAMP Issue Type: Bug Components: Shell Affects Versions: 0.5.0.Final Reporter: Eric Wittmann Assignee: Brett Meyer The s-ramp shell cannot create a custom property on an artifact without also setting a value (even if the value is empty string). I think this should be possible with the following syntax (currently invalid): {code} s-ramp:property set foo {code} If no value is supplied then the property should be simply added without one. If the property already exists, then the value should be removed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 14:49:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 1 Oct 2014 14:49:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-555) S-RAMP failing to install into Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-555. ----------------------------- Resolution: Out of Date > S-RAMP failing to install into Fuse > ----------------------------------- > > Key: SRAMP-555 > URL: https://issues.jboss.org/browse/SRAMP-555 > Project: S-RAMP > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: Brett Meyer > > Tried installing 0.6.0-SNAPSHOT into Fuse 6.1 and received this: > {code} > Error executing command: Could not start bundle mvn:org.sonatype.sisu/sisu-inject-bean/2.2.3 in feature(s) s-ramp-dependencies-0.6.0-SNAPSHOT: Unresolved constr > aint in bundle org.sonatype.inject [464]: Singleton conflict. > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 14:51:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 1 Oct 2014 14:51:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-533) Wire ZipToSrampArchiveProvider#getArchiveTypeHints up to the UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-533. ----------------------------- Resolution: Duplicate Issue > Wire ZipToSrampArchiveProvider#getArchiveTypeHints up to the UI > --------------------------------------------------------------- > > Key: SRAMP-533 > URL: https://issues.jboss.org/browse/SRAMP-533 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Uploading an artifact through the UI doesn't kick off ZipToSrampArchiveProvider#getArchiveTypeHints to go through all the integration projects and attempt to discover what to use. Make it so! -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 14:51:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 1 Oct 2014 14:51:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-533) Wire ZipToSrampArchiveProvider#getArchiveTypeHints up to the UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-533?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007826#comment-13007826 ] Brett Meyer commented on SRAMP-533: ----------------------------------- Superceded by SRAMP-580 > Wire ZipToSrampArchiveProvider#getArchiveTypeHints up to the UI > --------------------------------------------------------------- > > Key: SRAMP-533 > URL: https://issues.jboss.org/browse/SRAMP-533 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > Uploading an artifact through the UI doesn't kick off ZipToSrampArchiveProvider#getArchiveTypeHints to go through all the integration projects and attempt to discover what to use. Make it so! -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 15:00:04 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 1 Oct 2014 15:00:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-387) add javadoc jars to distro In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-387. ----------------------------- Fix Version/s: (was: 0.6.0) Resolution: Out of Date Out of date. Javadocs already unpacked under docs/api/javadoc > add javadoc jars to distro > --------------------------- > > Key: SRAMP-387 > URL: https://issues.jboss.org/browse/SRAMP-387 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Kurt Stam > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 15:02:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 1 Oct 2014 15:02:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-167) Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-167: --------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) > ------------------------------------------------------------------------------------- > > Key: SRAMP-167 > URL: https://issues.jboss.org/browse/SRAMP-167 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > We need to make sure that we can support the logical (non-document) artifact types. The mechanism for creating them is different (there's no POST of a document). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 1 15:19:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 1 Oct 2014 15:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-167) Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-167 started by Brett Meyer. ----------------------------------------- > Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) > ------------------------------------------------------------------------------------- > > Key: SRAMP-167 > URL: https://issues.jboss.org/browse/SRAMP-167 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > We need to make sure that we can support the logical (non-document) artifact types. The mechanism for creating them is different (there's no POST of a document). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 05:01:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 2 Oct 2014 05:01:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-578) Fuse Fabric commands refactoring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-578: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/495, https://github.com/Governance/s-ramp/pull/497 (was: https://github.com/Governance/s-ramp/pull/495) > Fuse Fabric commands refactoring > -------------------------------- > > Key: SRAMP-578 > URL: https://issues.jboss.org/browse/SRAMP-578 > Project: S-RAMP > Issue Type: Enhancement > Reporter: David virgil naranjo > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Modify the karaf fabric command name. > Allow the deployment of s-ramp and dtgov together in the same container. > There was a problem in the profile folder. As the class was extending the AbstractConfigureFabric command, the getProfileFolder method should not overwrite the parent. There is a problem with the folder where the overlord.properties and the overlord-saml.keystore file is saved. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 06:06:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 06:06:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-567) [resubmit] missing security context propagation with RemoteMessage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-567: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > [resubmit] missing security context propagation with RemoteMessage > ------------------------------------------------------------------ > > Key: RTGOV-567 > URL: https://issues.jboss.org/browse/RTGOV-567 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Michael Clay > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > currently there is no way to retry/resubmit switchyard services with a clientAuthentication policy because the context is not propagated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 06:14:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 06:14:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-587) Upgrade to SwitchYard 2.0.0.Alpha3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-587: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/217 > Upgrade to SwitchYard 2.0.0.Alpha3 > ---------------------------------- > > Key: RTGOV-587 > URL: https://issues.jboss.org/browse/RTGOV-587 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Quickstarts are no longer part of the build, so need to fix tests that use them. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 06:14:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 06:14:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-587) Upgrade to SwitchYard 2.0.0.Alpha3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-587. ------------------------------ Resolution: Done > Upgrade to SwitchYard 2.0.0.Alpha3 > ---------------------------------- > > Key: RTGOV-587 > URL: https://issues.jboss.org/browse/RTGOV-587 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Quickstarts are no longer part of the build, so need to fix tests that use them. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 09:46:03 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 2 Oct 2014 09:46:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-588) Fuse Fabric Karaf Command Encrypt Aes Password In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-588: ------------------------------------------ Summary: Fuse Fabric Karaf Command Encrypt Aes Password Key: SRAMP-588 URL: https://issues.jboss.org/browse/SRAMP-588 Project: S-RAMP Issue Type: Bug Reporter: David virgil naranjo Assignee: David virgil naranjo The jmspassword is not getting encrypted with the AesEncrypter class for the SrampConfigure karaf command for fuse fabric. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 09:54:03 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 2 Oct 2014 09:54:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-588) Fuse Fabric Karaf Command Encrypt Aes Password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-588: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/115 > Fuse Fabric Karaf Command Encrypt Aes Password > ---------------------------------------------- > > Key: SRAMP-588 > URL: https://issues.jboss.org/browse/SRAMP-588 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > The jmspassword is not getting encrypted with the AesEncrypter class for the SrampConfigure karaf command for fuse fabric. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 09:56:03 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 2 Oct 2014 09:56:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-588) Fuse Fabric Karaf Command Encrypt Aes Password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-588: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/115, https://github.com/Governance/s-ramp/pull/498 (was: https://github.com/Governance/overlord-commons/pull/115) > Fuse Fabric Karaf Command Encrypt Aes Password > ---------------------------------------------- > > Key: SRAMP-588 > URL: https://issues.jboss.org/browse/SRAMP-588 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > The jmspassword is not getting encrypted with the AesEncrypter class for the SrampConfigure karaf command for fuse fabric. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 09:57:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 09:57:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-554) Fuse MBeans already installed exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-554: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/218 > Fuse MBeans already installed exception > --------------------------------------- > > Key: RTGOV-554 > URL: https://issues.jboss.org/browse/RTGOV-554 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When rtgov installed in Fuse, followed by switchyard, the refresh of packages has the side effect of uninstalling rtgov and re-installing the bundles. > However when re-installed, the MBean registrations are failing saying already installed. Need to find out why they are not being unregistered. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 09:58:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 09:58:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-588) Investigate multiple init from overlord-commons ServiceRegistry In-Reply-To: References: Message-ID: Gary Brown created RTGOV-588: -------------------------------- Summary: Investigate multiple init from overlord-commons ServiceRegistry Key: RTGOV-588 URL: https://issues.jboss.org/browse/RTGOV-588 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Related to RTGOV-554 - overlord-commons ServiceRegistry calling init multiple times. Will wait for update to commons 2.0.11 before investigating further. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 09:59:05 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 09:59:05 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-588) Investigate multiple init from overlord-commons ServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-588: ----------------------------- Fix Version/s: 2.0.0.Final > Investigate multiple init from overlord-commons ServiceRegistry > --------------------------------------------------------------- > > Key: RTGOV-588 > URL: https://issues.jboss.org/browse/RTGOV-588 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Related to RTGOV-554 - overlord-commons ServiceRegistry calling init multiple times. > Will wait for update to commons 2.0.11 before investigating further. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 10:00:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 10:00:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-554) Fuse MBeans already installed exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-554. ------------------------------ Resolution: Done > Fuse MBeans already installed exception > --------------------------------------- > > Key: RTGOV-554 > URL: https://issues.jboss.org/browse/RTGOV-554 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When rtgov installed in Fuse, followed by switchyard, the refresh of packages has the side effect of uninstalling rtgov and re-installing the bundles. > However when re-installed, the MBean registrations are failing saying already installed. Need to find out why they are not being unregistered. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 10:28:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 10:28:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-588) Fuse Fabric Karaf Command Encrypt Aes Password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-588. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > Fuse Fabric Karaf Command Encrypt Aes Password > ---------------------------------------------- > > Key: SRAMP-588 > URL: https://issues.jboss.org/browse/SRAMP-588 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > The jmspassword is not getting encrypted with the AesEncrypter class for the SrampConfigure karaf command for fuse fabric. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 10:58:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 10:58:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-16: -------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > Issue Type: Task > Components: IDE Integration > Affects Versions: 0.6.0 > Reporter: Kurt Stam > Assignee: Brett Meyer > > 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.1#6329) From issues at jboss.org Thu Oct 2 10:58:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 10:58:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-16: ----------------------------- Fix Version/s: (was: 0.6.0) > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > Issue Type: Task > Components: IDE Integration > Affects Versions: 0.6.0 > Reporter: Kurt Stam > Assignee: Brett Meyer > > 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.1#6329) From issues at jboss.org Thu Oct 2 11:07:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 11:07:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-535: ------------------------------ Priority: Critical (was: Major) > Reset UUID of artifact when it is deleted > ----------------------------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 11:47:04 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 11:47:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-535 started by Brett Meyer. ----------------------------------------- > Reset UUID of artifact when it is deleted > ----------------------------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 12:35:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 12:35:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-515) Document activity collection from OSGi service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-515: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/219 > Document activity collection from OSGi service > ---------------------------------------------- > > Key: RTGOV-515 > URL: https://issues.jboss.org/browse/RTGOV-515 > Project: RTGov (Run Time Governance) > Issue Type: Task > Components: Documentation > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Describe how to integrate the activity collector into an OSGi application, based on the order management example. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 12:35:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 2 Oct 2014 12:35:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-515) Document activity collection from OSGi service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-515. ------------------------------ Resolution: Done > Document activity collection from OSGi service > ---------------------------------------------- > > Key: RTGOV-515 > URL: https://issues.jboss.org/browse/RTGOV-515 > Project: RTGov (Run Time Governance) > Issue Type: Task > Components: Documentation > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Describe how to integrate the activity collector into an OSGi application, based on the order management example. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 13:00:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 13:00:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008226#comment-13008226 ] Brett Meyer commented on SRAMP-535: ----------------------------------- Impl note: The sramp:uuid property stays the same on the Node. I simply changed the trash path to s-ramp-trash/uuid/timestamp. Later, when auditing supports deleted artifacts, we can simply look up the uuid path and grab its children, rather than having to deal with convoluted logic. > Reset UUID of artifact when it is deleted > ----------------------------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 13:23:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 13:23:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-535) Correct JCR trash pat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-535: ------------------------------ Summary: Correct JCR trash pat (was: Reset UUID of artifact when it is deleted) > Correct JCR trash pat > --------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 13:23:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 13:23:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-535) Correct JCR trash path In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-535: ------------------------------ Summary: Correct JCR trash path (was: Correct JCR trash pat) > Correct JCR trash path > ---------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 13:24:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 2 Oct 2014 13:24:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-535) Correct JCR trash path In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-535. ------------------------------- Resolution: Done > Correct JCR trash path > ---------------------- > > Key: SRAMP-535 > URL: https://issues.jboss.org/browse/SRAMP-535 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.5.0.Beta3 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.6.0 > > > Currently when an artifact is deleted we do not delete the JCR node. Instead we move it to another location in the JCR tree. This allows us to potentially add a new node with the same UUID (e.g. a user-specified one). > However, the deleted artifact is still sitting over in the trash JCR folder with that original user-defined UUID. So now if you try to delete the new artifact you'll get this: > {code} > A node definition that allows same name siblings could not be found for the node "/s-ramp-trash/artifacts/03/3a/75/4766e0b8f42a6810ecd6dd73c441a3ed7e[2]" in workspace "default" > {code} > Possible solution is to generate a new UUID for the trashed artifact when it gets moved? Or else allow same-name-siblings in the JCR tree only for s-ramp/trash (not sure this is possible). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 14:48:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 2 Oct 2014 14:48:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-589) SSO Logout failing with an exception In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-589: ----------------------------------- Summary: SSO Logout failing with an exception Key: SRAMP-589 URL: https://issues.jboss.org/browse/SRAMP-589 Project: S-RAMP Issue Type: Bug Reporter: Eric Wittmann Assignee: Eric Wittmann {code} 14:45:52,872 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-/127.0.0.1:8080-56) JBWEB000236: Servlet.ser vice() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server ExceptionServer Exception at org.overlord.commons.auth.filters.SamlSPFilter.doFilter(SamlSPFilter.java:379) [overlord-commons-auth-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redh at-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.11-SNAPSHOT .jar:2.0.11-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redh at-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.1 1-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redh at-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redh at-19] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7. 4.0.Final-redhat-19] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redha t-4] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 14:49:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 2 Oct 2014 14:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-589) SSO Logout failing with an exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-589: -------------------------------- Description: {code} 14:45:52,872 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-/127.0.0.1:8080-56) JBWEB000236: Servlet.ser vice() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server ExceptionServer Exception at org.overlord.commons.auth.filters.SamlSPFilter.doFilter(SamlSPFilter.java:379) [overlord-commons-auth-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] {code} was: {code} 14:45:52,872 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-/127.0.0.1:8080-56) JBWEB000236: Servlet.ser vice() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server ExceptionServer Exception at org.overlord.commons.auth.filters.SamlSPFilter.doFilter(SamlSPFilter.java:379) [overlord-commons-auth-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redh at-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.11-SNAPSHOT .jar:2.0.11-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redh at-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.1 1-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redh at-4] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redh at-19] at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7. 4.0.Final-redhat-19] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redha t-4] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] {code} > SSO Logout failing with an exception > ------------------------------------ > > Key: SRAMP-589 > URL: https://issues.jboss.org/browse/SRAMP-589 > Project: S-RAMP > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: Eric Wittmann > > {code} > 14:45:52,872 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-/127.0.0.1:8080-56) JBWEB000236: Servlet.ser > vice() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server ExceptionServer Exception > at org.overlord.commons.auth.filters.SamlSPFilter.doFilter(SamlSPFilter.java:379) [overlord-commons-auth-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 14:54:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 2 Oct 2014 14:54:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-139) Logout not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008256#comment-13008256 ] Eric Wittmann commented on OVERLORD-139: ---------------------------------------- Just failed on EAP 6.3 for me: https://issues.jboss.org/browse/SRAMP-589 > Logout not working > ------------------ > > Key: OVERLORD-139 > URL: https://issues.jboss.org/browse/OVERLORD-139 > Project: Overlord > Issue Type: Bug > Environment: Fedora 20 > S-RAMP installed into JBoss EAP 6.1.1.GA > Firefox 31 > Chrome 36 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > I logged in to S-RAMP UI, subsequently tried to logout (Click on 'admin' -> logout) and I was redirected back to s-ramp-ui, still logged in. I'm able to reproduce in both Firefox & Chrome. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 14:55:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 2 Oct 2014 14:55:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-589) SSO Logout failing with an exception In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-589. ------------------------------- Resolution: Duplicate Issue Duplicate of: OVERLORD-139 https://issues.jboss.org/browse/OVERLORD-139 > SSO Logout failing with an exception > ------------------------------------ > > Key: SRAMP-589 > URL: https://issues.jboss.org/browse/SRAMP-589 > Project: S-RAMP > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: Eric Wittmann > > {code} > 14:45:52,872 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-/127.0.0.1:8080-56) JBWEB000236: Servlet.ser > vice() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server ExceptionServer Exception > at org.overlord.commons.auth.filters.SamlSPFilter.doFilter(SamlSPFilter.java:379) [overlord-commons-auth-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.11-SNAPSHOT.jar:2.0.11-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.jboss.as.web.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:134) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:99) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.session.JvmRouteValve.invoke(JvmRouteValve.java:92) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.session.LockingValve.invoke(LockingValve.java:64) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 2 14:55:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 2 Oct 2014 14:55:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-139) Logout not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated OVERLORD-139: ----------------------------------- Fix Version/s: Overlord-Commons-2.0.11.Final > Logout not working > ------------------ > > Key: OVERLORD-139 > URL: https://issues.jboss.org/browse/OVERLORD-139 > Project: Overlord > Issue Type: Bug > Environment: Fedora 20 > S-RAMP installed into JBoss EAP 6.1.1.GA > Firefox 31 > Chrome 36 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > Fix For: Overlord-Commons-2.0.11.Final > > > I logged in to S-RAMP UI, subsequently tried to logout (Click on 'admin' -> logout) and I was redirected back to s-ramp-ui, still logged in. I'm able to reproduce in both Firefox & Chrome. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 05:16:11 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 3 Oct 2014 05:16:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-153) Fabric Password Encryption not allowed In-Reply-To: References: Message-ID: David virgil naranjo created OVERLORD-153: --------------------------------------------- Summary: Fabric Password Encryption not allowed Key: OVERLORD-153 URL: https://issues.jboss.org/browse/OVERLORD-153 Project: Overlord Issue Type: Bug Reporter: David virgil naranjo Assignee: Gary Brown -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 05:16:11 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 3 Oct 2014 05:16:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-153) Fabric Password Encryption not allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo reassigned OVERLORD-153: --------------------------------------------- Assignee: David virgil naranjo (was: Gary Brown) > Fabric Password Encryption not allowed > -------------------------------------- > > Key: OVERLORD-153 > URL: https://issues.jboss.org/browse/OVERLORD-153 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 07:36:12 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 3 Oct 2014 07:36:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-153) Fabric Password Encryption not allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated OVERLORD-153: ------------------------------------------ Git Pull Request: https://github.com/Governance/dtgov/pull/246, https://github.com/Governance/overlord-commons/pull/116, https://github.com/Governance/s-ramp/pull/499 > Fabric Password Encryption not allowed > -------------------------------------- > > Key: OVERLORD-153 > URL: https://issues.jboss.org/browse/OVERLORD-153 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:15:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 08:15:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-509: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/220 > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:15:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 08:15:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-509. ------------------------------ Resolution: Done > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:17:11 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 3 Oct 2014 08:17:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008476#comment-13008476 ] RH Bugzilla Integration commented on RTGOV-509: ----------------------------------------------- Gary Brown changed the Status of [bug 1053468|https://bugzilla.redhat.com/show_bug.cgi?id=1053468] from NEW to MODIFIED > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:40:13 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 3 Oct 2014 08:40:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-509: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1053468, https://bugzilla.redhat.com/show_bug.cgi?id=1149180 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1053468) > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 08:43:11 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 3 Oct 2014 08:43:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008489#comment-13008489 ] RH Bugzilla Integration commented on RTGOV-509: ----------------------------------------------- Gary Brown changed the Status of [bug 1149180|https://bugzilla.redhat.com/show_bug.cgi?id=1149180] from NEW to MODIFIED > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 09:49:12 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 3 Oct 2014 09:49:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-151) Fuse Fabric Commands refactoring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved OVERLORD-151. ---------------------------------- Fix Version/s: Overlord-Commons-2.0.11.Final Resolution: Done > Fuse Fabric Commands refactoring > -------------------------------- > > Key: OVERLORD-151 > URL: https://issues.jboss.org/browse/OVERLORD-151 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.11.Final > > > Remove the fuse fabric interpolation. Now there is not interpolation done by them and it is done using the apache commons interpolation. > Improve the Karaf commands for Fabric. Do not allow to modify the overlord commons profile user information when it is executed from a subclass. > Add a Karaf Command to modify the Overlord user in case it is desired. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 09:49:12 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 3 Oct 2014 09:49:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-153) Fabric Password Encryption not allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated OVERLORD-153: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > Fabric Password Encryption not allowed > -------------------------------------- > > Key: OVERLORD-153 > URL: https://issues.jboss.org/browse/OVERLORD-153 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 09:50:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 3 Oct 2014 09:50:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-153) Fabric Password Encryption not allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved OVERLORD-153. ---------------------------------- Fix Version/s: Overlord-Commons-2.0.11.Final Resolution: Done > Fabric Password Encryption not allowed > -------------------------------------- > > Key: OVERLORD-153 > URL: https://issues.jboss.org/browse/OVERLORD-153 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.11.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:38:11 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 3 Oct 2014 11:38:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-589) Create Karaf Commands to configure Fuse In-Reply-To: References: Message-ID: David virgil naranjo created RTGOV-589: ------------------------------------------ Summary: Create Karaf Commands to configure Fuse Key: RTGOV-589 URL: https://issues.jboss.org/browse/RTGOV-589 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: David virgil naranjo Assignee: David virgil naranjo -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:40:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 11:40:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-148) Add support for wildfly 8 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-148: -------------------------------- Fix Version/s: Overlord-Commons-2.0.12.Fina (was: Overlord-Commons-2.0.11.Final) > Add support for wildfly 8 > ------------------------- > > Key: OVERLORD-148 > URL: https://issues.jboss.org/browse/OVERLORD-148 > Project: Overlord > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.12.Fina > > > We need to make sure overlord-commons works and can be installed on wildfly 8. This means updating the installer and ensuring that the IDP functions properly. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:40:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 11:40:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-147) Use the maven-bundle-plugin in WAR projects (overlord-commons) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-147: -------------------------------- Fix Version/s: Overlord-Commons-2.0.12.Fina (was: Overlord-Commons-2.0.11.Final) > Use the maven-bundle-plugin in WAR projects (overlord-commons) > -------------------------------------------------------------- > > Key: OVERLORD-147 > URL: https://issues.jboss.org/browse/OVERLORD-147 > Project: Overlord > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.12.Fina > > > Right now in our WAR projects we are using the war plugin to configure the manifest for osgi. Instead we should use the bundle plugin. > Links: > https://ops4j1.jira.com/wiki/display/paxweb/OSGi-fy+your+WAR > https://ops4j1.jira.com/wiki/display/ops4j/Getting+the+benefits+of+maven-bundle-plugin+in+other+project+types > Here is an example of using it in overlord-commons-idp: > {code} > > 4.0.0 > > org.overlord > overlord-commons > 2.0.3-SNAPSHOT > > overlord-commons-idp > war > Overlord Commons: IDP > An identity provider using PicketLink SAML. > > > > org.picketlink > picketlink-federation > > > org.picketbox > picketbox > > > org.picketlink > picketlink-federation > > > org.jboss.logging > jboss-logging > > > ${project.groupId} > overlord-commons-auth > > > ${project.groupId} > overlord-commons-auth-jboss7 > > > ${project.groupId} > overlord-commons-auth-jetty8 > > > ${project.groupId} > overlord-commons-auth-tomcat7 > > > > org.jboss.spec.javax.servlet > jboss-servlet-api_3.0_spec > provided > > > > > > org.codehaus.mojo > build-helper-maven-plugin > > > regex-property > > regex-property > > > project.version.osgi > ${project.version} > -SNAPSHOT > .Snapshot > false > > > > > > > > > > > > > > > > > > > > > > > > > > > > maven-war-plugin > > > > ${project.build.outputDirectory}/META-INF/MANIFEST.MF > > > > > org.apache.felix > maven-bundle-plugin > > > bundle-manifest > process-classes > > manifest > > > > > false --> > ${project.artifactId} > true > classes > > 2 > ${project.artifactId} > ${project.version.osgi} > /overlord-idp > /overlord-idp > org.apache.log4j,javax.servlet, javax.servlet.http,javax.security.auth.login,javax.xml.stream,javax.xml.stream.events,javax.xml.namespace,javax.xml.transform,javax.xml.transform.dom,javax.xml.transform.stream,javax.xml.parsers,javax.xml.datatype,javax.xml.crypto,javax.xml.crypto.dsig,javax.xml.bind,org.apache.karaf.jaas.boot.principal,org.eclipse.jetty.plus.jaas,org.xml.sax,org.w3c.dom,org.w3c.dom.ls,org.overlord.commons.auth.util,org.picketlink.identity.federation.core.interfaces > > .,WEB-INF/classes,WEB-INF/lib/commons-logging-${version.commons-logging}.jar,WEB-INF/lib/jboss-logging-${version.org.jboss.logging}.jar,WEB-INF/lib/jbossxacml-2.0.8.Final.jar,WEB-INF/lib/picketbox-${picketbox.version}.jar,WEB-INF/lib/picketlink-common-${picketlink.version}.jar,WEB-INF/lib/picketlink-config-${picketlink.version}.jar,WEB-INF/lib/picketlink-federation-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-api-${picketlink.version}.jar,WEB-INF/lib/picketlink-idm-impl-${picketlink.version}.jar,WEB-INF/lib/xmlsec-1.5.1.jar > > > > > > > > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:40:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 11:40:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-139) Logout not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-139: -------------------------------- Fix Version/s: Overlord-Commons-2.0.12.Fina (was: Overlord-Commons-2.0.11.Final) > Logout not working > ------------------ > > Key: OVERLORD-139 > URL: https://issues.jboss.org/browse/OVERLORD-139 > Project: Overlord > Issue Type: Bug > Environment: Fedora 20 > S-RAMP installed into JBoss EAP 6.1.1.GA > Firefox 31 > Chrome 36 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > Fix For: Overlord-Commons-2.0.12.Fina > > > I logged in to S-RAMP UI, subsequently tried to logout (Click on 'admin' -> logout) and I was redirected back to s-ramp-ui, still logged in. I'm able to reproduce in both Firefox & Chrome. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:40:13 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 11:40:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-138) Tests for OSGiServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-138: -------------------------------- Fix Version/s: Overlord-Commons-2.0.12.Fina (was: Overlord-Commons-2.0.11.Final) > Tests for OSGiServiceRegistry > ----------------------------- > > Key: OVERLORD-138 > URL: https://issues.jboss.org/browse/OVERLORD-138 > Project: Overlord > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.12.Fina > > > Provide unit or integration tests to ensure OSGi services accessed via 'get' or service listener approach are correctly initialized and closed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:40:13 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 11:40:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-137) Ensure cached OSGi services are removed when service bundle uninstalled In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated OVERLORD-137: -------------------------------- Fix Version/s: Overlord-Commons-2.0.12.Fina (was: Overlord-Commons-2.0.11.Final) > Ensure cached OSGi services are removed when service bundle uninstalled > ----------------------------------------------------------------------- > > Key: OVERLORD-137 > URL: https://issues.jboss.org/browse/OVERLORD-137 > Project: Overlord > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.12.Fina > > > When services are retrieved using the getServices or getSingleService method on the ServiceRegistry(Util), they are cached for more efficient subsequent access. > The ServiceListener mechanism enables a client to be notified when services implementing a particular interface are registered or unregistered. > Either use a direct OSGi service listener, or the ServiceRegistry ServiceListener, to determine when the cached services should be removed. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 11:47:13 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 11:47:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-589) Create Karaf Commands to configure Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-589: ----------------------------- Fix Version/s: 2.0.0.Final > Create Karaf Commands to configure Fuse > --------------------------------------- > > Key: RTGOV-589 > URL: https://issues.jboss.org/browse/RTGOV-589 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 16:03:10 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 16:03:10 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-590) Optional size on Elasticsearch search does not return all of the expected results In-Reply-To: References: Message-ID: Gary Brown created RTGOV-590: -------------------------------- Summary: Optional size on Elasticsearch search does not return all of the expected results Key: RTGOV-590 URL: https://issues.jboss.org/browse/RTGOV-590 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final After RTGOV-509 was implemented, there was a change in behaviour due to the response size becoming optional - however this resulted in not all of the expected activity type objects being returned from a query. If a default large size is specified, this seems to cause all values to be returned. The same behaviour is observed by performing a query direct on to the Elasticsearch REST API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 16:47:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 16:47:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-590) Optional size on Elasticsearch search does not return all of the expected results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-590: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/221 > Optional size on Elasticsearch search does not return all of the expected results > --------------------------------------------------------------------------------- > > Key: RTGOV-590 > URL: https://issues.jboss.org/browse/RTGOV-590 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > After RTGOV-509 was implemented, there was a change in behaviour due to the response size becoming optional - however this resulted in not all of the expected activity type objects being returned from a query. > If a default large size is specified, this seems to cause all values to be returned. The same behaviour is observed by performing a query direct on to the Elasticsearch REST API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 3 16:47:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 3 Oct 2014 16:47:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-590) Optional size on Elasticsearch search does not return all of the expected results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-590. ------------------------------ Resolution: Done > Optional size on Elasticsearch search does not return all of the expected results > --------------------------------------------------------------------------------- > > Key: RTGOV-590 > URL: https://issues.jboss.org/browse/RTGOV-590 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > After RTGOV-509 was implemented, there was a change in behaviour due to the response size becoming optional - however this resulted in not all of the expected activity type objects being returned from a query. > If a default large size is specified, this seems to cause all values to be returned. The same behaviour is observed by performing a query direct on to the Elasticsearch REST API. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 04:09:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 6 Oct 2014 04:09:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-588) Investigate multiple init from overlord-commons ServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-588: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Investigate multiple init from overlord-commons ServiceRegistry > --------------------------------------------------------------- > > Key: RTGOV-588 > URL: https://issues.jboss.org/browse/RTGOV-588 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Related to RTGOV-554 - overlord-commons ServiceRegistry calling init multiple times. > Will wait for update to commons 2.0.11 before investigating further. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 04:09:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 6 Oct 2014 04:09:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-588) Investigate multiple init from overlord-commons ServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-588: ----------------------------- Issue Type: Bug (was: Task) > Investigate multiple init from overlord-commons ServiceRegistry > --------------------------------------------------------------- > > Key: RTGOV-588 > URL: https://issues.jboss.org/browse/RTGOV-588 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Related to RTGOV-554 - overlord-commons ServiceRegistry calling init multiple times. > Will wait for update to commons 2.0.11 before investigating further. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 6 04:10:11 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 6 Oct 2014 04:10:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-512) Situation list refresh waits indefinitely after UI not used for a while on fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-512: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Situation list refresh waits indefinitely after UI not used for a while on fuse > ------------------------------------------------------------------------------- > > Key: RTGOV-512 > URL: https://issues.jboss.org/browse/RTGOV-512 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Eric Wittmann > Fix For: 2.1.0.Final > > > When testing the RTGov UI on fuse, found that if the UI had been left running for a while, when returning to it and refreshing the Situations list, it didn't return (i.e. the spinning icon continued indefinitely). > If the UI was closed and reopened, using the localhost:8181/rtgov-ui URL, it went straight into the dashboard without requesting credentials, and when selecting the 'Situations' link, it showed the list immediately. > In the log, found the following exceptions when this occurred: > {noformat} > 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | > javax.servlet.ServletException: java.io.IOException: Closed > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > Caused by: java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > ... 28 more > 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error > java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 03:24:11 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 7 Oct 2014 03:24:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-591) Support Fabric deployment using karaf commands In-Reply-To: References: Message-ID: David virgil naranjo created RTGOV-591: ------------------------------------------ Summary: Support Fabric deployment using karaf commands Key: RTGOV-591 URL: https://issues.jboss.org/browse/RTGOV-591 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: David virgil naranjo Assignee: David virgil naranjo Support Fuse/Fabric deployment using karaf commands -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 04:58:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 7 Oct 2014 04:58:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-589) Create Karaf Commands to configure Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-589: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Create Karaf Commands to configure Fuse > --------------------------------------- > > Key: RTGOV-589 > URL: https://issues.jboss.org/browse/RTGOV-589 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 2.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 04:58:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 7 Oct 2014 04:58:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-575) endex custom loading of index mappings per .epn deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-575: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > endex custom loading of index mappings per .epn deployment > ----------------------------------------------------------- > > Key: RTGOV-575 > URL: https://issues.jboss.org/browse/RTGOV-575 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: Event Processor > Reporter: ivan mckinley > Assignee: Gary Brown > Labels: elasticsearch > Fix For: 2.1.0.Final > > > Prior to the karaf integration it was possible to deploy a epn with a elasticsearch store configured for a separate index as rtogv. > 1: developer would deploy a custom epn with a ElasticsearchKeyValueStore configured for a custom index and type. > 2: the elastisearchclient class would look for a file name $index-mapping.json on the path > The concept is developers can store business data they extracted from the activity events and store in ES for later analysis via kibana or what ever > unfortunately the following line > Thread.currentThread().setContextClassLoader(TransportClient.class.getClassLoader()); > in ElasticsearchClient that was added for the karaf intergration means that the classloader can not longer see any bundled $index-mappings.json file that accompany the deployed epns (.war) > one solution would be to switch to the same mechanism used to to load ip.json or epn.json files -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 04:58:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 7 Oct 2014 04:58:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-555) EPNs not properly registered after rtgov refresh in Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-555: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > EPNs not properly registered after rtgov refresh in Fuse > -------------------------------------------------------- > > Key: RTGOV-555 > URL: https://issues.jboss.org/browse/RTGOV-555 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > When installing rtgov followed by switchyard in fuse, the EPNs are not all re-registered. > It appears that the activators are being called, which establishes service listeners on the EPNManager, but only some of the EPNs are then called back when the EPNManager is available. > Firstly need to consider adding some form of timer on the activators, to log an error if the EPN is not eventually registered. But need to find out why some activators are called, while others are not. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 05:00:14 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 7 Oct 2014 05:00:14 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-589) Create Karaf Commands to configure Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-589: ----------------------------- Fix Version/s: 2.0.0.Final (was: 2.1.0.Final) > Create Karaf Commands to configure Fuse > --------------------------------------- > > Key: RTGOV-589 > URL: https://issues.jboss.org/browse/RTGOV-589 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 05:00:14 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 7 Oct 2014 05:00:14 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-589) Create Karaf Commands to configure Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-589. ------------------------------ Resolution: Done > Create Karaf Commands to configure Fuse > --------------------------------------- > > Key: RTGOV-589 > URL: https://issues.jboss.org/browse/RTGOV-589 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 10:20:12 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Tue, 7 Oct 2014 10:20:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-592) Filtering situations by status "Unresolved" is not working In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-592: --------------------------------- Summary: Filtering situations by status "Unresolved" is not working Key: RTGOV-592 URL: https://issues.jboss.org/browse/RTGOV-592 Project: RTGov (Run Time Governance) Issue Type: Bug Components: User Interface Affects Versions: 2.0.0.Final Environment: Fuse 6.1 + switchyard 2.0.0.Alpha3 + overlord 2.0.0.Final Reporter: Andrej Vano Assignee: Gary Brown Filtering by status "Unresolved" always return No situations found. even if there are unresolved situations. All other statuses (resolved, in progress..) are working correctly -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 10:27:26 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 10:27:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-592) Filtering situations by status "Unresolved" is not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-592: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1150158 > Filtering situations by status "Unresolved" is not working > ---------------------------------------------------------- > > Key: RTGOV-592 > URL: https://issues.jboss.org/browse/RTGOV-592 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Environment: Fuse 6.1 + switchyard 2.0.0.Alpha3 + overlord 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > > Filtering by status "Unresolved" always return No situations found. even if there are unresolved situations. All other statuses (resolved, in progress..) are working correctly -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 10:35:40 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 7 Oct 2014 10:35:40 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-592) Filtering situations by status "Unresolved" is not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-592: ----------------------------- Fix Version/s: 2.1.0.Final > Filtering situations by status "Unresolved" is not working > ---------------------------------------------------------- > > Key: RTGOV-592 > URL: https://issues.jboss.org/browse/RTGOV-592 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Environment: Fuse 6.1 + switchyard 2.0.0.Alpha3 + overlord 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Filtering by status "Unresolved" always return No situations found. even if there are unresolved situations. All other statuses (resolved, in progress..) are working correctly -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 11:34:12 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 11:34:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-140) Ensure consistent fav icon for all overlord apps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009391#comment-13009391 ] RH Bugzilla Integration commented on OVERLORD-140: -------------------------------------------------- Eric Wittmann changed the Status of [bug 1048779|https://bugzilla.redhat.com/show_bug.cgi?id=1048779] from NEW to MODIFIED > Ensure consistent fav icon for all overlord apps > ------------------------------------------------ > > Key: OVERLORD-140 > URL: https://issues.jboss.org/browse/OVERLORD-140 > Project: Overlord > Issue Type: Enhancement > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.9.Final > > > Ensure that all UI apps (s-ramp, dtgov, rtgov) share a common favicon. Presumably we should use the overlord icon currently included in overlord-commons-uiheader. This can be accomplished by simply including this markup in the gwt host page: > {code} > > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:02:14 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:02:14 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-545) Provide ability to delete ontology via UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009414#comment-13009414 ] RH Bugzilla Integration commented on SRAMP-545: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146588|https://bugzilla.redhat.com/show_bug.cgi?id=1146588] from NEW to MODIFIED > Provide ability to delete ontology via UI > ----------------------------------------- > > Key: SRAMP-545 > URL: https://issues.jboss.org/browse/SRAMP-545 > Project: S-RAMP > Issue Type: Enhancement > Components: UI > Affects Versions: 0.5.0.Final > Reporter: Stefan Bunciak > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.6.0.Final > > > There is no way how to delete ontology in S-RAMP UI. One would expect such functionality in Ontology Management section. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:20 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-585) Use Karaf Commands to include UI Headers in the Fabric deployment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009415#comment-13009415 ] RH Bugzilla Integration commented on SRAMP-585: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Use Karaf Commands to include UI Headers in the Fabric deployment > ----------------------------------------------------------------- > > Key: SRAMP-585 > URL: https://issues.jboss.org/browse/SRAMP-585 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0.Final > > > The UI Headers are not getting loaded in the Fuse Fabric installation. > https://github.com/Governance/s-ramp/pull/496 > THe UI Headers are normally loaded from a file included in a folder overlord-apps. In the case of Fuse Fabric, this folder can not be read from the profiles. > The solution proposed is to use the karaf commands to include the header information in the overlord.properties. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:20 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-151) Fuse Fabric Commands refactoring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009416#comment-13009416 ] RH Bugzilla Integration commented on OVERLORD-151: -------------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Fuse Fabric Commands refactoring > -------------------------------- > > Key: OVERLORD-151 > URL: https://issues.jboss.org/browse/OVERLORD-151 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.11.Final > > > Remove the fuse fabric interpolation. Now there is not interpolation done by them and it is done using the apache commons interpolation. > Improve the Karaf commands for Fabric. Do not allow to modify the overlord commons profile user information when it is executed from a subclass. > Add a Karaf Command to modify the Overlord user in case it is desired. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:21 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:21 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-566) Remove Fuse from installer and replace with new Karaf commands In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009418#comment-13009418 ] RH Bugzilla Integration commented on SRAMP-566: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Remove Fuse from installer and replace with new Karaf commands > -------------------------------------------------------------- > > Key: SRAMP-566 > URL: https://issues.jboss.org/browse/SRAMP-566 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0.Final > > > Rather than continue to support Fuse from within the installer, instead create Karaf command(s) to handle it all. Each project will have at least it's own overlord:[project]:configure. We'll also need to kick off overlord-commons GenerateSamlKeystoreCommand somehow, either by creating a central overlord:commons:configure (not sure that's best) or running it from *all* other projects' configure commands (and ensure it's only run once). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:22 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:22 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009417#comment-13009417 ] RH Bugzilla Integration commented on SRAMP-380: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Passwords in clear text when running in Fuse 6.1 > ------------------------------------------------ > > Key: SRAMP-380 > URL: https://issues.jboss.org/browse/SRAMP-380 > Project: S-RAMP > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.6.0.Final > > > When we install into JBoss EAP we make sure that we don't have any clear text passwords in any configuration files. This is made possible by using the Vault, which allows us to store passwords in the vault and then refer to those vault locations from our config files. > I don't know if there is something similar to be done in Fuse 6.1 > In addition, the login credentials for supported users in EAP are not stored in clear text (the EAP Application Realm config files store an encrypted version of the passwords). > In Fuse 6.1 we are storing the login user credentials in a users.properties file in clear text. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:23 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-578) Fuse Fabric commands refactoring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009419#comment-13009419 ] RH Bugzilla Integration commented on SRAMP-578: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Fuse Fabric commands refactoring > -------------------------------- > > Key: SRAMP-578 > URL: https://issues.jboss.org/browse/SRAMP-578 > Project: S-RAMP > Issue Type: Enhancement > Reporter: David virgil naranjo > Assignee: Brett Meyer > Fix For: 0.6.0.Final > > > Modify the karaf fabric command name. > Allow the deployment of s-ramp and dtgov together in the same container. > There was a problem in the profile folder. As the class was extending the AbstractConfigureFabric command, the getProfileFolder method should not overwrite the parent. There is a problem with the folder where the overlord.properties and the overlord-saml.keystore file is saved. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-570) Improve s-ramp commands for Fuse/Fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009420#comment-13009420 ] RH Bugzilla Integration commented on SRAMP-570: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Improve s-ramp commands for Fuse/Fabric > --------------------------------------- > > Key: SRAMP-570 > URL: https://issues.jboss.org/browse/SRAMP-570 > Project: S-RAMP > Issue Type: Enhancement > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0.Final > > > For Fuse: > 1.) Make the password argument optional > 2.) If no Overlord installation has been attempted (the existence of overlord.properties in FUSE/etc is a good test), fail if no password is provided > 3.) If a password is provided, but overlord.properties already exists, print what Gary mentioned: an installation already exists, re-using those credentials, but the "overlord:changePassword" command is available > 4.) Create overlord:changePassword. It would regenerate the keystore and update any applicable *.properties values > Modify/Add commands to deploy in Fuse Fabric. Create new commands. They would be like fuse commands, but starting by fabric : fabric:overlord:s-ramp:configure -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-569) Create maven plugin to merge .properties files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009421#comment-13009421 ] RH Bugzilla Integration commented on SRAMP-569: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Create maven plugin to merge .properties files > ---------------------------------------------- > > Key: SRAMP-569 > URL: https://issues.jboss.org/browse/SRAMP-569 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0.Final > > > SRAMP-566 removes Fuse from s-ramp-installer. Instead, Fuse configuration is scripted through s-ramp-karaf-commands. That project currently controls its own versions of sramp.properties, sramp-ui.properties, etc. This was originally done since some of the values are static and *specific* to Fuse. > However, several values remain unchanged when compared to the other platforms. It would be better if s-ramp-karaf-commands/pom.xml was able to pull ../s-ramp-installer/**/*.properties and merge it with .properties still controlled in s-ramp-karaf-commands. However, the s-ramp-karaf-commands version would contain *only* the Fuse specific values. > Essentially, we're relying on s-ramp-installer's versions during buildtime, but overriding with any necessary Fuse values in s-ramp-karaf-commands. A custom Maven plugin to support this should be incredibly easy. Use Java's Properties, load the first version, then load and override with the 2nd. See http://beardedgeeks.googlecode.com/svn/docs/maven-merge-properties-plugin/0.2/index.html for inspiration. > Note that this is also needed for overlord-commons-karaf-commands (configure.dtd, overlord.properties, etc.) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-142) Not all required overlord properties are created if file already exists in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009422#comment-13009422 ] RH Bugzilla Integration commented on OVERLORD-142: -------------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Not all required overlord properties are created if file already exists in fuse > ------------------------------------------------------------------------------- > > Key: OVERLORD-142 > URL: https://issues.jboss.org/browse/OVERLORD-142 > Project: Overlord > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: Overlord-Commons-2.0.8.Final > > > The properties: > overlord.auth.saml-key-alias=overlord > overlord.auth.saml-keystore=${sys\:karaf.home}/etc/overlord-saml.keystore > are not created by the overlord:generatesamlkeystore command if the file already exists. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:25 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-153) Fabric Password Encryption not allowed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009423#comment-13009423 ] RH Bugzilla Integration commented on OVERLORD-153: -------------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Fabric Password Encryption not allowed > -------------------------------------- > > Key: OVERLORD-153 > URL: https://issues.jboss.org/browse/OVERLORD-153 > Project: Overlord > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.11.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:26 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-117) Pull Fabric profile tasks out of overlord-commons-dist-fuse6 and into a new overlord-commons-dist-fabric-profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009426#comment-13009426 ] RH Bugzilla Integration commented on OVERLORD-117: -------------------------------------------------- Brett Meyer changed the Status of [bug 1146591|https://bugzilla.redhat.com/show_bug.cgi?id=1146591] from NEW to MODIFIED > Pull Fabric profile tasks out of overlord-commons-dist-fuse6 and into a new overlord-commons-dist-fabric-profile > ---------------------------------------------------------------------------------------------------------------- > > Key: OVERLORD-117 > URL: https://issues.jboss.org/browse/OVERLORD-117 > Project: Overlord > Issue Type: Task > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.9.Final > > > Similar to S-RAMP, DTGov, and RTGov, pull the Fabric profiles into a separate dist within overlord-commons. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 12:03:26 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 7 Oct 2014 12:03:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-544) SNAPSHOT artifacts can no longer be pulled from S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009427#comment-13009427 ] RH Bugzilla Integration commented on SRAMP-544: ----------------------------------------------- Brett Meyer changed the Status of [bug 1146617|https://bugzilla.redhat.com/show_bug.cgi?id=1146617] from NEW to MODIFIED > SNAPSHOT artifacts can no longer be pulled from S-RAMP > ------------------------------------------------------ > > Key: SRAMP-544 > URL: https://issues.jboss.org/browse/SRAMP-544 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > Priority: Critical > Fix For: 0.6.0.Final > > > If a project uses the Wagon or facade as a dependency repo, SRAMP-507 breaks the ability to pull SNAPSHOT artifacts. Since we append the timestamp, simply using the original GAV no longer works. To duplicate, run the new multimodule webapp demo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 7 19:20:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 7 Oct 2014 19:20:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-167) Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-167: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/500 > Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) > ------------------------------------------------------------------------------------- > > Key: SRAMP-167 > URL: https://issues.jboss.org/browse/SRAMP-167 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > > We need to make sure that we can support the logical (non-document) artifact types. The mechanism for creating them is different (there's no POST of a document). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 10:45:20 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 10:45:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-167) Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-167. ------------------------------- Resolution: Done "Completed", with the caveat that the pull request has several TODOs due to issues with the spec schemas. Once those have been addressed with S-RAMP 1.1 (hopefully), re-visit. > Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) > ------------------------------------------------------------------------------------- > > Key: SRAMP-167 > URL: https://issues.jboss.org/browse/SRAMP-167 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > > We need to make sure that we can support the logical (non-document) artifact types. The mechanism for creating them is different (there's no POST of a document). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 10:45:22 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 10:45:22 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-167) Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-167: ------------------------------ Fix Version/s: 0.7.0.Final > Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) > ------------------------------------------------------------------------------------- > > Key: SRAMP-167 > URL: https://issues.jboss.org/browse/SRAMP-167 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > We need to make sure that we can support the logical (non-document) artifact types. The mechanism for creating them is different (there's no POST of a document). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:02:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:02:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-110) Implement fine-grained classification view in the Atom API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-110: ------------------------------ Parent: (was: SRAMP-106) Issue Type: Feature Request (was: Sub-task) > Implement fine-grained classification view in the Atom API > ---------------------------------------------------------- > > Key: SRAMP-110 > URL: https://issues.jboss.org/browse/SRAMP-110 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > > The spec defines fine-grained views, including one for the classifications. This allows clients to get a manipulate (add, delete, get feed) the classifications for an artifact in the S-RAMP repository directly, removing the need to deal with the whole artifact at once. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:03:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:03:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-110) Implement fine-grained classification view in the Atom API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010004#comment-13010004 ] Brett Meyer commented on SRAMP-110: ----------------------------------- Converting to separate Feature Request. Fine-grained views are optional in the spec. > Implement fine-grained classification view in the Atom API > ---------------------------------------------------------- > > Key: SRAMP-110 > URL: https://issues.jboss.org/browse/SRAMP-110 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > > The spec defines fine-grained views, including one for the classifications. This allows clients to get a manipulate (add, delete, get feed) the classifications for an artifact in the S-RAMP repository directly, removing the need to deal with the whole artifact at once. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:03:12 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:03:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-94) Handle fine-grained Atom view for relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-94: ----------------------------- Parent: (was: SRAMP-90) Issue Type: Feature Request (was: Sub-task) > Handle fine-grained Atom view for relationships > ----------------------------------------------- > > Key: SRAMP-94 > URL: https://issues.jboss.org/browse/SRAMP-94 > Project: S-RAMP > Issue Type: Feature Request > Components: Atom Binding > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > > Relationships have their own separate Atom API endpoints. For example, you can get a feed of just the relationships for an artifact. In addition, you cn add (and I believe delete) individual relationships directly via this mechanism. This task should probably result in a new RelationshipResource RESTEasy class. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:03:12 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:03:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-94) Handle fine-grained Atom view for relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-94?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010005#comment-13010005 ] Brett Meyer commented on SRAMP-94: ---------------------------------- Converting to separate Feature Request. Fine-grained views are optional in the spec. > Handle fine-grained Atom view for relationships > ----------------------------------------------- > > Key: SRAMP-94 > URL: https://issues.jboss.org/browse/SRAMP-94 > Project: S-RAMP > Issue Type: Feature Request > Components: Atom Binding > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > > Relationships have their own separate Atom API endpoints. For example, you can get a feed of just the relationships for an artifact. In addition, you cn add (and I believe delete) individual relationships directly via this mechanism. This task should probably result in a new RelationshipResource RESTEasy class. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:04:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:04:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-106) Support S-RAMP classifications In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-106. ----------------------------- Fix Version/s: 0.1.0 - Milestone 3 (Workflow and Relationships) Resolution: Done > Support S-RAMP classifications > ------------------------------ > > Key: SRAMP-106 > URL: https://issues.jboss.org/browse/SRAMP-106 > Project: S-RAMP > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.1.0 - Milestone 3 (Workflow and Relationships) > > > This is a parent task for all of the individual bits of work needed to be done related to supporting S-RAMP classifications. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:05:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:05:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-169) Organization hierarchy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-169: ------------------------------ Parent: (was: SRAMP-462) Issue Type: Feature Request (was: Sub-task) > Organization hierarchy > ---------------------- > > Key: SRAMP-169 > URL: https://issues.jboss.org/browse/SRAMP-169 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Kurt Stam > > The SRAMP spec defines an Organization entity (derived from HumanActor) that can be related to a ServiceImplementation using the 'provides' relationship. > In large organizations it may be necessary to define more of a organizational structure, to correctly associate the services with the appropriate business units, departments, etc. that are responsible for the service. > The other issue is whether a 'provides' relationship is enough. This may indicate the implementers of the service, but not necessarily the support contact if there is a problem with the service. So potentially there should also be a 'supports' relationship that can optionally be used where the support is provided by a different team. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:06:13 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:06:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-169) Organization hierarchy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010006#comment-13010006 ] Brett Meyer commented on SRAMP-169: ----------------------------------- Converting to separate Feature Request. Not required by the spec. > Organization hierarchy > ---------------------- > > Key: SRAMP-169 > URL: https://issues.jboss.org/browse/SRAMP-169 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Gary Brown > Assignee: Kurt Stam > > The SRAMP spec defines an Organization entity (derived from HumanActor) that can be related to a ServiceImplementation using the 'provides' relationship. > In large organizations it may be necessary to define more of a organizational structure, to correctly associate the services with the appropriate business units, departments, etc. that are responsible for the service. > The other issue is whether a 'provides' relationship is enough. This may indicate the implementers of the service, but not necessarily the support contact if there is a problem with the service. So potentially there should also be a 'supports' relationship that can optionally be used where the support is provided by a different team. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:35:12 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:35:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-590) StoredQueryWorkspace must include all available queries in its app:collection In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-590: --------------------------------- Summary: StoredQueryWorkspace must include all available queries in its app:collection Key: SRAMP-590 URL: https://issues.jboss.org/browse/SRAMP-590 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 8 15:35:12 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 8 Oct 2014 15:35:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-590) StoredQueryWorkspace must include all available queries in its app:collection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-590: ------------------------------ Description: {quote}The workspace for the query artifact model MUST contain an app:collection element for each Stored Query that exists in the S-RAMP implementation.{quote} > StoredQueryWorkspace must include all available queries in its app:collection > ----------------------------------------------------------------------------- > > Key: SRAMP-590 > URL: https://issues.jboss.org/browse/SRAMP-590 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote}The workspace for the query artifact model MUST contain an app:collection element for each Stored Query that exists in the S-RAMP implementation.{quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 01:55:11 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Thu, 9 Oct 2014 01:55:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-593) UX: Make filtering more full-text In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-593: --------------------------------- Summary: UX: Make filtering more full-text Key: RTGOV-593 URL: https://issues.jboss.org/browse/RTGOV-593 Project: RTGov (Run Time Governance) Issue Type: Bug Components: User Interface Affects Versions: 2.0.0.Final Reporter: Andrej Vano Assignee: Gary Brown Fix For: 2.1.0.Final The filtering in the UI is a bit confusing, here are some examples: 1. Have 1 situation with subject "{urn:switchyard-soa:rtgov_console:1.0.0}OrderService|submitOrder" If I want to filter by the subject the results are: - "o" - no situations - "or" - no situations - "ord" - no situations - "orde" - no situations - "order" - no situations - "orders" - no situations - "orderse" - no situations - "orderser" - no situations - "orderserv" - finally the situation is found This is why I set it as a bug: 2. Have 4 situations with descriptions "CPS", "HPS", "MPS", "LPS" representing "Critical Priority Situation" etc. If I want to filter these situations by description: - "h" - no situations - "hp" - no situations - "hps" - All 4 situations returned -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 01:58:11 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 9 Oct 2014 01:58:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-593) UX: Make filtering more full-text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-593: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1150870 > UX: Make filtering more full-text > --------------------------------- > > Key: RTGOV-593 > URL: https://issues.jboss.org/browse/RTGOV-593 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The filtering in the UI is a bit confusing, here are some examples: > 1. Have 1 situation with subject "{urn:switchyard-soa:rtgov_console:1.0.0}OrderService|submitOrder" > If I want to filter by the subject the results are: > - "o" - no situations > - "or" - no situations > - "ord" - no situations > - "orde" - no situations > - "order" - no situations > - "orders" - no situations > - "orderse" - no situations > - "orderser" - no situations > - "orderserv" - finally the situation is found > This is why I set it as a bug: > 2. Have 4 situations with descriptions "CPS", "HPS", "MPS", "LPS" representing "Critical Priority Situation" etc. > If I want to filter these situations by description: > - "h" - no situations > - "hp" - no situations > - "hps" - All 4 situations returned -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 04:03:13 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 9 Oct 2014 04:03:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-593) UX: Make filtering more full-text In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reassigned RTGOV-593: -------------------------------- Assignee: ivan mckinley (was: Gary Brown) Any thoughts Ivan? I know the elasticsearch has a score associated with a search - do we need to make this configurable? Although wondering whether increasing the score may improve the situation with example (2), but possible make it worse for (1). > UX: Make filtering more full-text > --------------------------------- > > Key: RTGOV-593 > URL: https://issues.jboss.org/browse/RTGOV-593 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: Andrej Vano > Assignee: ivan mckinley > Fix For: 2.1.0.Final > > > The filtering in the UI is a bit confusing, here are some examples: > 1. Have 1 situation with subject "{urn:switchyard-soa:rtgov_console:1.0.0}OrderService|submitOrder" > If I want to filter by the subject the results are: > - "o" - no situations > - "or" - no situations > - "ord" - no situations > - "orde" - no situations > - "order" - no situations > - "orders" - no situations > - "orderse" - no situations > - "orderser" - no situations > - "orderserv" - finally the situation is found > This is why I set it as a bug: > 2. Have 4 situations with descriptions "CPS", "HPS", "MPS", "LPS" representing "Critical Priority Situation" etc. > If I want to filter these situations by description: > - "h" - no situations > - "hp" - no situations > - "hps" - All 4 situations returned -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 08:56:11 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 9 Oct 2014 08:56:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-594) Move common Elasticsearch capabilities into overlord-commons In-Reply-To: References: Message-ID: Gary Brown created RTGOV-594: -------------------------------- Summary: Move common Elasticsearch capabilities into overlord-commons Key: RTGOV-594 URL: https://issues.jboss.org/browse/RTGOV-594 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final Move Elasticsearch functionality that may be of use to other overlord projects into overlord-commons. This could include the basic Elasticsearch client code (and configuration) and the proxy REST service for adding authentication support when accessing the Elasticsearch server. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 08:58:14 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 9 Oct 2014 08:58:14 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-154) Move shared Elasticsearch functionality from rtgov into commons In-Reply-To: References: Message-ID: Gary Brown created OVERLORD-154: ----------------------------------- Summary: Move shared Elasticsearch functionality from rtgov into commons Key: OVERLORD-154 URL: https://issues.jboss.org/browse/OVERLORD-154 Project: Overlord Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: Overlord-Commons-2.0.12.Fina Move the Elasticsearch functionality, currently used in rtgov, that is of common use to other Overlord projects. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 09:04:25 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 9 Oct 2014 09:04:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-566) [resubmit] RemoteMessage#context is empty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010213#comment-13010213 ] RH Bugzilla Integration commented on RTGOV-566: ----------------------------------------------- George Varsamis changed the Status of [bug 1146207|https://bugzilla.redhat.com/show_bug.cgi?id=1146207] from MODIFIED to ON_QA > [resubmit] RemoteMessage#context is empty > ----------------------------------------- > > Key: RTGOV-566 > URL: https://issues.jboss.org/browse/RTGOV-566 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Michael Clay > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > because RemoteMessage#context is empty/not used there is no way to pass > properties required for the implementation of the resubmitted/retried service invocation (e.g. SOAPHeader are stored as message properties) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 09:04:25 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 9 Oct 2014 09:04:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-556) RTGov UI no longer working on FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010214#comment-13010214 ] RH Bugzilla Integration commented on RTGOV-556: ----------------------------------------------- George Varsamis changed the Status of [bug 1146206|https://bugzilla.redhat.com/show_bug.cgi?id=1146206] from ASSIGNED to ON_QA > RTGov UI no longer working on FSW 6.0 > ------------------------------------- > > Key: RTGOV-556 > URL: https://issues.jboss.org/browse/RTGOV-556 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: overlord-rtgov-elasticsearch.properties > > > RTGov UI beta 1 worked on FSW 6.0, but subsequent changes to rtgov have caused it to stop working. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 09:04:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 9 Oct 2014 09:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010225#comment-13010225 ] RH Bugzilla Integration commented on RTGOV-509: ----------------------------------------------- George Varsamis changed the Status of [bug 1149180|https://bugzilla.redhat.com/show_bug.cgi?id=1149180] from MODIFIED to ON_QA > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 12:11:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 9 Oct 2014 12:11:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-590) StoredQueryWorkspace must include all available queries in its app:collection In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-590. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > StoredQueryWorkspace must include all available queries in its app:collection > ----------------------------------------------------------------------------- > > Key: SRAMP-590 > URL: https://issues.jboss.org/browse/SRAMP-590 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > {quote}The workspace for the query artifact model MUST contain an app:collection element for each Stored Query that exists in the S-RAMP implementation.{quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 22:04:10 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 9 Oct 2014 22:04:10 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-591) Default EAP 6.3 Installation throws ERROR:Naming context is read-only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer moved DTGOV-245 to SRAMP-591: ----------------------------------------- Project: S-RAMP (was: DTGov (Design Time Governance)) Key: SRAMP-591 (was: DTGOV-245) Affects Version/s: (was: 1.4) Fix Version/s: (was: 1.5) > Default EAP 6.3 Installation throws ERROR:Naming context is read-only > --------------------------------------------------------------------- > > Key: SRAMP-591 > URL: https://issues.jboss.org/browse/SRAMP-591 > Project: S-RAMP > Issue Type: Bug > Environment: CentOs 7 (3.10.0-123.el7.x86_64), > JAVA: java version "1.7.0_65"; OpenJDK Runtime Environment (rhel-2.5.1.2.el7_0-x86_64 u65-b17); OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) > Apache Ant 1.9.2 > The whole system runs inside of a virtual box with 4GB RAM, 2 CPUs and 50GB Harddrive. > Reporter: Sebastian Goschin > Assignee: Brett Meyer > > After installing DTgov and S-RAMP at EAP 6.3 and before installing workflows and ontologies of DTgov 1.4 by "ant seed", the EAP 6.3 throws errors during startup. > 18:18:49,657 WARN [org.overlord.sramp.events.jms.JMSEventProducer] (ServerService Thread Pool -- 58) Could not discover "ConnectionFactory" and/or the configured topics/queues over JNDI. Assuming a non-EE environment or that JMS/JNDI isnt configured. Falling back on an embedded ActiveMQ broker, available on {0} > 18:18:50,196 INFO [org.apache.activemq.store.kahadb.plist.PListStoreImpl] (ServerService Thread Pool -- 58) PListStore:[/home/admin/activemq-data/localhost/tmp_storage] started > 18:18:50,201 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Using Persistence Adapter: KahaDBPersistenceAdapter[/home/admin/activemq-data/localhost/KahaDB] > 18:18:50,234 INFO [org.jboss.solder.exception.control.extension] (MSC service thread 1-4) Adding handler Qualifiers: [@javax.enterprise.inject.Any()] TraversalMode: BREADTH_FIRST Handles Type: class java.lang.Throwable Precedence: -100 [method] public org.jboss.seam.transaction.SimpleTransactionExceptionHandler.markTransactionRollback(CaughtException) to known handlers > 18:18:50,248 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:50,282 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:50,556 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.sramp.governance.workflow.jbpm.ProcessService.processBean > 18:18:50,560 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.jbpm.ProcessBean.processEngineService > 18:18:50,581 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.taskapi.TaskApi.processEngineService > 18:18:50,799 INFO [org.jboss.web] (ServerService Thread Pool -- 68) JBAS018210: Register web context: /dtgov > 18:18:51,107 INFO [solder-servlet] (ServerService Thread Pool -- 68) Catch Integration for Servlets enabled > 18:18:57,085 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) KahaDB is version 4 > 18:18:57,110 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovering from the journal ... > 18:18:57,111 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovery replayed 2 operations from the journal in 0.008 seconds. > 18:18:57,162 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) is starting > 18:18:57,176 INFO [org.apache.activemq.transport.TransportServerThreadSupport] (ServerService Thread Pool -- 58) Listening for connections at: tcp://localhost:61616 > 18:18:57,177 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector tcp://localhost:61616 Started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) For help or more information please see: http://activemq.apache.org > 18:18:57,178 WARN [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Store limit is 102400 mb, whilst the data directory: /home/admin/activemq-data/localhost/KahaDB only has 44079 mb of usable space > 18:18:57,179 ERROR [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Temporary Store limit is 51200 mb, whilst the temporary data directory: /home/admin/activemq-data/localhost/tmp_storage only has 44079 mb of usable space > 18:18:57,211 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:57,211 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:57,214 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:57,218 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector vm://localhost Started -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 9 22:06:11 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 9 Oct 2014 22:06:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-591) Default EAP 6.3 Installation throws ERROR:Naming context is read-only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010442#comment-13010442 ] Brett Meyer commented on SRAMP-591: ----------------------------------- I was able to reproduce what you're seeing when using standalone, but it appears to work perfectly with standalone-full. I'm seeing a few suggestions here and there that there may have been a problem with ActiveMQ within EAP that may have caused the specific errors, but supposedly that was already fixed. Unfortunately, I can't find much more info about it. For now, we'll need to require standalone-full: {code}bin/standalone.sh -c standalone-full.xml{code} That may be a good idea, considering some of the things coming up on the roadmap. I've added more info to the docs. > Default EAP 6.3 Installation throws ERROR:Naming context is read-only > --------------------------------------------------------------------- > > Key: SRAMP-591 > URL: https://issues.jboss.org/browse/SRAMP-591 > Project: S-RAMP > Issue Type: Bug > Environment: CentOs 7 (3.10.0-123.el7.x86_64), > JAVA: java version "1.7.0_65"; OpenJDK Runtime Environment (rhel-2.5.1.2.el7_0-x86_64 u65-b17); OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) > Apache Ant 1.9.2 > The whole system runs inside of a virtual box with 4GB RAM, 2 CPUs and 50GB Harddrive. > Reporter: Sebastian Goschin > Assignee: Brett Meyer > > After installing DTgov and S-RAMP at EAP 6.3 and before installing workflows and ontologies of DTgov 1.4 by "ant seed", the EAP 6.3 throws errors during startup. > 18:18:49,657 WARN [org.overlord.sramp.events.jms.JMSEventProducer] (ServerService Thread Pool -- 58) Could not discover "ConnectionFactory" and/or the configured topics/queues over JNDI. Assuming a non-EE environment or that JMS/JNDI isnt configured. Falling back on an embedded ActiveMQ broker, available on {0} > 18:18:50,196 INFO [org.apache.activemq.store.kahadb.plist.PListStoreImpl] (ServerService Thread Pool -- 58) PListStore:[/home/admin/activemq-data/localhost/tmp_storage] started > 18:18:50,201 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Using Persistence Adapter: KahaDBPersistenceAdapter[/home/admin/activemq-data/localhost/KahaDB] > 18:18:50,234 INFO [org.jboss.solder.exception.control.extension] (MSC service thread 1-4) Adding handler Qualifiers: [@javax.enterprise.inject.Any()] TraversalMode: BREADTH_FIRST Handles Type: class java.lang.Throwable Precedence: -100 [method] public org.jboss.seam.transaction.SimpleTransactionExceptionHandler.markTransactionRollback(CaughtException) to known handlers > 18:18:50,248 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:50,282 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:50,556 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.sramp.governance.workflow.jbpm.ProcessService.processBean > 18:18:50,560 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.jbpm.ProcessBean.processEngineService > 18:18:50,581 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.taskapi.TaskApi.processEngineService > 18:18:50,799 INFO [org.jboss.web] (ServerService Thread Pool -- 68) JBAS018210: Register web context: /dtgov > 18:18:51,107 INFO [solder-servlet] (ServerService Thread Pool -- 68) Catch Integration for Servlets enabled > 18:18:57,085 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) KahaDB is version 4 > 18:18:57,110 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovering from the journal ... > 18:18:57,111 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovery replayed 2 operations from the journal in 0.008 seconds. > 18:18:57,162 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) is starting > 18:18:57,176 INFO [org.apache.activemq.transport.TransportServerThreadSupport] (ServerService Thread Pool -- 58) Listening for connections at: tcp://localhost:61616 > 18:18:57,177 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector tcp://localhost:61616 Started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) For help or more information please see: http://activemq.apache.org > 18:18:57,178 WARN [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Store limit is 102400 mb, whilst the data directory: /home/admin/activemq-data/localhost/KahaDB only has 44079 mb of usable space > 18:18:57,179 ERROR [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Temporary Store limit is 51200 mb, whilst the temporary data directory: /home/admin/activemq-data/localhost/tmp_storage only has 44079 mb of usable space > 18:18:57,211 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:57,211 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:57,214 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:57,218 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector vm://localhost Started -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 02:37:11 2014 From: issues at jboss.org (Sebastian Goschin (JIRA)) Date: Fri, 10 Oct 2014 02:37:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-591) Default EAP 6.3 Installation throws ERROR:Naming context is read-only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010469#comment-13010469 ] Sebastian Goschin commented on SRAMP-591: ----------------------------------------- Thanks for this info. It worked for me as well. > Default EAP 6.3 Installation throws ERROR:Naming context is read-only > --------------------------------------------------------------------- > > Key: SRAMP-591 > URL: https://issues.jboss.org/browse/SRAMP-591 > Project: S-RAMP > Issue Type: Bug > Environment: CentOs 7 (3.10.0-123.el7.x86_64), > JAVA: java version "1.7.0_65"; OpenJDK Runtime Environment (rhel-2.5.1.2.el7_0-x86_64 u65-b17); OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) > Apache Ant 1.9.2 > The whole system runs inside of a virtual box with 4GB RAM, 2 CPUs and 50GB Harddrive. > Reporter: Sebastian Goschin > Assignee: Brett Meyer > > After installing DTgov and S-RAMP at EAP 6.3 and before installing workflows and ontologies of DTgov 1.4 by "ant seed", the EAP 6.3 throws errors during startup. > 18:18:49,657 WARN [org.overlord.sramp.events.jms.JMSEventProducer] (ServerService Thread Pool -- 58) Could not discover "ConnectionFactory" and/or the configured topics/queues over JNDI. Assuming a non-EE environment or that JMS/JNDI isnt configured. Falling back on an embedded ActiveMQ broker, available on {0} > 18:18:50,196 INFO [org.apache.activemq.store.kahadb.plist.PListStoreImpl] (ServerService Thread Pool -- 58) PListStore:[/home/admin/activemq-data/localhost/tmp_storage] started > 18:18:50,201 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Using Persistence Adapter: KahaDBPersistenceAdapter[/home/admin/activemq-data/localhost/KahaDB] > 18:18:50,234 INFO [org.jboss.solder.exception.control.extension] (MSC service thread 1-4) Adding handler Qualifiers: [@javax.enterprise.inject.Any()] TraversalMode: BREADTH_FIRST Handles Type: class java.lang.Throwable Precedence: -100 [method] public org.jboss.seam.transaction.SimpleTransactionExceptionHandler.markTransactionRollback(CaughtException) to known handlers > 18:18:50,248 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:50,282 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:50,556 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.sramp.governance.workflow.jbpm.ProcessService.processBean > 18:18:50,560 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.jbpm.ProcessBean.processEngineService > 18:18:50,581 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.taskapi.TaskApi.processEngineService > 18:18:50,799 INFO [org.jboss.web] (ServerService Thread Pool -- 68) JBAS018210: Register web context: /dtgov > 18:18:51,107 INFO [solder-servlet] (ServerService Thread Pool -- 68) Catch Integration for Servlets enabled > 18:18:57,085 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) KahaDB is version 4 > 18:18:57,110 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovering from the journal ... > 18:18:57,111 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovery replayed 2 operations from the journal in 0.008 seconds. > 18:18:57,162 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) is starting > 18:18:57,176 INFO [org.apache.activemq.transport.TransportServerThreadSupport] (ServerService Thread Pool -- 58) Listening for connections at: tcp://localhost:61616 > 18:18:57,177 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector tcp://localhost:61616 Started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) For help or more information please see: http://activemq.apache.org > 18:18:57,178 WARN [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Store limit is 102400 mb, whilst the data directory: /home/admin/activemq-data/localhost/KahaDB only has 44079 mb of usable space > 18:18:57,179 ERROR [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Temporary Store limit is 51200 mb, whilst the temporary data directory: /home/admin/activemq-data/localhost/tmp_storage only has 44079 mb of usable space > 18:18:57,211 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:57,211 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:57,214 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:57,218 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector vm://localhost Started -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 04:42:11 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Fri, 10 Oct 2014 04:42:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-595) List of services can't be refreshed on EAP In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-595: --------------------------------- Summary: List of services can't be refreshed on EAP Key: RTGOV-595 URL: https://issues.jboss.org/browse/RTGOV-595 Project: RTGov (Run Time Governance) Issue Type: Bug Components: User Interface Affects Versions: 2.0.0.Final Environment: EAP 6.3 + switchyard 2.0.0.Alpha2 + rtgov 2.0.0.Final Reporter: Andrej Vano Assignee: Gary Brown Fix For: 2.1.0.Final If you access the services page, the deployed services are immediately listed correctly. When you hit the refresh button, the list of services can't be refreshed - it will hang on Finding services, please wait... (no result even after 2 mins) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 04:50:13 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Fri, 10 Oct 2014 04:50:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-596) UX: Overlord artwork not big enough for 1920x1080 In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-596: --------------------------------- Summary: UX: Overlord artwork not big enough for 1920x1080 Key: RTGOV-596 URL: https://issues.jboss.org/browse/RTGOV-596 Project: RTGov (Run Time Governance) Issue Type: Bug Components: User Interface Affects Versions: 2.0.0.Final Environment: firefox, chrome Reporter: Andrej Vano Assignee: Gary Brown Priority: Trivial Fix For: 2.1.0.Final The overlord artwork is not big enough for displays with resolution 1920x1080 (I think the standard resolution at the moment). See: http://oi61.tinypic.com/2ihqwpe.jpg -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 04:53:12 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 10 Oct 2014 04:53:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-595) List of services can't be refreshed on EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-595: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1151367 > List of services can't be refreshed on EAP > ------------------------------------------ > > Key: RTGOV-595 > URL: https://issues.jboss.org/browse/RTGOV-595 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Environment: EAP 6.3 + switchyard 2.0.0.Alpha2 + rtgov 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > If you access the services page, the deployed services are immediately listed correctly. When you hit the refresh button, the list of services can't be refreshed - it will hang on Finding services, please wait... (no result even after 2 mins) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 06:22:11 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 10 Oct 2014 06:22:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-155) UX: Overlord artwork not big enough for 1920x1080 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown moved RTGOV-596 to OVERLORD-155: ------------------------------------------- Project: Overlord (was: RTGov (Run Time Governance)) Key: OVERLORD-155 (was: RTGOV-596) Affects Version/s: Overlord-Commons-2.0.11.Final (was: 2.0.0.Final) Component/s: (was: User Interface) Fix Version/s: Overlord-Commons-2.0.12.Fina (was: 2.1.0.Final) > UX: Overlord artwork not big enough for 1920x1080 > ------------------------------------------------- > > Key: OVERLORD-155 > URL: https://issues.jboss.org/browse/OVERLORD-155 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.11.Final > Environment: firefox, chrome > Reporter: Andrej Vano > Assignee: Gary Brown > Priority: Trivial > Fix For: Overlord-Commons-2.0.12.Fina > > > The overlord artwork is not big enough for displays with resolution 1920x1080 (I think the standard resolution at the moment). See: http://oi61.tinypic.com/2ihqwpe.jpg -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 06:22:11 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 10 Oct 2014 06:22:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-155) UX: Overlord artwork not big enough for 1920x1080 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reassigned OVERLORD-155: ----------------------------------- Assignee: Eric Wittmann (was: Gary Brown) > UX: Overlord artwork not big enough for 1920x1080 > ------------------------------------------------- > > Key: OVERLORD-155 > URL: https://issues.jboss.org/browse/OVERLORD-155 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.11.Final > Environment: firefox, chrome > Reporter: Andrej Vano > Assignee: Eric Wittmann > Priority: Trivial > Fix For: Overlord-Commons-2.0.12.Fina > > > The overlord artwork is not big enough for displays with resolution 1920x1080 (I think the standard resolution at the moment). See: http://oi61.tinypic.com/2ihqwpe.jpg -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 07:30:12 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 10 Oct 2014 07:30:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-141) Ensure all Overlord JARs are marked as 'distributable' in web.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010589#comment-13010589 ] RH Bugzilla Integration commented on OVERLORD-141: -------------------------------------------------- Eric Wittmann changed the Status of [bug 1035296|https://bugzilla.redhat.com/show_bug.cgi?id=1035296] from NEW to MODIFIED > Ensure all Overlord JARs are marked as 'distributable' in web.xml > ----------------------------------------------------------------- > > Key: OVERLORD-141 > URL: https://issues.jboss.org/browse/OVERLORD-141 > Project: Overlord > Issue Type: Task > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.9.Final > > > While configuring a clustered server consisting of 2 FSW standalone servers, I needed to manually add tag to all design time governance web applications (there is 5 of them). > http://docs.jboss.org/jbossas/docs/Clustering_Guide/4/html/clustering-http-app.html > http://tomcat.apache.org/tomcat-6.0-doc/cluster-howto.html > This is a simple matter of adding the tag to all relevant web.xml files in all overlord web applications for all platforms: > overlord-commons-idp.war > s-ramp-server.war > s-ramp-ui.war > dtgov.war > dtgov-ui.war > rtgov.war > rtgov-ui.war -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 08:48:12 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Fri, 10 Oct 2014 08:48:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-595) List of services can't be refreshed on EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010618#comment-13010618 ] Andrej Vano commented on RTGOV-595: ----------------------------------- The same behaviour can be reproduced on fuse aswell > List of services can't be refreshed on EAP > ------------------------------------------ > > Key: RTGOV-595 > URL: https://issues.jboss.org/browse/RTGOV-595 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Environment: EAP 6.3 + switchyard 2.0.0.Alpha2 + rtgov 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > If you access the services page, the deployed services are immediately listed correctly. When you hit the refresh button, the list of services can't be refreshed - it will hang on Finding services, please wait... (no result even after 2 mins) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 08:50:12 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Fri, 10 Oct 2014 08:50:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-595) List of services can't be refreshed on EAP/Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrej Vano updated RTGOV-595: ------------------------------ Summary: List of services can't be refreshed on EAP/Fuse (was: List of services can't be refreshed on EAP) > List of services can't be refreshed on EAP/Fuse > ----------------------------------------------- > > Key: RTGOV-595 > URL: https://issues.jboss.org/browse/RTGOV-595 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Affects Versions: 2.0.0.Final > Environment: EAP 6.3 + switchyard 2.0.0.Alpha2 + rtgov 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > If you access the services page, the deployed services are immediately listed correctly. When you hit the refresh button, the list of services can't be refreshed - it will hang on Finding services, please wait... (no result even after 2 mins) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 10:39:12 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 10 Oct 2014 10:39:12 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-597) Exception when installing overlord-rtgov-samples-all-sla profile in fabric In-Reply-To: References: Message-ID: Gary Brown created RTGOV-597: -------------------------------- Summary: Exception when installing overlord-rtgov-samples-all-sla profile in fabric Key: RTGOV-597 URL: https://issues.jboss.org/browse/RTGOV-597 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: David virgil naranjo Fix For: 2.1.0.Final Installing the SLA sample causes the following exceptions when the container is being provisioned: {noformat} Provision Exception: io.fabric8.agent.utils.MultiException: Error updating agent at io.fabric8.agent.DeploymentAgent.install(DeploymentAgent.java:943) at io.fabric8.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:579) at io.fabric8.agent.DeploymentAgent$2.run(DeploymentAgent.java:304) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) org.osgi.framework.BundleException: Activator start error in bundle samples-karaf-sla-epn [367]. at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2437) at org.apache.felix.framework.Felix$7.call(Felix.java:2325) at org.apache.felix.framework.Felix.runInContext(Felix.java:2188) at org.apache.felix.framework.Felix.activateBundle(Felix.java:2323) at org.apache.felix.framework.Felix.startBundle(Felix.java:2090) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955) at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942) at io.fabric8.agent.DeploymentAgent.install(DeploymentAgent.java:936) at io.fabric8.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:579) at io.fabric8.agent.DeploymentAgent$2.run(DeploymentAgent.java:304) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.RuntimeException: Failed to register network at org.overlord.rtgov.epn.loader.osgi.EPNActivator.registerEPN(EPNActivator.java:121) at org.overlord.rtgov.epn.loader.osgi.EPNActivator$1.registered(EPNActivator.java:52) at org.overlord.rtgov.epn.loader.osgi.EPNActivator$1.registered(EPNActivator.java:48) at org.overlord.commons.services.OSGiServiceRegistry$ServiceListenerAdapter.init(OSGiServiceRegistry.java:305) at org.overlord.commons.services.OSGiServiceRegistry$ServiceListenerAdapter.(OSGiServiceRegistry.java:262) at org.overlord.commons.services.OSGiServiceRegistry.addServiceListener(OSGiServiceRegistry.java:222) at org.overlord.commons.services.CompositeServiceRegistry.addServiceListener(CompositeServiceRegistry.java:85) at org.overlord.commons.services.ServiceRegistryUtil.addServiceListener(ServiceRegistryUtil.java:60) at org.overlord.rtgov.epn.loader.osgi.EPNActivator.start(EPNActivator.java:61) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645) at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2387) ... 15 more Caused by: java.lang.Exception: Failed to load Drools rules 'SLAViolationDerived.drl' for Event Processor 'SLAViolationDerived' at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:347) at org.overlord.rtgov.ep.drools.DroolsEventProcessor.createSession(DroolsEventProcessor.java:244) at org.overlord.rtgov.ep.drools.DroolsEventProcessor.init(DroolsEventProcessor.java:90) at org.overlord.rtgov.epn.Node.init(Node.java:233) at org.overlord.rtgov.epn.Network.preInit(Network.java:202) at org.overlord.rtgov.epn.AbstractEPNLoader.preInit(AbstractEPNLoader.java:34) at org.overlord.rtgov.epn.loader.osgi.EPNActivator.registerEPN(EPNActivator.java:109) ... 25 more Caused by: java.lang.NoClassDefFoundError: org/drools/compiler/lang/DRL6Expressions$relationalExpression_scope at org.drools.compiler.lang.DRL6Expressions.relationalExpression(DRL6Expressions.java:2442) at org.drools.compiler.lang.DRL6Expressions.inExpression(DRL6Expressions.java:2280) at org.drools.compiler.lang.DRL6Expressions.instanceOfExpression(DRL6Expressions.java:2211) at org.drools.compiler.lang.DRL6Expressions.equalityExpression(DRL6Expressions.java:2111) at org.drools.compiler.lang.DRL6Expressions.andExpression(DRL6Expressions.java:2042) at org.drools.compiler.lang.DRL6Expressions.exclusiveOrExpression(DRL6Expressions.java:1974) at org.drools.compiler.lang.DRL6Expressions.inclusiveOrExpression(DRL6Expressions.java:1906) at org.drools.compiler.lang.DRL6Expressions.conditionalAndExpression(DRL6Expressions.java:1817) at org.drools.compiler.lang.DRL6Expressions.conditionalOrExpression(DRL6Expressions.java:1727) at org.drools.compiler.lang.DRL6Parser.constraint(DRL6Parser.java:3482) at org.drools.compiler.lang.DRL6Parser.positionalConstraints(DRL6Parser.java:3397) at org.drools.compiler.lang.DRL6Parser.speculatePositionalConstraints(DRL6Parser.java:3379) at org.drools.compiler.lang.DRL6Parser.lhsPattern(DRL6Parser.java:3288) at org.drools.compiler.lang.DRL6Parser.lhsPatternBind(DRL6Parser.java:3038) at org.drools.compiler.lang.DRL6Parser.lhsUnary(DRL6Parser.java:2367) at org.drools.compiler.lang.DRL6Parser.lhsAnd(DRL6Parser.java:2261) at org.drools.compiler.lang.DRL6Parser.lhsOr(DRL6Parser.java:2117) at org.drools.compiler.lang.DRL6Parser.lhsExpression(DRL6Parser.java:2016) at org.drools.compiler.lang.DRL6Parser.lhs(DRL6Parser.java:1992) at org.drools.compiler.lang.DRL6Parser.rule(DRL6Parser.java:1323) at org.drools.compiler.lang.DRL6Parser.statement(DRL6Parser.java:230) at org.drools.compiler.lang.DRL6Parser.compilationUnit(DRL6Parser.java:110) at org.drools.compiler.lang.AbstractDRLParser.compilationUnit(AbstractDRLParser.java:86) at org.drools.compiler.compiler.DrlParser.compile(DrlParser.java:238) at org.drools.compiler.compiler.DrlParser.parse(DrlParser.java:155) at org.drools.compiler.compiler.DrlParser.parse(DrlParser.java:144) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.drlToPackageDescr(KnowledgeBuilderImpl.java:409) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$1.map(CompositeKnowledgeBuilderImpl.java:443) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildResource(CompositeKnowledgeBuilderImpl.java:368) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackageDescr(CompositeKnowledgeBuilderImpl.java:351) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:100) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:91) at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:220) at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:43) at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:208) at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:177) at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:316) ... 31 more Caused by: java.lang.ClassNotFoundException: Unable to load class 'org.drools.compiler.lang.DRL6Expressions$relationalExpression_scope' because the bundle wiring for org.drools.compiler is no longer valid. at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1494) at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 68 more {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 10:51:13 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 10 Oct 2014 10:51:13 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-591) Support Fabric deployment using karaf commands In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-591: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/224 > Support Fabric deployment using karaf commands > ---------------------------------------------- > > Key: RTGOV-591 > URL: https://issues.jboss.org/browse/RTGOV-591 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Support Fuse/Fabric deployment using karaf commands -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 10:51:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 10 Oct 2014 10:51:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-591) Support Fabric deployment using karaf commands In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-591. ------------------------------ Resolution: Done Thanks David. > Support Fabric deployment using karaf commands > ---------------------------------------------- > > Key: RTGOV-591 > URL: https://issues.jboss.org/browse/RTGOV-591 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Support Fuse/Fabric deployment using karaf commands -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 10 12:16:11 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 10 Oct 2014 12:16:11 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-597) Exception when installing overlord-rtgov-samples-all-sla profile in fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010776#comment-13010776 ] Gary Brown commented on RTGOV-597: ---------------------------------- Even when installing the SLA sample at the same time as the others, it does not work - although this time the console just showed "Provision Status: finalizing" and no additional information logged. Command used was: fabric:container-add-profile child overlord-rtgov-all overlord-rtgov-samples-all-ordermgmt overlord-rtgov-samples-all-sla > Exception when installing overlord-rtgov-samples-all-sla profile in fabric > -------------------------------------------------------------------------- > > Key: RTGOV-597 > URL: https://issues.jboss.org/browse/RTGOV-597 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 2.1.0.Final > > > Installing the SLA sample causes the following exceptions when the container is being provisioned: > {noformat} > Provision Exception: > io.fabric8.agent.utils.MultiException: Error updating agent > at io.fabric8.agent.DeploymentAgent.install(DeploymentAgent.java:943) > at io.fabric8.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:579) > at io.fabric8.agent.DeploymentAgent$2.run(DeploymentAgent.java:304) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > org.osgi.framework.BundleException: Activator start error in bundle samples-karaf-sla-epn [367]. > at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2437) > at org.apache.felix.framework.Felix$7.call(Felix.java:2325) > at org.apache.felix.framework.Felix.runInContext(Felix.java:2188) > at org.apache.felix.framework.Felix.activateBundle(Felix.java:2323) > at org.apache.felix.framework.Felix.startBundle(Felix.java:2090) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955) > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942) > at io.fabric8.agent.DeploymentAgent.install(DeploymentAgent.java:936) > at io.fabric8.agent.DeploymentAgent.doUpdate(DeploymentAgent.java:579) > at io.fabric8.agent.DeploymentAgent$2.run(DeploymentAgent.java:304) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > Caused by: java.lang.RuntimeException: Failed to register network > at org.overlord.rtgov.epn.loader.osgi.EPNActivator.registerEPN(EPNActivator.java:121) > at org.overlord.rtgov.epn.loader.osgi.EPNActivator$1.registered(EPNActivator.java:52) > at org.overlord.rtgov.epn.loader.osgi.EPNActivator$1.registered(EPNActivator.java:48) > at org.overlord.commons.services.OSGiServiceRegistry$ServiceListenerAdapter.init(OSGiServiceRegistry.java:305) > at org.overlord.commons.services.OSGiServiceRegistry$ServiceListenerAdapter.(OSGiServiceRegistry.java:262) > at org.overlord.commons.services.OSGiServiceRegistry.addServiceListener(OSGiServiceRegistry.java:222) > at org.overlord.commons.services.CompositeServiceRegistry.addServiceListener(CompositeServiceRegistry.java:85) > at org.overlord.commons.services.ServiceRegistryUtil.addServiceListener(ServiceRegistryUtil.java:60) > at org.overlord.rtgov.epn.loader.osgi.EPNActivator.start(EPNActivator.java:61) > at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:645) > at org.apache.felix.framework.Felix.doActivateBundle(Felix.java:2387) > ... 15 more > Caused by: java.lang.Exception: Failed to load Drools rules 'SLAViolationDerived.drl' for Event Processor 'SLAViolationDerived' > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:347) > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.createSession(DroolsEventProcessor.java:244) > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.init(DroolsEventProcessor.java:90) > at org.overlord.rtgov.epn.Node.init(Node.java:233) > at org.overlord.rtgov.epn.Network.preInit(Network.java:202) > at org.overlord.rtgov.epn.AbstractEPNLoader.preInit(AbstractEPNLoader.java:34) > at org.overlord.rtgov.epn.loader.osgi.EPNActivator.registerEPN(EPNActivator.java:109) > ... 25 more > Caused by: java.lang.NoClassDefFoundError: org/drools/compiler/lang/DRL6Expressions$relationalExpression_scope > at org.drools.compiler.lang.DRL6Expressions.relationalExpression(DRL6Expressions.java:2442) > at org.drools.compiler.lang.DRL6Expressions.inExpression(DRL6Expressions.java:2280) > at org.drools.compiler.lang.DRL6Expressions.instanceOfExpression(DRL6Expressions.java:2211) > at org.drools.compiler.lang.DRL6Expressions.equalityExpression(DRL6Expressions.java:2111) > at org.drools.compiler.lang.DRL6Expressions.andExpression(DRL6Expressions.java:2042) > at org.drools.compiler.lang.DRL6Expressions.exclusiveOrExpression(DRL6Expressions.java:1974) > at org.drools.compiler.lang.DRL6Expressions.inclusiveOrExpression(DRL6Expressions.java:1906) > at org.drools.compiler.lang.DRL6Expressions.conditionalAndExpression(DRL6Expressions.java:1817) > at org.drools.compiler.lang.DRL6Expressions.conditionalOrExpression(DRL6Expressions.java:1727) > at org.drools.compiler.lang.DRL6Parser.constraint(DRL6Parser.java:3482) > at org.drools.compiler.lang.DRL6Parser.positionalConstraints(DRL6Parser.java:3397) > at org.drools.compiler.lang.DRL6Parser.speculatePositionalConstraints(DRL6Parser.java:3379) > at org.drools.compiler.lang.DRL6Parser.lhsPattern(DRL6Parser.java:3288) > at org.drools.compiler.lang.DRL6Parser.lhsPatternBind(DRL6Parser.java:3038) > at org.drools.compiler.lang.DRL6Parser.lhsUnary(DRL6Parser.java:2367) > at org.drools.compiler.lang.DRL6Parser.lhsAnd(DRL6Parser.java:2261) > at org.drools.compiler.lang.DRL6Parser.lhsOr(DRL6Parser.java:2117) > at org.drools.compiler.lang.DRL6Parser.lhsExpression(DRL6Parser.java:2016) > at org.drools.compiler.lang.DRL6Parser.lhs(DRL6Parser.java:1992) > at org.drools.compiler.lang.DRL6Parser.rule(DRL6Parser.java:1323) > at org.drools.compiler.lang.DRL6Parser.statement(DRL6Parser.java:230) > at org.drools.compiler.lang.DRL6Parser.compilationUnit(DRL6Parser.java:110) > at org.drools.compiler.lang.AbstractDRLParser.compilationUnit(AbstractDRLParser.java:86) > at org.drools.compiler.compiler.DrlParser.compile(DrlParser.java:238) > at org.drools.compiler.compiler.DrlParser.parse(DrlParser.java:155) > at org.drools.compiler.compiler.DrlParser.parse(DrlParser.java:144) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.drlToPackageDescr(KnowledgeBuilderImpl.java:409) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl$1.map(CompositeKnowledgeBuilderImpl.java:443) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildResource(CompositeKnowledgeBuilderImpl.java:368) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackageDescr(CompositeKnowledgeBuilderImpl.java:351) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:100) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:91) > at org.drools.compiler.kie.builder.impl.AbstractKieModule.buildKnowledgePackages(AbstractKieModule.java:220) > at org.drools.compiler.kie.builder.impl.AbstractKieProject.verify(AbstractKieProject.java:43) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildKieProject(KieBuilderImpl.java:208) > at org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:177) > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:316) > ... 31 more > Caused by: java.lang.ClassNotFoundException: Unable to load class 'org.drools.compiler.lang.DRL6Expressions$relationalExpression_scope' because the bundle wiring for org.drools.compiler is no longer valid. > at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1494) > at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:75) > at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1955) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > ... 68 more > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 03:20:35 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Mon, 13 Oct 2014 03:20:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-598) Fuse: Missing SwitchYardServicesProvider.serverURLs property in overlord-rtgov.properties In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-598: --------------------------------- Summary: Fuse: Missing SwitchYardServicesProvider.serverURLs property in overlord-rtgov.properties Key: RTGOV-598 URL: https://issues.jboss.org/browse/RTGOV-598 Project: RTGov (Run Time Governance) Issue Type: Bug Affects Versions: 2.0.0.Final Environment: fuse Reporter: Andrej Vano Assignee: Gary Brown Fix For: 2.1.0.Final The configuration of switchyard-remote endpoint is missing in fuse - it is causing "ConnectionException: Connection refused" when trying to resubmit the message from the UI. The url should be: http://localhost:8181/switchyard-remote -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 03:23:36 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 13 Oct 2014 03:23:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-598) Fuse: Missing SwitchYardServicesProvider.serverURLs property in overlord-rtgov.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-598: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1151949 > Fuse: Missing SwitchYardServicesProvider.serverURLs property in overlord-rtgov.properties > ----------------------------------------------------------------------------------------- > > Key: RTGOV-598 > URL: https://issues.jboss.org/browse/RTGOV-598 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Affects Versions: 2.0.0.Final > Environment: fuse > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The configuration of switchyard-remote endpoint is missing in fuse - it is causing "ConnectionException: Connection refused" when trying to resubmit the message from the UI. > The url should be: http://localhost:8181/switchyard-remote -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 03:31:35 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Mon, 13 Oct 2014 03:31:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-599) Fuse: resubmit is always successful In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-599: --------------------------------- Summary: Fuse: resubmit is always successful Key: RTGOV-599 URL: https://issues.jboss.org/browse/RTGOV-599 Project: RTGov (Run Time Governance) Issue Type: Bug Affects Versions: 2.0.0.Final Environment: fuse with added property from RTGOV-598 Reporter: Andrej Vano Assignee: Gary Brown Fix For: 2.1.0.Final Adding the property from RTGOV-598 solves the problem with "Connection Refused", but the resubmitted message will always success even if you resubmit the same message that caused the error. This resubmitted request is probably not sent successfully because it is not generating any additional situations -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 03:34:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 13 Oct 2014 03:34:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-599) Fuse: resubmit is always successful In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-599: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1151951 > Fuse: resubmit is always successful > ----------------------------------- > > Key: RTGOV-599 > URL: https://issues.jboss.org/browse/RTGOV-599 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Affects Versions: 2.0.0.Final > Environment: fuse with added property from RTGOV-598 > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Adding the property from RTGOV-598 solves the problem with "Connection Refused", but the resubmitted message will always success even if you resubmit the same message that caused the error. > This resubmitted request is probably not sent successfully because it is not generating any additional situations -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 05:34:35 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Mon, 13 Oct 2014 05:34:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-592) Credentials and server url are hardcoded in s-ramp tests In-Reply-To: References: Message-ID: Stefan Bunciak created SRAMP-592: ------------------------------------ Summary: Credentials and server url are hardcoded in s-ramp tests Key: SRAMP-592 URL: https://issues.jboss.org/browse/SRAMP-592 Project: S-RAMP Issue Type: Bug Affects Versions: 0.6.0.Final Reporter: Stefan Bunciak Assignee: Stefan Bunciak Priority: Minor Fix For: 0.7.0.Final -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 06:24:35 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Mon, 13 Oct 2014 06:24:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-592) Credentials and server url are hardcoded in s-ramp tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bunciak updated SRAMP-592: --------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/501 > Credentials and server url are hardcoded in s-ramp tests > -------------------------------------------------------- > > Key: SRAMP-592 > URL: https://issues.jboss.org/browse/SRAMP-592 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Stefan Bunciak > Priority: Minor > Fix For: 0.7.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 08:11:35 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Mon, 13 Oct 2014 08:11:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-600) Fuse: posting activities via REST result in org.jboss.resteasy.spi.BadRequestException In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-600: --------------------------------- Summary: Fuse: posting activities via REST result in org.jboss.resteasy.spi.BadRequestException Key: RTGOV-600 URL: https://issues.jboss.org/browse/RTGOV-600 Project: RTGov (Run Time Governance) Issue Type: Bug Affects Versions: 2.0.0.Final Environment: fuse + switchyard 2.0.0.Alpha3 + rtgov 2.0.0.Final Reporter: Andrej Vano Assignee: Gary Brown Fix For: 2.1.0.Final Sending activities manually results in org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: java.util.List of content type: application/json Full stack trace is here: http://pastebin.test.redhat.com/239538 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 08:13:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 13 Oct 2014 08:13:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-600) Fuse: posting activities via REST result in org.jboss.resteasy.spi.BadRequestException In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-600: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1152051 > Fuse: posting activities via REST result in org.jboss.resteasy.spi.BadRequestException > -------------------------------------------------------------------------------------- > > Key: RTGOV-600 > URL: https://issues.jboss.org/browse/RTGOV-600 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Affects Versions: 2.0.0.Final > Environment: fuse + switchyard 2.0.0.Alpha3 + rtgov 2.0.0.Final > Reporter: Andrej Vano > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Sending activities manually results in org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: java.util.List of content type: application/json > Full stack trace is here: http://pastebin.test.redhat.com/239538 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 08:53:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 13 Oct 2014 08:53:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-593) GWT exception when no network connection available In-Reply-To: References: Message-ID: Gary Brown created SRAMP-593: -------------------------------- Summary: GWT exception when no network connection available Key: SRAMP-593 URL: https://issues.jboss.org/browse/SRAMP-593 Project: S-RAMP Issue Type: Bug Affects Versions: 0.6.0.Final Reporter: Gary Brown Assignee: Brett Meyer After starting up a freshly seeded EAP server, accessed the UI and selected overlord.demo.SimpleReleaseProcess.bpmn. This resulted in an error dialog being displayed with: "Uncaught GWT Error! Exception caught: Exception caught: Exception caught: (TypeError) : Cannot read property 'edit' of undefined" At the time my network connection was disabled. When I later tried the UI again with my network connection enabled, it worked fine. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 08:56:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 13 Oct 2014 08:56:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-594) s-ramp:getMetaData command returns npe In-Reply-To: References: Message-ID: Gary Brown created SRAMP-594: -------------------------------- Summary: s-ramp:getMetaData command returns npe Key: SRAMP-594 URL: https://issues.jboss.org/browse/SRAMP-594 Project: S-RAMP Issue Type: Bug Affects Versions: 0.6.0.Final Reporter: Gary Brown Assignee: Brett Meyer After working through section 7 in the user guide, I had set the description property on an artifact and then exited the cli. When I went back into the console and connected, I then issued the command: s-ramp:getMetaData feed:15 and got: {noformat} java.lang.NullPointerException at org.overlord.sramp.shell.commands.core.GetMetaDataCommand.execute(GetMetaDataCommand.java:71) at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:103) at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.simontuffs.onejar.Boot.run(Boot.java:340) at com.simontuffs.onejar.Boot.main(Boot.java:166) {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 11:06:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 13 Oct 2014 11:06:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-592) Credentials and server url are hardcoded in s-ramp tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-592. ------------------------------- Resolution: Done > Credentials and server url are hardcoded in s-ramp tests > -------------------------------------------------------- > > Key: SRAMP-592 > URL: https://issues.jboss.org/browse/SRAMP-592 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Stefan Bunciak > Priority: Minor > Fix For: 0.7.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 15:01:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 13 Oct 2014 15:01:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-595) Support content encoding value on atom:content In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-595: --------------------------------- Summary: Support content encoding value on atom:content Key: SRAMP-595 URL: https://issues.jboss.org/browse/SRAMP-595 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer The atom:content mapping must support something like: {code}type="application/xml; charset=utf-8"{code} If, for example, XmlDocument#contentEncoding is set to "utf-8", append that to atom:content. If present when an Entry is posted, know how to split up the value and set both contentType and contentEncoding. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 13 15:52:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 13 Oct 2014 15:52:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-596) Set urn:x-s-ramp:2013:kind atom category In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-596: --------------------------------- Summary: Set urn:x-s-ramp:2013:kind atom category Key: SRAMP-596 URL: https://issues.jboss.org/browse/SRAMP-596 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer urn:x-s-ramp:2013:kind Indicates the kind of the entry Occurs in Artifact Entry, Relationship Target Entry, Relationship Type Entry, and Property Entry documents, except as noted below. Legal values for the term attribute are "derived" Indicates entry is part of a Derived Model "modeled" Indicates entry is pre-defined and is part of the SOA or Service Implementation Models or is part of an extended artifact model "generic" Indicates entry is ad-hoc Does not occur in Artifact Entry documents. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 14 06:46:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 14 Oct 2014 06:46:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-592) Credentials and server url are hardcoded in s-ramp tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-592: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1152512 > Credentials and server url are hardcoded in s-ramp tests > -------------------------------------------------------- > > Key: SRAMP-592 > URL: https://issues.jboss.org/browse/SRAMP-592 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Stefan Bunciak > Priority: Minor > Fix For: 0.7.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 14 12:08:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 14 Oct 2014 12:08:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-465) Investigate alternative methods for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-465: ------------------------------ Description: Investigate increased automatic artifact relationships (ie, service A depends on service B), useful for impact analysis. Possibly include Java-specific improvements, such as custom annotations (and scanning). was:Investigate increased automatic artifact relationships (ie, service A depends on service B), useful for impact analysis. Possibly include Java-specific improvements, such as custom annotations (and scanning). > Investigate alternative methods for relationship resolution > ----------------------------------------------------------- > > Key: SRAMP-465 > URL: https://issues.jboss.org/browse/SRAMP-465 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Investigate increased automatic artifact relationships (ie, service A depends on service B), useful for impact analysis. Possibly include Java-specific improvements, such as custom annotations (and scanning). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 14 12:09:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 14 Oct 2014 12:09:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-465) Investigate alternative methods for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011666#comment-13011666 ] Brett Meyer commented on SRAMP-465: ----------------------------------- Currently, if you manually uploaded a WsdlDocument, then uploaded a WAR that contained that exact same WSDL, you'd get duplicate WsdlDocuments. The same is true if you upload 2 WARs with the same WSDLs within them. One improvement could be checking hashes to see if the exact artifact already exists, then reusing it in the relationships. > Investigate alternative methods for relationship resolution > ----------------------------------------------------------- > > Key: SRAMP-465 > URL: https://issues.jboss.org/browse/SRAMP-465 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Investigate increased automatic artifact relationships (ie, service A depends on service B), useful for impact analysis. Possibly include Java-specific improvements, such as custom annotations (and scanning). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 14 12:19:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 14 Oct 2014 12:19:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-597) Finish supporting/testing EAP domain mode In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-597: --------------------------------- Summary: Finish supporting/testing EAP domain mode Key: SRAMP-597 URL: https://issues.jboss.org/browse/SRAMP-597 Project: S-RAMP Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer SRAMP-394 started this process, but testing ran into issues that were never documented or researched. Pick the task back up. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 14 12:41:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 14 Oct 2014 12:41:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-592) Credentials and server url are hardcoded in s-ramp tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13011687#comment-13011687 ] RH Bugzilla Integration commented on SRAMP-592: ----------------------------------------------- Brett Meyer changed the Status of [bug 1152512|https://bugzilla.redhat.com/show_bug.cgi?id=1152512] from NEW to MODIFIED > Credentials and server url are hardcoded in s-ramp tests > -------------------------------------------------------- > > Key: SRAMP-592 > URL: https://issues.jboss.org/browse/SRAMP-592 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Stefan Bunciak > Priority: Minor > Fix For: 0.7.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 10:03:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 10:03:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-601) Enforcer issues in org.overlord.rtgov.activity-management:activity In-Reply-To: References: Message-ID: Brett Meyer created RTGOV-601: --------------------------------- Summary: Enforcer issues in org.overlord.rtgov.activity-management:activity Key: RTGOV-601 URL: https://issues.jboss.org/browse/RTGOV-601 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Brett Meyer Assignee: Gary Brown After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the module. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 10:41:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 10:41:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-601) Enforcer issues in multiple modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated RTGOV-601: ------------------------------ Summary: Enforcer issues in multiple modules (was: Enforcer issues in org.overlord.rtgov.activity-management:activity) > Enforcer issues in multiple modules > ----------------------------------- > > Key: RTGOV-601 > URL: https://issues.jboss.org/browse/RTGOV-601 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Gary Brown > > After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: > {code} > [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] > [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > +=======================+ > |VULNERABILITY DETECTED!| > +=======================+ > For more information visit: > - https://access.redhat.com/security/cve/CVE-2009-2625 > {code} > What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. > For now, enforcer is completely disabled on the module. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 10:42:37 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 10:42:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-601) Enforcer issues in multiple modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated RTGOV-601: ------------------------------ Description: org.overlord.rtgov.activity-management:activity org.overlord.rtgov.integration:rtgov-switchyard After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the module. was: After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the module. > Enforcer issues in multiple modules > ----------------------------------- > > Key: RTGOV-601 > URL: https://issues.jboss.org/browse/RTGOV-601 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Gary Brown > > org.overlord.rtgov.activity-management:activity > org.overlord.rtgov.integration:rtgov-switchyard > After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: > {code} > [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] > [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > +=======================+ > |VULNERABILITY DETECTED!| > +=======================+ > For more information visit: > - https://access.redhat.com/security/cve/CVE-2009-2625 > {code} > What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. > For now, enforcer is completely disabled on the module. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 10:50:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 10:50:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-601) Enforcer issues in multiple modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated RTGOV-601: ------------------------------ Description: org.overlord.rtgov.activity-management:activity org.overlord.rtgov.integration:rtgov-switchyard After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the listed modules. was: org.overlord.rtgov.activity-management:activity org.overlord.rtgov.integration:rtgov-switchyard After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the module. > Enforcer issues in multiple modules > ----------------------------------- > > Key: RTGOV-601 > URL: https://issues.jboss.org/browse/RTGOV-601 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Gary Brown > > org.overlord.rtgov.activity-management:activity > org.overlord.rtgov.integration:rtgov-switchyard > After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: > {code} > [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] > [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > +=======================+ > |VULNERABILITY DETECTED!| > +=======================+ > For more information visit: > - https://access.redhat.com/security/cve/CVE-2009-2625 > {code} > What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. > For now, enforcer is completely disabled on the listed modules. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 11:31:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 11:31:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-601) Enforcer issues in multiple modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated RTGOV-601: ------------------------------ Description: org.overlord.rtgov.activity-management:activity org.overlord.rtgov.integration:rtgov-switchyard org.overlord.rtgov.distribution:overlord-rtgov-features-fuse6 After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the listed modules. was: org.overlord.rtgov.activity-management:activity org.overlord.rtgov.integration:rtgov-switchyard After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the listed modules. > Enforcer issues in multiple modules > ----------------------------------- > > Key: RTGOV-601 > URL: https://issues.jboss.org/browse/RTGOV-601 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Gary Brown > > org.overlord.rtgov.activity-management:activity > org.overlord.rtgov.integration:rtgov-switchyard > org.overlord.rtgov.distribution:overlord-rtgov-features-fuse6 > After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: > {code} > [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] > [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > +=======================+ > |VULNERABILITY DETECTED!| > +=======================+ > For more information visit: > - https://access.redhat.com/security/cve/CVE-2009-2625 > {code} > What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. > For now, enforcer is completely disabled on the listed modules. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 11:35:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 11:35:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-601) Enforcer issues in multiple modules In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated RTGOV-601: ------------------------------ Description: org.overlord.rtgov.activity-management:activity org.overlord.rtgov.integration:rtgov-switchyard org.overlord.rtgov.distribution:overlord-rtgov-features-fuse6 org.overlord.rtgov.ui:overlord-rtgov-ui-dev-server After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the listed modules. was: org.overlord.rtgov.activity-management:activity org.overlord.rtgov.integration:rtgov-switchyard org.overlord.rtgov.distribution:overlord-rtgov-features-fuse6 After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: {code} [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: +=======================+ |VULNERABILITY DETECTED!| +=======================+ For more information visit: - https://access.redhat.com/security/cve/CVE-2009-2625 {code} What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. For now, enforcer is completely disabled on the listed modules. > Enforcer issues in multiple modules > ----------------------------------- > > Key: RTGOV-601 > URL: https://issues.jboss.org/browse/RTGOV-601 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Gary Brown > > org.overlord.rtgov.activity-management:activity > org.overlord.rtgov.integration:rtgov-switchyard > org.overlord.rtgov.distribution:overlord-rtgov-features-fuse6 > org.overlord.rtgov.ui:overlord-rtgov-ui-dev-server > After upgrading to the BOM CR14, enforcer fails, but no actual errors are shown during the build. The only thing relevant I can find: > {code} > [WARNING] The dependency xercesImpl-2.9.1 matches a vulnerability recorded in the victims database. [CVE-2009-2625] > [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > +=======================+ > |VULNERABILITY DETECTED!| > +=======================+ > For more information visit: > - https://access.redhat.com/security/cve/CVE-2009-2625 > {code} > What's odd is that we don't explicitly depend on xercesImpl. I'm not sure if that's a bug in the plugin: failing due to a warning on a transitive dependency. > For now, enforcer is completely disabled on the listed modules. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 14:19:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 14:19:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-591) Default EAP 6.3 Installation throws ERROR:Naming context is read-only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012303#comment-13012303 ] Brett Meyer commented on SRAMP-591: ----------------------------------- Leaving this open to investigate whether or not embedded ActiveMQ will actually work on EAP if standalone is used. > Default EAP 6.3 Installation throws ERROR:Naming context is read-only > --------------------------------------------------------------------- > > Key: SRAMP-591 > URL: https://issues.jboss.org/browse/SRAMP-591 > Project: S-RAMP > Issue Type: Bug > Environment: CentOs 7 (3.10.0-123.el7.x86_64), > JAVA: java version "1.7.0_65"; OpenJDK Runtime Environment (rhel-2.5.1.2.el7_0-x86_64 u65-b17); OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) > Apache Ant 1.9.2 > The whole system runs inside of a virtual box with 4GB RAM, 2 CPUs and 50GB Harddrive. > Reporter: Sebastian Goschin > Assignee: Brett Meyer > > After installing DTgov and S-RAMP at EAP 6.3 and before installing workflows and ontologies of DTgov 1.4 by "ant seed", the EAP 6.3 throws errors during startup. > 18:18:49,657 WARN [org.overlord.sramp.events.jms.JMSEventProducer] (ServerService Thread Pool -- 58) Could not discover "ConnectionFactory" and/or the configured topics/queues over JNDI. Assuming a non-EE environment or that JMS/JNDI isnt configured. Falling back on an embedded ActiveMQ broker, available on {0} > 18:18:50,196 INFO [org.apache.activemq.store.kahadb.plist.PListStoreImpl] (ServerService Thread Pool -- 58) PListStore:[/home/admin/activemq-data/localhost/tmp_storage] started > 18:18:50,201 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Using Persistence Adapter: KahaDBPersistenceAdapter[/home/admin/activemq-data/localhost/KahaDB] > 18:18:50,234 INFO [org.jboss.solder.exception.control.extension] (MSC service thread 1-4) Adding handler Qualifiers: [@javax.enterprise.inject.Any()] TraversalMode: BREADTH_FIRST Handles Type: class java.lang.Throwable Precedence: -100 [method] public org.jboss.seam.transaction.SimpleTransactionExceptionHandler.markTransactionRollback(CaughtException) to known handlers > 18:18:50,248 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:50,282 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:50,556 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.sramp.governance.workflow.jbpm.ProcessService.processBean > 18:18:50,560 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.jbpm.ProcessBean.processEngineService > 18:18:50,581 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.taskapi.TaskApi.processEngineService > 18:18:50,799 INFO [org.jboss.web] (ServerService Thread Pool -- 68) JBAS018210: Register web context: /dtgov > 18:18:51,107 INFO [solder-servlet] (ServerService Thread Pool -- 68) Catch Integration for Servlets enabled > 18:18:57,085 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) KahaDB is version 4 > 18:18:57,110 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovering from the journal ... > 18:18:57,111 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovery replayed 2 operations from the journal in 0.008 seconds. > 18:18:57,162 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) is starting > 18:18:57,176 INFO [org.apache.activemq.transport.TransportServerThreadSupport] (ServerService Thread Pool -- 58) Listening for connections at: tcp://localhost:61616 > 18:18:57,177 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector tcp://localhost:61616 Started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) For help or more information please see: http://activemq.apache.org > 18:18:57,178 WARN [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Store limit is 102400 mb, whilst the data directory: /home/admin/activemq-data/localhost/KahaDB only has 44079 mb of usable space > 18:18:57,179 ERROR [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Temporary Store limit is 51200 mb, whilst the temporary data directory: /home/admin/activemq-data/localhost/tmp_storage only has 44079 mb of usable space > 18:18:57,211 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:57,211 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:57,214 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:57,218 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector vm://localhost Started -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 16:55:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 16:55:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-598) Use 403 response if artifact published to the wrong endpoint In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-598: --------------------------------- Summary: Use 403 response if artifact published to the wrong endpoint Key: SRAMP-598 URL: https://issues.jboss.org/browse/SRAMP-598 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} The server currently throws back a 500 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 17:14:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 17:14:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-598) Improve error condition handling and map to applicable HTTP response codes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-598: ------------------------------ Description: {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} The server currently throws back 500 responses was: {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} The server currently throws back a 500 > Improve error condition handling and map to applicable HTTP response codes > -------------------------------------------------------------------------- > > Key: SRAMP-598 > URL: https://issues.jboss.org/browse/SRAMP-598 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} > {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} > The server currently throws back 500 responses -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 17:14:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 17:14:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-598) Improve error condition handling and map to applicable HTTP response codes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-598: ------------------------------ Summary: Improve error condition handling and map to applicable HTTP response codes (was: Use 403 response if artifact published to the wrong endpoint) > Improve error condition handling and map to applicable HTTP response codes > -------------------------------------------------------------------------- > > Key: SRAMP-598 > URL: https://issues.jboss.org/browse/SRAMP-598 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} > The server currently throws back a 500 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 17:18:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 17:18:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-598) Improve error condition handling and map to applicable HTTP response codes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-598: ------------------------------ Description: {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} {quote}If the artifact being edited is not in the repository at the time of the PUT, then the server SHALL return an HTTP error code of "404" indicating a Not Found.{quote} The server currently throws back 500 responses was: {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} The server currently throws back 500 responses > Improve error condition handling and map to applicable HTTP response codes > -------------------------------------------------------------------------- > > Key: SRAMP-598 > URL: https://issues.jboss.org/browse/SRAMP-598 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} > {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} > {quote}If the artifact being edited is not in the repository at the time of the PUT, then the server SHALL return an HTTP error code of "404" indicating a Not Found.{quote} > The server currently throws back 500 responses -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 17:22:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 17:22:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-541) Tighten the restrictions on artifact content updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13012343#comment-13012343 ] Brett Meyer commented on SRAMP-541: ----------------------------------- Another thing to consider is that users may need to first create the metadata, then update the content, rather than solely using the multipart upload. Both methods are required by the spec, so removing the ability to update content probably can't happen, period. > Tighten the restrictions on artifact content updates > ---------------------------------------------------- > > Key: SRAMP-541 > URL: https://issues.jboss.org/browse/SRAMP-541 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > The restrictions on updateContent need beefed up. See the discussion on https://community.jboss.org/message/884381. > At a minimum, the spec states that: > "Documents which have a Derived Model associated with them cannot be updated in the repository. They must be removed and republished." -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 17:24:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 17:24:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-541) Tighten the restrictions on artifact content updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-541: ------------------------------ Comment: was deleted (was: Another thing to consider is that users may need to first create the metadata, then update the content, rather than solely using the multipart upload. Both methods are required by the spec, so removing the ability to update content probably can't happen, period.) > Tighten the restrictions on artifact content updates > ---------------------------------------------------- > > Key: SRAMP-541 > URL: https://issues.jboss.org/browse/SRAMP-541 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > The restrictions on updateContent need beefed up. See the discussion on https://community.jboss.org/message/884381. > At a minimum, the spec states that: > "Documents which have a Derived Model associated with them cannot be updated in the repository. They must be removed and republished." -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 15 18:09:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 15 Oct 2014 18:09:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-598) Improve error condition handling and map to applicable HTTP response codes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-598: ------------------------------ Description: {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} {quote}If the artifact being edited is not in the repository at the time of the PUT, then the server SHALL return an HTTP error code of "404" indicating a Not Found.{quote} {quote}Requests to retrieve an Artifact Entry document from the incorrect Artifact Type Model will result an HTTP "404" Not Found.{quote} The server currently throws back 500 responses was: {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} {quote}If the artifact being edited is not in the repository at the time of the PUT, then the server SHALL return an HTTP error code of "404" indicating a Not Found.{quote} The server currently throws back 500 responses > Improve error condition handling and map to applicable HTTP response codes > -------------------------------------------------------------------------- > > Key: SRAMP-598 > URL: https://issues.jboss.org/browse/SRAMP-598 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} > {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} > {quote}If the artifact being edited is not in the repository at the time of the PUT, then the server SHALL return an HTTP error code of "404" indicating a Not Found.{quote} > {quote}Requests to retrieve an Artifact Entry document from the incorrect Artifact Type Model will result an HTTP "404" Not Found.{quote} > The server currently throws back 500 responses -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 16 05:08:35 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Thu, 16 Oct 2014 05:08:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-602) Fuse: Querying Graph Dependency via REST fails with ClassNotFoundException In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-602: --------------------------------- Summary: Fuse: Querying Graph Dependency via REST fails with ClassNotFoundException Key: RTGOV-602 URL: https://issues.jboss.org/browse/RTGOV-602 Project: RTGov (Run Time Governance) Issue Type: Bug Affects Versions: 2.0.0.Final Environment: fuse + switchyard 2.0.0.Alpha3 + rtgov 2.0.0.Final Reporter: Andrej Vano Assignee: Gary Brown Fix For: 2.1.0.Final Querying the graph dependency via REST on fuse fails with java.lang.ClassNotFoundException: javax.enterprise.context.spi.CreationalContext not found by rtgov-common Full error response is here: http://pastebin.test.redhat.com/240370 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 05:35:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 17 Oct 2014 05:35:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-603) Refreshing service list in RTGov UI waits indefinitely In-Reply-To: References: Message-ID: Gary Brown created RTGOV-603: -------------------------------- Summary: Refreshing service list in RTGov UI waits indefinitely Key: RTGOV-603 URL: https://issues.jboss.org/browse/RTGOV-603 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final When refreshing the services list, it appears to wait indefinitely. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 11:15:39 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 11:15:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-599) Batch upload through linked artifacts in a multipart POST In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-599: --------------------------------- Summary: Batch upload through linked artifacts in a multipart POST Key: SRAMP-599 URL: https://issues.jboss.org/browse/SRAMP-599 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer {quote} 2.3.5.2.1 Using Batch POST RFC 2387, "The MIME Multipart/Related Content-type" describes how to perform a multipart POST of binary documents. S-RAMP builds on this RFC to extend the IETF draft document "ATOM Multi-part Media Resource Creation" to support the simultaneous publishing of a collection of non-dependent and dependent resources and their associated metadata. With this approach it is possible, for example, to publish an XSD document which imports two other XSD documents by including it as well as its dependencies in a single POST to the repository. The Batch POST method requires an atom entry document as the root body part. This root atom entry document points to any dependent atom entry documents contained in other body parts using atom:link elements with an href attribute whose value is the Content-ID of the relevant body part. It also points at the actual document content by specifying the Content-ID of the relevant body part as the value of the src attribute in the atom:content element of the atom entry document. This approach provides complete linkage between a document and its dependencies and all corresponding binary resources. {quote} Although we implement the archive-based method of batch uploading, we do not currently support plain multipart for multiple artifacts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 11:22:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 11:22:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-600) Support batch updates In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-600: --------------------------------- Summary: Support batch updates Key: SRAMP-600 URL: https://issues.jboss.org/browse/SRAMP-600 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer BatchResource allows batch uploads through an archive. SRAMP-599 will support batch uploads though multipart. However, both mechanisms must also support PUT for updating artifacts. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 11:25:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 11:25:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-601) Support deleting an artifact's content In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-601: --------------------------------- Summary: Support deleting an artifact's content Key: SRAMP-601 URL: https://issues.jboss.org/browse/SRAMP-601 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer 2.3.5.5 requires that we support deleting an artifact's *content*, which should remove it's media link. We currently only support deleting the artifact itself. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 11:52:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 11:52:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-602) Implement fine-grained Properties view in the Atom API In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-602: --------------------------------- Summary: Implement fine-grained Properties view in the Atom API Key: SRAMP-602 URL: https://issues.jboss.org/browse/SRAMP-602 Project: S-RAMP Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/cs01/part2-atom-binding/s-ramp-v1.0-cs01-part2-atom-binding.html#_Toc377548248 Although not required, the spec suggests implementing a fine-grained view for managing artifact *properties*, similar to classifications (SRAMP-110) and relationships (SRAMP-94) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 12:12:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 12:12:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-603) Implement the Atom binding's "fine-grained views" In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-603: --------------------------------- Summary: Implement the Atom binding's "fine-grained views" Key: SRAMP-603 URL: https://issues.jboss.org/browse/SRAMP-603 Project: S-RAMP Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 12:12:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 12:12:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-602) Implement fine-grained Properties view in the Atom API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-602: ------------------------------ Parent: SRAMP-603 Issue Type: Sub-task (was: Feature Request) > Implement fine-grained Properties view in the Atom API > ------------------------------------------------------ > > Key: SRAMP-602 > URL: https://issues.jboss.org/browse/SRAMP-602 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > http://docs.oasis-open.org/s-ramp/s-ramp/v1.0/cs01/part2-atom-binding/s-ramp-v1.0-cs01-part2-atom-binding.html#_Toc377548248 > Although not required, the spec suggests implementing a fine-grained view for managing artifact *properties*, similar to classifications (SRAMP-110) and relationships (SRAMP-94) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 12:12:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 12:12:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-110) Implement fine-grained classification view in the Atom API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-110: ------------------------------ Parent: SRAMP-603 Issue Type: Sub-task (was: Feature Request) > Implement fine-grained classification view in the Atom API > ---------------------------------------------------------- > > Key: SRAMP-110 > URL: https://issues.jboss.org/browse/SRAMP-110 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > > The spec defines fine-grained views, including one for the classifications. This allows clients to get a manipulate (add, delete, get feed) the classifications for an artifact in the S-RAMP repository directly, removing the need to deal with the whole artifact at once. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 12:13:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 12:13:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-94) Handle fine-grained Atom view for relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-94?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-94: ----------------------------- Parent: SRAMP-603 Issue Type: Sub-task (was: Feature Request) > Handle fine-grained Atom view for relationships > ----------------------------------------------- > > Key: SRAMP-94 > URL: https://issues.jboss.org/browse/SRAMP-94 > Project: S-RAMP > Issue Type: Sub-task > Components: Atom Binding > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > > Relationships have their own separate Atom API endpoints. For example, you can get a feed of just the relationships for an artifact. In addition, you cn add (and I believe delete) individual relationships directly via this mechanism. This task should probably result in a new RelationshipResource RESTEasy class. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 12:25:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 17 Oct 2014 12:25:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-604) Dependency graph not displayed correctly In-Reply-To: References: Message-ID: Gary Brown created RTGOV-604: -------------------------------- Summary: Dependency graph not displayed correctly Key: RTGOV-604 URL: https://issues.jboss.org/browse/RTGOV-604 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final The size of the dependency graph is cropped so diagrams are not being displayed correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 17 15:04:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 17 Oct 2014 15:04:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-598) Improve error condition handling and map to applicable HTTP response codes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-598 started by Brett Meyer. ----------------------------------------- > Improve error condition handling and map to applicable HTTP response codes > -------------------------------------------------------------------------- > > Key: SRAMP-598 > URL: https://issues.jboss.org/browse/SRAMP-598 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} > {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} > {quote}If the artifact being edited is not in the repository at the time of the PUT, then the server SHALL return an HTTP error code of "404" indicating a Not Found.{quote} > {quote}Requests to retrieve an Artifact Entry document from the incorrect Artifact Type Model will result an HTTP "404" Not Found.{quote} > The server currently throws back 500 responses -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 04:25:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 20 Oct 2014 04:25:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013254#comment-13013254 ] David virgil naranjo commented on SRAMP-506: -------------------------------------------- Then Marc, What is the solution you suggest can fit better this problem? > Maven repository facade. Add extended type > ------------------------------------------ > > Key: SRAMP-506 > URL: https://issues.jboss.org/browse/SRAMP-506 > Project: S-RAMP > Issue Type: Sub-task > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > It is necessary to add the possibility of setting a different s-ramp type. > By default right now the s-ramp type is Java Archive. For uploading switchyard applications it is necessary to add a mechanism to set the extended type. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 04:32:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 20 Oct 2014 04:32:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-214) When uploading a jar - upload a text file with the output of jar tv In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013256#comment-13013256 ] David virgil naranjo commented on SRAMP-214: -------------------------------------------- I imagine you mean to create an artifact in s-ramp that contains all the entries of the zipped file, that can be a War, Jar, Ear, ZIp. This artifact can be a child of the main WAR/JAR/EAR/ZIP. We need to agree about the S-ramp type. Can be something like ZipContent, or ZipEntries or CompressedEntries. > When uploading a jar - upload a text file with the output of jar tv > ------------------------------------------------------------------- > > Key: SRAMP-214 > URL: https://issues.jboss.org/browse/SRAMP-214 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Kurt Stam > Assignee: David virgil naranjo > > It's nice to know the content of a jar/war/ear archive (for searching/diffing/or just to see what's in it etc). Would be nice to 'extract' a jar tf > jar-content.txt file and upload that to s-ramp too -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 04:35:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 20 Oct 2014 04:35:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-605) Document additional properties on DroolsEventProcessor In-Reply-To: References: Message-ID: Gary Brown created RTGOV-605: -------------------------------- Summary: Document additional properties on DroolsEventProcessor Key: RTGOV-605 URL: https://issues.jboss.org/browse/RTGOV-605 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final Document the new 'eventProcessingMode' and 'asynchronous' attributes on the Drools event processor. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 04:35:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 20 Oct 2014 04:35:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-434) Upgrade overlord-commons-services to use ServiceTracker in the osgi impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013258#comment-13013258 ] David virgil naranjo commented on SRAMP-434: -------------------------------------------- Is there any example of this in our current code? I tried to search about this in all the java files and no result. > Upgrade overlord-commons-services to use ServiceTracker in the osgi impl > ------------------------------------------------------------------------ > > Key: SRAMP-434 > URL: https://issues.jboss.org/browse/SRAMP-434 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > Currently I'm going straight for the service refs in the osgi registry. Instead we should use ServiceTracker. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 04:39:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 20 Oct 2014 04:39:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-438) Reduce the # of jars in s-ramp-ui-war-fuse61's /WEB-INF/lib In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo reassigned SRAMP-438: ------------------------------------------ Assignee: Brett Meyer (was: David virgil naranjo) I think the number of jars have been already decreased. I was thinking if this issue can be closed. > Reduce the # of jars in s-ramp-ui-war-fuse61's /WEB-INF/lib > ----------------------------------------------------------- > > Key: SRAMP-438 > URL: https://issues.jboss.org/browse/SRAMP-438 > Project: S-RAMP > Issue Type: Enhancement > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Minor > > s-ramp-ui-war-fuse61 includes 100+ jars in /WEB-INF/lib, mostly due to Weld/CDI's lack of OSGi support. Some/many of these could probably be removed, but it needs evaluated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 04:40:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 20 Oct 2014 04:40:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-528) Include fuse fabric installer for sramp and dtgov In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo resolved SRAMP-528. ---------------------------------------- Resolution: Rejected > Include fuse fabric installer for sramp and dtgov > ------------------------------------------------- > > Key: SRAMP-528 > URL: https://issues.jboss.org/browse/SRAMP-528 > Project: S-RAMP > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Include a new entry in the sramp-distro and dtgov-distro assembly projects. > It will generate the profiles to be deployed in fuse fabric. It will ask the user for the keystore password and generate the overlord-saml.keystore -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 07:37:35 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 20 Oct 2014 07:37:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-434) Upgrade overlord-commons-services to use ServiceTracker in the osgi impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013353#comment-13013353 ] Eric Wittmann commented on SRAMP-434: ------------------------------------- There is not. > Upgrade overlord-commons-services to use ServiceTracker in the osgi impl > ------------------------------------------------------------------------ > > Key: SRAMP-434 > URL: https://issues.jboss.org/browse/SRAMP-434 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > Currently I'm going straight for the service refs in the osgi registry. Instead we should use ServiceTracker. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 10:11:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 20 Oct 2014 10:11:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-528) Include fuse fabric installer for sramp and dtgov In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-528. ----------------------------- > Include fuse fabric installer for sramp and dtgov > ------------------------------------------------- > > Key: SRAMP-528 > URL: https://issues.jboss.org/browse/SRAMP-528 > Project: S-RAMP > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Include a new entry in the sramp-distro and dtgov-distro assembly projects. > It will generate the profiles to be deployed in fuse fabric. It will ask the user for the keystore password and generate the overlord-saml.keystore -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 10:13:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 20 Oct 2014 10:13:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-438) Reduce the # of jars in s-ramp-ui-war-fuse61's /WEB-INF/lib In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013499#comment-13013499 ] Brett Meyer commented on SRAMP-438: ----------------------------------- I think you're right -- it has improved to a certain extent. SRAMP-562 should help even more. But after that, we should still probably evaluate what remains. There may be more that we can clean up. > Reduce the # of jars in s-ramp-ui-war-fuse61's /WEB-INF/lib > ----------------------------------------------------------- > > Key: SRAMP-438 > URL: https://issues.jboss.org/browse/SRAMP-438 > Project: S-RAMP > Issue Type: Enhancement > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Minor > > s-ramp-ui-war-fuse61 includes 100+ jars in /WEB-INF/lib, mostly due to Weld/CDI's lack of OSGi support. Some/many of these could probably be removed, but it needs evaluated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 10:25:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 20 Oct 2014 10:25:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-434) Upgrade overlord-commons-services to use ServiceTracker in the osgi impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013504#comment-13013504 ] Brett Meyer commented on SRAMP-434: ----------------------------------- [~virchete], here's an example: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-osgi/src/main/java/org/hibernate/osgi/OsgiServiceUtil.java > Upgrade overlord-commons-services to use ServiceTracker in the osgi impl > ------------------------------------------------------------------------ > > Key: SRAMP-434 > URL: https://issues.jboss.org/browse/SRAMP-434 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > Currently I'm going straight for the service refs in the osgi registry. Instead we should use ServiceTracker. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 15:26:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 20 Oct 2014 15:26:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-598) Improve error condition handling and map to applicable HTTP response codes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-598. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Improve error condition handling and map to applicable HTTP response codes > -------------------------------------------------------------------------- > > Key: SRAMP-598 > URL: https://issues.jboss.org/browse/SRAMP-598 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > {quote}Publishing an artifact to the wrong collection will result in HTTP error "403" Forbidden.{quote} > {quote}If the supplied uuid property value duplicates one already in the repository, the server SHALL return an HTTP error code of "409" indicating a Conflict.{quote} > {quote}If the artifact being edited is not in the repository at the time of the PUT, then the server SHALL return an HTTP error code of "404" indicating a Not Found.{quote} > {quote}Requests to retrieve an Artifact Entry document from the incorrect Artifact Type Model will result an HTTP "404" Not Found.{quote} > The server currently throws back 500 responses -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 20 15:44:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 20 Oct 2014 15:44:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-604) Show relationships targeting the current artifact in the UI In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-604: --------------------------------- Summary: Show relationships targeting the current artifact in the UI Key: SRAMP-604 URL: https://issues.jboss.org/browse/SRAMP-604 Project: S-RAMP Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Great idea from [~eric.wittmann] on an email thread: {quote} I also think there is room in the UI for some way to show all artifacts that point to the current artifact by a specific relationship. So perhaps an editable drop-down control allowing the user to select a common relationship or type their own, which would result in this query: /s-ramp//[[@uuid = ]] The , , and values come from the currently selected artifact. The comes from the dropdown. Populate a table with the results! {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 07:56:35 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Tue, 21 Oct 2014 07:56:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-605) Remove binaries from SwitchYard integration test In-Reply-To: References: Message-ID: Stefan Bunciak created SRAMP-605: ------------------------------------ Summary: Remove binaries from SwitchYard integration test Key: SRAMP-605 URL: https://issues.jboss.org/browse/SRAMP-605 Project: S-RAMP Issue Type: Bug Affects Versions: 0.6.0.Final Reporter: Stefan Bunciak Assignee: Stefan Bunciak Fix For: 0.7.0.Final {code}SwitchYardClientTest{code} currently leverages pre-built switchyard quickstarts (stored in scm). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 07:57:35 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Tue, 21 Oct 2014 07:57:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-605) Remove binaries from SwitchYard integration test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bunciak updated SRAMP-605: --------------------------------- Description: {{SwitchYardClientTest}} currently leverages pre-built switchyard quickstarts (stored in scm). (was: {code}SwitchYardClientTest{code} currently leverages pre-built switchyard quickstarts (stored in scm). ) > Remove binaries from SwitchYard integration test > ------------------------------------------------ > > Key: SRAMP-605 > URL: https://issues.jboss.org/browse/SRAMP-605 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Stefan Bunciak > Fix For: 0.7.0.Final > > > {{SwitchYardClientTest}} currently leverages pre-built switchyard quickstarts (stored in scm). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 08:34:35 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Tue, 21 Oct 2014 08:34:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-605) Remove binaries from SwitchYard integration test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bunciak updated SRAMP-605: --------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/505 > Remove binaries from SwitchYard integration test > ------------------------------------------------ > > Key: SRAMP-605 > URL: https://issues.jboss.org/browse/SRAMP-605 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Stefan Bunciak > Fix For: 0.7.0.Final > > > {{SwitchYardClientTest}} currently leverages pre-built switchyard quickstarts (stored in scm). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:19:36 2014 From: issues at jboss.org (Giorgi Modebadze (JIRA)) Date: Tue, 21 Oct 2014 10:19:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: Giorgi Modebadze created SRAMP-606: -------------------------------------- Summary: Unable to use update custom metadata using REST call Key: SRAMP-606 URL: https://issues.jboss.org/browse/SRAMP-606 Project: S-RAMP Issue Type: Bug Reporter: Giorgi Modebadze Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:22:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 21 Oct 2014 10:22:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support built-in relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-547 started by Brett Meyer. ----------------------------------------- > Support built-in relationships > ------------------------------ > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > WsdlDocument, XsdDocument, etc. do not currently include support for importedXsds, includedXsds, redefinedXsds, importedWsdls, etc. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:31:35 2014 From: issues at jboss.org (Giorgi Modebadze (JIRA)) Date: Tue, 21 Oct 2014 10:31:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giorgi Modebadze updated SRAMP-606: ----------------------------------- Description: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Everything works fine on Jetty, problem is produced on EAP. Affects Version/s: 0.6.0.Final Component/s: Atom Binding S-RAMP API > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Everything works fine on Jetty, problem is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:36:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 21 Oct 2014 10:36:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support built-in relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Description: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlService: protected List port; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Port: protected BindingTarget binding; Part: protected XsdTypeTarget type; protected ElementTarget element; OperationOutput: protected MessageTarget message; OperationInput: protected MessageTarget message; Operation: protected OperationInputTarget input; protected OperationOutputTarget output; protected List fault; Message: protected List part; Fault: protected MessageTarget message; BindingOperation: protected List fault; protected BindingOperationInputTarget input; protected BindingOperationOutputTarget output; protected OperationTarget operation; Binding: protected List bindingOperation; protected PortTypeTarget portType; was:WsdlDocument, XsdDocument, etc. do not currently include support for importedXsds, includedXsds, redefinedXsds, importedWsdls, etc. > Support built-in relationships > ------------------------------ > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlService: > protected List port; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Port: > protected BindingTarget binding; > Part: > protected XsdTypeTarget type; > protected ElementTarget element; > OperationOutput: > protected MessageTarget message; > OperationInput: > protected MessageTarget message; > Operation: > protected OperationInputTarget input; > protected OperationOutputTarget output; > protected List fault; > Message: > protected List part; > Fault: > protected MessageTarget message; > BindingOperation: > protected List fault; > protected BindingOperationInputTarget input; > protected BindingOperationOutputTarget output; > protected OperationTarget operation; > Binding: > protected List bindingOperation; > protected PortTypeTarget portType; -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:39:36 2014 From: issues at jboss.org (Giorgi Modebadze (JIRA)) Date: Tue, 21 Oct 2014 10:39:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giorgi Modebadze updated SRAMP-606: ----------------------------------- Description: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Predefined URLs for updating metadata work alright on EAP. E.g. http://localhost:8080/dtgov/rest/update/{name}/{value}/{uuid} Problem is produced on custom Rest calls only. Everything works fine on Jetty, error is produced on EAP. was: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Everything works fine on Jetty, problem is produced on EAP. > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/{name}/{value}/{uuid} > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:40:36 2014 From: issues at jboss.org (Giorgi Modebadze (JIRA)) Date: Tue, 21 Oct 2014 10:40:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giorgi Modebadze updated SRAMP-606: ----------------------------------- Description: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Predefined URLs for updating metadata work alright on EAP. E.g. http://localhost:8080/dtgov/rest/update/ {name}/ {value}/ {uuid} Problem is produced on custom Rest calls only. Everything works fine on Jetty, error is produced on EAP. was: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Predefined URLs for updating metadata work alright on EAP. E.g. http://localhost:8080/dtgov/rest/update/{name}/{value}/{uuid} Problem is produced on custom Rest calls only. Everything works fine on Jetty, error is produced on EAP. > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/ {name}/ {value}/ {uuid} > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:40:37 2014 From: issues at jboss.org (Giorgi Modebadze (JIRA)) Date: Tue, 21 Oct 2014 10:40:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giorgi Modebadze updated SRAMP-606: ----------------------------------- Description: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Predefined URLs for updating metadata work alright on EAP. E.g. http://localhost:8080/dtgov/rest/update/{name}/{value}/{uuid} Problem is produced on custom Rest calls only. Everything works fine on Jetty, error is produced on EAP. was: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Predefined URLs for updating metadata work alright on EAP. E.g. http://localhost:8080/dtgov/rest/update/ {name}/ {value}/ {uuid} Problem is produced on custom Rest calls only. Everything works fine on Jetty, error is produced on EAP. > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/{name}/{value}/{uuid} > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 10:45:38 2014 From: issues at jboss.org (Giorgi Modebadze (JIRA)) Date: Tue, 21 Oct 2014 10:45:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Giorgi Modebadze updated SRAMP-606: ----------------------------------- Description: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Predefined URLs for updating metadata work alright on EAP. E.g. http://localhost:8080/dtgov/rest/update/name/value/uuid Problem is produced on custom Rest calls only. Everything works fine on Jetty, error is produced on EAP. was: I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. E.g. PUT call to Rest Service: http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd As a result, artifact with the given UUID will have property with name key and value Testvalue. Here is the simple code that accepts REST calls: https://gist.github.com/anonymous/469be08cc2610e727517 Here's the pom.xml https://gist.github.com/anonymous/08a3c91163c682cc6cd0 The error from EAP: https://gist.github.com/anonymous/b6422e498a3a90f4c28c Predefined URLs for updating metadata work alright on EAP. E.g. http://localhost:8080/dtgov/rest/update/{name}/{value}/{uuid} Problem is produced on custom Rest calls only. Everything works fine on Jetty, error is produced on EAP. > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/name/value/uuid > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 11:24:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 21 Oct 2014 11:24:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support built-in relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Description: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; was: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlService: protected List port; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Port: protected BindingTarget binding; Part: protected XsdTypeTarget type; protected ElementTarget element; OperationOutput: protected MessageTarget message; OperationInput: protected MessageTarget message; Operation: protected OperationInputTarget input; protected OperationOutputTarget output; protected List fault; Message: protected List part; Fault: protected MessageTarget message; BindingOperation: protected List fault; protected BindingOperationInputTarget input; protected BindingOperationOutputTarget output; protected OperationTarget operation; Binding: protected List bindingOperation; protected PortTypeTarget portType; > Support built-in relationships > ------------------------------ > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 14:17:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 21 Oct 2014 14:17:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13013980#comment-13013980 ] Brett Meyer commented on SRAMP-466: ----------------------------------- SRAMP-547 could also be improved with this. For instance, includedXsds with relative paths could be resolved. Rather than stripping the path, check to see if it exists in the archive. > Better utilize batch mode for relationship resolution > ----------------------------------------------------- > > Key: SRAMP-466 > URL: https://issues.jboss.org/browse/SRAMP-466 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 14:17:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 21 Oct 2014 14:17:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support built-in relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Description: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace. - Include targets will be parsed. Any derived content will be attached to the parent. - Include targets including a full URL will be downloaded. If that fails, we'll attempt to match the *filename* to an existing artifact. Note that relative paths will be stripped, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. was: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; > Support built-in relationships > ------------------------------ > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace. > - Include targets will be parsed. Any derived content will be attached to the parent. > - Include targets including a full URL will be downloaded. If that fails, we'll attempt to match the *filename* to an existing artifact. Note that relative paths will be stripped, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 14:23:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 21 Oct 2014 14:23:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support derived relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Summary: Support derived relationships (was: Support built-in relationships) > Support derived relationships > ----------------------------- > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace. > - Include targets will be parsed. Any derived content will be attached to the parent. > - Include targets including a full URL will be downloaded. If that fails, we'll attempt to match the *filename* to an existing artifact. Note that relative paths will be stripped, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 21 14:27:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 21 Oct 2014 14:27:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support derived relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Description: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace. - Include targets will be parsed. Any derived content will be attached to the parent. - Include targets including a full URL will be downloaded. If that fails, we'll attempt to match the *filename* to an existing artifact. Note that relative paths will be stripped, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will supersede any found in the includes. was: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace. - Include targets will be parsed. Any derived content will be attached to the parent. - Include targets including a full URL will be downloaded. If that fails, we'll attempt to match the *filename* to an existing artifact. Note that relative paths will be stripped, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. > Support derived relationships > ----------------------------- > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace. > - Include targets will be parsed. Any derived content will be attached to the parent. > - Include targets including a full URL will be downloaded. If that fails, we'll attempt to match the *filename* to an existing artifact. Note that relative paths will be stripped, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. > - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will supersede any found in the includes. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 03:22:35 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Wed, 22 Oct 2014 03:22:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-606) UI: No pagination for the list of services In-Reply-To: References: Message-ID: Andrej Vano created RTGOV-606: --------------------------------- Summary: UI: No pagination for the list of services Key: RTGOV-606 URL: https://issues.jboss.org/browse/RTGOV-606 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Andrej Vano Assignee: Gary Brown Currently the list of services displays just fixed amount of services (the default number is 10) without any information that there are more services that are not displayed - see attached screenshot. If the widget does not support pagination, it should be documented that the user may not see all the services and that he can change the number of displayed services in the widget settings -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 03:23:35 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Wed, 22 Oct 2014 03:23:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-606) UI: No pagination for the list of services In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrej Vano updated RTGOV-606: ------------------------------ Attachment: kibana_listofservices.png > UI: No pagination for the list of services > ------------------------------------------ > > Key: RTGOV-606 > URL: https://issues.jboss.org/browse/RTGOV-606 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Andrej Vano > Assignee: Gary Brown > Attachments: kibana_listofservices.png > > > Currently the list of services displays just fixed amount of services (the default number is 10) without any information that there are more services that are not displayed - see attached screenshot. > If the widget does not support pagination, it should be documented that the user may not see all the services and that he can change the number of displayed services in the widget settings -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 03:24:35 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Wed, 22 Oct 2014 03:24:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-606) UI: No pagination for the list of services widget In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrej Vano updated RTGOV-606: ------------------------------ Summary: UI: No pagination for the list of services widget (was: UI: No pagination for the list of services) > UI: No pagination for the list of services widget > ------------------------------------------------- > > Key: RTGOV-606 > URL: https://issues.jboss.org/browse/RTGOV-606 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Andrej Vano > Assignee: Gary Brown > Attachments: kibana_listofservices.png > > > Currently the list of services displays just fixed amount of services (the default number is 10) without any information that there are more services that are not displayed - see attached screenshot. > If the widget does not support pagination, it should be documented that the user may not see all the services and that he can change the number of displayed services in the widget settings -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 03:56:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 22 Oct 2014 03:56:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-606) UI: No pagination for the list of services widget In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014105#comment-13014105 ] Gary Brown commented on RTGOV-606: ---------------------------------- [~imckinle] Any thoughts on how the widget can be configured to offer pagination or does the user just need to update the config on the widget to increase the displayed number? > UI: No pagination for the list of services widget > ------------------------------------------------- > > Key: RTGOV-606 > URL: https://issues.jboss.org/browse/RTGOV-606 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Andrej Vano > Assignee: Gary Brown > Attachments: kibana_listofservices.png > > > Currently the list of services displays just fixed amount of services (the default number is 10) without any information that there are more services that are not displayed - see attached screenshot. > If the widget does not support pagination, it should be documented that the user may not see all the services and that he can change the number of displayed services in the widget settings -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 08:50:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 22 Oct 2014 08:50:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-571) Support stored queries in UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-571?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-571: ------------------------------ Description: SRAMP-29 added support for stored queries. Once SRAMP-554 is finished, add stored query support in the UI. Consider adding a "Save as Stored Query" button to the search sidebar or above the search results. The latter may be more natural. When clicked, it would open a small prompt to provide a name. All queries would be available in a drop down, available for execution. (was: SRAMP-29 added support for stored queries. Once SRAMP-554 is finished, add stored query support in the UI. Consider adding a "Save as Stored Query" button to the search sidebar or above the search results. The latter may be more natural. When clicked, it would open a small prompt to provide a name.) > Support stored queries in UI > ---------------------------- > > Key: SRAMP-571 > URL: https://issues.jboss.org/browse/SRAMP-571 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > SRAMP-29 added support for stored queries. Once SRAMP-554 is finished, add stored query support in the UI. Consider adding a "Save as Stored Query" button to the search sidebar or above the search results. The latter may be more natural. When clicked, it would open a small prompt to provide a name. All queries would be available in a drop down, available for execution. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 08:55:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 22 Oct 2014 08:55:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-605) Remove binaries from SwitchYard integration test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-605. ------------------------------- Resolution: Done > Remove binaries from SwitchYard integration test > ------------------------------------------------ > > Key: SRAMP-605 > URL: https://issues.jboss.org/browse/SRAMP-605 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Stefan Bunciak > Fix For: 0.7.0.Final > > > {{SwitchYardClientTest}} currently leverages pre-built switchyard quickstarts (stored in scm). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 22 14:34:35 2014 From: issues at jboss.org (=?UTF-8?Q?Jan_Bou=C5=A1ka_=28JIRA=29?=) Date: Wed, 22 Oct 2014 14:34:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014399#comment-13014399 ] Jan Bou?ka commented on SRAMP-16: --------------------------------- Hallo, I am working on this issue. I added UI mockup but I don't know if it is all right. > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > Issue Type: Task > Components: IDE Integration > Affects Versions: 0.6.0.Final > Reporter: Kurt Stam > Assignee: Brett Meyer > Attachments: 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.1#6329) From issues at jboss.org Wed Oct 22 14:44:35 2014 From: issues at jboss.org (=?UTF-8?Q?Jan_Bou=C5=A1ka_=28JIRA=29?=) Date: Wed, 22 Oct 2014 14:44:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014399#comment-13014399 ] Jan Bou?ka edited comment on SRAMP-16 at 10/22/14 2:43 PM: ----------------------------------------------------------- Hello, I am working on this issue. I added UI mockup but I don't know if it is all right. was (Author: bouskaj): Hallo, I am working on this issue. I added UI mockup but I don't know if it is all right. > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > Issue Type: Task > Components: IDE Integration > Affects Versions: 0.6.0.Final > Reporter: Kurt Stam > Assignee: Brett Meyer > Attachments: 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.1#6329) From issues at jboss.org Thu Oct 23 06:00:43 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Thu, 23 Oct 2014 06:00:43 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014531#comment-13014531 ] Stefan Bunciak commented on SRAMP-16: ------------------------------------- Hi [~brmeyer]! Could you please have a look and provide a feed-back on the UI Mockup? Thank you! > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > Issue Type: Task > Components: IDE Integration > Affects Versions: 0.6.0.Final > Reporter: Kurt Stam > Assignee: Brett Meyer > Attachments: 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.1#6329) From issues at jboss.org Thu Oct 23 06:16:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 23 Oct 2014 06:16:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-604) Dependency graph not displayed correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-604: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/226 > Dependency graph not displayed correctly > ---------------------------------------- > > Key: RTGOV-604 > URL: https://issues.jboss.org/browse/RTGOV-604 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The size of the dependency graph is cropped so diagrams are not being displayed correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 23 06:16:35 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 23 Oct 2014 06:16:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-604) Dependency graph not displayed correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-604. ------------------------------ Resolution: Done > Dependency graph not displayed correctly > ---------------------------------------- > > Key: RTGOV-604 > URL: https://issues.jboss.org/browse/RTGOV-604 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The size of the dependency graph is cropped so diagrams are not being displayed correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 24 03:16:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 24 Oct 2014 03:16:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-583) Consider completely removing the web-view support in the Maven Facade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014762#comment-13014762 ] David virgil naranjo commented on SRAMP-583: -------------------------------------------- I think is good to have a maven tree view depending on trhe complex situations we can reach to. I thought the current implementation was complete and it displayed the artifacts included in a group and listed correctly the groups. What are the key areas that are being missed? And what are the complex situations maybe we have to deal in the future? Just for my understanding. I imagine the artifact grouping could be one situation. Just as the user view, I think having a view like this is useful. As this url will be added as maven repository, I like the idea of having access to the artifacts. What would be good also, is to have a kind of tree organized view in s-ramp. > Consider completely removing the web-view support in the Maven Facade > --------------------------------------------------------------------- > > Key: SRAMP-583 > URL: https://issues.jboss.org/browse/SRAMP-583 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > > Although I understand the initial desire to have a web-view interface for the Maven Facade (similar to Nexus' ability to navigate the repo w/ a web browser), I think I'd recommend removing the capability entirely. The current implementation isn't complete and misses a few key areas. Overcoming every complex situation will be challenging and not worth the effort. > I would much rather require the use of the real S-RAMP UI. If there are specific use cases that the Facade view aimed for, implement them as improvements to the UI. > So, I'm advocating that we strip out the Facade view, JSPs, etc. entirely. Thoughts? -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 24 09:18:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 24 Oct 2014 09:18:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13014912#comment-13014912 ] Brett Meyer commented on SRAMP-16: ---------------------------------- (CC [~eric.wittmann] & [~objectiser]) [~bouskaj], hello! Glad to have your help! The approach looks like a great start! You've encompassed the 2 main use cases: uploading an artifact to S-RAMP, and downloading artifacts from S-RAMP and incorporating them into your project. Here's a few comments: - When you upload an artifact, it would be useful to use a popup screen where the user could provide artifact metadata (name, artifact type, properties, etc.). - Your S-RAMP repo screen currently has 1 "Query" box. Definitely keep that -- that will allow developers to use the S-RAMP query language. However, we might also need a sidebar with an advanced search form, really similar to what the web UI has. That way, users can still filter the artifacts, even if they don't know the full query language. Other than that, you're on the right track! Thanks again for the help! > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > Issue Type: Task > Components: IDE Integration > Affects Versions: 0.6.0.Final > Reporter: Kurt Stam > Assignee: Brett Meyer > Attachments: 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.1#6329) From issues at jboss.org Mon Oct 27 10:31:35 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Mon, 27 Oct 2014 10:31:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-607) Hardcoded connection factory jndi name in JMSEventProducer In-Reply-To: References: Message-ID: Stefan Bunciak created SRAMP-607: ------------------------------------ Summary: Hardcoded connection factory jndi name in JMSEventProducer Key: SRAMP-607 URL: https://issues.jboss.org/browse/SRAMP-607 Project: S-RAMP Issue Type: Bug Components: Core Affects Versions: 0.6.0.Final Reporter: Stefan Bunciak Assignee: Brett Meyer Fix For: 0.7.0.Final -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 15:04:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 27 Oct 2014 15:04:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-608) SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-608: --------------------------------- Summary: SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect Key: SRAMP-608 URL: https://issues.jboss.org/browse/SRAMP-608 Project: S-RAMP Issue Type: Bug Reporter: Brett Meyer Assignee: Brett Meyer Priority: Critical Complex returns both Complex and Simple. Simple does not work, period. See commented-out failure at the bottom of JCRWsdlDocumentPersistenceTest -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 15:18:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 27 Oct 2014 15:18:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-609) Create a new ArtifactBuilder concept In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-609: --------------------------------- Summary: Create a new ArtifactBuilder concept Key: SRAMP-609 URL: https://issues.jboss.org/browse/SRAMP-609 Project: S-RAMP Issue Type: Enhancement Reporter: Brett Meyer Assignee: Brett Meyer The Deriver and Linker concepts are necessary, but are somewhat inflexible and unextenadble. For SRAMP-547, SRAMP-465, SRAMP-466, etc., a better solution is needed. Replace with an ArtifactBuilder that is in charge of building up the primary artifact and its set of derived artifacts. The set of available builders will be chained together, allowing devs to extend the build-in capabilities. When building, if a relationship target is not available in the current set of primary/derived artifacts, a new mediation layer, RelationshipSource, will be given enough information to define the target value in a later step. This information could include a QName, etc. After the artifacts are persisted in JCR, the builders are re-called to process any RelationshipSources. Technically, this could be combined with the above into one single step. However, due to the chaining, we want to provide visibility into the entire set of artifacts provided by the whole chain. The alternative, passing the list of artifacts through the chain, is brittle and would require knowing required ordering ahead of time. This idea will be vital for SRAMP-466 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 15:28:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 27 Oct 2014 15:28:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-608) SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015400#comment-13015400 ] Brett Meyer commented on SRAMP-608: ----------------------------------- Also see JCRBatchPersistenceTest#testWsdlBatch > SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect > -------------------------------------------------------------- > > Key: SRAMP-608 > URL: https://issues.jboss.org/browse/SRAMP-608 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Critical > > Complex returns both Complex and Simple. Simple does not work, period. See commented-out failure at the bottom of JCRWsdlDocumentPersistenceTest -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 16:48:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 27 Oct 2014 16:48:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-609) Create a new ArtifactBuilder concept In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-609 started by Brett Meyer. ----------------------------------------- > Create a new ArtifactBuilder concept > ------------------------------------ > > Key: SRAMP-609 > URL: https://issues.jboss.org/browse/SRAMP-609 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > The Deriver and Linker concepts are necessary, but are somewhat inflexible and unextenadble. For SRAMP-547, SRAMP-465, SRAMP-466, etc., a better solution is needed. > Replace with an ArtifactBuilder that is in charge of building up the primary artifact and its set of derived artifacts. The set of available builders will be chained together, allowing devs to extend the build-in capabilities. > When building, if a relationship target is not available in the current set of primary/derived artifacts, a new mediation layer, RelationshipSource, will be given enough information to define the target value in a later step. This information could include a QName, etc. > After the artifacts are persisted in JCR, the builders are re-called to process any RelationshipSources. Technically, this could be combined with the above into one single step. However, due to the chaining, we want to provide visibility into the entire set of artifacts provided by the whole chain. The alternative, passing the list of artifacts through the chain, is brittle and would require knowing required ordering ahead of time. This idea will be vital for SRAMP-466 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Oct 27 16:49:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 27 Oct 2014 16:49:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-466 started by Brett Meyer. ----------------------------------------- > Better utilize batch mode for relationship resolution > ----------------------------------------------------- > > Key: SRAMP-466 > URL: https://issues.jboss.org/browse/SRAMP-466 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 28 03:46:35 2014 From: issues at jboss.org (=?UTF-8?Q?Jan_Bou=C5=A1ka_=28JIRA=29?=) Date: Tue, 28 Oct 2014 03:46:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015451#comment-13015451 ] Jan Bou?ka commented on SRAMP-16: --------------------------------- Hello [~brmeyer]. I made changes according to your advice. Could you have a look on the new UI Mockup? Thank you. > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > 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.1#6329) From issues at jboss.org Tue Oct 28 09:27:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 28 Oct 2014 09:27:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-16) Eclipse IDE: S-RAMP tooling In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015522#comment-13015522 ] Brett Meyer commented on SRAMP-16: ---------------------------------- [~bouskaj], great start! I think that's plenty to start with. Our UI is always changing and we'll probably keep this in sync as it does. However, this looks like a fine place to get going. Good work! > Eclipse IDE: S-RAMP tooling > --------------------------- > > Key: SRAMP-16 > URL: https://issues.jboss.org/browse/SRAMP-16 > Project: S-RAMP > 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.1#6329) From issues at jboss.org Tue Oct 28 14:15:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 28 Oct 2014 14:15:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-610) Remove the old Deriver concepts In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-610: --------------------------------- Summary: Remove the old Deriver concepts Key: SRAMP-610 URL: https://issues.jboss.org/browse/SRAMP-610 Project: S-RAMP Issue Type: Task Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 1.0 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.1#6329) From issues at jboss.org Tue Oct 28 17:35:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 28 Oct 2014 17:35:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support derived relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Description: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. - Note that relative paths will be stripped from the filenames, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will be generated. was: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace. - Include targets will be parsed. Any derived content will be attached to the parent. - Include targets including a full URL will be downloaded. If that fails, we'll attempt to match the *filename* to an existing artifact. Note that relative paths will be stripped, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will supersede any found in the includes. > Support derived relationships > ----------------------------- > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. > - Note that relative paths will be stripped from the filenames, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. > - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will be generated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Oct 28 17:48:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 28 Oct 2014 17:48:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support derived relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Description: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. - Since we're checking the filename, uploaded XSDs *must* include the slug *or* manually set the artifact name to the filename. - Note that relative paths will be stripped from the filenames, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will be generated. was: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. - Note that relative paths will be stripped from the filenames, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will be generated. > Support derived relationships > ----------------------------- > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. > - Since we're checking the filename, uploaded XSDs *must* include the slug *or* manually set the artifact name to the filename. > - Note that relative paths will be stripped from the filenames, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. > - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will be generated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 08:04:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 29 Oct 2014 08:04:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-604) Dependency graph not displayed correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-604: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1158445 > Dependency graph not displayed correctly > ---------------------------------------- > > Key: RTGOV-604 > URL: https://issues.jboss.org/browse/RTGOV-604 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The size of the dependency graph is cropped so diagrams are not being displayed correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 11:50:35 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 29 Oct 2014 11:50:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-604) Dependency graph not displayed correctly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015887#comment-13015887 ] RH Bugzilla Integration commented on RTGOV-604: ----------------------------------------------- Gary Brown changed the Status of [bug 1158445|https://bugzilla.redhat.com/show_bug.cgi?id=1158445] from NEW to MODIFIED > Dependency graph not displayed correctly > ---------------------------------------- > > Key: RTGOV-604 > URL: https://issues.jboss.org/browse/RTGOV-604 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > The size of the dependency graph is cropped so diagrams are not being displayed correctly. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 12:44:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 29 Oct 2014 12:44:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-466: ------------------------------ Comment: was deleted (was: SRAMP-547 could also be improved with this. For instance, includedXsds with relative paths could be resolved. Rather than stripping the path, check to see if it exists in the archive.) > Better utilize batch mode for relationship resolution > ----------------------------------------------------- > > Key: SRAMP-466 > URL: https://issues.jboss.org/browse/SRAMP-466 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 14:27:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 29 Oct 2014 14:27:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support derived relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/508 > Support derived relationships > ----------------------------- > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. > - Since we're checking the filename, uploaded XSDs *must* include the slug *or* manually set the artifact name to the filename. > - Note that relative paths will be stripped from the filenames, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. > - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will be generated. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 14:27:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 29 Oct 2014 14:27:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support derived relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-547: ------------------------------ Description: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. - Since we're checking the filename, uploaded XSDs *must* include the slug *or* manually set the artifact name to the filename. - Note that relative paths will be stripped from the filenames, so conflicts could occur. was: XsdDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; WsdlDocument: protected List importedXsds; protected List includedXsds; protected List redefinedXsds; protected List importedWsdls; Things to note in the docs: - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. - Since we're checking the filename, uploaded XSDs *must* include the slug *or* manually set the artifact name to the filename. - Note that relative paths will be stripped from the filenames, so conflicts could occur. But, once SRAMP-466 is finished, relative paths could be checked against the archive. - Redefined targets will work exactly like includes (including the above caveats). Only difference is their derived artifacts will be generated. > Support derived relationships > ----------------------------- > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. > - Since we're checking the filename, uploaded XSDs *must* include the slug *or* manually set the artifact name to the filename. > - Note that relative paths will be stripped from the filenames, so conflicts could occur. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 14:28:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 29 Oct 2014 14:28:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-609) Create a new ArtifactBuilder concept In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-609: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/508 > Create a new ArtifactBuilder concept > ------------------------------------ > > Key: SRAMP-609 > URL: https://issues.jboss.org/browse/SRAMP-609 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > > The Deriver and Linker concepts are necessary, but are somewhat inflexible and unextenadble. For SRAMP-547, SRAMP-465, SRAMP-466, etc., a better solution is needed. > Replace with an ArtifactBuilder that is in charge of building up the primary artifact and its set of derived artifacts. The set of available builders will be chained together, allowing devs to extend the build-in capabilities. > When building, if a relationship target is not available in the current set of primary/derived artifacts, a new mediation layer, RelationshipSource, will be given enough information to define the target value in a later step. This information could include a QName, etc. > After the artifacts are persisted in JCR, the builders are re-called to process any RelationshipSources. Technically, this could be combined with the above into one single step. However, due to the chaining, we want to provide visibility into the entire set of artifacts provided by the whole chain. The alternative, passing the list of artifacts through the chain, is brittle and would require knowing required ordering ahead of time. This idea will be vital for SRAMP-466 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 14:28:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 29 Oct 2014 14:28:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-466: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/508 > Better utilize batch mode for relationship resolution > ----------------------------------------------------- > > Key: SRAMP-466 > URL: https://issues.jboss.org/browse/SRAMP-466 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Oct 29 14:29:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 29 Oct 2014 14:29:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015922#comment-13015922 ] Brett Meyer commented on SRAMP-466: ----------------------------------- For now, keeping this really simple. During relationship resolution, results are ordered by creation timestamp, newest-to-oldest. Grab the newest and assume it's the most relevant. > Better utilize batch mode for relationship resolution > ----------------------------------------------------- > > Key: SRAMP-466 > URL: https://issues.jboss.org/browse/SRAMP-466 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:20:35 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 30 Oct 2014 09:20:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016090#comment-13016090 ] Eric Wittmann commented on SRAMP-573: ------------------------------------- Shouldn't Ctrl-U clear the text? Ctrl-C is SIGINT - shouldn't that exit the shell? > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:21:37 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 30 Oct 2014 09:21:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016090#comment-13016090 ] Eric Wittmann edited comment on SRAMP-573 at 10/30/14 9:20 AM: --------------------------------------------------------------- Shouldn't Ctrl-U and Ctrl-K clear the text (from cursor to the start and end of the line, respectively)? Ctrl-C is SIGINT - shouldn't that exit the shell? was (Author: eric.wittmann): Shouldn't Ctrl-U clear the text? Ctrl-C is SIGINT - shouldn't that exit the shell? > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:24:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 30 Oct 2014 09:24:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016094#comment-13016094 ] Brett Meyer commented on SRAMP-573: ----------------------------------- I guess I'm thinking more in terms of a console, such as Fuse, SSH, etc. Ctrl+C works exactly as it does in a normal OS terminal -- simply kills what you're currently working on or blows away the current line. Ctrl+D exits. But I get Eric's point. Thoughts? > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:29:36 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 30 Oct 2014 09:29:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016096#comment-13016096 ] Eric Wittmann commented on SRAMP-573: ------------------------------------- Did a little testing on various shells here and yeah, Ctrl-C tends to simply abort whatever the user is currently doing. Essentially it's like hitting Enter except the command that was typed is *not* executed. That makes sense. I think Ctrl-U and Ctrl-K would *also* be lovely to have. > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:29:37 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 30 Oct 2014 09:29:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016097#comment-13016097 ] Eric Wittmann commented on SRAMP-573: ------------------------------------- Also I'm completely on-board with Ctrl-D exiting. :) > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:33:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 30 Oct 2014 09:33:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016102#comment-13016102 ] Brett Meyer commented on SRAMP-573: ----------------------------------- {quote} Essentially it's like hitting Enter except the command that was typed is not executed. {quote} [~virchete], ^^^ that's a great way of describing what I was hoping for! And +1 to Ctrl+D cleanly exiting. IIRC, last time I tried it you got an NPE > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:43:38 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 30 Oct 2014 09:43:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016112#comment-13016112 ] David virgil naranjo commented on SRAMP-573: -------------------------------------------- What about Control+ D, exiting. Ctrl-U and Ctrl-K clear the text And for control +C we wait, as this is a more complex development. I tried a solution using threads, creating a thread per command executed, and in case the Control+C is pressed trying to kill/stop the process. But it is not easy to kill a Thread in Java. It should be done using the Thread.interrupt(). > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:44:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 30 Oct 2014 09:44:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016113#comment-13016113 ] David virgil naranjo commented on SRAMP-573: -------------------------------------------- As well as i talked with brett in irc, would be good to have a undeploy or undo method per command that can be executed when an interrupted exception is thrown. > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 09:53:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 30 Oct 2014 09:53:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016120#comment-13016120 ] Brett Meyer commented on SRAMP-573: ----------------------------------- David, let's keep this really simple to start with: 1.) Ctrl+C == Enter, but the typed command is *not* executed. This essentially clears the current line, just as it would in an OS console. 2.) Ctrl+C does *not* exit the shell. 3.) Ctrl+D *does* exit the shell, cleanly (no Exceptions) 4.) Consider Ctrl+U and Ctrl+K as well. As far as interrupting an executing command, undos, etc., let's hold off. My intentions for this were purely so that if I mistype something, I can hit Ctrl+C, clear it, and not have the shell go bye bye. > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 10:01:35 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 30 Oct 2014 10:01:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016124#comment-13016124 ] David virgil naranjo commented on SRAMP-573: -------------------------------------------- Oki, but in case the Control+C is typed when the command is being executed, then it will not do nothing. > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 10:10:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 30 Oct 2014 10:10:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-573?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016126#comment-13016126 ] Brett Meyer commented on SRAMP-573: ----------------------------------- {quote}Oki, but in case the Control+C is typed when the command is being executed, then it will not do nothing.{quote} Correct, for now, but we can improve it later. > Ctrl+C should not exit the CLI > ------------------------------ > > Key: SRAMP-573 > URL: https://issues.jboss.org/browse/SRAMP-573 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: David virgil naranjo > > If you mistype a command in the CLI, I'd expect Ctrl+C to clear it. Instead, it exits the shell completely. Instead, limit that to Ctrl+D. Block Ctrl+C from exiting and ensure it clears the current partially-typed command. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 12:15:37 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 30 Oct 2014 12:15:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-609) Create a new ArtifactBuilder concept In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-609. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Create a new ArtifactBuilder concept > ------------------------------------ > > Key: SRAMP-609 > URL: https://issues.jboss.org/browse/SRAMP-609 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > The Deriver and Linker concepts are necessary, but are somewhat inflexible and unextenadble. For SRAMP-547, SRAMP-465, SRAMP-466, etc., a better solution is needed. > Replace with an ArtifactBuilder that is in charge of building up the primary artifact and its set of derived artifacts. The set of available builders will be chained together, allowing devs to extend the build-in capabilities. > When building, if a relationship target is not available in the current set of primary/derived artifacts, a new mediation layer, RelationshipSource, will be given enough information to define the target value in a later step. This information could include a QName, etc. > After the artifacts are persisted in JCR, the builders are re-called to process any RelationshipSources. Technically, this could be combined with the above into one single step. However, due to the chaining, we want to provide visibility into the entire set of artifacts provided by the whole chain. The alternative, passing the list of artifacts through the chain, is brittle and would require knowing required ordering ahead of time. This idea will be vital for SRAMP-466 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 12:16:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 30 Oct 2014 12:16:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-547) Support derived relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-547. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Support derived relationships > ----------------------------- > > Key: SRAMP-547 > URL: https://issues.jboss.org/browse/SRAMP-547 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > XsdDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > WsdlDocument: > protected List importedXsds; > protected List includedXsds; > protected List redefinedXsds; > protected List importedWsdls; > Things to note in the docs: > - Import/include/redefine targets must already exist in the repo or be included in the uploaded artifact/batch. Target determined by namespace -> targetNamespace and filename. > - Since we're checking the filename, uploaded XSDs *must* include the slug *or* manually set the artifact name to the filename. > - Note that relative paths will be stripped from the filenames, so conflicts could occur. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Oct 30 12:16:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 30 Oct 2014 12:16:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-466. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Better utilize batch mode for relationship resolution > ----------------------------------------------------- > > Key: SRAMP-466 > URL: https://issues.jboss.org/browse/SRAMP-466 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 09:58:38 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 09:58:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-608) SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016411#comment-13016411 ] Brett Meyer commented on SRAMP-608: ----------------------------------- Can't reproduce -- both tests now pass. Verified w/ manual feed queries as well. But, resolving with the test fixes. > SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect > -------------------------------------------------------------- > > Key: SRAMP-608 > URL: https://issues.jboss.org/browse/SRAMP-608 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Critical > > Complex returns both Complex and Simple. Simple does not work, period. See commented-out failure at the bottom of JCRWsdlDocumentPersistenceTest -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 09:59:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 09:59:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-608) SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-608. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > SimpleTypeDeclaration/ComplexTypeDeclaration queries incorrect > -------------------------------------------------------------- > > Key: SRAMP-608 > URL: https://issues.jboss.org/browse/SRAMP-608 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Critical > Fix For: 0.7.0.Final > > > Complex returns both Complex and Simple. Simple does not work, period. See commented-out failure at the bottom of JCRWsdlDocumentPersistenceTest -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 10:10:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 10:10:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-607) Hardcoded connection factory jndi name in JMSEventProducer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-607. ------------------------------- Resolution: Done > Hardcoded connection factory jndi name in JMSEventProducer > ---------------------------------------------------------- > > Key: SRAMP-607 > URL: https://issues.jboss.org/browse/SRAMP-607 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 10:10:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 10:10:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-607) Hardcoded connection factory jndi name in JMSEventProducer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016417#comment-13016417 ] Brett Meyer commented on SRAMP-607: ----------------------------------- [~sbunciak], FYI, I added this to sramp.properties: {code} # S-RAMP will automatically attempt to discover a JMS ConnectionFactory through the literal JNDI name # "ConnectionFactory". However, that name can be overridden here. sramp.config.events.jms.connectionfactory = ConnectionFactory {code} > Hardcoded connection factory jndi name in JMSEventProducer > ---------------------------------------------------------- > > Key: SRAMP-607 > URL: https://issues.jboss.org/browse/SRAMP-607 > Project: S-RAMP > Issue Type: Bug > Components: Core > Affects Versions: 0.6.0.Final > Reporter: Stefan Bunciak > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 10:11:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 10:11:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-606 started by Brett Meyer. ----------------------------------------- > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/name/value/uuid > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 10:12:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 10:12:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016418#comment-13016418 ] Brett Meyer commented on SRAMP-606: ----------------------------------- [~giorgimode], thanks for the great write-up -- I'll see what I can do to reproduce it. > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/name/value/uuid > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 12:47:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 12:47:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016503#comment-13016503 ] Brett Meyer commented on SRAMP-606: ----------------------------------- [~giorgimode], here's the issue. RESTEasy was pulling in NamespacePrefixMapper from 2 different ClassLoaders: 1.) the com.sun.xml.bind EAP module and 2.) your app. #2 is transitive, included by the s-ramp-client dependency. The quick fix: {code} org.overlord.sramp s-ramp-client 0.7.0-SNAPSHOT com.sun.xml.bind jaxb-impl ... com.sun.xml.bind,org.jboss.resteasy.resteasy-jaxrs,org.apache.httpcomponents {code} Note the addition of the com.sun.xml.bind module in the manifestEntries. After I did that, it worked perfectly. For now, I think the "fix" is going to be mentioning this caveat in our docs. Having to do platform-specific builds of s-ramp-client isn't really something I think we should spend time on, nor is it worth the maintenance. Hopefully that helps! > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/name/value/uuid > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 13:00:35 2014 From: issues at jboss.org (Giorgi Modebadze (JIRA)) Date: Fri, 31 Oct 2014 13:00:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016508#comment-13016508 ] Giorgi Modebadze commented on SRAMP-606: ---------------------------------------- Thanks a lot for the fix. The workaround I came up with was to manually replace the UpdateMetaDataResource.class in dtgov.war with my UpdateMetaDataResource class and redeploy dtgov.war. But in future, good to know I can use additional REST calls without redeploying whole dtgov.war. > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/name/value/uuid > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 13:24:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 13:24:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-606) Unable to use update custom metadata using REST call In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-606. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Unable to use update custom metadata using REST call > ---------------------------------------------------- > > Key: SRAMP-606 > URL: https://issues.jboss.org/browse/SRAMP-606 > Project: S-RAMP > Issue Type: Bug > Components: Atom Binding, S-RAMP API > Affects Versions: 0.6.0.Final > Reporter: Giorgi Modebadze > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > I created my own work item handler and deployed it on EAP. My modified UpdateMetaDataResource adds custom properties to artifact on S-RAMP according to some key value. > E.g. PUT call to Rest Service: > http://localhost:8080/s-ramp-adapter/rest/update/property/key/Testvalue/d6df0626-0a70-48a6-bb34-fc0f478b81bd > As a result, artifact with the given UUID will have property with name key and value Testvalue. > Here is the simple code that accepts REST calls: > https://gist.github.com/anonymous/469be08cc2610e727517 > Here's the pom.xml > https://gist.github.com/anonymous/08a3c91163c682cc6cd0 > The error from EAP: > https://gist.github.com/anonymous/b6422e498a3a90f4c28c > Predefined URLs for updating metadata work alright on EAP. E.g. > http://localhost:8080/dtgov/rest/update/name/value/uuid > Problem is produced on custom Rest calls only. > Everything works fine on Jetty, error is produced on EAP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 14:49:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 14:49:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-594) s-ramp:getMetaData command returns npe In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-594. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > s-ramp:getMetaData command returns npe > -------------------------------------- > > Key: SRAMP-594 > URL: https://issues.jboss.org/browse/SRAMP-594 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.6.0.Final > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > After working through section 7 in the user guide, I had set the description property on an artifact and then exited the cli. > When I went back into the console and connected, I then issued the command: > s-ramp:getMetaData feed:15 > and got: > {noformat} > java.lang.NullPointerException > at org.overlord.sramp.shell.commands.core.GetMetaDataCommand.execute(GetMetaDataCommand.java:71) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:103) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:601) > at com.simontuffs.onejar.Boot.run(Boot.java:340) > at com.simontuffs.onejar.Boot.main(Boot.java:166) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 14:50:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 14:50:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-591) Default EAP 6.3 Installation throws ERROR:Naming context is read-only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-591. ------------------------------- Fix Version/s: 0.7.0.Final Resolution: Done > Default EAP 6.3 Installation throws ERROR:Naming context is read-only > --------------------------------------------------------------------- > > Key: SRAMP-591 > URL: https://issues.jboss.org/browse/SRAMP-591 > Project: S-RAMP > Issue Type: Bug > Environment: CentOs 7 (3.10.0-123.el7.x86_64), > JAVA: java version "1.7.0_65"; OpenJDK Runtime Environment (rhel-2.5.1.2.el7_0-x86_64 u65-b17); OpenJDK 64-Bit Server VM (build 24.65-b04, mixed mode) > Apache Ant 1.9.2 > The whole system runs inside of a virtual box with 4GB RAM, 2 CPUs and 50GB Harddrive. > Reporter: Sebastian Goschin > Assignee: Brett Meyer > Fix For: 0.7.0.Final > > > After installing DTgov and S-RAMP at EAP 6.3 and before installing workflows and ontologies of DTgov 1.4 by "ant seed", the EAP 6.3 throws errors during startup. > 18:18:49,657 WARN [org.overlord.sramp.events.jms.JMSEventProducer] (ServerService Thread Pool -- 58) Could not discover "ConnectionFactory" and/or the configured topics/queues over JNDI. Assuming a non-EE environment or that JMS/JNDI isnt configured. Falling back on an embedded ActiveMQ broker, available on {0} > 18:18:50,196 INFO [org.apache.activemq.store.kahadb.plist.PListStoreImpl] (ServerService Thread Pool -- 58) PListStore:[/home/admin/activemq-data/localhost/tmp_storage] started > 18:18:50,201 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Using Persistence Adapter: KahaDBPersistenceAdapter[/home/admin/activemq-data/localhost/KahaDB] > 18:18:50,234 INFO [org.jboss.solder.exception.control.extension] (MSC service thread 1-4) Adding handler Qualifiers: [@javax.enterprise.inject.Any()] TraversalMode: BREADTH_FIRST Handles Type: class java.lang.Throwable Precedence: -100 [method] public org.jboss.seam.transaction.SimpleTransactionExceptionHandler.markTransactionRollback(CaughtException) to known handlers > 18:18:50,248 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:50,279 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:50,280 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:50,281 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:50,282 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:50,556 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.sramp.governance.workflow.jbpm.ProcessService.processBean > 18:18:50,560 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.jbpm.ProcessBean.processEngineService > 18:18:50,581 WARN [org.jboss.weld.Bootstrap] (MSC service thread 1-4) WELD-001440 Scope type @javax.enterprise.context.ApplicationScoped() used on injection point [field] @ApplicationScoped @Inject private org.overlord.dtgov.taskapi.TaskApi.processEngineService > 18:18:50,799 INFO [org.jboss.web] (ServerService Thread Pool -- 68) JBAS018210: Register web context: /dtgov > 18:18:51,107 INFO [solder-servlet] (ServerService Thread Pool -- 68) Catch Integration for Servlets enabled > 18:18:57,085 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) KahaDB is version 4 > 18:18:57,110 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovering from the journal ... > 18:18:57,111 INFO [org.apache.activemq.store.kahadb.MessageDatabase] (ServerService Thread Pool -- 58) Recovery replayed 2 operations from the journal in 0.008 seconds. > 18:18:57,162 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) is starting > 18:18:57,176 INFO [org.apache.activemq.transport.TransportServerThreadSupport] (ServerService Thread Pool -- 58) Listening for connections at: tcp://localhost:61616 > 18:18:57,177 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector tcp://localhost:61616 Started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Apache ActiveMQ 5.8.0 (localhost, ID:overlordtestserver-38457-1412871529503-2:1) started > 18:18:57,178 INFO [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) For help or more information please see: http://activemq.apache.org > 18:18:57,178 WARN [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Store limit is 102400 mb, whilst the data directory: /home/admin/activemq-data/localhost/KahaDB only has 44079 mb of usable space > 18:18:57,179 ERROR [org.apache.activemq.broker.BrokerService] (ServerService Thread Pool -- 58) Temporary Store limit is 51200 mb, whilst the temporary data directory: /home/admin/activemq-data/localhost/tmp_storage only has 44079 mb of usable space > 18:18:57,211 ERROR [stderr] (JMX connector) Exception in thread "JMX connector" java.lang.UnsupportedOperationException: JBAS011859: Naming context is read-only > 18:18:57,211 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.requireOwner(WritableServiceBasedNamingStore.java:155) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.WritableServiceBasedNamingStore.bind(WritableServiceBasedNamingStore.java:63) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:248) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.InitialContext$DefaultInitialContext.bind(InitialContext.java:268) > 18:18:57,213 ERROR [stderr] (JMX connector) at org.jboss.as.naming.NamingContext.bind(NamingContext.java:257) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,213 ERROR [stderr] (JMX connector) at javax.naming.InitialContext.bind(InitialContext.java:419) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:643) > 18:18:57,214 ERROR [stderr] (JMX connector) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:426) > 18:18:57,214 ERROR [stderr] (JMX connector) at org.apache.activemq.broker.jmx.ManagementContext$1.run(ManagementContext.java:131) > 18:18:57,218 INFO [org.apache.activemq.broker.TransportConnector] (ServerService Thread Pool -- 58) Connector vm://localhost Started -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 15:05:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 15:05:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-199) Wsdl and Xsd Derivers are not setting up import/include relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13016535#comment-13016535 ] Brett Meyer commented on SRAMP-199: ----------------------------------- Superseded by SRAMP-547 > Wsdl and Xsd Derivers are not setting up import/include relationships > --------------------------------------------------------------------- > > Key: SRAMP-199 > URL: https://issues.jboss.org/browse/SRAMP-199 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.2.0 - Security & S-RAMP-1.0 > Reporter: Eric Wittmann > Assignee: Brett Meyer > > The XSD deriver and WSDL derivers need to set up relationships to other xsd/wsdl documents when they are imported or included. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 15:05:36 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 15:05:36 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-199) Wsdl and Xsd Derivers are not setting up import/include relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-199. ----------------------------- Resolution: Duplicate Issue > Wsdl and Xsd Derivers are not setting up import/include relationships > --------------------------------------------------------------------- > > Key: SRAMP-199 > URL: https://issues.jboss.org/browse/SRAMP-199 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.2.0 - Security & S-RAMP-1.0 > Reporter: Eric Wittmann > Assignee: Brett Meyer > > The XSD deriver and WSDL derivers need to set up relationships to other xsd/wsdl documents when they are imported or included. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Oct 31 15:20:35 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 31 Oct 2014 15:20:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-456) CXF version mismatch causing WebServiceTest to fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-456. ----------------------------- Resolution: Out of Date Out-of-date. The SwitchYard multiapp demo has been replaced by a generic servlet multiapp demo. > CXF version mismatch causing WebServiceTest to fail > --------------------------------------------------- > > Key: SRAMP-456 > URL: https://issues.jboss.org/browse/SRAMP-456 > Project: S-RAMP > Issue Type: Bug > Reporter: Gary Brown > Assignee: Brett Meyer > > Switchyard is currently using an older version of the IP BOM (CR6), which has version 2.6.8, while current version for alpha is supposed to be CR9, which has cxf 2.7.11. > This is causing a CNFE for org.apache.cxf.io.CopyingOutputStream. > Currently ignoring the test until versions are aligned. -- This message was sent by Atlassian JIRA (v6.3.1#6329)