From issues at jboss.org Tue Sep 2 12:41:59 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Sep 2014 12:41:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-561) Support Fuse JMS In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-561: --------------------------------- Summary: Support Fuse JMS Key: SRAMP-561 URL: https://issues.jboss.org/browse/SRAMP-561 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: David virgil naranjo Fix For: 0.6.0 SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 13:28:00 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Sep 2014 13:28:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-433) Create a proper Event producer for s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-433. ------------------------------- Resolution: Done > Create a proper Event producer for s-ramp > ----------------------------------------- > > Key: SRAMP-433 > URL: https://issues.jboss.org/browse/SRAMP-433 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently dtgov monitors s-ramp for changes by polling. It would be more efficient if dtgov could listen for events it cared about. > Ideally we could add a listener to the s-ramp repository either at the global level or by including a filter of some kind, so we can make sure to get only a subset of the total events coming from the server. > Event design thoughts: https://community.jboss.org/message/884274 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 15:19:00 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 2 Sep 2014 15:19:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-562) Convert S-RAMP UI errai services to jax-rs endpoints In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-562: ----------------------------------- Summary: Convert S-RAMP UI errai services to jax-rs endpoints Key: SRAMP-562 URL: https://issues.jboss.org/browse/SRAMP-562 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Components: UI Reporter: Eric Wittmann Assignee: Brett Meyer Currently we use Errai RPC services to communicate between the UI client and the server. We should switch all of these from Errai RPC to REST, which would allow us to remove all server-side Errai dependencies and thus no longer use CDI. This is a big win when running in Fuse and it doesn't make the UI any more complicated. It also has the side effect of introducing a REST API for the user interface, potentially allowing alternative implementations, integrations, embedded components in other UIs, etc. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 15:20:59 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 2 Sep 2014 15:20:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-563) Convert DTGov UI errai services to jax-rs endpoints In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-563: ----------------------------------- Summary: Convert DTGov UI errai services to jax-rs endpoints Key: SRAMP-563 URL: https://issues.jboss.org/browse/SRAMP-563 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Components: UI Reporter: Eric Wittmann Assignee: Brett Meyer Currently we use Errai RPC services to communicate between the UI client and the server. We should switch all of these from Errai RPC to REST, which would allow us to remove all server-side Errai dependencies and thus no longer use CDI. This is a big win when running in Fuse and it doesn't make the UI any more complicated. It also has the side effect of introducing a REST API for the user interface, potentially allowing alternative implementations, integrations, embedded components in other UIs, etc. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 2 15:59:59 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 2 Sep 2014 15:59:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-120) GitHub CNAME file In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved OVERLORD-120. ---------------------------------- Resolution: Done > GitHub CNAME file > ----------------- > > Key: OVERLORD-120 > URL: https://issues.jboss.org/browse/OVERLORD-120 > Project: Overlord > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 04:51:59 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 4 Sep 2014 04:51:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-409) Overlord commons Messages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998722#comment-12998722 ] David virgil naranjo commented on SRAMP-409: -------------------------------------------- https://github.com/dvirgiln/overlord-commons/tree/messages https://github.com/dvirgiln/s-ramp/tree/messages > Overlord commons Messages > ------------------------- > > Key: SRAMP-409 > URL: https://issues.jboss.org/browse/SRAMP-409 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Create a new project in Overlord-commons called overlord-commons-messages. > Then use this Messages abstraction in S-ramp and dtgov. In case necessary, in these projects extends the CommonMessages functionality and customize it. > Also add the overlord-commons-messages to the project overlord-commons-ant and use it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 05:49:00 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 4 Sep 2014 05:49:00 -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:all-tabpanel ] David virgil naranjo updated OVERLORD-117: ------------------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/105 > 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 > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > > 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 Thu Sep 4 06:06:00 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 4 Sep 2014 06:06:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-542) If a SNAPSHOT artifact does not include a timestamp, have DeployCommand generate it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-542: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/482 > If a SNAPSHOT artifact does not include a timestamp, have DeployCommand generate it > ----------------------------------------------------------------------------------- > > Key: SRAMP-542 > URL: https://issues.jboss.org/browse/SRAMP-542 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > Priority: Minor > Fix For: 0.6.0 > > > Low priority -- we shouldn't consider this until 0.6. > DeployCommand is currently assuming a SNAPSHOT artifact includes a timestamp. But, if I'm using the CLI to deploy a locally built artifact, it won't. Consider automatically generating a timestamp if it's missing so that I can upload new snapshots. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 08:32:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 4 Sep 2014 08:32:02 -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:all-tabpanel ] Eric Wittmann resolved OVERLORD-141. ------------------------------------ Resolution: Done > 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 > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > 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 Thu Sep 4 08:33:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 4 Sep 2014 08:33:02 -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:all-tabpanel ] Eric Wittmann updated OVERLORD-141: ----------------------------------- Fix Version/s: Overlord-Commons-2.0.9.Final > 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 > Security Level: Public(Everyone can see) > 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 Thu Sep 4 08:33:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 4 Sep 2014 08:33:02 -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:all-tabpanel ] Eric Wittmann updated OVERLORD-140: ----------------------------------- Fix Version/s: Overlord-Commons-2.0.9.Final > Ensure consistent fav icon for all overlord apps > ------------------------------------------------ > > Key: OVERLORD-140 > URL: https://issues.jboss.org/browse/OVERLORD-140 > Project: Overlord > Issue Type: Enhancement > Security Level: Public(Everyone can see) > 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 Thu Sep 4 08:33:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 4 Sep 2014 08:33:03 -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:all-tabpanel ] Eric Wittmann resolved OVERLORD-140. ------------------------------------ Resolution: Done > Ensure consistent fav icon for all overlord apps > ------------------------------------------------ > > Key: OVERLORD-140 > URL: https://issues.jboss.org/browse/OVERLORD-140 > Project: Overlord > Issue Type: Enhancement > Security Level: Public(Everyone can see) > 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 Thu Sep 4 08:33:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 4 Sep 2014 08:33:03 -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:all-tabpanel ] Eric Wittmann closed OVERLORD-141. ---------------------------------- > 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 > Security Level: Public(Everyone can see) > 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 Thu Sep 4 08:33:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 4 Sep 2014 08:33:03 -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:all-tabpanel ] Eric Wittmann closed OVERLORD-140. ---------------------------------- > Ensure consistent fav icon for all overlord apps > ------------------------------------------------ > > Key: OVERLORD-140 > URL: https://issues.jboss.org/browse/OVERLORD-140 > Project: Overlord > Issue Type: Enhancement > Security Level: Public(Everyone can see) > 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 Thu Sep 4 09:05:00 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 09:05:00 -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:all-tabpanel ] Brett Meyer resolved OVERLORD-117. ---------------------------------- Fix Version/s: Overlord-Commons-2.0.9.Final Resolution: Done > 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 > Security Level: Public(Everyone can see) > 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 Thu Sep 4 10:29:01 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 4 Sep 2014 10:29:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-561) Support Fuse JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998948#comment-12998948 ] David virgil naranjo commented on SRAMP-561: -------------------------------------------- This is the IRC conversation with the fuse fabric guys: virchete use the JMS API [16:22] --> theute (~theute at redhat/jboss/theute) se ha unido a este canal. [16:22] Queue queue = new ActiveMQ("any.name.you.like") [16:22] Queue queue = new ActiveMQQueue("any.name.you.like") [16:23] jstrachan but for example in JBoss EAP you need to define in the standalone-full.xml the queues and topics [16:23] virchete: or session.createQueue("any.name.you.like") [16:23] virchete: jboss likes to make it hard. [16:23] :) [16:23] jaja [16:23] ok chrino [16:23] with activemq things are easy. [16:23] then you mean if [16:23] i include the active mq features [16:24] then using the Queue queue = new ActiveMQQueue("any.name.you.like") [16:24] would work [16:24] yeah. [16:24] you have code that's using JMS already right? [16:24] yes [16:24] yep [16:24] that's it > Support Fuse JMS > ---------------- > > Key: SRAMP-561 > URL: https://issues.jboss.org/browse/SRAMP-561 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. > Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:35:00 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 10:35:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-538) password encryption in overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-538. ------------------------------- Fix Version/s: 0.5.0.Final Resolution: Done > password encryption in overlord commons > --------------------------------------- > > Key: SRAMP-538 > URL: https://issues.jboss.org/browse/SRAMP-538 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Adapt the installers and distribution packages to the new changes done in overlord commons to encrypt the overlord.properties passwords: > Related overlord-commons jira: > https://issues.jboss.org/browse/OVERLORD-128 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:35:01 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 10:35:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-538) password encryption in overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-538. ----------------------------- > password encryption in overlord commons > --------------------------------------- > > Key: SRAMP-538 > URL: https://issues.jboss.org/browse/SRAMP-538 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Adapt the installers and distribution packages to the new changes done in overlord commons to encrypt the overlord.properties passwords: > Related overlord-commons jira: > https://issues.jboss.org/browse/OVERLORD-128 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:37:01 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 10:37:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-128) Encrypt the passwords in overlord.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved OVERLORD-128. ---------------------------------- Fix Version/s: Overlord-Commons-2.0.7.Final Resolution: Done > Encrypt the passwords in overlord.properties > -------------------------------------------- > > Key: OVERLORD-128 > URL: https://issues.jboss.org/browse/OVERLORD-128 > Project: Overlord > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.7.Final > > > The password properties inside of the overlord.properties file should be encrypted in the properties file and then decrypted by the application whenever the encrypted properties are used. > Properties to be encrypted: > overlord.auth.saml-key-alias-password > overlord.auth.saml-keystore-password > It can be used as synchronous security encrypting algorithm, the AES Encrypting algorithm. > It can be used commons-coded. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:37:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 10:37:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-128) Encrypt the passwords in overlord.properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed OVERLORD-128. -------------------------------- > Encrypt the passwords in overlord.properties > -------------------------------------------- > > Key: OVERLORD-128 > URL: https://issues.jboss.org/browse/OVERLORD-128 > Project: Overlord > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: Overlord-Commons-2.0.7.Final > > > The password properties inside of the overlord.properties file should be encrypted in the properties file and then decrypted by the application whenever the encrypted properties are used. > Properties to be encrypted: > overlord.auth.saml-key-alias-password > overlord.auth.saml-keystore-password > It can be used as synchronous security encrypting algorithm, the AES Encrypting algorithm. > It can be used commons-coded. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:38:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 10:38:03 -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:all-tabpanel ] Brett Meyer resolved SRAMP-380. ------------------------------- Resolution: Done > 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 > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > 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 Thu Sep 4 10:39:01 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 10:39:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-527) Add overlord.properties to fuse fabric profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-527. ------------------------------- Fix Version/s: 0.5.0.Final Resolution: Done > Add overlord.properties to fuse fabric profile > ---------------------------------------------- > > Key: SRAMP-527 > URL: https://issues.jboss.org/browse/SRAMP-527 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Add the overlord.properties file to the overlord fuse fabric profile. > Try the deployment in fuse fabric. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 10:39:01 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 10:39:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-527) Add overlord.properties to fuse fabric profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-527. ----------------------------- > Add overlord.properties to fuse fabric profile > ---------------------------------------------- > > Key: SRAMP-527 > URL: https://issues.jboss.org/browse/SRAMP-527 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Add the overlord.properties file to the overlord fuse fabric profile. > Try the deployment in fuse fabric. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 11:03:01 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 4 Sep 2014 11:03:01 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-561) Support Fuse JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12998969#comment-12998969 ] David virgil naranjo commented on SRAMP-561: -------------------------------------------- [16:47] yeah.. so I'd just use new ActiveMQConnectionFactory(url) [16:47] and make url configurable. [16:47] when in fabric, configure url="fabric://default" [16:48] and the client will connect to a random broker in the default group. [16:48] if not in fabric, configure url to be something like: "failover://(tcp://localhost:61616)" [16:48] where your explictly configuring where the broker is running. [16:50] by default that is the port [16:50] 61616 [16:50] yeah [16:50] ok man [16:50] very helpful [16:51] if anytime you have a doubt about jboss overlord project [16:51] come to me [16:51] xD [16:51] ok thx! > Support Fuse JMS > ---------------- > > Key: SRAMP-561 > URL: https://issues.jboss.org/browse/SRAMP-561 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. > Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 4 11:08:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 4 Sep 2014 11:08:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-542) If a SNAPSHOT artifact does not include a timestamp, have DeployCommand generate it In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-542. ------------------------------- Resolution: Done > If a SNAPSHOT artifact does not include a timestamp, have DeployCommand generate it > ----------------------------------------------------------------------------------- > > Key: SRAMP-542 > URL: https://issues.jboss.org/browse/SRAMP-542 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > Priority: Minor > Fix For: 0.6.0 > > > Low priority -- we shouldn't consider this until 0.6. > DeployCommand is currently assuming a SNAPSHOT artifact includes a timestamp. But, if I'm using the CLI to deploy a locally built artifact, it won't. Consider automatically generating a timestamp if it's missing so that I can upload new snapshots. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 08:37:59 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 5 Sep 2014 08:37:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-564) Fuse Deployment, Class Not found exception org.overlord.sramp.events In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-564: ------------------------------------------ Summary: Fuse Deployment, Class Not found exception org.overlord.sramp.events Key: SRAMP-564 URL: https://issues.jboss.org/browse/SRAMP-564 Project: S-RAMP Issue Type: Bug Reporter: David virgil naranjo Assignee: David virgil naranjo There is an exception in Fuse Fabric related with two new packages included in s-ramp: java.lang.NoClassDefFoundError: org/overlord/sramp/events/EventProducerFactory the packages to be included in the pom.xml of s-ramp-server are org/overlord/sramp/events and org/overlord/sramp/events.jms -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 08:42:59 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 5 Sep 2014 08:42:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-564) Fuse Deployment, Class Not found exception org.overlord.sramp.events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-564: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/483 > Fuse Deployment, Class Not found exception org.overlord.sramp.events > -------------------------------------------------------------------- > > Key: SRAMP-564 > URL: https://issues.jboss.org/browse/SRAMP-564 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > There is an exception in Fuse Fabric related with two new packages included in s-ramp: > java.lang.NoClassDefFoundError: org/overlord/sramp/events/EventProducerFactory > the packages to be included in the pom.xml of s-ramp-server are > org/overlord/sramp/events and org/overlord/sramp/events.jms -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 10:19:00 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 5 Sep 2014 10:19:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-561) Support Fuse JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-561: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/484 > Support Fuse JMS > ---------------- > > Key: SRAMP-561 > URL: https://issues.jboss.org/browse/SRAMP-561 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. > Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 5 10:43:00 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 5 Sep 2014 10:43:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-564) Fuse Deployment, Class Not found exception org.overlord.sramp.events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-564. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > Fuse Deployment, Class Not found exception org.overlord.sramp.events > -------------------------------------------------------------------- > > Key: SRAMP-564 > URL: https://issues.jboss.org/browse/SRAMP-564 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > There is an exception in Fuse Fabric related with two new packages included in s-ramp: > java.lang.NoClassDefFoundError: org/overlord/sramp/events/EventProducerFactory > the packages to be included in the pom.xml of s-ramp-server are > org/overlord/sramp/events and org/overlord/sramp/events.jms -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 06:40:00 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 8 Sep 2014 06:40:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-561) Support Fuse JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999812#comment-12999812 ] David virgil naranjo commented on SRAMP-561: -------------------------------------------- Related fuse fabric integration: https://developer.jboss.org/message/903193#903193 > Support Fuse JMS > ---------------- > > Key: SRAMP-561 > URL: https://issues.jboss.org/browse/SRAMP-561 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. > Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 07:05:00 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 8 Sep 2014 07:05:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: Gary Brown created RTGOV-568: -------------------------------- Summary: Update elasticsearch to 1.3.2 Key: RTGOV-568 URL: https://issues.jboss.org/browse/RTGOV-568 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 07:06:00 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 8 Sep 2014 07:06:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-568: ----------------------------- Fix Version/s: 2.0.0.Final > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 08:35:59 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 8 Sep 2014 08:35:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-569) Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 In-Reply-To: References: Message-ID: Gary Brown created RTGOV-569: -------------------------------- Summary: Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 Key: RTGOV-569 URL: https://issues.jboss.org/browse/RTGOV-569 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Related to comment on RTGOV-556 - the switchyard version used in the FSW 6.0 RTGOV UI war is 2.x where it should be 1.x. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 08:42:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 8 Sep 2014 08:42:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-569) Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-569: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/199 > Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 > -------------------------------------------------------------------------- > > Key: RTGOV-569 > URL: https://issues.jboss.org/browse/RTGOV-569 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Related to comment on RTGOV-556 - the switchyard version used in the FSW 6.0 RTGOV UI war is 2.x where it should be 1.x. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 08:43:00 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 8 Sep 2014 08:43:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-569) Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-569. ------------------------------ Resolution: Done > Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 > -------------------------------------------------------------------------- > > Key: RTGOV-569 > URL: https://issues.jboss.org/browse/RTGOV-569 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Related to comment on RTGOV-556 - the switchyard version used in the FSW 6.0 RTGOV UI war is 2.x where it should be 1.x. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 11:13:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Sep 2014 11:13:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-560) Exception deployment on Fuse and Fuse Fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-560. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > Exception deployment on Fuse and Fuse Fabric > -------------------------------------------- > > Key: SRAMP-560 > URL: https://issues.jboss.org/browse/SRAMP-560 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > There is an exception in the deployment of s-ramp in Fuse and Fuse Fabric. Some packages has been removed from the project s-ramp-atom > at org.apache.karaf.shell.console.jline.DelayedStarted.run(DelayedStarted.java:61)[17:org.apache.karaf.shell.console:2.3.0.redhat-610379] > Caused by: org.osgi.framework.BundleException: Unresolved constraint in bundle org.overlord.sramp.s-ramp-server-fuse61 [409]: Unable to resolve 409.0: missing requirement [409.0] osgi.wiring.package; (osgi.wiring.package=org.overlord.sramp.atom.services.brms.packages) > at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4225)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] > at org.apache.felix.framework.Felix.startBundle(Felix.java:2063)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:955)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] > at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:942)[org.apache.felix.framework-4.0.3.redhat-610379.jar:] > at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:474)[22:org.apache.karaf.features.core:2.3.0.redhat-610379] > ... 15 more > Remove the non existing packages in the Import-Package tag, of the s-ramp-server pom.xml -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 11:13:59 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Sep 2014 11:13:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-409) Overlord commons Messages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-409: ------------------------------ Priority: Minor (was: Major) > Overlord commons Messages > ------------------------- > > Key: SRAMP-409 > URL: https://issues.jboss.org/browse/SRAMP-409 > Project: S-RAMP > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Priority: Minor > > Create a new project in Overlord-commons called overlord-commons-messages. > Then use this Messages abstraction in S-ramp and dtgov. In case necessary, in these projects extends the CommonMessages functionality and customize it. > Also add the overlord-commons-messages to the project overlord-commons-ant and use it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 11:14:00 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Sep 2014 11:14:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-409) Overlord commons Messages In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999976#comment-12999976 ] Brett Meyer commented on SRAMP-409: ----------------------------------- Leaving this open. But, based on discussions, deferring. It's an admirable thought, but has quite a few implications that need thoroughly addressed. > Overlord commons Messages > ------------------------- > > Key: SRAMP-409 > URL: https://issues.jboss.org/browse/SRAMP-409 > Project: S-RAMP > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Priority: Minor > > Create a new project in Overlord-commons called overlord-commons-messages. > Then use this Messages abstraction in S-ramp and dtgov. In case necessary, in these projects extends the CommonMessages functionality and customize it. > Also add the overlord-commons-messages to the project overlord-commons-ant and use it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 8 11:16:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 8 Sep 2014 11:16:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-457) S-ramp installer error when installing over an existing server instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-457. ----------------------------- Resolution: Rejected According to David, this was opened in error. Closing. > S-ramp installer error when installing over an existing server instance > ----------------------------------------------------------------------- > > Key: SRAMP-457 > URL: https://issues.jboss.org/browse/SRAMP-457 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Error in the s-ramp distro assembly for jboss eap: > > > > It happens when it is installed over a not clean jboss server instance: > > Steps: > > Unzip Jboss eap 6.3 Alpha > > Install switchyard over eap > > execute the ant s-ramp-distro assembly build > > If you run now jboss eap it will work. > > Install again s-ramp in jboss eap then causes the following error: > https://gist.github.com/dvirgiln/b2f5f80234c97fc2b3b1 > The overlord-commons installer will get skipped if run multiple times, > but it does this by looking for the keystore. If it finds the keystore > it assumes that it's already been run and skips itself. > Nothing like this exists for s-ramp. So it will make all the > standalone.xml changes (using XSLT) each time you run it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 9 09:24:59 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 9 Sep 2014 09:24:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-561) Support Fuse JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-561: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/484, https://github.com/Governance/overlord-commons/pull/106 (was: https://github.com/Governance/s-ramp/pull/484) > Support Fuse JMS > ---------------- > > Key: SRAMP-561 > URL: https://issues.jboss.org/browse/SRAMP-561 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. > Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 9 09:31:01 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 9 Sep 2014 09:31:01 -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.10.Final (was: Overlord-Commons-2.0.8.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.10.Final > > > 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 Tue Sep 9 09:31:01 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 9 Sep 2014 09:31:01 -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.10.Final (was: Overlord-Commons-2.0.8.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.10.Final > > > 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 Tue Sep 9 14:16:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Sep 2014 14:16:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-145) Re-write the home page's "What is Overlord?" In-Reply-To: References: Message-ID: Brett Meyer created OVERLORD-145: ------------------------------------ Summary: Re-write the home page's "What is Overlord?" Key: OVERLORD-145 URL: https://issues.jboss.org/browse/OVERLORD-145 Project: Overlord Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer "What is Overlord?" is old and could be better utilized. Re-write -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 9 15:48:00 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Sep 2014 15:48:00 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-145) Re-write the home page's "What is Overlord?" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000509#comment-13000509 ] Brett Meyer commented on OVERLORD-145: -------------------------------------- [~eric.wittmann], [~objectiser], any ideas on this one? > Re-write the home page's "What is Overlord?" > -------------------------------------------- > > Key: OVERLORD-145 > URL: https://issues.jboss.org/browse/OVERLORD-145 > Project: Overlord > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > "What is Overlord?" is old and could be better utilized. Re-write -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 9 16:16:59 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Sep 2014 16:16:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-525) Release plugin not changing the artifact versions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-525. ----------------------------- Resolution: Out of Date Closing -- not worth the time to investigate. release.sh doesn't even use the plugin > Release plugin not changing the artifact versions > ------------------------------------------------- > > Key: SRAMP-525 > URL: https://issues.jboss.org/browse/SRAMP-525 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > > The release plugin doesn't appear to be changing the artifact versions. All POMs have the same SNAPSHOT version, even after correctly setting the release version with the release.sh script. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 9 16:22:59 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Sep 2014 16:22:59 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-557) "No artifacts found" shown erroneously when artifact type suggestion is clicked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-557 started by Brett Meyer. ----------------------------------------- > "No artifacts found" shown erroneously when artifact type suggestion is clicked > ------------------------------------------------------------------------------- > > Key: SRAMP-557 > URL: https://issues.jboss.org/browse/SRAMP-557 > Project: S-RAMP > Issue Type: Bug > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Minor > > In the UI, upload an xsd. Then, on the left, search for the "XsdDocumen" type (leave off the "t"), then click the suggestion. The display shows results, but also shows "No artifacts found." in addition. Logic off? Note that this *only* happens when the suggestion is clicked. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 9 20:25:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 9 Sep 2014 20:25:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-557) "No artifacts found" shown erroneously when artifact type suggestion is clicked In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-557. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > "No artifacts found" shown erroneously when artifact type suggestion is clicked > ------------------------------------------------------------------------------- > > Key: SRAMP-557 > URL: https://issues.jboss.org/browse/SRAMP-557 > Project: S-RAMP > Issue Type: Bug > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > In the UI, upload an xsd. Then, on the left, search for the "XsdDocumen" type (leave off the "t"), then click the suggestion. The display shows results, but also shows "No artifacts found." in addition. Logic off? Note that this *only* happens when the suggestion is clicked. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 10 11:11:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Sep 2014 11:11:19 -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:all-tabpanel ] Work on SRAMP-545 started by Brett Meyer. ----------------------------------------- > 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 > > > 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 Wed Sep 10 11:18:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 10 Sep 2014 11:18:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-565) Ontology download button is broken In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-565: --------------------------------- Summary: Ontology download button is broken Key: SRAMP-565 URL: https://issues.jboss.org/browse/SRAMP-565 Project: S-RAMP Issue Type: Bug Reporter: Brett Meyer Assignee: Brett Meyer The ontology download button leads to: http://localhost:8080/s-ramp-ui/app/services/ontologyDownload?uuid=[uuid] It currently 404s -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 11:06:19 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 11 Sep 2014 11:06:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-146) OSGi issue with overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann moved APIMAN-149 to OVERLORD-146: ----------------------------------------------- Project: Overlord (was: APIMan (API Management)) Key: OVERLORD-146 (was: APIMAN-149) Affects Version/s: Overlord-Commons-2.0.9.Final (was: 1.0.0.Alpha) Component/s: (was: Gateway) Fix Version/s: Overlord-Commons-2.0.10.Final (was: 1.0.0.Beta) (was: 1.0.0.Final) > OSGi issue with overlord commons > -------------------------------- > > Key: OVERLORD-146 > URL: https://issues.jboss.org/browse/OVERLORD-146 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.9.Final > Reporter: Kurt Stam > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.10.Final > > > missing requirement [org.overlord.apiman.rt-engine-core/1.0.0.Alpha1] osgi.wiring.package; filter:="(osgi.wiring.package=org.overlord.commons.i18n)"]]]] > The overlord.commons.i18n package is not exported, and therefor the engine can not see it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 11:06:19 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 11 Sep 2014 11:06:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-146) OSGi issue with overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on OVERLORD-146 started by Eric Wittmann. ---------------------------------------------- > OSGi issue with overlord commons > -------------------------------- > > Key: OVERLORD-146 > URL: https://issues.jboss.org/browse/OVERLORD-146 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.9.Final > Reporter: Kurt Stam > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.10.Final > > > missing requirement [org.overlord.apiman.rt-engine-core/1.0.0.Alpha1] osgi.wiring.package; filter:="(osgi.wiring.package=org.overlord.commons.i18n)"]]]] > The overlord.commons.i18n package is not exported, and therefor the engine can not see it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 13:27:19 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 11 Sep 2014 13:27:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-146) OSGi issue with overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated OVERLORD-146: ----------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/107 > OSGi issue with overlord commons > -------------------------------- > > Key: OVERLORD-146 > URL: https://issues.jboss.org/browse/OVERLORD-146 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.9.Final > Reporter: Kurt Stam > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.10.Final > > > missing requirement [org.overlord.apiman.rt-engine-core/1.0.0.Alpha1] osgi.wiring.package; filter:="(osgi.wiring.package=org.overlord.commons.i18n)"]]]] > The overlord.commons.i18n package is not exported, and therefor the engine can not see it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 13:27:19 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 11 Sep 2014 13:27:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-146) OSGi issue with overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved OVERLORD-146. ------------------------------------ Resolution: Done > OSGi issue with overlord commons > -------------------------------- > > Key: OVERLORD-146 > URL: https://issues.jboss.org/browse/OVERLORD-146 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.9.Final > Reporter: Kurt Stam > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.10.Final > > > missing requirement [org.overlord.apiman.rt-engine-core/1.0.0.Alpha1] osgi.wiring.package; filter:="(osgi.wiring.package=org.overlord.commons.i18n)"]]]] > The overlord.commons.i18n package is not exported, and therefor the engine can not see it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 13:27:20 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 11 Sep 2014 13:27:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-146) OSGi issue with overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed OVERLORD-146. ---------------------------------- > OSGi issue with overlord commons > -------------------------------- > > Key: OVERLORD-146 > URL: https://issues.jboss.org/browse/OVERLORD-146 > Project: Overlord > Issue Type: Bug > Affects Versions: Overlord-Commons-2.0.9.Final > Reporter: Kurt Stam > Assignee: Eric Wittmann > Fix For: Overlord-Commons-2.0.10.Final > > > missing requirement [org.overlord.apiman.rt-engine-core/1.0.0.Alpha1] osgi.wiring.package; filter:="(osgi.wiring.package=org.overlord.commons.i18n)"]]]] > The overlord.commons.i18n package is not exported, and therefor the engine can not see it. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 16:46:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Sep 2014 16:46:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-565) Ontology download button is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-565 started by Brett Meyer. ----------------------------------------- > Ontology download button is broken > ---------------------------------- > > Key: SRAMP-565 > URL: https://issues.jboss.org/browse/SRAMP-565 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > > The ontology download button leads to: > http://localhost:8080/s-ramp-ui/app/services/ontologyDownload?uuid=[uuid] > It currently 404s -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 16:56:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Sep 2014 16:56:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-565) Ontology download button is broken when using s-ramp-dev-server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-565: ------------------------------ Summary: Ontology download button is broken when using s-ramp-dev-server (was: Ontology download button is broken) > Ontology download button is broken when using s-ramp-dev-server > --------------------------------------------------------------- > > Key: SRAMP-565 > URL: https://issues.jboss.org/browse/SRAMP-565 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > > The ontology download button leads to: > http://localhost:8080/s-ramp-ui/app/services/ontologyDownload?uuid=[uuid] > It currently 404s -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 16:57:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Sep 2014 16:57:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-565) Ontology download button is broken when using s-ramp-dev-server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001632#comment-13001632 ] Brett Meyer commented on SRAMP-565: ----------------------------------- OntologyDownloadServlet simply needs added to SrampDevServer > Ontology download button is broken when using s-ramp-dev-server > --------------------------------------------------------------- > > Key: SRAMP-565 > URL: https://issues.jboss.org/browse/SRAMP-565 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > > The ontology download button leads to: > http://localhost:8080/s-ramp-ui/app/services/ontologyDownload?uuid=[uuid] > It currently 404s -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 17:13:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Sep 2014 17:13:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-565) Ontology download button is broken when using s-ramp-dev-server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-565. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > Ontology download button is broken when using s-ramp-dev-server > --------------------------------------------------------------- > > Key: SRAMP-565 > URL: https://issues.jboss.org/browse/SRAMP-565 > Project: S-RAMP > Issue Type: Bug > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > The ontology download button leads to: > http://localhost:8080/s-ramp-ui/app/services/ontologyDownload?uuid=[uuid] > It currently 404s -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 11 17:46:20 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 11 Sep 2014 17:46:20 -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:all-tabpanel ] Brett Meyer resolved SRAMP-545. ------------------------------- Resolution: Done > 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 > > > 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 Fri Sep 12 06:19:20 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Sep 2014 06:19:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-570) Document Elasticsearch cluster configuration options In-Reply-To: References: Message-ID: Gary Brown created RTGOV-570: -------------------------------- Summary: Document Elasticsearch cluster configuration options Key: RTGOV-570 URL: https://issues.jboss.org/browse/RTGOV-570 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Incorporate Ivan's information on clustering Elasticsearch into rtgov docs: "Quick doc outline how Elasticsearch for FSW can be configured to - become part of a ES cluster (default) - act a a simple client but saving data a remote ES cluster - INVM mode. when ES node is started in jboss jvm https://mojo.redhat.com/groups/jboss-integration-sme/blog/2014/09/10/configure-fsw61rtgov2-to-join-a-es-cluster?sr=stream" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 07:28:20 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Sep 2014 07:28:20 -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:all-tabpanel ] Gary Brown updated RTGOV-566: ----------------------------- Fix Version/s: 2.0.0.Final > [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 Fri Sep 12 07:28:20 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Sep 2014 07:28:20 -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.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.0.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 Fri Sep 12 09:03:19 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Sep 2014 09:03:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-571) Investigate moving from Errai event bus to Unified Push Server for notifications to rtgov-ui In-Reply-To: References: Message-ID: Gary Brown created RTGOV-571: -------------------------------- Summary: Investigate moving from Errai event bus to Unified Push Server for notifications to rtgov-ui Key: RTGOV-571 URL: https://issues.jboss.org/browse/RTGOV-571 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final Determine whether it is possible to use the Unified Push Server as a mechanism for distributing notifications to the rtgov-ui (i.e. new situations). If it is possible, then it could also provide a means for viewing those notifications via a mobile device. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 09:07:19 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Sep 2014 09:07:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-572) Convert RTGov UI Errai services to jax-rs In-Reply-To: References: Message-ID: Gary Brown created RTGOV-572: -------------------------------- Summary: Convert RTGov UI Errai services to jax-rs Key: RTGOV-572 URL: https://issues.jboss.org/browse/RTGOV-572 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final Cloned from SRAMP-562: "Currently we use Errai RPC services to communicate between the UI client and the server. We should switch all of these from Errai RPC to REST, which would allow us to remove all server-side Errai dependencies and thus no longer use CDI. This is a big win when running in Fuse and it doesn't make the UI any more complicated. It also has the side effect of introducing a REST API for the user interface, potentially allowing alternative implementations, integrations, embedded components in other UIs, etc." Current complication is that Errai bus is used to push "situation created" notifications to the UI - need to investigate alternative (e.g. RTGOV-571). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 09:09:19 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 12 Sep 2014 09:09:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-572) Convert RTGov UI Errai services to jax-rs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001850#comment-13001850 ] Gary Brown commented on RTGOV-572: ---------------------------------- Need an alternative solution for pushing notifications before this conversion could happen. > Convert RTGov UI Errai services to jax-rs > ----------------------------------------- > > Key: RTGOV-572 > URL: https://issues.jboss.org/browse/RTGOV-572 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Cloned from SRAMP-562: > "Currently we use Errai RPC services to communicate between the UI client and the server. We should switch all of these from Errai RPC to REST, which would allow us to remove all server-side Errai dependencies and thus no longer use CDI. This is a big win when running in Fuse and it doesn't make the UI any more complicated. It also has the side effect of introducing a REST API for the user interface, potentially allowing alternative implementations, integrations, embedded components in other UIs, etc." > Current complication is that Errai bus is used to push "situation created" notifications to the UI - need to investigate alternative (e.g. RTGOV-571). -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 10:34:20 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 12 Sep 2014 10:34:20 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-132) Add APIMan to governance.github.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved OVERLORD-132. ------------------------------------ Resolution: Done > Add APIMan to governance.github.io > ---------------------------------- > > Key: OVERLORD-132 > URL: https://issues.jboss.org/browse/OVERLORD-132 > Project: Overlord > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Eric Wittmann > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 10:35:26 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 12 Sep 2014 10:35:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-132) Add APIMan to governance.github.io In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed OVERLORD-132. ---------------------------------- > Add APIMan to governance.github.io > ---------------------------------- > > Key: OVERLORD-132 > URL: https://issues.jboss.org/browse/OVERLORD-132 > Project: Overlord > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Eric Wittmann > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 14:37:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Sep 2014 14:37:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-504) Classifier filter UI label not updated on return to page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-504. ------------------------------- Resolution: Done > Classifier filter UI label not updated on return to page > -------------------------------------------------------- > > Key: SRAMP-504 > URL: https://issues.jboss.org/browse/SRAMP-504 > Project: S-RAMP > Issue Type: Bug > Components: UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Steps to reproduce: > 1) Add an artifact to s-ramp > 2) Add an ontology to s-ramp > 3) Add one of the classifiers to the s-ramp artifact from (1) > 4) In the artifact listing page select the classifier from (3) in the Classifier filter section > 5) note the label is updated, for example: > {code} > Deployment Status (1 selected) > {code} > 6) click the artifact in the list (to navigate to the artifact details page) > 7) navigate back to the artifact listing page (e.g. via the breadcrumb) > 8) Bug: even though the classifier is *still* selected in the filter, the filter label now reads: > {code} > Deployment Status (0 selected) > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 15:25:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Sep 2014 15:25:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-558) UI: Suggest users while typing in "Created By" & "Last Modified By" fields In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-558. ----------------------------- Resolution: Won't Fix Decided against this. It'll won't be easy to parse all primary artifact nodes and find the full list of users. Attempting to pull them from the UI artifact results might be possible, but with paging you have the potential to only get a subset. All in all, lots of work for an extremely minimal gain. Rejecting. > UI: Suggest users while typing in "Created By" & "Last Modified By" fields > -------------------------------------------------------------------------- > > Key: SRAMP-558 > URL: https://issues.jboss.org/browse/SRAMP-558 > Project: S-RAMP > Issue Type: Enhancement > Components: UI > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 12 17:35:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Sep 2014 17:35:19 -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=13002080#comment-13002080 ] Brett Meyer commented on SRAMP-535: ----------------------------------- [~eric.wittmann], is the "deleted" artifact kept purely for auditing? If so, will reseting the UUID screw with that? Or, are the audit nodes pulled over with the "deleted" node? It looks like enabling same-name siblings for specific children is possible: http://www.day.com/specs/jcr/2.0/22_Same-Name_Siblings.html. But even so, the question is the same. How are the "deleted" artifacts used and what might the implications be? > 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 > 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 Fri Sep 12 17:50:19 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 12 Sep 2014 17:50:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-488) Use the maven-bundle-plugin in WAR projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-488 started by Brett Meyer. ----------------------------------------- > Use the maven-bundle-plugin in WAR projects > ------------------------------------------- > > Key: SRAMP-488 > URL: https://issues.jboss.org/browse/SRAMP-488 > Project: S-RAMP > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > 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 Mon Sep 15 03:52:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 15 Sep 2014 03:52:02 -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.11.Final (was: Overlord-Commons-2.0.10.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.11.Final > > > 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 Mon Sep 15 03:52:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 15 Sep 2014 03:52:02 -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.11.Final (was: Overlord-Commons-2.0.10.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.11.Final > > > 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 Mon Sep 15 06:14:02 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Mon, 15 Sep 2014 06:14:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-569) Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13002267#comment-13002267 ] Michael Clay commented on RTGOV-569: ------------------------------------ reviewed/tested > Resubmit causes serialization problem in RTGov UI when deployed to FSW 6.0 > -------------------------------------------------------------------------- > > Key: RTGOV-569 > URL: https://issues.jboss.org/browse/RTGOV-569 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Related to comment on RTGOV-556 - the switchyard version used in the FSW 6.0 RTGOV UI war is 2.x where it should be 1.x. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 06:25:03 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Mon, 15 Sep 2014 06:25:03 -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=13002280#comment-13002280 ] Michael Clay commented on RTGOV-566: ------------------------------------ another use case for this This one is required because for e.g. SOAP messages originating from a SCA binding for which there is no possibility to configure a custom ContextMapper to retrieve/extract (SOAP header) exchange properties which need to be simply passed through to some referenced service (Reference). Consider the following example application with one service with a soap and a sca binding and an implementation which simple forwards (proxies) the soap request to some referenced service (i.e. Reference in sy/sca terms). This referenced service is configured with a custom contextmapper which has the same configuration like the one on the incoming soap binding to tunnel/forward all SOAP header properties. > [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 Mon Sep 15 07:21:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 15 Sep 2014 07:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-130) GenerateSamlKeystoreUtil currently using three deprecated BC classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved OVERLORD-130. ------------------------------------ Resolution: Done > GenerateSamlKeystoreUtil currently using three deprecated BC classes > -------------------------------------------------------------------- > > Key: OVERLORD-130 > URL: https://issues.jboss.org/browse/OVERLORD-130 > Project: Overlord > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > In overlord-commons we have the GenerateSamlKeystoreUtil class. This class is currently using BouncyCastle to do some keystore related stuff. It's using three deprecated classes from BC. We need to figure out a way to do this same work without using deprecated code. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 07:21:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 15 Sep 2014 07:21:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-130) GenerateSamlKeystoreUtil currently using three deprecated BC classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed OVERLORD-130. ---------------------------------- > GenerateSamlKeystoreUtil currently using three deprecated BC classes > -------------------------------------------------------------------- > > Key: OVERLORD-130 > URL: https://issues.jboss.org/browse/OVERLORD-130 > Project: Overlord > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: David virgil naranjo > > In overlord-commons we have the GenerateSamlKeystoreUtil class. This class is currently using BouncyCastle to do some keystore related stuff. It's using three deprecated classes from BC. We need to figure out a way to do this same work without using deprecated code. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 15 08:29:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 15 Sep 2014 08:29: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=13002333#comment-13002333 ] Eric Wittmann commented on SRAMP-535: ------------------------------------- Deleted nodes are kept for auditing, yes. The audit information lives as child nodes on the artifact node. So changing the UUI *should* be ok. I would suggest perhaps something like _deleted_ or something like that. And have same-name-siblings enabled only for the "trash" part of the tree. Definitely do not want to enable same-name-siblings for the main tree, as we use that feature specifically to ensure that we don't create multiple nodes with the same UUID. That was probably obviously but perhaps worth repeating. :) > 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 > 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 Mon Sep 15 12:09:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 15 Sep 2014 12:09:02 -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: Brett Meyer created SRAMP-566: --------------------------------- Summary: 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 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 Sep 16 11:40:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 16 Sep 2014 11:40:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-573) XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved In-Reply-To: References: Message-ID: Gary Brown created RTGOV-573: -------------------------------- Summary: XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved Key: RTGOV-573 URL: https://issues.jboss.org/browse/RTGOV-573 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When using the XPath type processor, it is currently geared to extracting text attribute values from an XML document to be provided as a property in the activity event. Need to fix this so that an xpath expression can be used to also extract an xml fragment. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 12:08:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 16 Sep 2014 12:08:03 -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=13003006#comment-13003006 ] Gary Brown commented on RTGOV-566: ---------------------------------- Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a variation (e.g. 'serializeWithHeaders') to enable message content only serialization to be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' or 'serializeWithHeaders' is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. > [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 Tue Sep 16 12:59:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 16 Sep 2014 12:59:02 -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=13003006#comment-13003006 ] Gary Brown edited comment on RTGOV-566 at 9/16/14 12:58 PM: ------------------------------------------------------------ Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a configuration property on this transformer (e.g. 'includeHeaders') to enable message content only serialization to also be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' (with includeHeaders=true) is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. was (Author: objectiser): Was initially thinking that may be the relevant header values could be extracted individually using the existing mechanism in the ip.json definition. However the xpath type processor is limited, as it was implemented to extract the attribute values, rather than intended to represent xml doc fragments - so a patch would be required anyway. Therefore rather than trying to use the existing mechanism, I'm thinking it may be better to leverage the use of 'serialize' transformer as an indication that header values are also required - or having a variation (e.g. 'serializeWithHeaders') to enable message content only serialization to be supported? So essentially the main approach would be, * leave the property mechanism as is, to extract specific information from the message content or header values * if 'serialize' or 'serializeWithHeaders' is defined for the 'transformer', then encode relevant values in a special map property May need to limit the types that can be serialized initially to string and DOM? SwitchYard security context would be handled as a special case, after deciding best approach. > [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 Tue Sep 16 16:53:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 16 Sep 2014 16:53:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-573) XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-573: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/201 > XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-573 > URL: https://issues.jboss.org/browse/RTGOV-573 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When using the XPath type processor, it is currently geared to extracting text attribute values from an XML document to be provided as a property in the activity event. > Need to fix this so that an xpath expression can be used to also extract an xml fragment. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 16:53:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 16 Sep 2014 16:53:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-573) XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-573. ------------------------------ Resolution: Done > XPath type processor only extracts text attributes but doesn't allow xml fragments to be retrieved > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-573 > URL: https://issues.jboss.org/browse/RTGOV-573 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When using the XPath type processor, it is currently geared to extracting text attribute values from an XML document to be provided as a property in the activity event. > Need to fix this so that an xpath expression can be used to also extract an xml fragment. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 16 16:55:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 16 Sep 2014 16:55:02 -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=13003230#comment-13003230 ] Gary Brown commented on RTGOV-566: ---------------------------------- If type processors are used to extract the header details using xpath, then this associated bug will be relevant. > [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 Tue Sep 16 22:49:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 16 Sep 2014 22:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-561) Support Fuse JMS In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-561. ------------------------------- Resolution: Done > Support Fuse JMS > ---------------- > > Key: SRAMP-561 > URL: https://issues.jboss.org/browse/SRAMP-561 > Project: S-RAMP > Issue Type: Enhancement > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > SRAMP-433 created JMS events within S-RAMP. For Tomcat, Jetty, and standalone EAP, we use an embedded ActiveMQ broker. For standalone-full EAP, we re-use the existing HornetQ JMS and JNDI resources. > Supposedly, Fuse provides ActiveMQ out-of-the-box. We should re-use that, rather than relying on the embedded broker. Investigate and figure out a way to add the JMS resources during S-RAMP installation, similar to the new configureJMS-jboss-eap-6.xslt. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 04:00:03 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Wed, 17 Sep 2014 04:00:03 -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=13003329#comment-13003329 ] Michael Clay commented on RTGOV-566: ------------------------------------ have you also discussed the possiblity to allow custom messagecomposer and contextmapper on the receiving sca binding side - with this option available all relevant properties can be recreated from the message itself and it would align the sca binding with the other bindings (e.g. soap,jms) in the sense of supported features/options. > [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 Wed Sep 17 04:21:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 17 Sep 2014 04:21:03 -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=13003342#comment-13003342 ] Gary Brown commented on RTGOV-566: ---------------------------------- Hi Michael I'll let Keith comment on that. In terms of the general mechanism I have described, does this meet your needs? > [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 Wed Sep 17 08:52:02 2014 From: issues at jboss.org (Keith Babo (JIRA)) Date: Wed, 17 Sep 2014 08:52:02 -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=13003452#comment-13003452 ] Keith Babo commented on RTGOV-566: ---------------------------------- Support for SCA bindings was introduced to allow a "native" communication path into a SwitchYard application in support of the following use cases: 1) Inter-application communication between SwitchYard services. 2) Remote client access to a SwitchYard service. These cases are different from a traditional binding in that clients are dealing directly with the SY content and context. For other bindings (e.g. JMS, SOAP), the protocol-specific message needs to be mapped to the SY content and context, which is where a message composer and context mapper come in. If it is not possible to pass something via RemoteInvoker/RemoteMessage today, then we should definitely address that in the remote API and/or the SCA binding itself. My preference would be to avoid adding message composer support since clients should already be dealing with a native interface to SwitchYard. > [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 Wed Sep 17 10:48:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Sep 2014 10:48:02 -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:all-tabpanel ] Brett Meyer updated SRAMP-566: ------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/110, https://github.com/Governance/s-ramp/pull/487 > 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 > > 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 Wed Sep 17 11:33:02 2014 From: issues at jboss.org (Rob Cernich (JIRA)) Date: Wed, 17 Sep 2014 11:33:02 -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=13003538#comment-13003538 ] Rob Cernich commented on RTGOV-566: ----------------------------------- I agree with Keith. If we need to make adjustments, I think we should be looking at modifying the remote API. As Keith mentioned, the SCA binding is for native communication and, as such, the message, headers, and exchange should be completely configured by the client. If this is not possible today, then I think it's fair to ask for modifications to the remote API (as Keith suggests). > [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 Wed Sep 17 11:36:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 17 Sep 2014 11:36:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-567) Exception Integration Tests In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-567: ------------------------------------------ Summary: Exception Integration Tests Key: SRAMP-567 URL: https://issues.jboss.org/browse/SRAMP-567 Project: S-RAMP Issue Type: Bug Reporter: David virgil naranjo Assignee: David virgil naranjo Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.193 sec <<< FAILURE! testWagonPull(org.overlord.sramp.test.wagon.SrampWagonTest) Time elapsed: 1.402 sec <<< ERROR! java.lang.NullPointerException: null at java.lang.String.concat(String.java:1970) at org.codehaus.plexus.logging.console.ConsoleLogger.log(ConsoleLogger.java:91) at org.codehaus.plexus.logging.console.ConsoleLogger.error(ConsoleLogger.java:68) at org.overlord.sramp.wagon.SrampWagon.error(SrampWagon.java:992) at org.overlord.sramp.wagon.SrampWagon.doGetArtifact(SrampWagon.java:491) at org.overlord.sramp.wagon.SrampWagon.fillInputData(SrampWagon.java:224) at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) at org.overlord.sramp.test.wagon.SrampWagonTest.testWagonPull(SrampWagonTest.java:351) Running org.overlord.sramp.test.server.atom.services.OntologyResourceTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.866 sec Running org.overlord.sramp.test.server.atom.services.ServiceDocumentResourceTest Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.115 sec Running org.overlord.sramp.test.server.atom.services.QueryResourceTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 32.207 sec Running org.overlord.sramp.test.server.atom.services.AuditResourceTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.733 sec Running org.overlord.sramp.test.server.atom.services.BatchResourceTest Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.549 sec Running org.overlord.sramp.test.server.atom.services.ArtifactResourceTest Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.969 sec <<< FAILURE! testFullPurchaseOrderXSD(org.overlord.sramp.test.server.atom.services.ArtifactResourceTest) Time elapsed: 1.873 sec <<< ERROR! java.lang.NullPointerException: null at org.overlord.sramp.common.SrampModelUtils.getCustomProperty(SrampModelUtils.java:97) at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.verifyEntryUpdated(ArtifactResourceTest.java:736) at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.testFullPurchaseOrderXSD(ArtifactResourceTest.java:611) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 17 12:24:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Sep 2014 12:24:02 -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:all-tabpanel ] Work on SRAMP-566 started by Brett Meyer. ----------------------------------------- > 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 > > 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 Wed Sep 17 15:59:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 17 Sep 2014 15:59:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-488) Use the maven-bundle-plugin in WAR projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-488: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/489 > Use the maven-bundle-plugin in WAR projects > ------------------------------------------- > > Key: SRAMP-488 > URL: https://issues.jboss.org/browse/SRAMP-488 > Project: S-RAMP > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > 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 Thu Sep 18 04:38:03 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Thu, 18 Sep 2014 04:38:03 -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=13003760#comment-13003760 ] Michael Clay commented on RTGOV-566: ------------------------------------ - short summary how sy handles SOAP header properties \\ sy sets the incoming soap header properties in {{ContextMapper#mapFrom}} as message property with a soap header label {{context.setProperty(name, value).addLabels(SOAP_HEADER_LABELS);}} and retrieves and appends it on the outgoing soap message within {{ContextMapper#mapTo}} {code:title=ContextMapper.java|borderStyle=solid} for (Property property : context.getProperties()) { Object value = property.getValue(); if (value instanceof Node) { } else if (value instanceof Configuration) { } else { String v = value.toString(); if (SOAPHeadersType.XML.equals(_soapHeadersType)) { try { Element xmlElement = new ElementPuller().pull(new StringReader(v)); Node xmlNode = soapHeader.getOwnerDocument().importNode(xmlElement, true); soapHeader.appendChild(xmlNode); } catch (Throwable t) { soapHeader.addChildElement(qname).setValue(v); } } else { soapHeader.addChildElement(qname).setValue(v); } } } {code} what's also relevant here is the way {{context.getProperties()}} is implemented i.e. ALL exchange and message properties are considered. {code:title=ContextMapper.java|borderStyle=solid} @Override public Set getProperties() { Set properties = new HashSet(); properties.addAll(getProperties(Scope.EXCHANGE)); properties.addAll(getProperties(Scope.MESSAGE)); return properties; } {code} \\ As already mentioned we are using {{SOAPHeadersType#DOM}} on the incoming and outgoing ContextMapper side and therefore would also expect to receive DOM context property instances from Exchange objects originating from SwitchYardRemotingServlet -> but this is no hard constraint since an application can always override/configure those ContextMappers and add the required behaviour. \\ \\ - recap of how rtgov passes those context properties to switchyards remoting servlet: \\ On the rtgov side we are using {{ActivityType#properties}} which could be used to restore the RemoteMessage#context and those properties are string valued since we have to persist them. Therefore we have no way to directly pass/serialize DOM(w3c.Node) property value instance which would be anyway a bad idea since the serialization encoding format is already xml. \\ \\ - comment on Garys suggestion \\ What i don't like on this solution is that it breaks the existing separation of concerns between PropertyEvaluators(extract context properties) and InformationTransformers (message content serialization) in a bad way which mixes the two responsibilities i.e. header/property retrieving is spread over two (main)concepts of the informationprocessor which i think makes it harder to understand/maintain. \\ What about adding an addition resultType (org.w3c.dom.xpath.XPathResult) configuration option to the existing xpath evaluator in the same way as as it is possible with camel Xpath expression's http://camel.apache.org/xpath.html ..of course we still need to serialize the result type into string value. > [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 Sep 18 05:34:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 05:34:03 -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=13003783#comment-13003783 ] Gary Brown commented on RTGOV-566: ---------------------------------- Hi Michael Would have to disagree - the property mechanism within the information processor is intended to extract business relevant information that can be used in policies, not to serialize header values, which are really part of the message. Originally I was looking at using this mechanism, as a potential way to implement your requirement on FSW 6.0 without having to apply a patch. but this didn't work out. So I think the 'serialize' information transformer is the ideal place to handle serialization of not just the mesage payload, but header values aswell. If header values are stored in properties, then the ip.json configuration is more complex as it must list each header value of interest, as well as potentially define its unserialized representation (e.g. dom). It would also not be clear which properties are header values, and which are actually extracted values intended to support policies. I've actually implemented the mechanism described above - it simply requires the 'includeHeaders=true' set on the serialize information transformer, and it will resubmit all string and DOM header properties - the DOM properties are returned in the correct format. Branch: https://github.com/objectiser/rtgov/tree/RTGOV-566 I'll hold off merging until we have had further discussions. > [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 Sep 18 05:42:02 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Thu, 18 Sep 2014 05:42:02 -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=13003791#comment-13003791 ] Michael Clay commented on RTGOV-566: ------------------------------------ hi Gary, ok i understand thanks for clarification - btw are you aware of the fact that SOAP Header Values are only available as Exchange#context properties during the pipeline execution since the (incoming)SOAPMessageComposer only extract the first child of the SOAPBody as exctual message Context ie Exchange#message. The reason why i mention this is because i think you dont have access to the complete SOAPMessage (ie. SOAPHeader + SOAPBody) in you transformer. .this is my understanding of things maybe one of the SY guys could confirm/review this. > [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 Sep 18 05:49:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 05:49:02 -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=13003792#comment-13003792 ] Gary Brown commented on RTGOV-566: ---------------------------------- Ok thanks - I'll check with swyd team. > [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 Sep 18 05:54:03 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Thu, 18 Sep 2014 05:54:03 -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=13003795#comment-13003795 ] Michael Clay commented on RTGOV-566: ------------------------------------ the relevant section i was referring to is {{org.overlord.rtgov.internal.switchyard.exchange.AbstractExchangeEventProcessor#record}} in which you can see that only the actual message content is passed into the activitycollector#processInformation > [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 Sep 18 07:07:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 07:07:02 -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=13003828#comment-13003828 ] Gary Brown commented on RTGOV-566: ---------------------------------- The PropertyAccessor provides access to the header values in the 'message' scope. https://github.com/Governance/rtgov/blob/master/integration/switchyard/src/main/java/org/overlord/rtgov/internal/switchyard/exchange/AbstractExchangeEventProcessor.java#L460-L461 > [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 Sep 18 08:04:02 2014 From: issues at jboss.org (Keith Babo (JIRA)) Date: Thu, 18 Sep 2014 08:04:02 -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=13003848#comment-13003848 ] Keith Babo commented on RTGOV-566: ---------------------------------- The original SOAP message is not mapped into the exchange/message. The context mapper can be configured to map HTTP headers and SOAP headers into the message context and the SOAP body goes into the message content. The original SAAJ SOAPMessage reference is available to the message composer, so if access to this reference was required for some reason then it could simply be mapped into a context property. > [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 Sep 18 09:33:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 09:33:02 -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:all-tabpanel ] Gary Brown updated RTGOV-566: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/202 > [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 Sep 18 09:34:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 09:34:03 -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:all-tabpanel ] Gary Brown resolved RTGOV-566. ------------------------------ Resolution: Done Decided to merge this as there now seems to be agreement on the approach. Its been tested with the fix for SWITCHYARD-2336 and enables a DOM based header property to be stored in rtgov and used during the resubmission. > [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 Sep 18 10:08:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 18 Sep 2014 10:08:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-568) Use the maven-bundle-plugin in WAR projects In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-568: ----------------------------------- Summary: Use the maven-bundle-plugin in WAR projects Key: SRAMP-568 URL: https://issues.jboss.org/browse/SRAMP-568 Project: S-RAMP Issue Type: Task Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.6.0 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 Thu Sep 18 10:12:03 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 18 Sep 2014 10:12:03 -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 ] Eric Wittmann moved DTGOV-225 to OVERLORD-147: ---------------------------------------------- Project: Overlord (was: DTGov (Design Time Governance)) Key: OVERLORD-147 (was: DTGOV-225) Fix Version/s: Overlord-Commons-2.0.11.Final (was: 1.3.1) > 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.11.Final > > > 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 Thu Sep 18 10:29:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 10:29:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-488) Use the maven-bundle-plugin in WAR projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-488. ------------------------------- Resolution: Done > Use the maven-bundle-plugin in WAR projects > ------------------------------------------- > > Key: SRAMP-488 > URL: https://issues.jboss.org/browse/SRAMP-488 > Project: S-RAMP > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > 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 Thu Sep 18 10:36:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 10:36:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-569) Create maven plugin to merge .properties files In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-569: --------------------------------- Summary: 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 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 Thu Sep 18 10:36:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 10:36:03 -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:all-tabpanel ] Brett Meyer updated SRAMP-569: ------------------------------ Fix Version/s: 0.6.0 > 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 > > > 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 Thu Sep 18 10:43:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 10:43:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-563) Upgrade drools to 6.1.0.Final In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-563. ------------------------------ Resolution: Done > Upgrade drools to 6.1.0.Final > ----------------------------- > > Key: RTGOV-563 > URL: https://issues.jboss.org/browse/RTGOV-563 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Need to investigate conflict with mvel version in ip bom master (2.1.9.Final) while drools 6.1.0.Final is using 2.2.1.Final, which has changed some classes to interfaces or vice versa. > Current approach taken by switchyard: http://goo.gl/M7K84s -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 10:55:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 10:55:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-567) Exception Integration Tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-567: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/488 > Exception Integration Tests > --------------------------- > > Key: SRAMP-567 > URL: https://issues.jboss.org/browse/SRAMP-567 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.193 sec <<< FAILURE! > testWagonPull(org.overlord.sramp.test.wagon.SrampWagonTest) Time elapsed: 1.402 sec <<< ERROR! > java.lang.NullPointerException: null > at java.lang.String.concat(String.java:1970) > at org.codehaus.plexus.logging.console.ConsoleLogger.log(ConsoleLogger.java:91) > at org.codehaus.plexus.logging.console.ConsoleLogger.error(ConsoleLogger.java:68) > at org.overlord.sramp.wagon.SrampWagon.error(SrampWagon.java:992) > at org.overlord.sramp.wagon.SrampWagon.doGetArtifact(SrampWagon.java:491) > at org.overlord.sramp.wagon.SrampWagon.fillInputData(SrampWagon.java:224) > at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) > at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) > at org.overlord.sramp.test.wagon.SrampWagonTest.testWagonPull(SrampWagonTest.java:351) > Running org.overlord.sramp.test.server.atom.services.OntologyResourceTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.866 sec > Running org.overlord.sramp.test.server.atom.services.ServiceDocumentResourceTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.115 sec > Running org.overlord.sramp.test.server.atom.services.QueryResourceTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 32.207 sec > Running org.overlord.sramp.test.server.atom.services.AuditResourceTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.733 sec > Running org.overlord.sramp.test.server.atom.services.BatchResourceTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.549 sec > Running org.overlord.sramp.test.server.atom.services.ArtifactResourceTest > Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.969 sec <<< FAILURE! > testFullPurchaseOrderXSD(org.overlord.sramp.test.server.atom.services.ArtifactResourceTest) Time elapsed: 1.873 sec <<< ERROR! > java.lang.NullPointerException: null > at org.overlord.sramp.common.SrampModelUtils.getCustomProperty(SrampModelUtils.java:97) > at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.verifyEntryUpdated(ArtifactResourceTest.java:736) > at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.testFullPurchaseOrderXSD(ArtifactResourceTest.java:611) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 10:55:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 10:55:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-567) Exception Integration Tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-567: ------------------------------ Fix Version/s: 0.6.0 > Exception Integration Tests > --------------------------- > > Key: SRAMP-567 > URL: https://issues.jboss.org/browse/SRAMP-567 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.193 sec <<< FAILURE! > testWagonPull(org.overlord.sramp.test.wagon.SrampWagonTest) Time elapsed: 1.402 sec <<< ERROR! > java.lang.NullPointerException: null > at java.lang.String.concat(String.java:1970) > at org.codehaus.plexus.logging.console.ConsoleLogger.log(ConsoleLogger.java:91) > at org.codehaus.plexus.logging.console.ConsoleLogger.error(ConsoleLogger.java:68) > at org.overlord.sramp.wagon.SrampWagon.error(SrampWagon.java:992) > at org.overlord.sramp.wagon.SrampWagon.doGetArtifact(SrampWagon.java:491) > at org.overlord.sramp.wagon.SrampWagon.fillInputData(SrampWagon.java:224) > at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) > at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) > at org.overlord.sramp.test.wagon.SrampWagonTest.testWagonPull(SrampWagonTest.java:351) > Running org.overlord.sramp.test.server.atom.services.OntologyResourceTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.866 sec > Running org.overlord.sramp.test.server.atom.services.ServiceDocumentResourceTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.115 sec > Running org.overlord.sramp.test.server.atom.services.QueryResourceTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 32.207 sec > Running org.overlord.sramp.test.server.atom.services.AuditResourceTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.733 sec > Running org.overlord.sramp.test.server.atom.services.BatchResourceTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.549 sec > Running org.overlord.sramp.test.server.atom.services.ArtifactResourceTest > Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.969 sec <<< FAILURE! > testFullPurchaseOrderXSD(org.overlord.sramp.test.server.atom.services.ArtifactResourceTest) Time elapsed: 1.873 sec <<< ERROR! > java.lang.NullPointerException: null > at org.overlord.sramp.common.SrampModelUtils.getCustomProperty(SrampModelUtils.java:97) > at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.verifyEntryUpdated(ArtifactResourceTest.java:736) > at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.testFullPurchaseOrderXSD(ArtifactResourceTest.java:611) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 10:55:04 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 10:55:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-567) Exception Integration Tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-567. ------------------------------- Resolution: Done > Exception Integration Tests > --------------------------- > > Key: SRAMP-567 > URL: https://issues.jboss.org/browse/SRAMP-567 > Project: S-RAMP > Issue Type: Bug > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > Tests run: 5, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 58.193 sec <<< FAILURE! > testWagonPull(org.overlord.sramp.test.wagon.SrampWagonTest) Time elapsed: 1.402 sec <<< ERROR! > java.lang.NullPointerException: null > at java.lang.String.concat(String.java:1970) > at org.codehaus.plexus.logging.console.ConsoleLogger.log(ConsoleLogger.java:91) > at org.codehaus.plexus.logging.console.ConsoleLogger.error(ConsoleLogger.java:68) > at org.overlord.sramp.wagon.SrampWagon.error(SrampWagon.java:992) > at org.overlord.sramp.wagon.SrampWagon.doGetArtifact(SrampWagon.java:491) > at org.overlord.sramp.wagon.SrampWagon.fillInputData(SrampWagon.java:224) > at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) > at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) > at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) > at org.overlord.sramp.test.wagon.SrampWagonTest.testWagonPull(SrampWagonTest.java:351) > Running org.overlord.sramp.test.server.atom.services.OntologyResourceTest > Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.866 sec > Running org.overlord.sramp.test.server.atom.services.ServiceDocumentResourceTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.115 sec > Running org.overlord.sramp.test.server.atom.services.QueryResourceTest > Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 32.207 sec > Running org.overlord.sramp.test.server.atom.services.AuditResourceTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.733 sec > Running org.overlord.sramp.test.server.atom.services.BatchResourceTest > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.549 sec > Running org.overlord.sramp.test.server.atom.services.ArtifactResourceTest > Tests run: 12, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 9.969 sec <<< FAILURE! > testFullPurchaseOrderXSD(org.overlord.sramp.test.server.atom.services.ArtifactResourceTest) Time elapsed: 1.873 sec <<< ERROR! > java.lang.NullPointerException: null > at org.overlord.sramp.common.SrampModelUtils.getCustomProperty(SrampModelUtils.java:97) > at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.verifyEntryUpdated(ArtifactResourceTest.java:736) > at org.overlord.sramp.test.server.atom.services.ArtifactResourceTest.testFullPurchaseOrderXSD(ArtifactResourceTest.java:611) -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 12:01:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 12:01:03 -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:all-tabpanel ] Brett Meyer resolved SRAMP-566. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > 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 > > > 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 Thu Sep 18 12:50:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 18 Sep 2014 12:50:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-148) Add support for wildfly 8 In-Reply-To: References: Message-ID: Eric Wittmann created OVERLORD-148: -------------------------------------- Summary: 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.11.Final 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 Thu Sep 18 12:51:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 12:51:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-29) Add support for Stored Queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-29: -------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > Add support for Stored Queries > ------------------------------ > > Key: SRAMP-29 > URL: https://issues.jboss.org/browse/SRAMP-29 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > Section 4.6 of the S-RAMP spec discusses stored queries. We need to add support for them. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 12:53:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 12:53:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-29) Add support for Stored Queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-29: ----------------------------- Description: Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. (was: Section 4.6 of the S-RAMP spec discusses stored queries. We need to add support for them.) > Add support for Stored Queries > ------------------------------ > > Key: SRAMP-29 > URL: https://issues.jboss.org/browse/SRAMP-29 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 12:54:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 12:54:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: Gary Brown created RTGOV-574: -------------------------------- Summary: Investigate 'index already exists' exception when previous command indicates does not exist Key: RTGOV-574 URL: https://issues.jboss.org/browse/RTGOV-574 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable He also suggests: "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 12:56:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 12:56:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-29) Add support for Stored Queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-29: ----------------------------- Description: Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. {quote} S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details. The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes: queryName: The name of the Stored Query instance. This must be unique. queryExpression: The specification of the query expression. A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific. {quote} was:Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. > Add support for Stored Queries > ------------------------------ > > Key: SRAMP-29 > URL: https://issues.jboss.org/browse/SRAMP-29 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. > {quote} > S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details. > > The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes: > queryName: The name of the Stored Query instance. This must be unique. > queryExpression: The specification of the query expression. > > A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific. > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 12:59:02 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 18 Sep 2014 12:59:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004024#comment-13004024 ] ivan mckinley commented on RTGOV-574: ------------------------------------- Did you test this ? A quick test to verify if we are affected by this would be to sleep the method. or put a breakpoint in there private boolean prepareIndex(Map defaultSettings) { IndicesExistsResponse res = _client.admin().indices().prepareExists(_index).execute().actionGet(); thread.sleep(10000); boolean created = false; if (!res.isExists()) { CreateIndexRequestBuilder req = _client.admin().indices().prepareCreate(_index); req.setSettings(defaultSettings); created = req.execute().actionGet().isAcknowledged(); if (!created) { throw new RuntimeException("Could not create index [" + _index + "]"); } } return created; } > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 13:02:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 13:02:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-568: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/203 > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 13:02:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 13:02:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-568. ------------------------------ Resolution: Done Although raised RTGOV-574 to investigate change in behaviour. > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 13:04:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 18 Sep 2014 13:04:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004029#comment-13004029 ] Gary Brown commented on RTGOV-574: ---------------------------------- Not yet, will try tomorrow - although this shouldn't change the result as it is a synchronous call, unless they have introduced a bug. > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 18 13:19:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 18 Sep 2014 13:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-29) Add support for Stored Queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-29 started by Brett Meyer. ---------------------------------------- > Add support for Stored Queries > ------------------------------ > > Key: SRAMP-29 > URL: https://issues.jboss.org/browse/SRAMP-29 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. > {quote} > S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details. > > The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes: > queryName: The name of the Stored Query instance. This must be unique. > queryExpression: The specification of the query expression. > > A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific. > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 02:42:03 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Fri, 19 Sep 2014 02:42:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004127#comment-13004127 ] ivan mckinley commented on RTGOV-574: ------------------------------------- All the documentation states its a async operation. It would look like that the .execute() method needs to take a ActionListener callback. https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/action/ActionListener.java http://www.elasticsearch.org/guide/en/elasticsearch/client/java-api/current/java-api.html > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 05:36:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 05:36:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004213#comment-13004213 ] Gary Brown commented on RTGOV-574: ---------------------------------- Your second reference says "All operations are completely asynchronous in nature (either accepts a listener, or returns a future)." In this case it is receiving a 'future' and calling the 'actionGet()' on it, which would be blocking awaiting the result. > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 06:10:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 06:10:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-574: ----------------------------- Fix Version/s: (was: 2.0.0.Final) > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 06:18:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 06:18:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004220#comment-13004220 ] Gary Brown commented on RTGOV-574: ---------------------------------- Removing association with version 2.0.0.Final as does not appear to be causing any adverse effect - however will keep open for now. [~imckinle] Just wanted to check, is there a reason the mappings are applied regardless of whether the index is created or already exists? Does this need to be done for each restart - is it in case the mappings change? > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 06:22:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 06:22:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-539) Change pom.xml version property format to "version.x.y.x" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-539. ------------------------------ Resolution: Done Assume this issue can now be closed. If not, please reopen. Thanks Brett. > Change pom.xml version property format to "version.x.y.x" > --------------------------------------------------------- > > Key: RTGOV-539 > URL: https://issues.jboss.org/browse/RTGOV-539 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 2.0.0.Final > > > Currently we use x.y.z.version in the overlord projects. > We need to change this in all Overlord projects, not just S-RAMP. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 06:38:02 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Fri, 19 Sep 2014 06:38:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004226#comment-13004226 ] ivan mckinley commented on RTGOV-574: ------------------------------------- yes theres a reason, the rtgov index and types do not change. but in the event we need to add attributes applying mappings at each start allows us to do this. If a mapping configuration already exist then no changes occur on the ES backend. this is only concerned with additional attributes. The reasoning behind such a setup was to allow users to apply their ES types and indexes and add attributes as their project develops FYI: this feature no longer works since this line has been added from the karaf support. "Thread.currentThread().setContextClassLoader(TransportClient.class.getClassLoader());" the classcontext mean it cannot find any customer mapping files supplied by the end-users. > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 06:42:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 06:42:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-574) Investigate 'index already exists' exception when previous command indicates does not exist In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004228#comment-13004228 ] Gary Brown commented on RTGOV-574: ---------------------------------- Thanks for the clarification - could you raise a bug regarding the context classloader and we can see whether this can be addressed and still support fuse :) > Investigate 'index already exists' exception when previous command indicates does not exist > ------------------------------------------------------------------------------------------- > > Key: RTGOV-574 > URL: https://issues.jboss.org/browse/RTGOV-574 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > > When updating to Elasticsearch 1.3.2 (RTGOV-568), noticed that when the EAP server was restarted, it resulted in an IndexAlreadyExistsException from ES. > However this exception was generated from code called to create the indexes - however prior to that call it checks with the ES node whether the indexes already exist. > Ivan McKinley found the following reference that may be relevant: http://stackoverflow.com/questions/23883110/elasticsearch-index-exists-not-working-reliable > He also suggests: > "If this is the problem then we may have an impact from running ?embedded? mode. The more data we have the longer response from the async process perhaps. > externalising the es process may resolve this.. and another test is to remove the entire contents of the index/type/ to further prove that we are affect the amount of data. > The various scenarios here are definitely interesting for us regarding documentation" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 07:32:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Sep 2014 07:32: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 updated SRAMP-16: ----------------------------- Summary: Eclipse IDE: S-RAMP tooling (was: Browse the S-RAMP repository from within the IDE) > 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: Kurt Stam > Fix For: 0.6.0 > > > This issue is similar to the WebBased browser, but it should run inside the IDE. Maybe we can run it in Eclipse's WebContainer. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 07:34:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Sep 2014 07:34: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 updated SRAMP-16: ----------------------------- Description: Introducing IDE-based tooling, interacting with the S-RAMP repo, brings up several interesting use cases. (was: This issue is similar to the WebBased browser, but it should run inside the IDE. Maybe we can run it in Eclipse's WebContainer.) > 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: Kurt Stam > Fix For: 0.6.0 > > > Introducing IDE-based tooling, interacting with the S-RAMP repo, brings up several interesting use cases. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 07:43:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 19 Sep 2014 07:43: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 updated SRAMP-16: ----------------------------- Description: 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. was:Introducing IDE-based tooling, interacting with the S-RAMP repo, brings up several interesting use cases. > 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: Kurt Stam > Fix For: 0.6.0 > > > 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 Fri Sep 19 10:23:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 10:23:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-570) Document Elasticsearch cluster configuration options In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-570: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/204 > Document Elasticsearch cluster configuration options > ---------------------------------------------------- > > Key: RTGOV-570 > URL: https://issues.jboss.org/browse/RTGOV-570 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Incorporate Ivan's information on clustering Elasticsearch into rtgov docs: > "Quick doc outline how Elasticsearch for FSW can be configured to > - become part of a ES cluster (default) > - act a a simple client but saving data a remote ES cluster > - INVM mode. when ES node is started in jboss jvm > https://mojo.redhat.com/groups/jboss-integration-sme/blog/2014/09/10/configure-fsw61rtgov2-to-join-a-es-cluster?sr=stream" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:24:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 10:24:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-570) Document Elasticsearch cluster configuration options In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-570. ------------------------------ Resolution: Done > Document Elasticsearch cluster configuration options > ---------------------------------------------------- > > Key: RTGOV-570 > URL: https://issues.jboss.org/browse/RTGOV-570 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Incorporate Ivan's information on clustering Elasticsearch into rtgov docs: > "Quick doc outline how Elasticsearch for FSW can be configured to > - become part of a ES cluster (default) > - act a a simple client but saving data a remote ES cluster > - INVM mode. when ES node is started in jboss jvm > https://mojo.redhat.com/groups/jboss-integration-sme/blog/2014/09/10/configure-fsw61rtgov2-to-join-a-es-cluster?sr=stream" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 10:41:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 10:41:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-564) Discriminate between Service Responsetime and component Responsetime in Kibana dashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004333#comment-13004333 ] Gary Brown commented on RTGOV-564: ---------------------------------- I'm not entirely clear what representation you are looking for, although I understand the goal of trying to hide component services. Currently response times associated with promoted services have a 'gateway' property, so would you be able to create a dashboard of the style you are looking for, distinguishing the response information for promoted and component services using 'properties.gateway' field? If so, can you attach the modified dashboard on this jira and I'll try it out. Thanks. > Discriminate between Service Responsetime and component Responsetime in Kibana dashboard > ------------------------------------------------------------------------------------------ > > Key: RTGOV-564 > URL: https://issues.jboss.org/browse/RTGOV-564 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Kibana ui > The current kibana dashboard shows the response times for all component response times. It was observed that this is not optimal and clear to end-users. Endusers would initially be most interested in the response times on the promoted interface ?soap binding? for example. Independent to the switchyard world, this would mean only displaying the response time for the entire serviceTX (and ignoring the components response times) or as its know the activityUnit > Proposal, > that the landing kibana dashboard shows the response times for the entire serviceTX in a dedicated table and the response times for the components in another. > View the response of components could be another widget. i would not suggest another dashboard as this would mean users could not drill down into a service?s components > Example, in the default dashboard, the table LIST OF SERVICES TABLE. > This table displays the service tx response time but also the component response time. to the end user this not exactly clear > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/FundsService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/InventoryService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/LogisticsService > howto, > Perhaps a flag will be required on the response time object to discriminate component response time and service tx response times > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:13:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 11:13:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-562) Docs: reporting activity info needs to be updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-562: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/205 > Docs: reporting activity info needs to be updated > ------------------------------------------------- > > Key: RTGOV-562 > URL: https://issues.jboss.org/browse/RTGOV-562 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Need to update dev guide reporting activity section. Direct injection no longer used, instead use the overlord-commons ServiceRegistry. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 19 11:13:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 19 Sep 2014 11:13:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-562) Docs: reporting activity info needs to be updated In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-562. ------------------------------ Resolution: Done > Docs: reporting activity info needs to be updated > ------------------------------------------------- > > Key: RTGOV-562 > URL: https://issues.jboss.org/browse/RTGOV-562 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Need to update dev guide reporting activity section. Direct injection no longer used, instead use the overlord-commons ServiceRegistry. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 21 12:50:02 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Sun, 21 Sep 2014 12:50:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-575) endex custom loading of index mappings per .epn deployment In-Reply-To: References: Message-ID: ivan mckinley created RTGOV-575: ----------------------------------- Summary: 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 Affects Versions: 2.0.0.Final Reporter: ivan mckinley Assignee: Gary Brown 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 Sun Sep 21 15:41:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sun, 21 Sep 2014 15:41:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reopened RTGOV-568: ------------------------------ Elasticsearch version 1.2.0 and higher is dependent upon JDK 1.7. For rtgov 2.0 we will remain JDK 1.6 compatible. > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 21 15:42:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sun, 21 Sep 2014 15:42:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-568: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 21 15:56:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sun, 21 Sep 2014 15:56:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-568: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/203, https://github.com/Governance/rtgov/pull/206 (was: https://github.com/Governance/rtgov/pull/203) > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 03:23:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 22 Sep 2014 03:23:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-549) password encryption in overlord commons In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo resolved RTGOV-549. ---------------------------------------- Resolution: Done > password encryption in overlord commons > --------------------------------------- > > Key: RTGOV-549 > URL: https://issues.jboss.org/browse/RTGOV-549 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Adapt the installers and distribution packages to the new changes done in overlord commons to encrypt the overlord.properties passwords: > Related overlord-commons jira: > https://issues.jboss.org/browse/OVERLORD-128 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 04:30:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 22 Sep 2014 04:30:02 -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.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.0.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 Mon Sep 22 04:30:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 22 Sep 2014 04:30:03 -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: ----------------------------- Affects Version/s: (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.0.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 Mon Sep 22 04:31:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 22 Sep 2014 04:31:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-532) Path for Elasticsearch node data is relative In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-532: ----------------------------- Fix Version/s: 2.0.0.Final > Path for Elasticsearch node data is relative > -------------------------------------------- > > Key: RTGOV-532 > URL: https://issues.jboss.org/browse/RTGOV-532 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When RTGov is installed into EAP it sets path.data config property to "../elasticsearch". This is incorrect as the value > - should not be relative as it depends on the directory from which the server is started > - should use ${jboss.server.data.dir}/elasticsearch as it a place where all data files for EAP are stored -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 04:32:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 22 Sep 2014 04:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-479) Create a simple distribution for installing RTGov UI into FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown closed RTGOV-479. ---------------------------- Resolution: Out of Date > Create a simple distribution for installing RTGov UI into FSW 6.0 > ----------------------------------------------------------------- > > Key: RTGOV-479 > URL: https://issues.jboss.org/browse/RTGOV-479 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > > The distribution should include the new UI, the overlord-apps properties to include it in the SSO session, and also an EPN for recording the response times to Elasticsearch. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 05:37:14 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 22 Sep 2014 05:37:14 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-532) Path for Elasticsearch node data is relative In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-532: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/207 > Path for Elasticsearch node data is relative > -------------------------------------------- > > Key: RTGOV-532 > URL: https://issues.jboss.org/browse/RTGOV-532 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When RTGov is installed into EAP it sets path.data config property to "../elasticsearch". This is incorrect as the value > - should not be relative as it depends on the directory from which the server is started > - should use ${jboss.server.data.dir}/elasticsearch as it a place where all data files for EAP are stored -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 05:37:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 22 Sep 2014 05:37:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-532) Path for Elasticsearch node data is relative In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-532. ------------------------------ Resolution: Done > Path for Elasticsearch node data is relative > -------------------------------------------- > > Key: RTGOV-532 > URL: https://issues.jboss.org/browse/RTGOV-532 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When RTGov is installed into EAP it sets path.data config property to "../elasticsearch". This is incorrect as the value > - should not be relative as it depends on the directory from which the server is started > - should use ${jboss.server.data.dir}/elasticsearch as it a place where all data files for EAP are stored -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 06:56:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 22 Sep 2014 06:56:02 -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:all-tabpanel ] David virgil naranjo updated SRAMP-569: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/490, https://github.com/Governance/overlord-commons/pull/111 > 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 > > > 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 Mon Sep 22 08:10:04 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 22 Sep 2014 08:10:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-570) Improve s-ramp commands for Fuse/Fabric In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-570: ------------------------------------------ Summary: 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 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 Mon Sep 22 08:11:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 22 Sep 2014 08:11:02 -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:all-tabpanel ] David virgil naranjo updated SRAMP-570: --------------------------------------- Description: 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 was: 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 > 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 > > 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 Mon Sep 22 08:49:04 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 22 Sep 2014 08:49:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-560) Accessing the ActiveCollection REST service fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004727#comment-13004727 ] Eric Wittmann commented on RTGOV-560: ------------------------------------- My guess is that RESTEasy is failing to find its providers. The reason is likely because it locates them using a ServiceLoader approach. To work around this, we include the providers spec in the s-ramp server WAR: https://github.com/EricWittmann/s-ramp/blob/master/s-ramp-server/fuse61/src/main/resources/META-INF/services/javax.ws.rs.ext.Providers This is just a copy/paste of the file included by RESTEasy, but when running in Fuse it of course can't find it. > Accessing the ActiveCollection REST service fails > ------------------------------------------------- > > Key: RTGOV-560 > URL: https://issues.jboss.org/browse/RTGOV-560 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Accessing the Active Collection REST service within Fuse causes the following error: Error 400 Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > Previously the QuerySpec was passed via the REST API as a string, and converted to a QuerySpec class within the REST service. However to make the REST API docs more descriptive, the method was updated to pass in a QuerySpec object - which works fine in EAP, but is failing in Fuse. > The exception in the log is: > {noformat} > 21:52:58,747 | ERROR | qtp988607914-80 | SynchronousDispatcher | 309 - org.jboss.resteasy.resteasy-jaxrs - 2.3.7.Final | Failed executing POST /acm/query > org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:153)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:136)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:159)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:238)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:220)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all- > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 09:46:04 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 22 Sep 2014 09:46:04 -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=13004771#comment-13004771 ] Gary Brown commented on SRAMP-570: ---------------------------------- Not sure I like adding 'fabric' to the command - it makes it very long. Are there are alternatives? > 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 > > 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 Mon Sep 22 09:59:04 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 22 Sep 2014 09:59:04 -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=13004780#comment-13004780 ] David virgil naranjo commented on SRAMP-570: -------------------------------------------- I suggested the prefix fabric, because the normal command is overlord:s-ramp:configure. > 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 > > 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 Mon Sep 22 10:08:02 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Mon, 22 Sep 2014 10:08:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-564) Discriminate between Service Responsetime and component Responsetime in Kibana dashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004785#comment-13004785 ] ivan mckinley commented on RTGOV-564: ------------------------------------- Ok, Let me try this out. if the gateway flag works perhaps its makes to mark this part of the default dashboard > Discriminate between Service Responsetime and component Responsetime in Kibana dashboard > ------------------------------------------------------------------------------------------ > > Key: RTGOV-564 > URL: https://issues.jboss.org/browse/RTGOV-564 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Kibana ui > The current kibana dashboard shows the response times for all component response times. It was observed that this is not optimal and clear to end-users. Endusers would initially be most interested in the response times on the promoted interface ?soap binding? for example. Independent to the switchyard world, this would mean only displaying the response time for the entire serviceTX (and ignoring the components response times) or as its know the activityUnit > Proposal, > that the landing kibana dashboard shows the response times for the entire serviceTX in a dedicated table and the response times for the components in another. > View the response of components could be another widget. i would not suggest another dashboard as this would mean users could not drill down into a service?s components > Example, in the default dashboard, the table LIST OF SERVICES TABLE. > This table displays the service tx response time but also the component response time. to the end user this not exactly clear > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/FundsService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/InventoryService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/LogisticsService > howto, > Perhaps a flag will be required on the response time object to discriminate component response time and service tx response times > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 22 10:17:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Sep 2014 10:17:02 -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=13004796#comment-13004796 ] Brett Meyer commented on SRAMP-570: ----------------------------------- [~virchete], not sure that we need new Fabric commands at all. The overlay zip, provided by the fsw-fuse project, will continue to be the installation method. Your original ConfigureFabricProfilesCommand should be all that's needed. I'd vote to simply leave that as-is. > 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 > > 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 Mon Sep 22 10:18:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Sep 2014 10:18:03 -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=13004796#comment-13004796 ] Brett Meyer edited comment on SRAMP-570 at 9/22/14 10:17 AM: ------------------------------------------------------------- [~virchete], not sure that we need new Fabric commands at all. The overlay zip, provided by the fsw-fuse project, will continue to be the installation method. Your original ConfigureFabricProfilesCommand should be all that's needed (overlord:configureFabric). I'd vote to simply leave that as-is. was (Author: brmeyer): [~virchete], not sure that we need new Fabric commands at all. The overlay zip, provided by the fsw-fuse project, will continue to be the installation method. Your original ConfigureFabricProfilesCommand should be all that's needed. I'd vote to simply leave that as-is. > 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 > > 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 Mon Sep 22 10:21:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 22 Sep 2014 10:21:02 -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=13004803#comment-13004803 ] David virgil naranjo commented on SRAMP-570: -------------------------------------------- But the ConfigureFabricProfileCommand is not really well implemented. It modifies the overlord-commons profile and the s-ramp profile as well. The good solution would be to have an Sramp FabricConfiureCommand (in the s-ramp-karaf-commands) and a FabricConfigureCommand (in the overlord-commons-karaf-commands). > 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 > > 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 Mon Sep 22 10:34:04 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 22 Sep 2014 10:34:04 -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=13004812#comment-13004812 ] Brett Meyer commented on SRAMP-570: ----------------------------------- If that's the case, then sure. But +1 on Gary's suggestion: use something like overlord:s-ramp:configureFabric (keep "overlord" as the leading namespace) > 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 > > 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 Mon Sep 22 10:37:03 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 22 Sep 2014 10:37:03 -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=13004814#comment-13004814 ] David virgil naranjo commented on SRAMP-570: -------------------------------------------- That's good! Thanks! > 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 > > 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 Sep 23 09:29:04 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 23 Sep 2014 09:29:04 -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:all-tabpanel ] David virgil naranjo updated SRAMP-570: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/112, https://github.com/Governance/s-ramp/pull/492 > 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 > > 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 Sep 23 10:07:07 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 23 Sep 2014 10:07:07 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-510) Situation state transition to Close causes resolutionState and assignedTo properties to be cleared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005388#comment-13005388 ] Gary Brown commented on RTGOV-510: ---------------------------------- [~michaelclay] Could you confirm whether you are happy for the 'resolutionState' and 'assignedTo' properties to remain set when moved to closed state? > Situation state transition to Close causes resolutionState and assignedTo properties to be cleared > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-510 > URL: https://issues.jboss.org/browse/RTGOV-510 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently when transitioning a Situation to the Closed state causes the 'resolutionState' and 'assignedTo' properties to be cleared. > This is the same state as when the Situation is first created and therefore creates an ambiguity regarding whether the situation has been dealt with. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 14:56:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Sep 2014 14:56:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-571) Support stored queries in UI In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-571: --------------------------------- Summary: 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. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 15:17:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Sep 2014 15:17:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-572) S-RAMP Username should not be added to the CLI history In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-572: --------------------------------- Summary: S-RAMP Username should not be added to the CLI history Key: SRAMP-572 URL: https://issues.jboss.org/browse/SRAMP-572 Project: S-RAMP Issue Type: Bug Reporter: Brett Meyer Assignee: David virgil naranjo Priority: Minor How to reproduce: 1.) Start up s-ramp-shell 2.) connect http://localhost:8080/s-ramp-server 3.) enter username and password 4.) hit the up-arrow key 5.) note that the username provided in #3 appears in the history *No* user-provided values should be in the history. Find out why that's getting added. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 23 15:21:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Sep 2014 15:21:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-573) Ctrl+C should not exit the CLI In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-573: --------------------------------- Summary: 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 Tue Sep 23 15:22:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 23 Sep 2014 15:22:02 -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=13005502#comment-13005502 ] Brett Meyer commented on SRAMP-573: ----------------------------------- Also note that Ctrl+D currently gives a NPE. Make sure it exits cleanly. > 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 Wed Sep 24 10:34:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Sep 2014 10:34:02 -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:all-tabpanel ] Brett Meyer resolved SRAMP-569. ------------------------------- Resolution: Done > 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 > > > 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 Wed Sep 24 12:23:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 24 Sep 2014 12:23:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-395) S-RAMP allows artifacts to be created with invalid characters in the Artifact Type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005794#comment-13005794 ] RH Bugzilla Integration commented on SRAMP-395: ----------------------------------------------- Rick Wagner changed the Status of [bug 1114732|https://bugzilla.redhat.com/show_bug.cgi?id=1114732] from VERIFIED to CLOSED > S-RAMP allows artifacts to be created with invalid characters in the Artifact Type > ---------------------------------------------------------------------------------- > > Key: SRAMP-395 > URL: https://issues.jboss.org/browse/SRAMP-395 > Project: S-RAMP > Issue Type: Bug > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Alpha1 > > > There are two ways (I believe) that users can mistakenly create artifacts with an invalid artifact type. The first is via the CLI: > {code} > s-ramp:upload /path/to/file.ext "Invalid Type" > s-ramp:create "Invalid Type" "Valid Artifact Name" "Description goes here." > {code} > The other is via the s-ramp UI's Import Artifact dialog. This dialog allows the user to type in any Artifact Type they want, which is an opportunity to mess it up. > We need to make sure we have appropriate validation of any custom Artifact Type provided by the user on the server (probably in the REST layer). > For bonus points we can add validation to the UI and CLI to prevent the request from even being made to the server unless it's valid. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 13:32:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Sep 2014 13:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-29) Add support for Stored Queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-29: ----------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/494 > Add support for Stored Queries > ------------------------------ > > Key: SRAMP-29 > URL: https://issues.jboss.org/browse/SRAMP-29 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. > {quote} > S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details. > > The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes: > queryName: The name of the Stored Query instance. This must be unique. > queryExpression: The specification of the query expression. > > A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific. > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 14:36:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 24 Sep 2014 14:36:02 -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:all-tabpanel ] RH Bugzilla Integration updated RTGOV-556: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146206 > 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 Wed Sep 24 14:38:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 24 Sep 2014 14:38:02 -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=13005837#comment-13005837 ] RH Bugzilla Integration commented on RTGOV-556: ----------------------------------------------- Rick Wagner changed the Status of [bug 1146206|https://bugzilla.redhat.com/show_bug.cgi?id=1146206] from NEW to ASSIGNED > 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 Wed Sep 24 14:40:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 24 Sep 2014 14:40:02 -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:all-tabpanel ] RH Bugzilla Integration updated RTGOV-566: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146207 > [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 Wed Sep 24 14:41:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 24 Sep 2014 14:41:02 -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=13005838#comment-13005838 ] RH Bugzilla Integration commented on RTGOV-566: ----------------------------------------------- Rick Wagner changed the Status of [bug 1146207|https://bugzilla.redhat.com/show_bug.cgi?id=1146207] from NEW to ASSIGNED > [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 Wed Sep 24 16:48:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Sep 2014 16:48:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-29) Add support for Stored Queries In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-29. ------------------------------ Resolution: Done > Add support for Stored Queries > ------------------------------ > > Key: SRAMP-29 > URL: https://issues.jboss.org/browse/SRAMP-29 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > Section 4.5 of the S-RAMP spec discusses stored queries. We need to add support for them. > {quote} > S-RAMP provides support for storing queries in the repository using the StoredQuery Artifact Type. This can be convenient because it allows quick execution of a frequently performed query. The syntax associated with creation, retrieval, update and deletion of a Stored Query is binding specific. Refer to the appropriate binding document of this specification for details. > > The StoredQuery Artifact Type does NOT extend BaseArtifactType as do most other Artifact Types in S-RAMP, which means it is simpler and possesses only these built-in attributes: > queryName: The name of the Stored Query instance. This must be unique. > queryExpression: The specification of the query expression. > > A StoredQuery MAY also contain a list of propertyName values. These are used to indicate to the server that the results returned from the execution of the query SHALL include values for those property names when they are present in the artifact instance(s) returned. This can be valuable in bindings that may not necessarily return the complete artifact in query results. The actual format of the query response is binding specific. > {quote} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 16:49:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Sep 2014 16:49:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-23) Statically validate a parsed S-RAMP Query In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-23?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005868#comment-13005868 ] Brett Meyer commented on SRAMP-23: ---------------------------------- Moving out of SRAMP-21 -- not required by spec > Statically validate a parsed S-RAMP Query > ----------------------------------------- > > Key: SRAMP-23 > URL: https://issues.jboss.org/browse/SRAMP-23 > Project: S-RAMP > Issue Type: Sub-task > Components: Core > Affects Versions: 0.6.0 > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > Fix For: 0.6.0 > > > Implement a validator that can take an S-RAMP Query and ensure that it is valid (does not violate any of the restrictions imposed by the S-RAMP Query API specification). > The result should simply be a validator that accepts a parsed S-RAMP Query and throws an exception if the Query is invalid. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 16:50:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Sep 2014 16:50:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-23) Statically validate a parsed S-RAMP Query In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-23: ----------------------------- Parent: (was: SRAMP-21) Issue Type: Feature Request (was: Sub-task) > Statically validate a parsed S-RAMP Query > ----------------------------------------- > > Key: SRAMP-23 > URL: https://issues.jboss.org/browse/SRAMP-23 > Project: S-RAMP > Issue Type: Feature Request > Components: Core > Affects Versions: 0.6.0 > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > Fix For: 0.6.0 > > > Implement a validator that can take an S-RAMP Query and ensure that it is valid (does not violate any of the restrictions imposed by the S-RAMP Query API specification). > The result should simply be a validator that accepts a parsed S-RAMP Query and throws an exception if the Query is invalid. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Wed Sep 24 16:51:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 24 Sep 2014 16:51:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-21) Implement S-RAMP Query API In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-21. ------------------------------ Resolution: Done > Implement S-RAMP Query API > -------------------------- > > Key: SRAMP-21 > URL: https://issues.jboss.org/browse/SRAMP-21 > Project: S-RAMP > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.6.0 > > > The S-RAMP specification defines a Query API that is based on a subset of the X-Path 2.0 grammar. This query API needs to be implemented. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 05:02:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 05:02:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-560) Accessing the ActiveCollection REST service fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-560: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146411 > Accessing the ActiveCollection REST service fails > ------------------------------------------------- > > Key: RTGOV-560 > URL: https://issues.jboss.org/browse/RTGOV-560 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Accessing the Active Collection REST service within Fuse causes the following error: Error 400 Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > Previously the QuerySpec was passed via the REST API as a string, and converted to a QuerySpec class within the REST service. However to make the REST API docs more descriptive, the method was updated to pass in a QuerySpec object - which works fine in EAP, but is failing in Fuse. > The exception in the log is: > {noformat} > 21:52:58,747 | ERROR | qtp988607914-80 | SynchronousDispatcher | 309 - org.jboss.resteasy.resteasy-jaxrs - 2.3.7.Final | Failed executing POST /acm/query > org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:153)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:136)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:159)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:238)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:220)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all- > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 06:20:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 25 Sep 2014 06:20:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-560) Accessing the ActiveCollection REST service fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-560: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/208 > Accessing the ActiveCollection REST service fails > ------------------------------------------------- > > Key: RTGOV-560 > URL: https://issues.jboss.org/browse/RTGOV-560 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Accessing the Active Collection REST service within Fuse causes the following error: Error 400 Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > Previously the QuerySpec was passed via the REST API as a string, and converted to a QuerySpec class within the REST service. However to make the REST API docs more descriptive, the method was updated to pass in a QuerySpec object - which works fine in EAP, but is failing in Fuse. > The exception in the log is: > {noformat} > 21:52:58,747 | ERROR | qtp988607914-80 | SynchronousDispatcher | 309 - org.jboss.resteasy.resteasy-jaxrs - 2.3.7.Final | Failed executing POST /acm/query > org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:153)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:136)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:159)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:238)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:220)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all- > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 06:20:04 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 25 Sep 2014 06:20:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-560) Accessing the ActiveCollection REST service fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-560. ------------------------------ Resolution: Done > Accessing the ActiveCollection REST service fails > ------------------------------------------------- > > Key: RTGOV-560 > URL: https://issues.jboss.org/browse/RTGOV-560 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Accessing the Active Collection REST service within Fuse causes the following error: Error 400 Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > Previously the QuerySpec was passed via the REST API as a string, and converted to a QuerySpec class within the REST service. However to make the REST API docs more descriptive, the method was updated to pass in a QuerySpec object - which works fine in EAP, but is failing in Fuse. > The exception in the log is: > {noformat} > 21:52:58,747 | ERROR | qtp988607914-80 | SynchronousDispatcher | 309 - org.jboss.resteasy.resteasy-jaxrs - 2.3.7.Final | Failed executing POST /acm/query > org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:153)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:136)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:159)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:238)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:220)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all- > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 06:23:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 06:23:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-560) Accessing the ActiveCollection REST service fails In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006003#comment-13006003 ] RH Bugzilla Integration commented on RTGOV-560: ----------------------------------------------- Gary Brown changed the Status of [bug 1146411|https://bugzilla.redhat.com/show_bug.cgi?id=1146411] from NEW to MODIFIED > Accessing the ActiveCollection REST service fails > ------------------------------------------------- > > Key: RTGOV-560 > URL: https://issues.jboss.org/browse/RTGOV-560 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Accessing the Active Collection REST service within Fuse causes the following error: Error 400 Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > Previously the QuerySpec was passed via the REST API as a string, and converted to a QuerySpec class within the REST service. However to make the REST API docs more descriptive, the method was updated to pass in a QuerySpec object - which works fine in EAP, but is failing in Fuse. > The exception in the log is: > {noformat} > 21:52:58,747 | ERROR | qtp988607914-80 | SynchronousDispatcher | 309 - org.jboss.resteasy.resteasy-jaxrs - 2.3.7.Final | Failed executing POST /acm/query > org.jboss.resteasy.spi.BadRequestException: Could not find message body reader for type: class org.overlord.rtgov.active.collection.QuerySpec of content type: application/json > at org.jboss.resteasy.core.MessageBodyParameterInjector.inject(MessageBodyParameterInjector.java:153)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.injectArguments(MethodInjectorImpl.java:136)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:159)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:542)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:524)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:126)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50)[309:org.jboss.resteasy.resteasy-jaxrs:2.3.7.Final] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:684)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1496)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilterChain(SamlBearerTokenAuthFilter.java:238)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.overlord.commons.auth.filters.SamlBearerTokenAuthFilter.doFilter(SamlBearerTokenAuthFilter.java:220)[300:org.overlord.overlord-commons-auth:2.0.8.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all- > {noformat} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 09:31:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Sep 2014 09:31:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-574) S-RAMP 1.0 spec, optional requirements In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-574: --------------------------------- Summary: S-RAMP 1.0 spec, optional requirements Key: SRAMP-574 URL: https://issues.jboss.org/browse/SRAMP-574 Project: S-RAMP Issue Type: Task Reporter: Brett Meyer Assignee: Brett Meyer This supertask covers *optional* requirements discovered during SRAMP-462. In order to expedite S-RAMP 1.0.0.Final and 100% spec compliance, SRAMP-462 is focused solely on SHALLs. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 09:37:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Sep 2014 09:37:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-575) Support stored query templates/parameter-substitution In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-575: --------------------------------- Summary: Support stored query templates/parameter-substitution Key: SRAMP-575 URL: https://issues.jboss.org/browse/SRAMP-575 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Assignee: Brett Meyer >From the Atom Binding spec, 3.3.1: {quote} Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: ${var-name} A value for the var-name can then be specified as part of the query invocation. Default values are not supported. {quote} ex: s-ramp/serviceImplementation/ServiceInstance[@version >= ${MINVERSION}]> -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 09:43:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Sep 2014 09:43:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-575) Support stored query templates/parameter-substitution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-575: ------------------------------ Description: >From the Atom Binding spec, 3.3.1: {quote} Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: $\{var-name\} A value for the var-name can then be specified as part of the query invocation. Default values are not supported. {quote} ex: s-ramp/serviceImplementation/ServiceInstance[@version >= ${MINVERSION}]> was: >From the Atom Binding spec, 3.3.1: {quote} Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: ${var-name} A value for the var-name can then be specified as part of the query invocation. Default values are not supported. {quote} ex: s-ramp/serviceImplementation/ServiceInstance[@version >= ${MINVERSION}]> > Support stored query templates/parameter-substitution > ----------------------------------------------------- > > Key: SRAMP-575 > URL: https://issues.jboss.org/browse/SRAMP-575 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > From the Atom Binding spec, 3.3.1: > {quote} > Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: > > $\{var-name\} > > A value for the var-name can then be specified as part of the query invocation. Default values are not supported. > {quote} > ex: s-ramp/serviceImplementation/ServiceInstance[@version >= ${MINVERSION}]> -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 09:43:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Sep 2014 09:43:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-575) Support stored query templates/parameter-substitution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-575: ------------------------------ Description: >From the Atom Binding spec, 3.3.1: {quote} Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: $\{var-name\} A value for the var-name can then be specified as part of the query invocation. Default values are not supported. {quote} ex: s-ramp/serviceImplementation/ServiceInstance[@version >= $\{MINVERSION\}]> was: >From the Atom Binding spec, 3.3.1: {quote} Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: $\{var-name\} A value for the var-name can then be specified as part of the query invocation. Default values are not supported. {quote} ex: s-ramp/serviceImplementation/ServiceInstance[@version >= ${MINVERSION}]> > Support stored query templates/parameter-substitution > ----------------------------------------------------- > > Key: SRAMP-575 > URL: https://issues.jboss.org/browse/SRAMP-575 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > From the Atom Binding spec, 3.3.1: > {quote} > Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: > > $\{var-name\} > > A value for the var-name can then be specified as part of the query invocation. Default values are not supported. > {quote} > ex: s-ramp/serviceImplementation/ServiceInstance[@version >= $\{MINVERSION\}]> -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 09:44:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 25 Sep 2014 09:44:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-575) Support stored query templates/parameter-substitution In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-575: ------------------------------ Description: >From the Atom Binding spec, 3.3.1: {quote} Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: $\{var-name\} A value for the var-name can then be specified as part of the query invocation. Default values are not supported. {quote} {code}s-ramp/serviceImplementation/ServiceInstance[@version >= ${MINVERSION}]>{code} was: >From the Atom Binding spec, 3.3.1: {quote} Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: $\{var-name\} A value for the var-name can then be specified as part of the query invocation. Default values are not supported. {quote} ex: s-ramp/serviceImplementation/ServiceInstance[@version >= $\{MINVERSION\}]> > Support stored query templates/parameter-substitution > ----------------------------------------------------- > > Key: SRAMP-575 > URL: https://issues.jboss.org/browse/SRAMP-575 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Assignee: Brett Meyer > > From the Atom Binding spec, 3.3.1: > {quote} > Stored Query Entry documents MAY also be used as templates, allowing simple substitution of client specified parameter values during execution. The syntax for parameter substitution follows the XPath2 style to represent a variable within the query filter: > > $\{var-name\} > > A value for the var-name can then be specified as part of the query invocation. Default values are not supported. > {quote} > {code}s-ramp/serviceImplementation/ServiceInstance[@version >= ${MINVERSION}]>{code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 10:18:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 25 Sep 2014 10:18:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-510) Situation state transition to Close causes resolutionState and assignedTo properties to be cleared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reassigned RTGOV-510: -------------------------------- Assignee: Gary Brown (was: Michael Clay) > Situation state transition to Close causes resolutionState and assignedTo properties to be cleared > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-510 > URL: https://issues.jboss.org/browse/RTGOV-510 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently when transitioning a Situation to the Closed state causes the 'resolutionState' and 'assignedTo' properties to be cleared. > This is the same state as when the Situation is first created and therefore creates an ambiguity regarding whether the situation has been dealt with. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 10:19:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 25 Sep 2014 10:19:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-510) Situation state transition to Close causes resolutionState and assignedTo properties to be cleared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-510: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/209 > Situation state transition to Close causes resolutionState and assignedTo properties to be cleared > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-510 > URL: https://issues.jboss.org/browse/RTGOV-510 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently when transitioning a Situation to the Closed state causes the 'resolutionState' and 'assignedTo' properties to be cleared. > This is the same state as when the Situation is first created and therefore creates an ambiguity regarding whether the situation has been dealt with. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 10:19:04 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 25 Sep 2014 10:19:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-510) Situation state transition to Close causes resolutionState and assignedTo properties to be cleared In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-510. ------------------------------ Resolution: Done Changed button label and associated method names from 'Close' to 'Unassign' to better reflect what it was performing. > Situation state transition to Close causes resolutionState and assignedTo properties to be cleared > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-510 > URL: https://issues.jboss.org/browse/RTGOV-510 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently when transitioning a Situation to the Closed state causes the 'resolutionState' and 'assignedTo' properties to be cleared. > This is the same state as when the Situation is first created and therefore creates an ambiguity regarding whether the situation has been dealt with. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 11:01:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:01:02 -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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-545: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146588 > 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 > > > 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 Thu Sep 25 11:08:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:08:03 -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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-566: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 > > > 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 Thu Sep 25 11:08:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:08:04 -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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-380: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 > > > 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 Thu Sep 25 11:09:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:09:02 -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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-569: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 > > > 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 Thu Sep 25 11:09:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:09:03 -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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-570: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 > > 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 Thu Sep 25 11:25:03 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:25:03 -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:all-tabpanel ] RH Bugzilla Integration updated OVERLORD-117: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 Thu Sep 25 11:25:04 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:25:04 -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:all-tabpanel ] RH Bugzilla Integration updated OVERLORD-142: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 Thu Sep 25 11:38:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 25 Sep 2014 11:38:02 -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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-544: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146617 > 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 > > > 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 Thu Sep 25 16:17:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:17:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-576) Activity collector integration with Camel In-Reply-To: References: Message-ID: Jorge Morales created RTGOV-576: ----------------------------------- Summary: Activity collector integration with Camel Key: RTGOV-576 URL: https://issues.jboss.org/browse/RTGOV-576 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Jorge Morales Assignee: Gary Brown Activity Collector integration on Camel execution with following Activity Types: - Route started - Route finished This way we can gather also metrics on Route executions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:21:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:21:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-577) Activity Collector integration for jBPM Business events In-Reply-To: References: Message-ID: Jorge Morales created RTGOV-577: ----------------------------------- Summary: Activity Collector integration for jBPM Business events Key: RTGOV-577 URL: https://issues.jboss.org/browse/RTGOV-577 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Jorge Morales Assignee: Gary Brown Currently there is an activity collector integration with jBPM to report BPMN events (process started, process finished,...) It would be nice if also there would be integration to extract business information from the process and report it as Custom Activity Types, much like can be done with the Information Processor in SwitchYard, that extract business data from the payload. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:26:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:26:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-578) Support groovy as Event Processing technology In-Reply-To: References: Message-ID: Jorge Morales created RTGOV-578: ----------------------------------- Summary: Support groovy as Event Processing technology Key: RTGOV-578 URL: https://issues.jboss.org/browse/RTGOV-578 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Jorge Morales Assignee: Gary Brown Groovy is a nice scripting language, very related to java and very easy to use, with editor capabilities. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:28:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:28:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-579) Support esper as CEP event language in Event Processing In-Reply-To: References: Message-ID: Jorge Morales created RTGOV-579: ----------------------------------- Summary: Support esper as CEP event language in Event Processing Key: RTGOV-579 URL: https://issues.jboss.org/browse/RTGOV-579 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Jorge Morales Assignee: Gary Brown Esper (http://esper.codehaus.org/) is a very powerful and very easy to use CEP event processing engine. It would be good to provide support for it as an event processor for CEP types of processing. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:36:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:36:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-580) Support websockets as protocol for event submission In-Reply-To: References: Message-ID: Jorge Morales created RTGOV-580: ----------------------------------- Summary: Support websockets as protocol for event submission Key: RTGOV-580 URL: https://issues.jboss.org/browse/RTGOV-580 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Jorge Morales Assignee: Gary Brown Sending of messages to the Activity Server using HTTP protocol is not very network optimized. Using websockets can be very much optimized as can provide support for reliability and reduced transmission size. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:39:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:39:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-581) Support UDP as protocol for event submission In-Reply-To: References: Message-ID: Jorge Morales created RTGOV-581: ----------------------------------- Summary: Support UDP as protocol for event submission Key: RTGOV-581 URL: https://issues.jboss.org/browse/RTGOV-581 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Jorge Morales Assignee: Gary Brown Using an acknowleageable protocol as HTTP can make the business application/runtime server have some performance issues. Using UDP is both easy to configure, and more reliable in terms of the runtime server. Keep in mind that sometimes the event generation/submission should not compromise the execution of the core of the platforms. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:42:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:42:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-582) Configure Event submitters per ActivityUnits o Activity Types In-Reply-To: References: Message-ID: Jorge Morales created RTGOV-582: ----------------------------------- Summary: Configure Event submitters per ActivityUnits o Activity Types Key: RTGOV-582 URL: https://issues.jboss.org/browse/RTGOV-582 Project: RTGov (Run Time Governance) Issue Type: Feature Request Reporter: Jorge Morales Assignee: Gary Brown If more than one protocols can be used to communicate/submit events to the Activity Server, it should be configurable which Event Submitter to use per ActivityUnits or ActivityTypes, so this way we use a reliable transmission protocol for ActivityUnits/Types of high interest, and non reliable transmission protocols for low priority ActivityUnits/Types. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:43:03 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:43:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-582) Configure Event submitters per ActivityUnits o Activity Types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Morales updated RTGOV-582: -------------------------------- Priority: Minor (was: Major) > Configure Event submitters per ActivityUnits o Activity Types > ------------------------------------------------------------- > > Key: RTGOV-582 > URL: https://issues.jboss.org/browse/RTGOV-582 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > > If more than one protocols can be used to communicate/submit events to the Activity Server, it should be configurable which Event Submitter to use per ActivityUnits or ActivityTypes, so this way we use a reliable transmission protocol for ActivityUnits/Types of high interest, and non reliable transmission protocols for low priority ActivityUnits/Types. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:43:03 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:43:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-581) Support UDP as protocol for event submission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Morales updated RTGOV-581: -------------------------------- Priority: Minor (was: Major) > Support UDP as protocol for event submission > -------------------------------------------- > > Key: RTGOV-581 > URL: https://issues.jboss.org/browse/RTGOV-581 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > > Using an acknowleageable protocol as HTTP can make the business application/runtime server have some performance issues. Using UDP is both easy to configure, and more reliable in terms of the runtime server. > Keep in mind that sometimes the event generation/submission should not compromise the execution of the core of the platforms. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Thu Sep 25 16:43:03 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Thu, 25 Sep 2014 16:43:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-580) Support websockets as protocol for event submission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Morales updated RTGOV-580: -------------------------------- Priority: Minor (was: Major) > Support websockets as protocol for event submission > --------------------------------------------------- > > Key: RTGOV-580 > URL: https://issues.jboss.org/browse/RTGOV-580 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > > Sending of messages to the Activity Server using HTTP protocol is not very network optimized. Using websockets can be very much optimized as can provide support for reliability and reduced transmission size. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 02:49:02 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Fri, 26 Sep 2014 02:49: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: Andrej Vano created RTGOV-583: --------------------------------- Summary: 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 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 Fri Sep 26 03:58:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 03:58:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-577) Activity Collector integration for jBPM Business events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006359#comment-13006359 ] Gary Brown commented on RTGOV-577: ---------------------------------- Can you elaborate on how rtgov would access the business information, and also is this information state associated with the process, or communicated in some way with other processes/services? > Activity Collector integration for jBPM Business events > ------------------------------------------------------- > > Key: RTGOV-577 > URL: https://issues.jboss.org/browse/RTGOV-577 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > > Currently there is an activity collector integration with jBPM to report BPMN events (process started, process finished,...) It would be nice if also there would be integration to extract business information from the process and report it as Custom Activity Types, much like can be done with the Information Processor in SwitchYard, that extract business data from the payload. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 03:59:04 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 03:59:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-578) Support groovy as Event Processing technology In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-578: ----------------------------- Fix Version/s: 2.1.0.Final > Support groovy as Event Processing technology > --------------------------------------------- > > Key: RTGOV-578 > URL: https://issues.jboss.org/browse/RTGOV-578 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Groovy is a nice scripting language, very related to java and very easy to use, with editor capabilities. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 03:59:05 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 03:59:05 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-577) Activity Collector integration for jBPM Business events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-577: ----------------------------- Fix Version/s: 2.1.0.Final > Activity Collector integration for jBPM Business events > ------------------------------------------------------- > > Key: RTGOV-577 > URL: https://issues.jboss.org/browse/RTGOV-577 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Currently there is an activity collector integration with jBPM to report BPMN events (process started, process finished,...) It would be nice if also there would be integration to extract business information from the process and report it as Custom Activity Types, much like can be done with the Information Processor in SwitchYard, that extract business data from the payload. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:00:04 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:00:04 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-579) Support esper as CEP event language in Event Processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-579: ----------------------------- Fix Version/s: 2.1.0.Final > Support esper as CEP event language in Event Processing > ------------------------------------------------------- > > Key: RTGOV-579 > URL: https://issues.jboss.org/browse/RTGOV-579 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Esper (http://esper.codehaus.org/) is a very powerful and very easy to use CEP event processing engine. It would be good to provide support for it as an event processor for CEP types of processing. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:01:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:01:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-579) Support esper as CEP event language in Event Processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006360#comment-13006360 ] Gary Brown commented on RTGOV-579: ---------------------------------- Just curious, what are the benefits of Esper over Drools Fusion? > Support esper as CEP event language in Event Processing > ------------------------------------------------------- > > Key: RTGOV-579 > URL: https://issues.jboss.org/browse/RTGOV-579 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Esper (http://esper.codehaus.org/) is a very powerful and very easy to use CEP event processing engine. It would be good to provide support for it as an event processor for CEP types of processing. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:03:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:03:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-582) Configure Event submitters per ActivityUnits o Activity Types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006362#comment-13006362 ] Gary Brown commented on RTGOV-582: ---------------------------------- Interesting idea - not all activity units are equal! How do we determine the "level of interest" in an activity unit? Is it per collection source (e.g. switchyard), or could it be more fine grained than that - i.e. a particular switchyard app? > Configure Event submitters per ActivityUnits o Activity Types > ------------------------------------------------------------- > > Key: RTGOV-582 > URL: https://issues.jboss.org/browse/RTGOV-582 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > Fix For: 2.1.0.Final > > > If more than one protocols can be used to communicate/submit events to the Activity Server, it should be configurable which Event Submitter to use per ActivityUnits or ActivityTypes, so this way we use a reliable transmission protocol for ActivityUnits/Types of high interest, and non reliable transmission protocols for low priority ActivityUnits/Types. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:03:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:03:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-582) Configure Event submitters per ActivityUnits o Activity Types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-582: ----------------------------- Fix Version/s: 2.1.0.Final > Configure Event submitters per ActivityUnits o Activity Types > ------------------------------------------------------------- > > Key: RTGOV-582 > URL: https://issues.jboss.org/browse/RTGOV-582 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > Fix For: 2.1.0.Final > > > If more than one protocols can be used to communicate/submit events to the Activity Server, it should be configurable which Event Submitter to use per ActivityUnits or ActivityTypes, so this way we use a reliable transmission protocol for ActivityUnits/Types of high interest, and non reliable transmission protocols for low priority ActivityUnits/Types. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:05:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:05: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: ----------------------------- Fix Version/s: 2.0.0.Final > 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 Fri Sep 26 04:07:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:07:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-576) Activity collector integration with Camel In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-576: ----------------------------- Fix Version/s: 2.1.0.Final > Activity collector integration with Camel > ----------------------------------------- > > Key: RTGOV-576 > URL: https://issues.jboss.org/browse/RTGOV-576 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector integration on Camel execution with following Activity Types: > - Route started > - Route finished > This way we can gather also metrics on Route executions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:08:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:08:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-576) Activity collector integration with Camel In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006366#comment-13006366 ] Gary Brown commented on RTGOV-576: ---------------------------------- I'd like to see whether the existing 'process started/stopped' events could be reused or made more generic to support the concept of a task starting/stopping. And then have the details of these events determine whether it is a process, task, route, etc. > Activity collector integration with Camel > ----------------------------------------- > > Key: RTGOV-576 > URL: https://issues.jboss.org/browse/RTGOV-576 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector integration on Camel execution with following Activity Types: > - Route started > - Route finished > This way we can gather also metrics on Route executions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:09:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:09:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-580) Support websockets as protocol for event submission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-580: ----------------------------- Fix Version/s: 2.1.0.Final > Support websockets as protocol for event submission > --------------------------------------------------- > > Key: RTGOV-580 > URL: https://issues.jboss.org/browse/RTGOV-580 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > Fix For: 2.1.0.Final > > > Sending of messages to the Activity Server using HTTP protocol is not very network optimized. Using websockets can be very much optimized as can provide support for reliability and reduced transmission size. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:16:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:16:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-581) Support UDP as protocol for event submission In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-581: ----------------------------- Fix Version/s: 2.3.0.Final > Support UDP as protocol for event submission > -------------------------------------------- > > Key: RTGOV-581 > URL: https://issues.jboss.org/browse/RTGOV-581 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > Fix For: 2.3.0.Final > > > Using an acknowleageable protocol as HTTP can make the business application/runtime server have some performance issues. Using UDP is both easy to configure, and more reliable in terms of the runtime server. > Keep in mind that sometimes the event generation/submission should not compromise the execution of the core of the platforms. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:34:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:34:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-561) Multiple notifications generated from active collections in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-561: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/210 > Multiple notifications generated from active collections in fuse > ---------------------------------------------------------------- > > Key: RTGOV-561 > URL: https://issues.jboss.org/browse/RTGOV-561 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Situations active collection gets multiple duplicate notifications in fuse. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:34:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:34:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-561) Multiple notifications generated from active collections in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-561. ------------------------------ Resolution: Done > Multiple notifications generated from active collections in fuse > ---------------------------------------------------------------- > > Key: RTGOV-561 > URL: https://issues.jboss.org/browse/RTGOV-561 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Situations active collection gets multiple duplicate notifications in fuse. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:35:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:35:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-506) Bulk actions should describe number of affected situations in confirmation dialog In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-506: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Bulk actions should describe number of affected situations in confirmation dialog > --------------------------------------------------------------------------------- > > Key: RTGOV-506 > URL: https://issues.jboss.org/browse/RTGOV-506 > Project: RTGov (Run Time Governance) > Issue Type: Task > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.1.0.Final > > > The number of situations that will be affected by the bulk action should be displayed in the confirmation dialog. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:35:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:35:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-463) Test JPA components (Activity/Situation stores and event processor) in Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-463: ----------------------------- Fix Version/s: (was: 2.0.0.Final) > Test JPA components (Activity/Situation stores and event processor) in Karaf > ---------------------------------------------------------------------------- > > Key: RTGOV-463 > URL: https://issues.jboss.org/browse/RTGOV-463 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Brett Meyer > Original Estimate: 1 week > Remaining Estimate: 1 week > > [~brmeyer] Hope you don't mind me assigning this one to you. Doesn't need to be done until after alpha. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 04:37:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 04:37:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-463) Test JPA components (Activity/Situation stores and event processor) in Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown closed RTGOV-463. ---------------------------- Resolution: Won't Fix As of 2.0.0.Final, Elasticsearch is the primary supported ActivityStore and SituationStore implementation. > Test JPA components (Activity/Situation stores and event processor) in Karaf > ---------------------------------------------------------------------------- > > Key: RTGOV-463 > URL: https://issues.jboss.org/browse/RTGOV-463 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Brett Meyer > Original Estimate: 1 week > Remaining Estimate: 1 week > > [~brmeyer] Hope you don't mind me assigning this one to you. Doesn't need to be done until after alpha. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:26:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Fri, 26 Sep 2014 06:26:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-577) Activity Collector integration for jBPM Business events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006403#comment-13006403 ] Jorge Morales commented on RTGOV-577: ------------------------------------- I can not elaborate that much into how, as I do not know that much jBPM, but as with SwitchYard we extract information from the payload, we should be able to extract information from the BPMN message flowing in the jBPM process. Maybe another way to have TaskHandlers extracting the information and sending it to the Activity Server in an explicit way. > Activity Collector integration for jBPM Business events > ------------------------------------------------------- > > Key: RTGOV-577 > URL: https://issues.jboss.org/browse/RTGOV-577 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Currently there is an activity collector integration with jBPM to report BPMN events (process started, process finished,...) It would be nice if also there would be integration to extract business information from the process and report it as Custom Activity Types, much like can be done with the Information Processor in SwitchYard, that extract business data from the payload. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:28:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Fri, 26 Sep 2014 06:28:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-579) Support esper as CEP event language in Event Processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006405#comment-13006405 ] Jorge Morales commented on RTGOV-579: ------------------------------------- The language that Esper uses is very much like SQL so more user friendly, so that has helped Esper being adopted. Some examples: "select avg(price) from org.myapp.event.OrderEvent.win:time(30 sec)" "on PlayerAnswer pa merge PlayerAnswerWindow paw where pa.playerId = paw.playerId and pa.questionId = paw.questionId when not matched then insert select questionId, (select questionTime from QuestionWindow where questionId = pa.questionId) as questionTime, playerId, answer, clientAnswerTime, false as hasReceivedFA when matched and paw.answer is null then update set paw.answer = pa.answer, paw.clientAnswerTime = pa.clientAnswerTime" See: http://esper.codehaus.org/tutorials/tutorial/examples.html > Support esper as CEP event language in Event Processing > ------------------------------------------------------- > > Key: RTGOV-579 > URL: https://issues.jboss.org/browse/RTGOV-579 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Esper (http://esper.codehaus.org/) is a very powerful and very easy to use CEP event processing engine. It would be good to provide support for it as an event processor for CEP types of processing. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:33:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Fri, 26 Sep 2014 06:33:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-582) Configure Event submitters per ActivityUnits o Activity Types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006407#comment-13006407 ] Jorge Morales commented on RTGOV-582: ------------------------------------- I think that we should be exploring options with real use cases examples. I have done a project with similar concept as RTGov where I was submitting different types of events, those that model SOA events, which at the end provide with system behavior, and those customer/application specific events, which provided business behavior. Criticity of those are different in the sense that OPs needed to know how system was behaving, but they could live without having the business information in an scenario where the system was under heavy load, as they could do a replay of those events from logs at a later stage (batched business event replaying). I think they could be both, collection source and switchyard application, depending on the Activity Collector. > Configure Event submitters per ActivityUnits o Activity Types > ------------------------------------------------------------- > > Key: RTGOV-582 > URL: https://issues.jboss.org/browse/RTGOV-582 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Priority: Minor > Fix For: 2.1.0.Final > > > If more than one protocols can be used to communicate/submit events to the Activity Server, it should be configurable which Event Submitter to use per ActivityUnits or ActivityTypes, so this way we use a reliable transmission protocol for ActivityUnits/Types of high interest, and non reliable transmission protocols for low priority ActivityUnits/Types. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 06:35:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Fri, 26 Sep 2014 06:35:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-576) Activity collector integration with Camel In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006408#comment-13006408 ] Jorge Morales commented on RTGOV-576: ------------------------------------- Just think that insight into Camel could provide benefits for SwitchYard as well as for Fuse as source of Activity for RTGov, as in FUSE there is currently a lot of development done in Camel. Could be worth exploring current hooks in Camel, as in Fabric there are some metrics gathered from the Camel Routes. > Activity collector integration with Camel > ----------------------------------------- > > Key: RTGOV-576 > URL: https://issues.jboss.org/browse/RTGOV-576 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector integration on Camel execution with following Activity Types: > - Route started > - Route finished > This way we can gather also metrics on Route executions. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 07:12:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 07:12:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-577) Activity Collector integration for jBPM Business events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006413#comment-13006413 ] Gary Brown commented on RTGOV-577: ---------------------------------- One further clarification - is this for jbpm embedded in swyd, and/or jbpm running standalone? > Activity Collector integration for jBPM Business events > ------------------------------------------------------- > > Key: RTGOV-577 > URL: https://issues.jboss.org/browse/RTGOV-577 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Currently there is an activity collector integration with jBPM to report BPMN events (process started, process finished,...) It would be nice if also there would be integration to extract business information from the process and report it as Custom Activity Types, much like can be done with the Information Processor in SwitchYard, that extract business data from the payload. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 08:33:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 08:33:03 -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:all-tabpanel ] Gary Brown updated RTGOV-566: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/202, https://github.com/Governance/rtgov/pull/211 (was: https://github.com/Governance/rtgov/pull/202) > [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 Fri Sep 26 08:53:02 2014 From: issues at jboss.org (Jorge Morales (JIRA)) Date: Fri, 26 Sep 2014 08:53:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-577) Activity Collector integration for jBPM Business events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006457#comment-13006457 ] Jorge Morales commented on RTGOV-577: ------------------------------------- This should be for both, as would be good point of integrating jBPM community as well as BPMS as product. Integration should be also possible to happen in embedded jBPM in Switchyard as this is the primary integration point add off today Maybe should be splitted into 2 jiras, leave this one for integration in switchyard's jbpm and then create a new one for embedded collector for jbpm server. > Activity Collector integration for jBPM Business events > ------------------------------------------------------- > > Key: RTGOV-577 > URL: https://issues.jboss.org/browse/RTGOV-577 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Reporter: Jorge Morales > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Currently there is an activity collector integration with jBPM to report BPMN events (process started, process finished,...) It would be nice if also there would be integration to extract business information from the process and report it as Custom Activity Types, much like can be done with the Information Processor in SwitchYard, that extract business data from the payload. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 09:48:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 26 Sep 2014 09:48:02 -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=13006483#comment-13006483 ] RH Bugzilla Integration commented on RTGOV-566: ----------------------------------------------- Gary Brown changed the Status of [bug 1146207|https://bugzilla.redhat.com/show_bug.cgi?id=1146207] from ASSIGNED to MODIFIED > [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 Fri Sep 26 10:32:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 26 Sep 2014 10:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-584) Handle "class not found" in response from HttpInvoker In-Reply-To: References: Message-ID: Gary Brown created RTGOV-584: -------------------------------- Summary: Handle "class not found" in response from HttpInvoker Key: RTGOV-584 URL: https://issues.jboss.org/browse/RTGOV-584 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Issue with HttpInvoker throwing an exception when a class is not found. Investigate workaround in rtgov-ui. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Fri Sep 26 14:17:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 26 Sep 2014 14:17:02 -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:all-tabpanel ] Brett Meyer resolved SRAMP-570. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > 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 > > > 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 Sat Sep 27 09:02:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Sat, 27 Sep 2014 09:02:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-576) Demo not working: s-ramp-demos-mvn-integration In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-576: ----------------------------------- Summary: Demo not working: s-ramp-demos-mvn-integration Key: SRAMP-576 URL: https://issues.jboss.org/browse/SRAMP-576 Project: S-RAMP Issue Type: Feature Request Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.6.0 Testing for the 0.6.0 community release. The s-ramp-demos-mvn-integration demo appears to no longer work. The first half of it works fine (adding the artifact to s-ramp via maven). However the second half fails with: {code} [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building S-RAMP Demos: Maven Integration - App 0.6.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ Downloading: http://repository.jboss.org/nexus/content/groups/developer/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml Downloading: http://maven.repository.redhat.com/techpreview/all/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml Downloading: http://repo.fusesource.com/nexus/content/groups/public/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml Downloaded: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml (2 KB at 0.7KB/sec) Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-mvn-integration-artifacts-0.6.0-SNAPSHOT.pom [WARNING] The POM for org.overlord.sramp.demos:s-ramp-demos-mvn-integration-artifacts:jar:0.6.0-SNAPSHOT is missing, no dependency information available Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-mvn-integration-artifacts-0.6.0-SNAPSHOT.jar [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 27 09:18:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Sat, 27 Sep 2014 09:18:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-576) Demo not working: s-ramp-demos-mvn-integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006677#comment-13006677 ] Eric Wittmann commented on SRAMP-576: ------------------------------------- It's worth noting that the s-ramp-demos-webapp-multimodule (which does roughly the same thing) *worked*. In both cases I cleaned out my .m2/repository/org/overlord/sramp/demos directory just to make sure it didn't pull the dependency locally. {code}[INFO] Scanning for projects... [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building S-RAMP Demos: Multi-Module WebApp Deployment - Web App 0.6.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-webapp-multimodule-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml Downloading: http://repository.jboss.org/nexus/content/groups/public/org/overlord/sramp/demos/s-ramp-demos-webapp-multimodule-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml Downloaded: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-webapp-multimodule-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml (980 B at0.6 KB/sec) Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-webapp-multimodule-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-webapp-multimodule-artifacts-0.6.0-SNAPSHOT.pom Downloaded: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-webapp-multimodule-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-webapp-multimodule-artifacts-0.6.0-SNAPSHOT.pom (4 KB at 19.6 KB/sec) Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-webapp-multimodule-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-webapp-multimodule-artifacts-0.6.0-SNAPSHOT.jar Downloaded: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-webapp-multimodule-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-webapp-multimodule-artifacts-0.6.0-SNAPSHOT.jar (6 KB at 49.3 KB/sec) {code} > Demo not working: s-ramp-demos-mvn-integration > ---------------------------------------------- > > Key: SRAMP-576 > URL: https://issues.jboss.org/browse/SRAMP-576 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Testing for the 0.6.0 community release. The s-ramp-demos-mvn-integration demo appears to no longer work. The first half of it works fine (adding the artifact to s-ramp via maven). However the second half fails with: > {code} > [INFO] > [INFO] ------------------------------------------------------------------------ > [INFO] Building S-RAMP Demos: Maven Integration - App 0.6.0-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > Downloading: http://repository.jboss.org/nexus/content/groups/developer/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloading: http://maven.repository.redhat.com/techpreview/all/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloading: http://repo.fusesource.com/nexus/content/groups/public/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloaded: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml (2 KB at 0.7KB/sec) > Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-mvn-integration-artifacts-0.6.0-SNAPSHOT.pom > [WARNING] The POM for org.overlord.sramp.demos:s-ramp-demos-mvn-integration-artifacts:jar:0.6.0-SNAPSHOT is missing, no dependency information available > Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-mvn-integration-artifacts-0.6.0-SNAPSHOT.jar > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 27 10:05:02 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Sat, 27 Sep 2014 10:05:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-577) s-ramp-demos-webapp-multimodule-web WAR fails to deploy in EAP In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-577: ----------------------------------- Summary: s-ramp-demos-webapp-multimodule-web WAR fails to deploy in EAP Key: SRAMP-577 URL: https://issues.jboss.org/browse/SRAMP-577 Project: S-RAMP Issue Type: Bug Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.6.0 {code} 10:00:17,293 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war" (runtime-name: "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war") 10:00:17,576 INFO [org.jboss.web] (ServerService Thread Pool -- 145) JBAS018210: Register web context: /s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT 10:00:17,617 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT]] (ServerService Thread Pool -- 145) JBWEB000287: Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstr ap: java.lang.RuntimeException: Unable to find a public constructor for class org.jboss.resteasy.core.AsynchronousDispatcher at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:35) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:120) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:106) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:83) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:72) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:375) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:233) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap.contextInitialized(ResteasyBootstrap.java:28) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] at org.jboss.threads.JBossThread.run(JBossThread.java:122) 10:00:17,634 ERROR [org.apache.catalina.core] (ServerService Thread Pool -- 145) JBWEB001103: Error detected during context /s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT start, will stop it 10:00:17,668 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 145) MSC000001: Failed to start service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT": org.jboss.msc.service.StartException in service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodu le-web-0.6.0-SNAPSHOT": org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:97) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] at org.jboss.threads.JBossThread.run(JBossThread.java:122) Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:166) at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) ... 6 more 10:00:17,687 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war" was rolled back with the following failure message: {"JBAS014671: Failed services" => {"jboss.web.deployment.default-host.\"/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT\"" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host.\"/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT\": org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context"}} 10:00:17,727 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war (runtime-name: s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war) in 39ms 10:00:17,731 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.apache.catalina.servlets.DefaultServlet".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.apache.jasper.servlet.JspServlet".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT" (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT".realm (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] JBAS014777: Services which failed to start: service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT" {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 27 11:21:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sat, 27 Sep 2014 11:21:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-584) Handle "class not found" in response from HttpInvoker In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-584: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/212 > Handle "class not found" in response from HttpInvoker > ----------------------------------------------------- > > Key: RTGOV-584 > URL: https://issues.jboss.org/browse/RTGOV-584 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Issue with HttpInvoker throwing an exception when a class is not found. Investigate workaround in rtgov-ui. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sat Sep 27 11:22:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sat, 27 Sep 2014 11:22:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-584) Handle "class not found" in response from HttpInvoker In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-584. ------------------------------ Resolution: Done > Handle "class not found" in response from HttpInvoker > ----------------------------------------------------- > > Key: RTGOV-584 > URL: https://issues.jboss.org/browse/RTGOV-584 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Issue with HttpInvoker throwing an exception when a class is not found. Investigate workaround in rtgov-ui. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 28 15:04:02 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Sun, 28 Sep 2014 15:04:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-564) Discriminate between Service Responsetime and component Responsetime in Kibana dashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-564: -------------------------------- Attachment: RTGOV Gateways-1411930853701.json Dashboard with that only shows response times that have a value. Filter is based upon the gateway property properties.gateway:[* TO *] > Discriminate between Service Responsetime and component Responsetime in Kibana dashboard > ------------------------------------------------------------------------------------------ > > Key: RTGOV-564 > URL: https://issues.jboss.org/browse/RTGOV-564 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: RTGOV Gateways-1411930853701.json > > > Kibana ui > The current kibana dashboard shows the response times for all component response times. It was observed that this is not optimal and clear to end-users. Endusers would initially be most interested in the response times on the promoted interface ?soap binding? for example. Independent to the switchyard world, this would mean only displaying the response time for the entire serviceTX (and ignoring the components response times) or as its know the activityUnit > Proposal, > that the landing kibana dashboard shows the response times for the entire serviceTX in a dedicated table and the response times for the components in another. > View the response of components could be another widget. i would not suggest another dashboard as this would mean users could not drill down into a service?s components > Example, in the default dashboard, the table LIST OF SERVICES TABLE. > This table displays the service tx response time but also the component response time. to the end user this not exactly clear > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/FundsService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/InventoryService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/LogisticsService > howto, > Perhaps a flag will be required on the response time object to discriminate component response time and service tx response times > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Sun Sep 28 15:05:02 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Sun, 28 Sep 2014 15:05:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-564) Discriminate between Service Responsetime and component Responsetime in Kibana dashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006704#comment-13006704 ] ivan mckinley edited comment on RTGOV-564 at 9/28/14 3:04 PM: -------------------------------------------------------------- Dashboard that only shows response times that have a value for the properties.gateway attribute. all other entries will be ignore. This results in only showing the response times for the promote service. Filter is based upon the gateway property properties.gateway:[* TO *] was (Author: imckinle): Dashboard with that only shows response times that have a value. Filter is based upon the gateway property properties.gateway:[* TO *] > Discriminate between Service Responsetime and component Responsetime in Kibana dashboard > ------------------------------------------------------------------------------------------ > > Key: RTGOV-564 > URL: https://issues.jboss.org/browse/RTGOV-564 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: RTGOV Gateways-1411930853701.json > > > Kibana ui > The current kibana dashboard shows the response times for all component response times. It was observed that this is not optimal and clear to end-users. Endusers would initially be most interested in the response times on the promoted interface ?soap binding? for example. Independent to the switchyard world, this would mean only displaying the response time for the entire serviceTX (and ignoring the components response times) or as its know the activityUnit > Proposal, > that the landing kibana dashboard shows the response times for the entire serviceTX in a dedicated table and the response times for the components in another. > View the response of components could be another widget. i would not suggest another dashboard as this would mean users could not drill down into a service?s components > Example, in the default dashboard, the table LIST OF SERVICES TABLE. > This table displays the service tx response time but also the component response time. to the end user this not exactly clear > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/FundsService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/InventoryService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/LogisticsService > howto, > Perhaps a flag will be required on the response time object to discriminate component response time and service tx response times > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 04:23:02 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Mon, 29 Sep 2014 04:23: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:comment-tabpanel&focusedCommentId=13006778#comment-13006778 ] Michael Clay commented on RTGOV-567: ------------------------------------ the workaround here is to remove the hardwired 'clientAuthentication' policy from the component/service and enable it at runtime for the required binding within a ContextMapper i.e. Set required = new HashSet(); required.add(SecurityPolicy.CLIENT_AUTHENTICATION); context.setProperty(PolicyUtil.REQUIRED_PROPERTY, required, Scope.EXCHANGE).addLabels(BehaviorLabel.TRANSIENT.label()); > [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.0.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 Mon Sep 29 04:28:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 29 Sep 2014 04:28:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-578) Fuse Fabric commands refactoring In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-578: ------------------------------------------ Summary: 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 -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 08:46:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 29 Sep 2014 08:46: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:comment-tabpanel&focusedCommentId=13006839#comment-13006839 ] Brett Meyer commented on SRAMP-578: ----------------------------------- Hey [~virchete], did you have anything specific in mind for this? > 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 > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 10:33:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 29 Sep 2014 10:33:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-149) PoC Suitability of IzPack to provide Overlord installer(s) In-Reply-To: References: Message-ID: Gary Brown created OVERLORD-149: ----------------------------------- Summary: PoC Suitability of IzPack to provide Overlord installer(s) Key: OVERLORD-149 URL: https://issues.jboss.org/browse/OVERLORD-149 Project: Overlord Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Related to discussion: https://developer.jboss.org/thread/249103 Identify whether IzPack is capable of providing the functionality outlined in the discussion (e.g. create keystore, xslt transformations, etc). Also need to see whether can be easily used from within Docker (in silent mode) without X11 dependencies - potential issue raised by Jorge. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 10:34:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 29 Sep 2014 10:34:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-577) s-ramp-demos-webapp-multimodule-web WAR fails to deploy in EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006915#comment-13006915 ] Brett Meyer commented on SRAMP-577: ----------------------------------- That's what I get for using RE. I'll probably just convert this to plain-old REST > s-ramp-demos-webapp-multimodule-web WAR fails to deploy in EAP > -------------------------------------------------------------- > > Key: SRAMP-577 > URL: https://issues.jboss.org/browse/SRAMP-577 > Project: S-RAMP > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > {code} > 10:00:17,293 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war" (runtime-name: "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war") > 10:00:17,576 INFO [org.jboss.web] (ServerService Thread Pool -- 145) JBAS018210: Register web context: /s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT > 10:00:17,617 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT]] (ServerService Thread Pool -- 145) JBWEB000287: Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstr > ap: java.lang.RuntimeException: Unable to find a public constructor for class org.jboss.resteasy.core.AsynchronousDispatcher > at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:35) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:120) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:106) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:83) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:72) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:375) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:233) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap.contextInitialized(ResteasyBootstrap.java:28) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > 10:00:17,634 ERROR [org.apache.catalina.core] (ServerService Thread Pool -- 145) JBWEB001103: Error detected during context /s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT start, will stop it > 10:00:17,668 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 145) MSC000001: Failed to start service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT": org.jboss.msc.service.StartException in service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodu > le-web-0.6.0-SNAPSHOT": org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:97) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context > at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:166) > at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) > ... 6 more > 10:00:17,687 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war" was rolled back with the following failure message: > {"JBAS014671: Failed services" => {"jboss.web.deployment.default-host.\"/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT\"" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host.\"/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT\": org.jboss.msc.service.StartException in anonymous > service: JBAS018040: Failed to start context > Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context"}} > 10:00:17,727 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war (runtime-name: s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war) in 39ms > 10:00:17,731 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.apache.catalina.servlets.DefaultServlet".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.apache.jasper.servlet.JspServlet".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT" (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT".realm (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > JBAS014777: Services which failed to start: service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT" > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 10:35:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 29 Sep 2014 10:35:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-150) PoC Suitability of Embedded Ant for use in Overlord installer(s) In-Reply-To: References: Message-ID: Gary Brown created OVERLORD-150: ----------------------------------- Summary: PoC Suitability of Embedded Ant for use in Overlord installer(s) Key: OVERLORD-150 URL: https://issues.jboss.org/browse/OVERLORD-150 Project: Overlord Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Related to discussion: https://developer.jboss.org/thread/249103 May also be applicable to other PoC: OVERLORD-149, where possibly embedded Ant could be used inside the IzPack installer. Determine whether using embedded Ant can remove dependent on user having to have Ant installed, and also whether it reduces the size of the Docker image. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 13:15:05 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 29 Sep 2014 13:15:05 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-576) Demo not working: s-ramp-demos-mvn-integration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-576. ------------------------------- Resolution: Done > Demo not working: s-ramp-demos-mvn-integration > ---------------------------------------------- > > Key: SRAMP-576 > URL: https://issues.jboss.org/browse/SRAMP-576 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Testing for the 0.6.0 community release. The s-ramp-demos-mvn-integration demo appears to no longer work. The first half of it works fine (adding the artifact to s-ramp via maven). However the second half fails with: > {code} > [INFO] > [INFO] ------------------------------------------------------------------------ > [INFO] Building S-RAMP Demos: Maven Integration - App 0.6.0-SNAPSHOT > [INFO] ------------------------------------------------------------------------ > Downloading: http://repository.jboss.org/nexus/content/groups/developer/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloading: http://maven.repository.redhat.com/techpreview/all/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloading: http://repo.fusesource.com/nexus/content/groups/public/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml > Downloaded: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/maven-metadata.xml (2 KB at 0.7KB/sec) > Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-mvn-integration-artifacts-0.6.0-SNAPSHOT.pom > [WARNING] The POM for org.overlord.sramp.demos:s-ramp-demos-mvn-integration-artifacts:jar:0.6.0-SNAPSHOT is missing, no dependency information available > Downloading: sramp://localhost:8080/s-ramp-server/org/overlord/sramp/demos/s-ramp-demos-mvn-integration-artifacts/0.6.0-SNAPSHOT/s-ramp-demos-mvn-integration-artifacts-0.6.0-SNAPSHOT.jar > [INFO] ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] ------------------------------------------------------------------------ > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 14:24:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 29 Sep 2014 14:24:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-577) s-ramp-demos-webapp-multimodule-web WAR fails to deploy in EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-577. ------------------------------- Resolution: Done > s-ramp-demos-webapp-multimodule-web WAR fails to deploy in EAP > -------------------------------------------------------------- > > Key: SRAMP-577 > URL: https://issues.jboss.org/browse/SRAMP-577 > Project: S-RAMP > Issue Type: Bug > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > {code} > 10:00:17,293 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015876: Starting deployment of "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war" (runtime-name: "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war") > 10:00:17,576 INFO [org.jboss.web] (ServerService Thread Pool -- 145) JBAS018210: Register web context: /s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT > 10:00:17,617 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT]] (ServerService Thread Pool -- 145) JBWEB000287: Exception sending context initialized event to listener instance of class org.jboss.resteasy.plugins.server.servlet.ResteasyBootstr > ap: java.lang.RuntimeException: Unable to find a public constructor for class org.jboss.resteasy.core.AsynchronousDispatcher > at org.jboss.resteasy.plugins.server.resourcefactory.POJOResourceFactory.registered(POJOResourceFactory.java:35) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:120) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:106) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addResourceFactory(ResourceMethodRegistry.java:83) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.core.ResourceMethodRegistry.addPerRequestResource(ResourceMethodRegistry.java:72) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.spi.ResteasyDeployment.registration(ResteasyDeployment.java:375) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.spi.ResteasyDeployment.start(ResteasyDeployment.java:233) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap.contextInitialized(ResteasyBootstrap.java:28) [resteasy-jaxrs-2.3.8.Final-redhat-3.jar:] > at org.apache.catalina.core.StandardContext.contextListenerStart(StandardContext.java:3339) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3777) [jbossweb-7.4.8.Final-redhat-4.jar:7.4.8.Final-redhat-4] > at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) [jboss-as-web-7.4.0.Final-redhat-19.jar:7.4.0.Final-redhat-19] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > 10:00:17,634 ERROR [org.apache.catalina.core] (ServerService Thread Pool -- 145) JBWEB001103: Error detected during context /s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT start, will stop it > 10:00:17,668 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 145) MSC000001: Failed to start service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT": org.jboss.msc.service.StartException in service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodu > le-web-0.6.0-SNAPSHOT": org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:97) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_40] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_40] > at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_40] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context > at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:166) > at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:59) > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:94) > ... 6 more > 10:00:17,687 ERROR [org.jboss.as.server] (DeploymentScanner-threads - 1) JBAS015870: Deploy of deployment "s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war" was rolled back with the following failure message: > {"JBAS014671: Failed services" => {"jboss.web.deployment.default-host.\"/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT\"" => "org.jboss.msc.service.StartException in service jboss.web.deployment.default-host.\"/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT\": org.jboss.msc.service.StartException in anonymous > service: JBAS018040: Failed to start context > Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context"}} > 10:00:17,727 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Stopped deployment s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war (runtime-name: s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war) in 39ms > 10:00:17,731 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."com.sun.faces.config.ConfigureListener".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.faces.webapp.FacetTag".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.apache.catalina.servlets.DefaultServlet".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.apache.jasper.servlet.JspServlet".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".component."org.jboss.resteasy.plugins.server.servlet.ResteasyBootstrap".START (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT" (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT".realm (missing) dependents: [service jboss.deployment.unit."s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT.war".deploymentCompleteService] > JBAS014777: Services which failed to start: service jboss.web.deployment.default-host."/s-ramp-demos-webapp-multimodule-web-0.6.0-SNAPSHOT" > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 16:50:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 29 Sep 2014 16:50:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-564) Discriminate between Service Responsetime and component Responsetime in Kibana dashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-564: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/213 > Discriminate between Service Responsetime and component Responsetime in Kibana dashboard > ------------------------------------------------------------------------------------------ > > Key: RTGOV-564 > URL: https://issues.jboss.org/browse/RTGOV-564 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: RTGOV Gateways-1411930853701.json > > > Kibana ui > The current kibana dashboard shows the response times for all component response times. It was observed that this is not optimal and clear to end-users. Endusers would initially be most interested in the response times on the promoted interface ?soap binding? for example. Independent to the switchyard world, this would mean only displaying the response time for the entire serviceTX (and ignoring the components response times) or as its know the activityUnit > Proposal, > that the landing kibana dashboard shows the response times for the entire serviceTX in a dedicated table and the response times for the components in another. > View the response of components could be another widget. i would not suggest another dashboard as this would mean users could not drill down into a service?s components > Example, in the default dashboard, the table LIST OF SERVICES TABLE. > This table displays the service tx response time but also the component response time. to the end user this not exactly clear > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/FundsService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/InventoryService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/LogisticsService > howto, > Perhaps a flag will be required on the response time object to discriminate component response time and service tx response times > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 16:52:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 29 Sep 2014 16:52:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-564) Discriminate between Service Responsetime and component Responsetime in Kibana dashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-564. ------------------------------ Resolution: Done Thanks for the example dashboard Ivan. After further consideration I realised that basing the decision on the contents of the gateway field is only relevant for switchyard (and other services that report this information) however other systems may not have a gateway but still be 'public'. Therefore implemented a new boolean field on the RPCActivityType called 'internal' to indicate this fact. I've updated the default dashboard to use this information - and the filter can be disabled to show all services. > Discriminate between Service Responsetime and component Responsetime in Kibana dashboard > ------------------------------------------------------------------------------------------ > > Key: RTGOV-564 > URL: https://issues.jboss.org/browse/RTGOV-564 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: RTGOV Gateways-1411930853701.json > > > Kibana ui > The current kibana dashboard shows the response times for all component response times. It was observed that this is not optimal and clear to end-users. Endusers would initially be most interested in the response times on the promoted interface ?soap binding? for example. Independent to the switchyard world, this would mean only displaying the response time for the entire serviceTX (and ignoring the components response times) or as its know the activityUnit > Proposal, > that the landing kibana dashboard shows the response times for the entire serviceTX in a dedicated table and the response times for the components in another. > View the response of components could be another widget. i would not suggest another dashboard as this would mean users could not drill down into a service?s components > Example, in the default dashboard, the table LIST OF SERVICES TABLE. > This table displays the service tx response time but also the component response time. to the end user this not exactly clear > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/FundsService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/InventoryService > {urn:switchyard-quickstart-demo:orders:0.1.0}OrderService/LogisticsService > howto, > Perhaps a flag will be required on the response time object to discriminate component response time and service tx response times > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Mon Sep 29 23:31:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 29 Sep 2014 23:31:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-405) Documentation: add artifact model docs for SY model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007121#comment-13007121 ] RH Bugzilla Integration commented on SRAMP-405: ----------------------------------------------- belong at redhat.com changed the Status of [bug 1088989|https://bugzilla.redhat.com/show_bug.cgi?id=1088989] from VERIFIED to NEW > Documentation: add artifact model docs for SY model > --------------------------------------------------- > > Key: SRAMP-405 > URL: https://issues.jboss.org/browse/SRAMP-405 > Project: S-RAMP > Issue Type: Task > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Beta1 > > > We document many of our models but we're missing documentation for the SY model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 04:12:02 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Tue, 30 Sep 2014 04:12: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: Andrej Vano created RTGOV-585: --------------------------------- Summary: 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 Tue Sep 30 04:15:07 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 04:15:07 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reopened RTGOV-329: ------------------------------ > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 04:15:08 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 04:15:08 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-329: ----------------------------- Fix Version/s: (was: 2.1.0.Final) > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 04:15:09 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 04:15:09 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown closed RTGOV-329. ---------------------------- Resolution: Rejected > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 04:18:03 2014 From: issues at jboss.org (Andrej Vano (JIRA)) Date: Tue, 30 Sep 2014 04:18:03 -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 ] Andrej Vano updated RTGOV-585: ------------------------------ Steps to Reproduce: 1. install fuse, switchyard 2.0.0.Alpha2, overlord beta4 (rtgov-all, rtgov-switchyard) 2. install all quickstarts 3. send requests until you see "Customer Fred is suspended" 4. send request {"amount":400,"customer":"Fred"} was: 1. install fuse, switchyard 2.0.0.Alpha2, overlord beta4 2. install all quickstarts 3. send requests until you see "Customer Fred is suspended" 4. send request {"amount":400,"customer":"Fred"} > 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 Tue Sep 30 04:22:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 04:22:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-568: ----------------------------- Fix Version/s: 2.0.0.Final (was: 2.1.0.Final) > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 04:22:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 04:22:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-568. ------------------------------ Resolution: Done > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 04:23:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 04:23:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-568) Update elasticsearch to 1.3.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007170#comment-13007170 ] Gary Brown commented on RTGOV-568: ---------------------------------- Decision made to base rtgov 2.0.0..Final on JDK 1.7, so this change is now fine. > Update elasticsearch to 1.3.2 > ----------------------------- > > Key: RTGOV-568 > URL: https://issues.jboss.org/browse/RTGOV-568 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 04:27:03 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 04:27:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-586) UI providers should be located using commons ServiceRegistry In-Reply-To: References: Message-ID: Gary Brown created RTGOV-586: -------------------------------- Summary: UI providers should be located using commons ServiceRegistry Key: RTGOV-586 URL: https://issues.jboss.org/browse/RTGOV-586 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Currently the RTGov UI uses CDI to locate the provider implementations. Change this to use the commons ServiceRegistry, to make it easier to plug in new providers. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 05:44:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 05:44:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-586) UI ServicesProvider impls should be located using commons ServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-586: ----------------------------- Summary: UI ServicesProvider impls should be located using commons ServiceRegistry (was: UI providers should be located using commons ServiceRegistry) > UI ServicesProvider impls should be located using commons ServiceRegistry > ------------------------------------------------------------------------- > > Key: RTGOV-586 > URL: https://issues.jboss.org/browse/RTGOV-586 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently the RTGov UI uses CDI to locate the provider implementations. Change this to use the commons ServiceRegistry, to make it easier to plug in new providers. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 07:32:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 07:32:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-586) UI ServicesProvider impls should be located using commons ServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-586: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/214 > UI ServicesProvider impls should be located using commons ServiceRegistry > ------------------------------------------------------------------------- > > Key: RTGOV-586 > URL: https://issues.jboss.org/browse/RTGOV-586 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently the RTGov UI uses CDI to locate the provider implementations. Change this to use the commons ServiceRegistry, to make it easier to plug in new providers. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 07:33:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 07:33:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-586) UI ServicesProvider impls should be located using commons ServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007249#comment-13007249 ] Gary Brown commented on RTGOV-586: ---------------------------------- Also added ActionProvider abstraction to avoid having to extend the ServicesProvider interface when new actions are added. > UI ServicesProvider impls should be located using commons ServiceRegistry > ------------------------------------------------------------------------- > > Key: RTGOV-586 > URL: https://issues.jboss.org/browse/RTGOV-586 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently the RTGov UI uses CDI to locate the provider implementations. Change this to use the commons ServiceRegistry, to make it easier to plug in new providers. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 07:33:02 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 07:33:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-586) UI ServicesProvider impls should be located using commons ServiceRegistry In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-586. ------------------------------ Resolution: Done > UI ServicesProvider impls should be located using commons ServiceRegistry > ------------------------------------------------------------------------- > > Key: RTGOV-586 > URL: https://issues.jboss.org/browse/RTGOV-586 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently the RTGov UI uses CDI to locate the provider implementations. Change this to use the commons ServiceRegistry, to make it easier to plug in new providers. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 09:45:23 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 30 Sep 2014 09:45:23 -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: Rejected I believe you are sending the message content to the same URL as the orders (i.e. http://localhost:8181/cxf/orderservice/orders/submit). If the source of the instructions was https://developer.jboss.org/wiki/OverlordRTGovOnFuse (Trying the RTGov UI with samples) then the message: {noformat} {"amount":"400", "customer":"Fred"} {noformat} should be sent to URL: http://localhost:8181/cxf/orderservice/orders/pay If this is not the source of the error, then please re-open the jira. > 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 Tue Sep 30 11:44:04 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 30 Sep 2014 11:44:04 -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: --------------------------------------- Description: 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. > 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 > > 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 Sep 30 11:45:03 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 30 Sep 2014 11:45:03 -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=13007406#comment-13007406 ] David virgil naranjo commented on SRAMP-578: -------------------------------------------- Well, I was sure there would be things to modify and errors to be found. I modified the description. > 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 > > 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 Sep 30 11:50:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 30 Sep 2014 11:50:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-579) Fuse Fabric commands refactoring In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-579: ------------------------------------------ Summary: Fuse Fabric commands refactoring Key: SRAMP-579 URL: https://issues.jboss.org/browse/SRAMP-579 Project: S-RAMP Issue Type: Enhancement Reporter: David virgil naranjo Assignee: David virgil naranjo 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 Sep 30 11:51:02 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 30 Sep 2014 11:51:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-579) Fuse Fabric commands refactoring In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo closed SRAMP-579. -------------------------------------- Resolution: Duplicate Issue > Fuse Fabric commands refactoring > -------------------------------- > > Key: SRAMP-579 > URL: https://issues.jboss.org/browse/SRAMP-579 > Project: S-RAMP > Issue Type: Enhancement > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > 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 Sep 30 11:51:03 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 30 Sep 2014 11:51:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-151) Fuse Fabric Commands refactoring In-Reply-To: References: Message-ID: David virgil naranjo created OVERLORD-151: --------------------------------------------- Summary: 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 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 Sep 30 13:56:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 13:56: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:comment-tabpanel&focusedCommentId=13007440#comment-13007440 ] Brett Meyer commented on SRAMP-578: ----------------------------------- You were so confident that there'd be issues, that you opened a ticket in advance?! Just kidding ;) > 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 > > 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 Sep 30 14:00:04 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 14:00:04 -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 ] Brett Meyer updated SRAMP-578: ------------------------------ Git Pull Request: 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 > > 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 Sep 30 14:01:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 14: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 ] Brett Meyer resolved SRAMP-578. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done > 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 Tue Sep 30 14:02:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 30 Sep 2014 14:02: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 ] RH Bugzilla Integration updated SRAMP-578: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 Tue Sep 30 14:03:02 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 30 Sep 2014 14:03:02 -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 ] RH Bugzilla Integration updated OVERLORD-151: --------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1146591 > 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 > > 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 Sep 30 15:57:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 15:57:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-580) Server-side autodetection of artifact types In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-580: --------------------------------- Summary: Server-side autodetection of artifact types Key: SRAMP-580 URL: https://issues.jboss.org/browse/SRAMP-580 Project: S-RAMP Issue Type: Feature Request Reporter: Brett Meyer Assignee: Brett Meyer Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 15:58:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 15:58:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-580) Server-side autodetection of artifact types In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-580: ------------------------------ Description: Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. This should completely replace all other types of client-side logic. was: Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. > Server-side autodetection of artifact types > ------------------------------------------- > > Key: SRAMP-580 > URL: https://issues.jboss.org/browse/SRAMP-580 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, artifact type autodetection exists in multiple forms, nearly all of them client-side. The Maven Wagon inspects the deployment URL and makes assumptions. The UI checks file extensions. > Instead, move a more complete set of artifact-inspection logic server-side. Some semblance of this already exists, to a certain degree. For example, ZipToSrampArchiveProvider#accept(ArtifactType) already exists, but is currently used only to determine which module should expand the artifact. But, the concept could be used to define the artifact type based on the new artifact. It would require a hierarchy of sorts where the most "specialized" integrations (Switchyard, RTGov, DTGov, etc.) are considered first. If none of those "accept" the artifact, the next tier (more generic types) are considered. > The logic could be a mix of filename regex, archive inspection (ex: look for switchyard.xml), etc. > This should completely replace all other types of client-side logic. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 16:04:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 16:04:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-581) Finish the Maven Facade In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-581: --------------------------------- Summary: Finish the Maven Facade Key: SRAMP-581 URL: https://issues.jboss.org/browse/SRAMP-581 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 Tue Sep 30 16:05:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 16:05:02 -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:all-tabpanel ] Brett Meyer updated SRAMP-506: ------------------------------ Parent: SRAMP-581 Issue Type: Sub-task (was: Feature Request) > 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 Tue Sep 30 16:08:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 16:08:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-582) Create Maven Facade unit/integration test In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-582: --------------------------------- Summary: Create Maven Facade unit/integration test Key: SRAMP-582 URL: https://issues.jboss.org/browse/SRAMP-582 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Priority: Critical This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 16:10:03 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 16:10:03 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-581) Finish the Maven Facade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-581: ------------------------------ Description: The vision for the Maven Facade is the eventual replacement of the Maven Wagon, in addition to several interesting use cases. - deployment repository - dependency repository - Nexus Proxy support > Finish the Maven Facade > ----------------------- > > Key: SRAMP-581 > URL: https://issues.jboss.org/browse/SRAMP-581 > Project: S-RAMP > Issue Type: Feature Request > Reporter: Brett Meyer > Assignee: Brett Meyer > > The vision for the Maven Facade is the eventual replacement of the Maven Wagon, in addition to several interesting use cases. > - deployment repository > - dependency repository > - Nexus Proxy support -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 16:15:09 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 16:15:09 -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: Brett Meyer created SRAMP-583: --------------------------------- Summary: 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 Tue Sep 30 16:18:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 16:18:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-584) Test and document Nexus Proxy support In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-584: --------------------------------- Summary: Test and document Nexus Proxy support Key: SRAMP-584 URL: https://issues.jboss.org/browse/SRAMP-584 Project: S-RAMP Issue Type: Sub-task Reporter: Brett Meyer Once the Facade is "finished", verify that it can be used as a Nexus Proxy. Then, document this use case: "gain S-RAMP without losing your existing enterprise repo!" -- This message was sent by Atlassian JIRA (v6.3.1#6329) From issues at jboss.org Tue Sep 30 16:19:02 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 30 Sep 2014 16:19:02 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-582) Create Maven Facade unit/integration test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-582: ------------------------------ Description: This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. See SrampWagonTest for some inspiration. Some of it may be directly applicable. was:This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. > Create Maven Facade unit/integration test > ----------------------------------------- > > Key: SRAMP-582 > URL: https://issues.jboss.org/browse/SRAMP-582 > Project: S-RAMP > Issue Type: Sub-task > Reporter: Brett Meyer > Priority: Critical > > This should be the priority and done before any other sub-task. Create extensive unit/integration tests to provide adequate coverage of all Maven Facade functionality. Due to the Facade's potential complexity, it should be developed with a test-first approach. > See SrampWagonTest for some inspiration. Some of it may be directly applicable. -- This message was sent by Atlassian JIRA (v6.3.1#6329)