From issues at jboss.org Tue Jul 1 05:05:28 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 05:05:28 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-504) Remove 'Processing State' from RTGov UI Service List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Clay reassigned RTGOV-504: ---------------------------------- Assignee: Michael Clay (was: Gary Brown) > Remove 'Processing State' from RTGov UI Service List > ---------------------------------------------------- > > Key: RTGOV-504 > URL: https://issues.jboss.org/browse/RTGOV-504 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 05:05:28 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 05:05:28 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Clay reassigned RTGOV-505: ---------------------------------- Assignee: Michael Clay (was: Gary Brown) > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 05:05:29 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 05:05:29 -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 ] Michael Clay reassigned RTGOV-506: ---------------------------------- Assignee: Michael Clay (was: Gary Brown) > 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 > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.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.2.6#6264) From issues at jboss.org Tue Jul 1 08:08:27 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 08:08:27 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980955#comment-12980955 ] Michael Clay commented on RTGOV-505: ------------------------------------ hi gary, what do you mean with 'If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row.' as far as i understand switchyard a composite service has exactly 1 interface 1 or many bindings - what do you mean with 'interface values' in the above sentence could you pls give me an example > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 08:10:25 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 08:10:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980956#comment-12980956 ] Michael Clay commented on RTGOV-505: ------------------------------------ + could you pls file another ticket for missing reference binding - the same issue here > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:04:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 1 Jul 2014 09:04:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12980998#comment-12980998 ] Gary Brown commented on RTGOV-505: ---------------------------------- Sorry yes - it is one interface and one or more bindings - so should actually be easier to display. Will create a separate jira for reference list. > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:04:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 1 Jul 2014 09:04:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-513) List gateway bindings in Reference List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: Gary Brown created RTGOV-513: -------------------------------- Summary: List gateway bindings in Reference List, colour coded to reflect the gateway state Key: RTGOV-513 URL: https://issues.jboss.org/browse/RTGOV-513 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: User Interface Reporter: Gary Brown Assignee: Michael Clay Fix For: 2.0.0.Final Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:06:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 1 Jul 2014 09:06:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-513) List gateway bindings in Reference List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-513: ----------------------------- Description: Currently the 'binding' column in the reference list table is empty. This needs to be populated with the gateway value(s). The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). was: Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). > List gateway bindings in Reference List, colour coded to reflect the gateway state > ---------------------------------------------------------------------------------- > > Key: RTGOV-513 > URL: https://issues.jboss.org/browse/RTGOV-513 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the reference list table is empty. This needs to be populated with the gateway value(s). > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:48:25 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 09:48:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981040#comment-12981040 ] Michael Clay commented on RTGOV-505: ------------------------------------ done pls review and apply the pull request because there are some share dependencies required for RTGOV-513 > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:48:25 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 09:48:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-504) Remove 'Processing State' from RTGov UI Service List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-504?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981043#comment-12981043 ] Michael Clay commented on RTGOV-504: ------------------------------------ done PR sent > Remove 'Processing State' from RTGov UI Service List > ---------------------------------------------------- > > Key: RTGOV-504 > URL: https://issues.jboss.org/browse/RTGOV-504 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 09:58:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 1 Jul 2014 09:58:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-488) Use the maven-bundle-plugin in WAR projects In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-488: ----------------------------------- Summary: 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 Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.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.2.6#6264) From issues at jboss.org Tue Jul 1 10:00:27 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 1 Jul 2014 10:00:27 -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 ] Eric Wittmann updated SRAMP-488: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0) > 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 > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Tue Jul 1 10:02:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 1 Jul 2014 10:02:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-489) Remove newlines from WAR bundle classpaths in pom.xml files In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-489: ----------------------------------- Summary: Remove newlines from WAR bundle classpaths in pom.xml files Key: SRAMP-489 URL: https://issues.jboss.org/browse/SRAMP-489 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0 We use the WAR plugin to add manifest entries to support osgi in all our WARs. Currently the import packages, export packages, and bundle classpath all have newlines in their content. This is throwing off the maven pipeline for certain versions of the war plugin. Remove all newlines from pom.xml bundle entries. Do this for all projects: overlord-commons, s-ramp, dtgov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 10:04:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 1 Jul 2014 10:04:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-490: ----------------------------------- Summary: Remove version overrides for plugins (inherit from jboss-parent) Key: SRAMP-490 URL: https://issues.jboss.org/browse/SRAMP-490 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0 In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 11:18:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 11:18:24 -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:comment-tabpanel&focusedCommentId=12981107#comment-12981107 ] Brett Meyer commented on SRAMP-488: ----------------------------------- Does this duplicate SRAMP-412? > 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 > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Tue Jul 1 12:17:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 1 Jul 2014 12:17:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981139#comment-12981139 ] Gary Brown commented on RTGOV-505: ---------------------------------- Sorry for the delay Michael - trying to get Beta1 released first - hopefully shouldn't be too much longer. > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 13:28:24 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Tue, 1 Jul 2014 13:28:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981154#comment-12981154 ] Michael Clay commented on RTGOV-505: ------------------------------------ no problem - didn't know you are working on beta1 > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 15:58:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 15:58:24 -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:comment-tabpanel&focusedCommentId=12981188#comment-12981188 ] Brett Meyer commented on SRAMP-433: ----------------------------------- In the context of DTGov and workflows, I guess I'm not sure what I was thinking -- of course the messages shouldn't be lost. I'll get that cleaned up tonight. If expiration times are needed, we can investigate when it comes up. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:18:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 1 Jul 2014 16:18:24 -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:comment-tabpanel&focusedCommentId=12981191#comment-12981191 ] Eric Wittmann commented on SRAMP-433: ------------------------------------- I would defer to those with more eventing/JMS experience than me. However, it does seem like a serialized java object isn't ideal. I would also think that each event would at least need a small set of standard properties such as 'type' - no? I'm wondering what a typical CEP system would need to see. Does anyone have experience with Drools CEP? I did some Esper a long time ago. I think those are the types of things we'd want to leverage to react in interesting ways to the events. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:38:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 1 Jul 2014 16:38:24 -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:comment-tabpanel&focusedCommentId=12981194#comment-12981194 ] Gary Brown commented on SRAMP-433: ---------------------------------- Agree re: java objects - I've used Drools Fusion (CEP) with RTGov but only using typed java objects - where the conditions can access properties by name. Not sure how it deals with json or xml - something to investigate. +1, I think we need a standard event definition, although some events sources may generate their own representations, but these could be mapped at the outer layer for the event framework. For now we could define a simple core subset of properties that DTGov needs to react to SRAMP changes. As we then add new event sources we may need to expand this set of properties. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 16:40:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 1 Jul 2014 16:40:24 -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:comment-tabpanel&focusedCommentId=12981195#comment-12981195 ] Gary Brown commented on SRAMP-433: ---------------------------------- Actually simple solution to the first point - once we have defined our core event model, make it json serializable, but internally it can be distributed as a Java object model making it easier to write CEP rules? > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 22:41:23 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 22:41:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-491) Support EAP 6.2 In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-491: --------------------------------- Summary: Support EAP 6.2 Key: SRAMP-491 URL: https://issues.jboss.org/browse/SRAMP-491 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 0.5.0 ModeShape's new distro supposedly supports both EAP 6.2 and 6.3. 6.2 *should* work without many changes in S-RAMP. Hopefully an additional XSLT section is it... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 22:49:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 22:49:24 -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:comment-tabpanel&focusedCommentId=12981223#comment-12981223 ] Brett Meyer commented on SRAMP-433: ----------------------------------- I'll continue to fix up the general approach. Maybe it would be best to have you guys help me come up with a POJO-first approach for the event model. I'll just use RESTEasy JAXB annotations -- iirc, that can be serialized to both JSON and XML. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 22:55:23 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 22:55:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-486) s-ramp.sh should not require JAVA_HOME to be set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-486 started by Brett Meyer. > s-ramp.sh should not require JAVA_HOME to be set > ------------------------------------------------ > > Key: SRAMP-486 > URL: https://issues.jboss.org/browse/SRAMP-486 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > s-ramp.sh is the only FSW script that requires JAVA_HOME to be set. As RHEL installations by default do not set it, the requirement should be relaxed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 23:48:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 23:48:24 -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 updated SRAMP-433: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/448 > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 23:48:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 23:48:25 -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 updated SRAMP-433: ------------------------------ Git Pull Request: (was: https://github.com/Governance/s-ramp/pull/448) > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 1 23:48:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 1 Jul 2014 23:48:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-486) s-ramp.sh should not require JAVA_HOME to be set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-486: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/448 > s-ramp.sh should not require JAVA_HOME to be set > ------------------------------------------------ > > Key: SRAMP-486 > URL: https://issues.jboss.org/browse/SRAMP-486 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > s-ramp.sh is the only FSW script that requires JAVA_HOME to be set. As RHEL installations by default do not set it, the requirement should be relaxed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 00:10:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 00:10:24 -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:comment-tabpanel&focusedCommentId=12981228#comment-12981228 ] Brett Meyer commented on SRAMP-433: ----------------------------------- Thinking through all the use cases for the queues. Thoughts on the following? - configured in s-ramp properties file - disabled by default - dtgov-specific queue must be enabled during dtgov installation (or programmatically) - allow clients to create additional queues on the JMS platform and list them on the config prop - each event is sent to all registered queues w/ no expiration time > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 00:18:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 00:18:25 -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:comment-tabpanel&focusedCommentId=12981228#comment-12981228 ] Brett Meyer edited comment on SRAMP-433 at 7/2/14 12:16 AM: ------------------------------------------------------------ Thinking through all the use cases for the queues. Thoughts on the following? - configured in s-ramp properties file via JNDI names - disabled by default - dtgov-specific queue must be enabled during dtgov installation (or programmatically) - allow clients to create additional queues on the JMS platform and list them on the config prop - each event is sent to all registered queues w/ no expiration time was (Author: brmeyer): Thinking through all the use cases for the queues. Thoughts on the following? - configured in s-ramp properties file - disabled by default - dtgov-specific queue must be enabled during dtgov installation (or programmatically) - allow clients to create additional queues on the JMS platform and list them on the config prop - each event is sent to all registered queues w/ no expiration time > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 00:22:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 00:22:24 -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:comment-tabpanel&focusedCommentId=12981228#comment-12981228 ] Brett Meyer edited comment on SRAMP-433 at 7/2/14 12:20 AM: ------------------------------------------------------------ Thinking through all the use cases for the queues. Thoughts on the following? - configured in sramp.properties via a list of JNDI names - disabled by default - dtgov-specific queue automatically created on the s-ramp installation target, but the JNDI name must be "enabled" (added to the list) during dtgov installation - allow clients to create additional queues on the JMS platform and list them on the config prop - each event is published to all configured queues w/ no expiration time was (Author: brmeyer): Thinking through all the use cases for the queues. Thoughts on the following? - configured in s-ramp properties file via JNDI names - disabled by default - dtgov-specific queue must be enabled during dtgov installation (or programmatically) - allow clients to create additional queues on the JMS platform and list them on the config prop - each event is sent to all registered queues w/ no expiration time > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 00:42:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 00:42:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-490 started by Brett Meyer. > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 00:57:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 00:57:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981234#comment-12981234 ] Brett Meyer commented on SRAMP-490: ----------------------------------- https://github.com/brmeyer/s-ramp/commit/60ec7ac784f675daca3cdb9bd1e388b6beb6bf73 After doing so, everything passes except the Fuse distro: {quote} [ERROR] Failed to execute goal org.overlord:overlord-commons-maven-plugin:2.0.2.Final:generate-features-xml (default) on project s-ramp-distro-fuse61: invalid manifest format -> [Help 1] {quote} The bundle plugin wasn't overridden, so I'm not sure what else is contributing to that. Will investigate. > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 04:17:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 04:17:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-514) Document how to use/install rtgov client in fuse In-Reply-To: References: Message-ID: Gary Brown created RTGOV-514: -------------------------------- Summary: Document how to use/install rtgov client in fuse Key: RTGOV-514 URL: https://issues.jboss.org/browse/RTGOV-514 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 04:21:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 04:21:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-515) Document activity collection from OSGi service In-Reply-To: References: Message-ID: Gary Brown created RTGOV-515: -------------------------------- Summary: Document activity collection from OSGi service Key: RTGOV-515 URL: https://issues.jboss.org/browse/RTGOV-515 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Describe how to integrate the activity collector into an OSGi application, based on the order management example. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 05:01:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 05:01:24 -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:comment-tabpanel&focusedCommentId=12981291#comment-12981291 ] Gary Brown commented on SRAMP-433: ---------------------------------- With dtgov, we have been moving away from using property files, and instead storing configuration in sramp. So might be worth also storing sramps 'event producer' information in sramp. If this is not possible without having a new UI (which might take time), then may be use property file as a stop gap. In terms of the JMS setup - actually durable subscription would have been the most appropriate solution. SRAMP could happily publish on a pre-defined single topic, and clients could either use non-durable subscription to just get notifications, or durable subscription to ensure they don't miss out on anything. The one drawback is the issue we are trying to solve for DTGov - only a single active durable subscriber is permitted - so we couldn't have two or more dtgov clustered servers all operating in a load balanced manner across a durable subscription. This is a pity, as it would have been a good generic solution. ActiveMQ has a capability called Virtual Topics that may provide a solution - but think we need to remain JMS compliant to enable use of other JMS providers if necessary - so looks like we are stuck with queues, and therefore need to configure a queue per interested consumer. I think it would be good to have a default topic on which the events are published - this would cater for systems just interested in being notified - and also enable durable subscriptions for systems that don't want to miss anything. In terms of the queue for dtgov - how about: - have a default queue name configured in properties (not with a dtgov specific name, so could potentially be used by any consumer) - sramp event producer - when it attempts to access the jndi name, if it does not exist, it disables itself (queue must exist before sramp is started) - dtgov install will cause the queue to be created - so no explicit configuration, either by user on installation, or dtgov modifying sramp config thoughts? > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 05:07:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 05:07:25 -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:comment-tabpanel&focusedCommentId=12981296#comment-12981296 ] Gary Brown commented on SRAMP-433: ---------------------------------- +1 to allowing users to create additional queues/topics - but if the default topic and queue are provided ootb, that should minimise initial config. Impl note - if you use destinations, then you won't need to worry about whether the jndi name refers to a topic or queue - as from the sramp producer side it does not really matter. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 05:19:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 05:19:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-379) Remove gadget server from Karaf/EAP distributions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-379: ----------------------------- Fix Version/s: (was: 2.0.0.Final) > Remove gadget server from Karaf/EAP distributions > ------------------------------------------------- > > Key: RTGOV-379 > URL: https://issues.jboss.org/browse/RTGOV-379 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Support deployment of Gadget Server WAR into Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 05:24:25 2014 From: issues at jboss.org (Nick Cross (JIRA)) Date: Wed, 2 Jul 2014 05:24:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981301#comment-12981301 ] Nick Cross commented on SRAMP-490: ---------------------------------- We found the newlines in Import-Package/Bundle-ClassPath definitions in the pom caused an issue - changing them or changing to use the maven-bundle-plugin seemed to fix it. > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 08:44:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 08:44:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-505: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/139 > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 08:44:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 08:44:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-505) List gateway bindings in Service List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-505. ------------------------------ Resolution: Done > List gateway bindings in Service List, colour coded to reflect the gateway state > -------------------------------------------------------------------------------- > > Key: RTGOV-505 > URL: https://issues.jboss.org/browse/RTGOV-505 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the service list table is empty. This needs to be populated with the gateway value(s). > If multiple gateways are defined for the service, then the interface and binding values should be defined on separate lines in the single table row. > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:41:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:41:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-504) Remove 'Processing State' from RTGov UI Service List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-504: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/138 > Remove 'Processing State' from RTGov UI Service List > ---------------------------------------------------- > > Key: RTGOV-504 > URL: https://issues.jboss.org/browse/RTGOV-504 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:41:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:41:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-504) Remove 'Processing State' from RTGov UI Service List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-504. ------------------------------ Resolution: Done > Remove 'Processing State' from RTGov UI Service List > ---------------------------------------------------- > > Key: RTGOV-504 > URL: https://issues.jboss.org/browse/RTGOV-504 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:47:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:47:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-388) Update docs to describe Karaf installation, configuration and usage In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-388. ------------------------------ Resolution: Done > Update docs to describe Karaf installation, configuration and usage > ------------------------------------------------------------------- > > Key: RTGOV-388 > URL: https://issues.jboss.org/browse/RTGOV-388 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Update the quickstart and getting started guides to describe deployment to Karaf/Fuse. > Also need to update the component deployment information to describe how they differ when deploying to Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:51:26 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 09:51:26 -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:comment-tabpanel&focusedCommentId=12981436#comment-12981436 ] Brett Meyer commented on SRAMP-433: ----------------------------------- Gary, thanks for all that -- makes sense. > have a default queue name configured in properties (not with a dtgov specific name, so could potentially be used by any consumer) My only concern with that is shouldn't it be reserved solely for dtgov? What happens if dtgov is running, but a user attempts to pop messages off the "default queue" at the same time? Unless the other clients use a JMS session rollback (as I understand it), dtgov won't receive it, right? That was the intention behind using a dtgov-specific queue. Or am I missing something there? I hadn't intended for the topic(s) to be configurable at all, but I suppose that might make sense in certain situations. > if you use destinations, then you won't need to worry about whether the jndi name refers to a topic or queue Great point -- will do. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:57:26 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 2 Jul 2014 09:57:26 -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:comment-tabpanel&focusedCommentId=12981439#comment-12981439 ] Eric Wittmann commented on SRAMP-488: ------------------------------------- Oops! Yes it does. Sorry about that. > 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 > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Wed Jul 2 09:57:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:57:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-475) OSGi service list in RTGov UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-475: ----------------------------- Parent: (was: RTGOV-373) Issue Type: Feature Request (was: Sub-task) > OSGi service list in RTGov UI > ----------------------------- > > Key: RTGOV-475 > URL: https://issues.jboss.org/browse/RTGOV-475 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > As we can use rtgov to monitor standard OSGi services, these should also be listed in the RTGov UI service list. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:57:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:57:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-383) Use Declarative Services instead of Blueprint In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-383: ----------------------------- Parent: (was: RTGOV-373) Issue Type: Task (was: Sub-task) > Use Declarative Services instead of Blueprint > --------------------------------------------- > > Key: RTGOV-383 > URL: https://issues.jboss.org/browse/RTGOV-383 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > If time permits, explore moving to Declarative Services (DS) in place of using Blueprint, for dependency injection and property initialisation, as it may have benefit when using with Fabric (see https://mojo.redhat.com/docs/DOC-14757). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:57:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:57:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-379) Remove gadget server from Karaf/EAP distributions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-379: ----------------------------- Fix Version/s: 2.0.0.Final > Remove gadget server from Karaf/EAP distributions > ------------------------------------------------- > > Key: RTGOV-379 > URL: https://issues.jboss.org/browse/RTGOV-379 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Support deployment of Gadget Server WAR into Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:59:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:59:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-379) Remove gadget server from Karaf/EAP distributions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-379: ----------------------------- Fix Version/s: (was: 2.0.0.Final) > Remove gadget server from Karaf/EAP distributions > ------------------------------------------------- > > Key: RTGOV-379 > URL: https://issues.jboss.org/browse/RTGOV-379 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Support deployment of Gadget Server WAR into Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:59:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:59:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-379) Remove gadget server from Karaf/EAP distributions In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown closed RTGOV-379. ---------------------------- > Remove gadget server from Karaf/EAP distributions > ------------------------------------------------- > > Key: RTGOV-379 > URL: https://issues.jboss.org/browse/RTGOV-379 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Support deployment of Gadget Server WAR into Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:59:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:59:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-451) Enable deployment on Karaf3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-451: ----------------------------- Parent: (was: RTGOV-373) Issue Type: Task (was: Sub-task) > Enable deployment on Karaf3 > --------------------------- > > Key: RTGOV-451 > URL: https://issues.jboss.org/browse/RTGOV-451 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:59:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 09:59:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981440#comment-12981440 ] Brett Meyer commented on SRAMP-490: ----------------------------------- Thanks [~ncross] -- that's in SRAMP-489. Am I correct that it's limited to the WAR projects? > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 09:59:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 09:59:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-451) Support deployment on Karaf3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-451: ----------------------------- Summary: Support deployment on Karaf3 (was: Enable deployment on Karaf3) > Support deployment on Karaf3 > ---------------------------- > > Key: RTGOV-451 > URL: https://issues.jboss.org/browse/RTGOV-451 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:01:28 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 10:01:28 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-453) Create JPA EPN integration test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-453: ----------------------------- Parent: (was: RTGOV-373) Issue Type: Task (was: Sub-task) > Create JPA EPN integration test > ------------------------------- > > Key: RTGOV-453 > URL: https://issues.jboss.org/browse/RTGOV-453 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > RTGOV-374 improved JPA/ORM support, including the ability for an EPN to pass either a JPA persistence.xml or a native Hibernate hibernate.cfg.xml. This is unit tested, but needs incorporated into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:01:28 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 10:01:28 -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: ----------------------------- Parent: (was: RTGOV-373) Issue Type: Task (was: Sub-task) > 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 > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 2.0.0.Final > > 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.2.6#6264) From issues at jboss.org Wed Jul 2 10:03:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 10:03:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-412) Use the maven-bundle-plugin appropriately to support OSGi for WAR projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-412. ----------------------------- Fix Version/s: (was: 0.6.0) Resolution: Duplicate Issue > Use the maven-bundle-plugin appropriately to support OSGi for WAR projects > -------------------------------------------------------------------------- > > Key: SRAMP-412 > URL: https://issues.jboss.org/browse/SRAMP-412 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > > I was never able to get the maven-bundle-plugin working with the WAR modules, perhaps because they are overlays, perhaps because I was being stupid. In any case, we *really* should try to get that plugin working to make maintenance of the fuse version more manageable. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:03:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 10:03:24 -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:comment-tabpanel&focusedCommentId=12981444#comment-12981444 ] Brett Meyer commented on SRAMP-488: ----------------------------------- Close SRAMP-412, since you were more detailed in this one ;) > 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 > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Wed Jul 2 10:15:27 2014 From: issues at jboss.org (Nick Cross (JIRA)) Date: Wed, 2 Jul 2014 10:15:27 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981447#comment-12981447 ] Nick Cross commented on SRAMP-490: ---------------------------------- I believe so [~ewittmann] would know... > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:21:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 2 Jul 2014 10:21:25 -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:comment-tabpanel&focusedCommentId=12981454#comment-12981454 ] Gary Brown commented on SRAMP-433: ---------------------------------- I think to improve the "out of the box" experience, sramp using a default queue, and dtgov configuring it, would be a reasonable start. However the docs could make it clear that DTGov will only function correctly if it is the sole consumer for the queue - and if other systems need the same information, additional queues will need to be configured (and optionally the sramp/dtgov configurations changed to use a different name). > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:39:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 10:39:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-489) Remove newlines from WAR bundle classpaths in pom.xml files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-489 started by Brett Meyer. > Remove newlines from WAR bundle classpaths in pom.xml files > ----------------------------------------------------------- > > Key: SRAMP-489 > URL: https://issues.jboss.org/browse/SRAMP-489 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > We use the WAR plugin to add manifest entries to support osgi in all our WARs. Currently the import packages, export packages, and bundle classpath all have newlines in their content. This is throwing off the maven pipeline for certain versions of the war plugin. > Remove all newlines from pom.xml bundle entries. > Do this for all projects: overlord-commons, s-ramp, dtgov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:53:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 10:53:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-489) Remove newlines from WAR bundle classpaths in pom.xml files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981480#comment-12981480 ] Brett Meyer commented on SRAMP-489: ----------------------------------- Although this will be superseded by SRAMP-488 and SRAMP-413, need to fix this first. Since our Fuse support is currently stable, I'd rather not change it all up before 0.5.0.Final > Remove newlines from WAR bundle classpaths in pom.xml files > ----------------------------------------------------------- > > Key: SRAMP-489 > URL: https://issues.jboss.org/browse/SRAMP-489 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > We use the WAR plugin to add manifest entries to support osgi in all our WARs. Currently the import packages, export packages, and bundle classpath all have newlines in their content. This is throwing off the maven pipeline for certain versions of the war plugin. > Remove all newlines from pom.xml bundle entries. > Do this for all projects: overlord-commons, s-ramp, dtgov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 10:55:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 2 Jul 2014 10:55:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981481#comment-12981481 ] Eric Wittmann commented on SRAMP-490: ------------------------------------- Based on what I learned from [~ncross] and dcoleman I would say that it's limited to the WAR projects. The bundle plugin is used for anything that's not a WAR, and it appears to be the war plugin that is messing up the manifest. > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 11:48:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 11:48:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-489) Remove newlines from WAR bundle classpaths in pom.xml files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-489. ------------------------------- Resolution: Done > Remove newlines from WAR bundle classpaths in pom.xml files > ----------------------------------------------------------- > > Key: SRAMP-489 > URL: https://issues.jboss.org/browse/SRAMP-489 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > We use the WAR plugin to add manifest entries to support osgi in all our WARs. Currently the import packages, export packages, and bundle classpath all have newlines in their content. This is throwing off the maven pipeline for certain versions of the war plugin. > Remove all newlines from pom.xml bundle entries. > Do this for all projects: overlord-commons, s-ramp, dtgov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 11:48:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 11:48:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-490. ------------------------------- Resolution: Done > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:08:50 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 12:08:50 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-486) s-ramp.sh should not require JAVA_HOME to be set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-486. ------------------------------- Resolution: Done > s-ramp.sh should not require JAVA_HOME to be set > ------------------------------------------------ > > Key: SRAMP-486 > URL: https://issues.jboss.org/browse/SRAMP-486 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > s-ramp.sh is the only FSW script that requires JAVA_HOME to be set. As RHEL installations by default do not set it, the requirement should be relaxed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:14:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 2 Jul 2014 12:14:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-486) s-ramp.sh should not require JAVA_HOME to be set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981529#comment-12981529 ] RH Bugzilla Integration commented on SRAMP-486: ----------------------------------------------- Brett Meyer changed the Status of [bug 1057022|https://bugzilla.redhat.com/show_bug.cgi?id=1057022] from ASSIGNED to MODIFIED > s-ramp.sh should not require JAVA_HOME to be set > ------------------------------------------------ > > Key: SRAMP-486 > URL: https://issues.jboss.org/browse/SRAMP-486 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > s-ramp.sh is the only FSW script that requires JAVA_HOME to be set. As RHEL installations by default do not set it, the requirement should be relaxed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 12:26:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 12:26:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-492) Maven release configuration is broken In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-492: --------------------------------- Summary: Maven release configuration is broken Key: SRAMP-492 URL: https://issues.jboss.org/browse/SRAMP-492 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 0.5.0 There appears to be some issues within the javadocs plugin during the package phase. The root POM contains exclude and include packages in the plugin configuration -- I'm wondering if this section is off, missing an exclude, etc. For now, I manually built and deployed S-RAMP, but it's missing the javadocs in Nexus entirely. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 13:12:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 13:12:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-492) Maven release configuration is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-492: ------------------------------ Fix Version/s: (was: 0.5.0) > Maven release configuration is broken > ------------------------------------- > > Key: SRAMP-492 > URL: https://issues.jboss.org/browse/SRAMP-492 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > There appears to be some issues within the javadocs plugin during the package phase. The root POM contains exclude and include packages in the plugin configuration -- I'm wondering if this section is off, missing an exclude, etc. For now, I manually built and deployed S-RAMP, but it's missing the javadocs in Nexus entirely. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 13:12:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 13:12:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-492) Maven release configuration is broken In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-492. ----------------------------- Resolution: Cannot Reproduce Bug I'm no longer able to reproduce -- the release (w/ -DdryRun=true) appears to work perfectly, including the javadocs. It's possible that SRAMP-490 affected it > Maven release configuration is broken > ------------------------------------- > > Key: SRAMP-492 > URL: https://issues.jboss.org/browse/SRAMP-492 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > There appears to be some issues within the javadocs plugin during the package phase. The root POM contains exclude and include packages in the plugin configuration -- I'm wondering if this section is off, missing an exclude, etc. For now, I manually built and deployed S-RAMP, but it's missing the javadocs in Nexus entirely. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 15:54:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 15:54:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-493) 2 different modeshape dependency versions required to build In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-493: --------------------------------- Summary: 2 different modeshape dependency versions required to build Key: SRAMP-493 URL: https://issues.jboss.org/browse/SRAMP-493 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer When productized, s-ramp-distro-assembly fails since modeshape-distribution no longer includes the old jbosseap-61-dist. Instead of declaring it as an actual dependency, manually pull down the jar with maven-dependency-plugin, then use a fileSet in the assembly. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 15:54:25 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 2 Jul 2014 15:54:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-493) 2 different modeshape dependency versions required to build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-493: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1115531 > 2 different modeshape dependency versions required to build > ----------------------------------------------------------- > > Key: SRAMP-493 > URL: https://issues.jboss.org/browse/SRAMP-493 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > When productized, s-ramp-distro-assembly fails since modeshape-distribution no longer includes the old jbosseap-61-dist. Instead of declaring it as an actual dependency, manually pull down the jar with maven-dependency-plugin, then use a fileSet in the assembly. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 15:54:25 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 2 Jul 2014 15:54:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-493) 2 different modeshape dependency versions required to build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981638#comment-12981638 ] RH Bugzilla Integration commented on SRAMP-493: ----------------------------------------------- Brett Meyer changed the Status of [bug 1115531|https://bugzilla.redhat.com/show_bug.cgi?id=1115531] from NEW to ASSIGNED > 2 different modeshape dependency versions required to build > ----------------------------------------------------------- > > Key: SRAMP-493 > URL: https://issues.jboss.org/browse/SRAMP-493 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > When productized, s-ramp-distro-assembly fails since modeshape-distribution no longer includes the old jbosseap-61-dist. Instead of declaring it as an actual dependency, manually pull down the jar with maven-dependency-plugin, then use a fileSet in the assembly. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 15:56:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 15:56:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-493) 2 different modeshape dependency versions required to build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-493. ------------------------------- Fix Version/s: 0.5.0 Resolution: Done > 2 different modeshape dependency versions required to build > ----------------------------------------------------------- > > Key: SRAMP-493 > URL: https://issues.jboss.org/browse/SRAMP-493 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > When productized, s-ramp-distro-assembly fails since modeshape-distribution no longer includes the old jbosseap-61-dist. Instead of declaring it as an actual dependency, manually pull down the jar with maven-dependency-plugin, then use a fileSet in the assembly. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 15:58:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 2 Jul 2014 15:58:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-493) 2 different modeshape dependency versions required to build In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981640#comment-12981640 ] RH Bugzilla Integration commented on SRAMP-493: ----------------------------------------------- Brett Meyer changed the Status of [bug 1115531|https://bugzilla.redhat.com/show_bug.cgi?id=1115531] from ASSIGNED to MODIFIED > 2 different modeshape dependency versions required to build > ----------------------------------------------------------- > > Key: SRAMP-493 > URL: https://issues.jboss.org/browse/SRAMP-493 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > When productized, s-ramp-distro-assembly fails since modeshape-distribution no longer includes the old jbosseap-61-dist. Instead of declaring it as an actual dependency, manually pull down the jar with maven-dependency-plugin, then use a fileSet in the assembly. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 16:20:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 16:20:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-491) Support EAP 6.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-491 started by Brett Meyer. > Support EAP 6.2 > --------------- > > Key: SRAMP-491 > URL: https://issues.jboss.org/browse/SRAMP-491 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > ModeShape's new distro supposedly supports both EAP 6.2 and 6.3. 6.2 *should* work without many changes in S-RAMP. Hopefully an additional XSLT section is it... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 2 16:42:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 2 Jul 2014 16:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-491) Support EAP 6.2 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-491. ------------------------------- Resolution: Done > Support EAP 6.2 > --------------- > > Key: SRAMP-491 > URL: https://issues.jboss.org/browse/SRAMP-491 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > ModeShape's new distro supposedly supports both EAP 6.2 and 6.3. 6.2 *should* work without many changes in S-RAMP. Hopefully an additional XSLT section is it... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 04:44:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 3 Jul 2014 04:44:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-516) Document how to deploy EPN, ACS, AV, IP in OSGi In-Reply-To: References: Message-ID: Gary Brown created RTGOV-516: -------------------------------- Summary: Document how to deploy EPN, ACS, AV, IP in OSGi Key: RTGOV-516 URL: https://issues.jboss.org/browse/RTGOV-516 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Document the OSGi variant for the packing of EPN, AV, ACS and IP. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 07:46:24 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Thu, 3 Jul 2014 07:46:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-517) Make context optional for ActivityStore.getActivityTypes In-Reply-To: References: Message-ID: Jiri Pechanec created RTGOV-517: ----------------------------------- Summary: Make context optional for ActivityStore.getActivityTypes Key: RTGOV-517 URL: https://issues.jboss.org/browse/RTGOV-517 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Activity Server Reporter: Jiri Pechanec Assignee: Gary Brown Priority: Critical The query method is now deprecated due to tight binding to store backend. Unfortunately it means now it is not possible to get a list of ActivityTypes in a given timeframe. The method getActivityTypes provide such a functionality but it requires a knowledge of context. It should be useful to make the context optionally. At the same time when the context is optional it has to be mandatory to provide time window to prevent dumping the whole db/index. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 09:16:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 3 Jul 2014 09:16:31 -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=12982041#comment-12982041 ] RH Bugzilla Integration commented on SRAMP-395: ----------------------------------------------- Julian Coleman changed the Status of [bug 1114732|https://bugzilla.redhat.com/show_bug.cgi?id=1114732] from MODIFIED to ASSIGNED > 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 > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Alpha1, 0.5.0 > > > 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.2.6#6264) From issues at jboss.org Thu Jul 3 10:06:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 3 Jul 2014 10:06:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-517) Make context optional for ActivityStore.getActivityTypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-517: ----------------------------- Fix Version/s: 2.0.0.Final > Make context optional for ActivityStore.getActivityTypes > -------------------------------------------------------- > > Key: RTGOV-517 > URL: https://issues.jboss.org/browse/RTGOV-517 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > The query method is now deprecated due to tight binding to store backend. Unfortunately it means now it is not possible to get a list of ActivityTypes in a given timeframe. The method getActivityTypes provide such a functionality but it requires a knowledge of context. > It should be useful to make the context optionally. At the same time when the context is optional it has to be mandatory to provide time window to prevent dumping the whole db/index. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 10:52:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 3 Jul 2014 10:52:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-482) Register mbeans in Karaf, to be available in hawtio console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-482: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/141 > Register mbeans in Karaf, to be available in hawtio console > ----------------------------------------------------------- > > Key: RTGOV-482 > URL: https://issues.jboss.org/browse/RTGOV-482 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 10:52:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 3 Jul 2014 10:52:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-482) Register mbeans in Karaf, to be available in hawtio console In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-482. ------------------------------ Resolution: Done > Register mbeans in Karaf, to be available in hawtio console > ----------------------------------------------------------- > > Key: RTGOV-482 > URL: https://issues.jboss.org/browse/RTGOV-482 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 10:54:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 3 Jul 2014 10:54:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-373) Karaf support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-373. ------------------------------ Resolution: Done > Karaf support > ------------- > > Key: RTGOV-373 > URL: https://issues.jboss.org/browse/RTGOV-373 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Provide support for deploying RTGov into Karaf (JBoss Fuse). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 18:36:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 3 Jul 2014 18:36:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-413) Audit uses of BND in POMs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-413 started by Brett Meyer. > Audit uses of BND in POMs > ------------------------- > > Key: SRAMP-413 > URL: https://issues.jboss.org/browse/SRAMP-413 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > In most POMs, the Felix/BND plugin usage is really explicit. See if it can be cleaned up. For the most part, BND should be able to automatically generate what's needed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 3 18:58:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 3 Jul 2014 18:58:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-413) Audit uses of BND in POMs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-413. ------------------------------- Resolution: Done Pushed to the 0.6 branch > Audit uses of BND in POMs > ------------------------- > > Key: SRAMP-413 > URL: https://issues.jboss.org/browse/SRAMP-413 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > In most POMs, the Felix/BND plugin usage is really explicit. See if it can be cleaned up. For the most part, BND should be able to automatically generate what's needed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:37:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 4 Jul 2014 00:37:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-474 started by Brett Meyer. > CLI: Add a log-to-file option > ----------------------------- > > Key: SRAMP-474 > URL: https://issues.jboss.org/browse/SRAMP-474 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently CLI batch files must be created by hand. This isn't too much of a hardship, but it might be convenient for the interactive console to help out with this by allowing the user to log all commands executed to a file. This could be the basis for a CLI batch file that the user could include in some sort of integration scenario. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:39:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 4 Jul 2014 00:39:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-474: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/449 > CLI: Add a log-to-file option > ----------------------------- > > Key: SRAMP-474 > URL: https://issues.jboss.org/browse/SRAMP-474 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently CLI batch files must be created by hand. This isn't too much of a hardship, but it might be convenient for the interactive console to help out with this by allowing the user to log all commands executed to a file. This could be the basis for a CLI batch file that the user could include in some sort of integration scenario. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:41:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 4 Jul 2014 00:41:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982254#comment-12982254 ] Brett Meyer commented on SRAMP-474: ----------------------------------- [~eric.wittmann], up for reviewing https://github.com/Governance/s-ramp/pull/449 and make sure it's what you had in mind? If the log file is enabled, AbstractShellCommandReader simply writes each line. That's the 2nd commit. The first was me encapsulating all sramp.sh arguments in a class, including #properties and the new log-to-file option. > CLI: Add a log-to-file option > ----------------------------- > > Key: SRAMP-474 > URL: https://issues.jboss.org/browse/SRAMP-474 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently CLI batch files must be created by hand. This isn't too much of a hardship, but it might be convenient for the interactive console to help out with this by allowing the user to log all commands executed to a file. This could be the basis for a CLI batch file that the user could include in some sort of integration scenario. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 00:43:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 4 Jul 2014 00:43:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982255#comment-12982255 ] Brett Meyer commented on SRAMP-474: ----------------------------------- Once merged, include in the docs > CLI: Add a log-to-file option > ----------------------------- > > Key: SRAMP-474 > URL: https://issues.jboss.org/browse/SRAMP-474 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently CLI batch files must be created by hand. This isn't too much of a hardship, but it might be convenient for the interactive console to help out with this by allowing the user to log all commands executed to a file. This could be the basis for a CLI batch file that the user could include in some sort of integration scenario. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 06:19:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 06:19:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-518) Deploy RTGov server as a Vertx module In-Reply-To: References: Message-ID: Gary Brown created RTGOV-518: -------------------------------- Summary: Deploy RTGov server as a Vertx module Key: RTGOV-518 URL: https://issues.jboss.org/browse/RTGOV-518 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final Enable the RTGov server to be used as a Vertx module. Although the complete server could be encapsulated in a module, it may be better to separate out the main server components (e.g. ActivityStore, Event Process Network Manager, Active Collection Manager) as separate modules with appropriate inter-communication. Also some of the existing REST services should be made available as modules. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 06:43:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 06:43:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events In-Reply-To: References: Message-ID: Gary Brown created RTGOV-519: -------------------------------- Summary: Intercept activity from Vertx app interactions and report as activity events Key: RTGOV-519 URL: https://issues.jboss.org/browse/RTGOV-519 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.1.0.Final Vertx has a simple core that is not going to be extended to support any form of intercept mechanism. The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov. Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received). The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx. One approach to be considered: The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work. Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply. Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 06:43:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 06:43:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-519: ----------------------------- Reporter: Marc Savy (was: Gary Brown) > Intercept activity from Vertx app interactions and report as activity events > ---------------------------------------------------------------------------- > > Key: RTGOV-519 > URL: https://issues.jboss.org/browse/RTGOV-519 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Marc Savy > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Vertx has a simple core that is not going to be extended to support any form of intercept mechanism. > The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov. > Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received). > The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx. > One approach to be considered: > The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work. > Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply. > Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 06:43:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 06:43:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-518) Deploy RTGov server as a Vertx module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-518: ----------------------------- Reporter: Marc Savy (was: Gary Brown) > Deploy RTGov server as a Vertx module > ------------------------------------- > > Key: RTGOV-518 > URL: https://issues.jboss.org/browse/RTGOV-518 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Marc Savy > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Enable the RTGov server to be used as a Vertx module. > Although the complete server could be encapsulated in a module, it may be better to separate out the main server components (e.g. ActivityStore, Event Process Network Manager, Active Collection Manager) as separate modules with appropriate inter-communication. > Also some of the existing REST services should be made available as modules. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 06:43:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 06:43:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-518) Deploy RTGov server as a Vertx module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-518: ----------------------------- Reporter: Gary Brown (was: Marc Savy) > Deploy RTGov server as a Vertx module > ------------------------------------- > > Key: RTGOV-518 > URL: https://issues.jboss.org/browse/RTGOV-518 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Enable the RTGov server to be used as a Vertx module. > Although the complete server could be encapsulated in a module, it may be better to separate out the main server components (e.g. ActivityStore, Event Process Network Manager, Active Collection Manager) as separate modules with appropriate inter-communication. > Also some of the existing REST services should be made available as modules. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 06:45:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 06:45:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-519: ----------------------------- Reporter: Gary Brown (was: Marc Savy) > Intercept activity from Vertx app interactions and report as activity events > ---------------------------------------------------------------------------- > > Key: RTGOV-519 > URL: https://issues.jboss.org/browse/RTGOV-519 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Vertx has a simple core that is not going to be extended to support any form of intercept mechanism. > The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov. > Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received). > The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx. > One approach to be considered: > The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work. > Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply. > Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 09:07:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 09:07:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-517) Make context optional for ActivityStore.getActivityTypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-517: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/142 > Make context optional for ActivityStore.getActivityTypes > -------------------------------------------------------- > > Key: RTGOV-517 > URL: https://issues.jboss.org/browse/RTGOV-517 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > The query method is now deprecated due to tight binding to store backend. Unfortunately it means now it is not possible to get a list of ActivityTypes in a given timeframe. The method getActivityTypes provide such a functionality but it requires a knowledge of context. > It should be useful to make the context optionally. At the same time when the context is optional it has to be mandatory to provide time window to prevent dumping the whole db/index. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 09:07:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 09:07:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-458) ActivityServer integration test using deprecated query method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-458: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/142 > ActivityServer integration test using deprecated query method > ------------------------------------------------------------- > > Key: RTGOV-458 > URL: https://issues.jboss.org/browse/RTGOV-458 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The JBossASActivityServerServiceTest tested the activity server query method via the REST API. The issue was it relied on the JPA query language - hence this method was deprecated as it exposed the implementation. > Need to add further tests for the getActivityTypes and getActivityUnit method, to replace the query methods. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 09:07:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 09:07:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-517) Make context optional for ActivityStore.getActivityTypes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-517. ------------------------------ Resolution: Done > Make context optional for ActivityStore.getActivityTypes > -------------------------------------------------------- > > Key: RTGOV-517 > URL: https://issues.jboss.org/browse/RTGOV-517 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > The query method is now deprecated due to tight binding to store backend. Unfortunately it means now it is not possible to get a list of ActivityTypes in a given timeframe. The method getActivityTypes provide such a functionality but it requires a knowledge of context. > It should be useful to make the context optionally. At the same time when the context is optional it has to be mandatory to provide time window to prevent dumping the whole db/index. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 09:07:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 4 Jul 2014 09:07:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-458) ActivityServer integration test using deprecated query method In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-458. ------------------------------ Resolution: Done > ActivityServer integration test using deprecated query method > ------------------------------------------------------------- > > Key: RTGOV-458 > URL: https://issues.jboss.org/browse/RTGOV-458 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The JBossASActivityServerServiceTest tested the activity server query method via the REST API. The issue was it relied on the JPA query language - hence this method was deprecated as it exposed the implementation. > Need to add further tests for the getActivityTypes and getActivityUnit method, to replace the query methods. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 11:59:25 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 4 Jul 2014 11:59:25 -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=12982432#comment-12982432 ] RH Bugzilla Integration commented on SRAMP-395: ----------------------------------------------- Brett Meyer changed the Status of [bug 1114732|https://bugzilla.redhat.com/show_bug.cgi?id=1114732] from ASSIGNED to MODIFIED > 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 > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Alpha1, 0.5.0 > > > 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.2.6#6264) From issues at jboss.org Fri Jul 4 17:39:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 4 Jul 2014 17:39:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-474. ------------------------------- Resolution: Done Pushed to 0.6 > CLI: Add a log-to-file option > ----------------------------- > > Key: SRAMP-474 > URL: https://issues.jboss.org/browse/SRAMP-474 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently CLI batch files must be created by hand. This isn't too much of a hardship, but it might be convenient for the interactive console to help out with this by allowing the user to log all commands executed to a file. This could be the basis for a CLI batch file that the user could include in some sort of integration scenario. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 23:19:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 4 Jul 2014 23:19:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-168) Create a TCK test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-168: --------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > Create a TCK test suite > ----------------------- > > Key: SRAMP-168 > URL: https://issues.jboss.org/browse/SRAMP-168 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Kurt Stam > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Adding a Technical Compatibility Kit. > - add examples from spec docs > - add tests to validate the implementation adheres to the spec -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 4 23:19:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 4 Jul 2014 23:19:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-168) Create a TCK test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-168: ------------------------------ Parent: SRAMP-462 Issue Type: Sub-task (was: Task) > Create a TCK test suite > ----------------------- > > Key: SRAMP-168 > URL: https://issues.jboss.org/browse/SRAMP-168 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Kurt Stam > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Adding a Technical Compatibility Kit. > - add examples from spec docs > - add tests to validate the implementation adheres to the spec -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 08:38:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 08:38:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-112) Set href on all relationships in Atom layer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-112: --------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > Set href on all relationships in Atom layer > ------------------------------------------- > > Key: SRAMP-112 > URL: https://issues.jboss.org/browse/SRAMP-112 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Atom Binding > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > The persistence layer only sets the UUID of the relationship targets (for all relationships). The Atom layer needs to visit the artifact and add the full HREF on the targets. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 08:56:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 08:56:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-387) add javadoc jars to distro In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-387: --------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > add javadoc jars to distro > --------------------------- > > Key: SRAMP-387 > URL: https://issues.jboss.org/browse/SRAMP-387 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Kurt Stam > Assignee: Brett Meyer > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 08:58:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 08:58:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-199) Wsdl and Xsd Derivers are not setting up import/include relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-199: --------------------------------- Assignee: Brett Meyer (was: David virgil naranjo) > Wsdl and Xsd Derivers are not setting up import/include relationships > --------------------------------------------------------------------- > > Key: SRAMP-199 > URL: https://issues.jboss.org/browse/SRAMP-199 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.2.0 - Security & S-RAMP-1.0 > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > The XSD deriver and WSDL derivers need to set up relationships to other xsd/wsdl documents when they are imported or included. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 08:58:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 08:58:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-260) Free Text Search for artifacts Enhancement In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-260: --------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > Free Text Search for artifacts Enhancement > ------------------------------------------ > > Key: SRAMP-260 > URL: https://issues.jboss.org/browse/SRAMP-260 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Client > Environment: N/A > Reporter: Cojan van Ballegooijen > Assignee: Brett Meyer > Priority: Trivial > Fix For: 0.6.0 > > > The search field in Repository -> Artifacts of the S-RAMP UI web application looks like a free text search field. > One need to use the S-RAMP Query language. > https://github.com/Governance/s-ramp/wiki/GuideSrampQueryLanguage > Would be nice to have a free text search capability to search for artifacts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 09:06:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 09:06:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-225) CLI Query: option to print the next page in a query In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-225: --------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > CLI Query: option to print the next page in a query > --------------------------------------------------- > > Key: SRAMP-225 > URL: https://issues.jboss.org/browse/SRAMP-225 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Shell > Affects Versions: 0.3.0 - JBPM6 Integration > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > The CLI query command currently prints the first 100 items from the query results. It would be nice to have an option to show the next page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 09:08:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 09:08:24 -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 updated SRAMP-380: ------------------------------ Fix Version/s: 0.6.0 (was: 0.5.0) > 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: Eric Wittmann > 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.2.6#6264) From issues at jboss.org Sat Jul 5 09:08:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 09:08:24 -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 updated SRAMP-380: ------------------------------ Assignee: David virgil naranjo (was: Eric Wittmann) > 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.2.6#6264) From issues at jboss.org Sat Jul 5 09:08:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 09:08:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982476#comment-12982476 ] Brett Meyer commented on SRAMP-380: ----------------------------------- [~virchete], this probably isn't an extremely urgent priority, but interested in taking a look? Find out if Fuse has something similar to EAP's Valut? > 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.2.6#6264) From issues at jboss.org Sat Jul 5 09:10:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 09:10:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-383) Implement Maven integration as a server component instead of a wagon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-383: ------------------------------ Fix Version/s: (was: 0.6.0) > Implement Maven integration as a server component instead of a wagon > -------------------------------------------------------------------- > > Key: SRAMP-383 > URL: https://issues.jboss.org/browse/SRAMP-383 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > > Currently we integrate with Maven using a maven wagon. However, there are some fairly significant limitations with this method. Instead, we should implement a server component that would behave like a simple Maven repository but use the s-ramp repository as backing storage. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 5 09:10:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 5 Jul 2014 09:10:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-383) Implement Maven integration as a server component instead of a wagon In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-383. ----------------------------- Resolution: Duplicate Issue Closing this in favor of SRAMP-451 and its follow-ups. > Implement Maven integration as a server component instead of a wagon > -------------------------------------------------------------------- > > Key: SRAMP-383 > URL: https://issues.jboss.org/browse/SRAMP-383 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > > Currently we integrate with Maven using a maven wagon. However, there are some fairly significant limitations with this method. Instead, we should implement a server component that would behave like a simple Maven repository but use the s-ramp repository as backing storage. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 10:49:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Sun, 6 Jul 2014 10:49:24 -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=12982482#comment-12982482 ] RH Bugzilla Integration commented on SRAMP-395: ----------------------------------------------- Julian Coleman changed the Status of [bug 1114732|https://bugzilla.redhat.com/show_bug.cgi?id=1114732] from MODIFIED to POST > 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 > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Alpha1, 0.5.0 > > > 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.2.6#6264) From issues at jboss.org Sun Jul 6 13:37:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 13:37:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-431: ------------------------------ Description: Create a new s-ramp-test module to contain all integration tests. Thoughts: - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME - Fuse should be run in embedded mode. - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. The work-in-progress: https://github.com/brmeyer/s-ramp/commits/integration-tests https://github.com/brmeyer/s-ramp/compare/integration-tests was: Create a new s-ramp-test module to contain all integration tests. Thoughts: - 1 central abstract class (IntegrationTest) that contains all the functional tests and assertions (or if that gets too large, split it up into delegates) - 1 Arquillian test per supported container, extending the above. Mainly in charge of the @RunWith and @Deployments. Ex: EAPIntegrationTest extends IntegrationTest - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME - Fuse should be run in embedded mode. The work-in-progress: https://github.com/brmeyer/s-ramp/commits/integration-tests > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: > https://github.com/brmeyer/s-ramp/commits/integration-tests > https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 13:39:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 13:39:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-458) Integration tests: Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-458 started by Brett Meyer. > Integration tests: Tomcat > ------------------------- > > Key: SRAMP-458 > URL: https://issues.jboss.org/browse/SRAMP-458 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 13:41:26 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 13:41:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-431: ------------------------------ Description: Create a new s-ramp-test module to contain all integration tests. Thoughts: - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME - Fuse should be run in embedded mode. - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests was: Create a new s-ramp-test module to contain all integration tests. Thoughts: - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME - Fuse should be run in embedded mode. - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. The work-in-progress: https://github.com/brmeyer/s-ramp/commits/integration-tests https://github.com/brmeyer/s-ramp/compare/integration-tests > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 13:44:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 13:44:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982484#comment-12982484 ] Brett Meyer commented on SRAMP-431: ----------------------------------- Re-wrote the description, after scraping off my Arquillian rust ;) All, take a look at https://github.com/brmeyer/s-ramp/compare/integration-tests and let me know your thoughts. So far, it downloads Tomcat, unpacks it, and runs the full S-RAMP installer on it. Arquillian runs Tomcat in a managed-mode, then runs a simple client test (passes). Jetty's setup will be nearly identical. EAP too, minus the downloading (unpack the distro zip from a known location or support $JBOSS_HOME). However, Arquillian does not currently have a Jetty 8 container. Since there is Jetty 7 & 9, I may look into contributing one for 8. > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 13:48:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 13:48:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982485#comment-12982485 ] Brett Meyer commented on SRAMP-431: ----------------------------------- One thought for Fuse: The test currently runs Arquillian in its "as-client" mode, skipping the @Deployment completely. So that we can simply reuse those tests, we might consider configuring the embedded Fuse container with XML. IIRC, that's possible in Arquillian, rather than having to include another layer in the tests with the Fuse-specific @Deployment. > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sun Jul 6 13:52:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sun, 6 Jul 2014 13:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982484#comment-12982484 ] Brett Meyer edited comment on SRAMP-431 at 7/6/14 1:51 PM: ----------------------------------------------------------- Re-wrote the description, after scraping off my Arquillian rust ;) All, take a look at https://github.com/brmeyer/s-ramp/compare/integration-tests and let me know your thoughts. So far, it downloads Tomcat, unpacks it, and runs the full S-RAMP installer on it. Arquillian runs Tomcat in a managed-mode, then runs a simple client test (passes). EAP setup will be identical, minus the downloading (unpack the distro zip from a known location or support $JBOSS_HOME). Arquillian does not currently have a Jetty 8 container. Since there is Jetty 7 & 9, I may look into contributing one for 8. However, note that *none* of them support managed-mode -- all require embedded. Do we want to try that for Jetty, or look into writing a managed one? was (Author: brmeyer): Re-wrote the description, after scraping off my Arquillian rust ;) All, take a look at https://github.com/brmeyer/s-ramp/compare/integration-tests and let me know your thoughts. So far, it downloads Tomcat, unpacks it, and runs the full S-RAMP installer on it. Arquillian runs Tomcat in a managed-mode, then runs a simple client test (passes). Jetty's setup will be nearly identical. EAP too, minus the downloading (unpack the distro zip from a known location or support $JBOSS_HOME). However, Arquillian does not currently have a Jetty 8 container. Since there is Jetty 7 & 9, I may look into contributing one for 8. > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 10:06:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 7 Jul 2014 10:06:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-519) Intercept activity from Vertx app interactions and report as activity events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-519: ----------------------------- Assignee: Marc Savy (was: Gary Brown) > Intercept activity from Vertx app interactions and report as activity events > ---------------------------------------------------------------------------- > > Key: RTGOV-519 > URL: https://issues.jboss.org/browse/RTGOV-519 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Marc Savy > Fix For: 2.1.0.Final > > > Vertx has a simple core that is not going to be extended to support any form of intercept mechanism. > The current advice from the vertx team is to create a module that essentially acts as proxy to the real module being used. The problem with this approach is that it does not have any information about the client or service, which are required by rtgov. > Therefore the suggested approach will be to wrap the event bus api with an implementation that can be configured with information about the verticle in which it is being used. Then it can use that information when a message is being sent or received, to create activity events (e.g. request sent/received, response sent/received). > The other issue to consider is how to build ActivityUnits out of the various ActivityType events that may be associated with a business transaction instance. In some environments, the thread can be used to track and accumulate multiple activity events to the same unit. However this approach wouldn't work in Vertx. > One approach to be considered: > The activity events should be reported to an intermediate module responsible for accumulating events into a unit. If a response is expected, then when recording the request it should record the fact, so that the module building the activity unit can determine when invocation scopes have been completed, and therefore the activity unit submitted. (May be more complex than this, but possibly a starting point). The response handler would need to cache a 'replyTo' id that would enable it to submit response events to the same activity unit. This may be controlled on the client side (i.e. event bus proxy), as it may know when it has finished doing its work. > Worst case is that each verticle 'instance' would record its activity in a single activity unit - i.e. request received, and sent messages and received responses, before returning its reply. > Need to investigate whether vertx exposes any form of message ids between verticles - and if not, whether this is something they would consider adding. This would enable correlation of activity across verticles. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 10:06:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 7 Jul 2014 10:06:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-518) Deploy RTGov server as a Vertx module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-518: ----------------------------- Assignee: Marc Savy (was: Gary Brown) > Deploy RTGov server as a Vertx module > ------------------------------------- > > Key: RTGOV-518 > URL: https://issues.jboss.org/browse/RTGOV-518 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Marc Savy > Fix For: 2.1.0.Final > > > Enable the RTGov server to be used as a Vertx module. > Although the complete server could be encapsulated in a module, it may be better to separate out the main server components (e.g. ActivityStore, Event Process Network Manager, Active Collection Manager) as separate modules with appropriate inter-communication. > Also some of the existing REST services should be made available as modules. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 10:26:23 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 10:26:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-494) Allow the installer's password prompt to be skipped In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-494: --------------------------------- Summary: Allow the installer's password prompt to be skipped Key: SRAMP-494 URL: https://issues.jboss.org/browse/SRAMP-494 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer The integration tests, automated installers, etc., move the password prompt into a separate target. Skip it if the password property is already set. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 10:26:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 10:26:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-494) Allow the installer's password prompt to be skipped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-494: ------------------------------ Fix Version/s: 0.5.0 > Allow the installer's password prompt to be skipped > --------------------------------------------------- > > Key: SRAMP-494 > URL: https://issues.jboss.org/browse/SRAMP-494 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The integration tests, automated installers, etc., move the password prompt into a separate target. Skip it if the password property is already set. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:02:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:02:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Artifact Content (download) link not working in s-ramp In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-495: ----------------------------------- Summary: Artifact Content (download) link not working in s-ramp Key: SRAMP-495 URL: https://issues.jboss.org/browse/SRAMP-495 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: S-RAMP API, UI Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0 Reported by David (Beta1 testing): The artifact content link in the s-ramp artifact details is not working: Image related: artifact_content_link.jpeg Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:04:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:04:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-496) Maven Facade not working for artifacts with classifier (sources, tests, etc) In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-496: ----------------------------------- Summary: Maven Facade not working for artifacts with classifier (sources, tests, etc) Key: SRAMP-496 URL: https://issues.jboss.org/browse/SRAMP-496 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: David virgil naranjo Fix For: 0.5.0 Reported by David (0.5.0.Beta1 Testing): Maven repository servlet --> Not working in case of files that contains a classifier in its name, like sources or test. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:06:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:06:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-497) Exclude s-ramp-demos-assembly from all distro zips In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-497: ----------------------------------- Summary: Exclude s-ramp-demos-assembly from all distro zips Key: SRAMP-497 URL: https://issues.jboss.org/browse/SRAMP-497 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: Distro Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0 Reported by David (0.5.0.Beta1 Testing): This is not a demo, but rather a packaging of the other demos. It should be excluded from all zips. Ensure that it is. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:10:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:10:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-498) Provide a mechanism to consume "seed data" In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-498: ----------------------------------- Summary: Provide a mechanism to consume "seed data" Key: SRAMP-498 URL: https://issues.jboss.org/browse/SRAMP-498 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Brett Meyer This is a feature request from David based on his testing of 1.3.0.Beta1 of dtgov: "Would be very nice for the user, that the first time dtgov is executed, the cli-commands file is loaded and all the dtgov artifacts are installed in s-ramp." I think the idea is that currently the user must do this manually after installing and launching s-ramp/dtgov. Instead, it would be interesting to have a way to consume this data on startup. I'm adding this as a suggested enhancment to s-ramp. If we decide this feature is not appropriate for s-ramp, then we should move it to a DTGov feature request and consider it in that context. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:14:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:14:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-499) Include another filter for Expanded (similar to Derived) In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-499: ----------------------------------- Summary: Include another filter for Expanded (similar to Derived) Key: SRAMP-499 URL: https://issues.jboss.org/browse/SRAMP-499 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Brett Meyer Reported by David via his 0.5.0.Beta1 testing: "S-ramp Artifacts --> include another column called Expanded. Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded. I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them. If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property). I will prepare a html mock with my idea..." -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:16:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:16:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-499) Include another filter for Expanded (similar to Derived) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982686#comment-12982686 ] Eric Wittmann commented on SRAMP-499: ------------------------------------- I would prefer a solution that merged these two concepts in the UI. In other words, the filter section would add "Expanded" as an option alongside Derived - perhaps changing them to checkboxes instead of radio buttons. The existing derived column could be relabeled and the value could be one of: primary, expanded, derived Only primary artifacts would be shown by default (the filter would default to primary). > Include another filter for Expanded (similar to Derived) > -------------------------------------------------------- > > Key: SRAMP-499 > URL: https://issues.jboss.org/browse/SRAMP-499 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > > Reported by David via his 0.5.0.Beta1 testing: > "S-ramp Artifacts --> include another column called Expanded. > Then with this we can filter the original items (for example jars, war) from the files that are expanded from those Original Artifacts uploaded. > I continue thinking that when there are many artifadts uploaded it is difficult to filter and have an easy understanding of the artifact result list. For example you see a file kmodule.xml, and you do not know to what artifact it belongs. You need to enter in the artifact to have this information. And when the number of artifacts in s-ramp is so big, then you see many many files, that you have no idea about them. > If we include this expanded column and also filter field then we could have a view of the original artifacts (with no artifact parent property). > I will prepare a html mock with my idea..." -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:18:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:18:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-500) Improve the S-RAMP demo README files In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-500: ----------------------------------- Summary: Improve the S-RAMP demo README files Key: SRAMP-500 URL: https://issues.jboss.org/browse/SRAMP-500 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Brett Meyer >From David via his 0.5.0.Beta1 Testing: S-ramp DEMO README files. The majority of them are a copy/paste (not always). Here what can happen to user is that as you realized about the copy paste, then you do not read the README files, and they are not useful. I think we could explain little bit more in detail what the test is doing in terms of: - 2 files are uploaded: specify the names. - Then a query that checks the property name 'xxx' is executed... This can give more value to the good tests we have, and the user would read the README file. That for me is very important. A good example of Test Output is the s-ramp-demos-simple-client: {code} Uploading some XML schemas... Uploading artifact ws-humantask.xsd...done. Updating meta-data for artifact ws-humantask.xsd...done. Uploading artifact ws-humantask-context.xsd...done. Updating meta-data for artifact ws-humantask-context.xsd...done. Uploading artifact ws-humantask-policy.xsd...done. Updating meta-data for artifact ws-humantask-policy.xsd...done. Uploading artifact ws-humantask-types.xsd...done. Updating meta-data for artifact ws-humantask-types.xsd...done. Uploading artifact ws-humantask-leantask-api.wsdl...done. Updating meta-data for artifact ws-humantask-leantask-api.wsdl...done. Uploading artifact ws-humantask-protocol.wsdl...done. Updating meta-data for artifact ws-humantask-protocol.wsdl...done. Querying the S-RAMP repository for Schemas...success: 11 Schemas found: * address.xsd (b885aebb-9f84-424d-af1e-84e335163be7) * person.xsd (895719d6-0daa-448b-87c8-6085021e29ba) * ws-humantask-context.xsd (fb253cc7-d576-4127-b331-cc384218bc06) * ws-humantask-policy.xsd (2eebffe7-2e02-4985-b04f-24e6025489c3) * ws-humantask-types.xsd (cfa90bea-c27c-49bb-8ac2-604f2a3763f3) * ws-humantask.xsd (a3bc7c9f-54fa-489e-845c-a328ab968bd9) * wsrm-1.1-schema-200702.xsd (54731483-c7d1-40d6-b152-f332bebf17d1) * wsrmp-1.2-schema-200702.xsd (f3007bee-353e-4e1b-a79d-0aea85c7b1ed) * wss-wssecurity-secext-1.0.xsd (8cef7a73-e284-411e-9af9-9b1ada31f623) * wss-wssecurity-utility-1.0.xsd (cee6023f-e26f-4240-baa6-594d1eea4928) * wstx-wsba-1.1-schema-200701.xsd (30246422-dc4e-4bc6-8317-8d58a73e3c64) {code} It gives explanations about the files uploaded and the queries done. In other tests just it is said 2 files uploaded, and then query done sucessfully. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:20:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:20:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-501) Improve the Shell Command demo README In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-501: ----------------------------------- Summary: Improve the Shell Command demo README Key: SRAMP-501 URL: https://issues.jboss.org/browse/SRAMP-501 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Distro, Shell Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0 The README for the s-ramp-demo-shell-command is apparently not very clear. David was unable to successfully test this demo in 0.5.0.Beta1: "Can not execute s-ramp-demos-shell-command Copy the to s-ramp-demos-shell-command-0.5.0.Beta1.jar s-ramp-shell/s-ramp/commands Then execute the s-ramp-shell/sramp.sh Is not well explain the README file or at least I am not understanding how to do it." -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:20:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 11:20:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-501) Improve the Shell Command demo README In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982689#comment-12982689 ] Eric Wittmann commented on SRAMP-501: ------------------------------------- The idea behind this demo is to show how custom s-ramp shell commands can be created and contributed by users, thereby extending the commands available in the s-ramp CLI. The CLI has changed a fair amount since this demo was created - it is possible the demo needs to be updated as well as clarified. > Improve the Shell Command demo README > ------------------------------------- > > Key: SRAMP-501 > URL: https://issues.jboss.org/browse/SRAMP-501 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Distro, Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The README for the s-ramp-demo-shell-command is apparently not very clear. David was unable to successfully test this demo in 0.5.0.Beta1: > "Can not execute s-ramp-demos-shell-command > Copy the to s-ramp-demos-shell-command-0.5.0.Beta1.jar s-ramp-shell/s-ramp/commands > Then execute the s-ramp-shell/sramp.sh > Is not well explain the README file or at least I am not understanding how to do it." -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:50:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 7 Jul 2014 11:50:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-474) RTGov UI provider implementations as OSGi service in Karaf In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-474: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > RTGov UI provider implementations as OSGi service in Karaf > ---------------------------------------------------------- > > Key: RTGOV-474 > URL: https://issues.jboss.org/browse/RTGOV-474 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > See if possible to have the UI providers defined as OSGi services that can be resolved via activator etc, rather than CDI by including them in the war. > This would enable other technologies to be supported more easily within the UI. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:52:23 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 7 Jul 2014 11:52:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-475) OSGi service list in RTGov UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-475: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > OSGi service list in RTGov UI > ----------------------------- > > Key: RTGOV-475 > URL: https://issues.jboss.org/browse/RTGOV-475 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > As we can use rtgov to monitor standard OSGi services, these should also be listed in the RTGov UI service list. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 11:54:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 7 Jul 2014 11:54:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-309) Use switchyard higher level security API to get principal In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-309: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Use switchyard higher level security API to get principal > --------------------------------------------------------- > > Key: RTGOV-309 > URL: https://issues.jboss.org/browse/RTGOV-309 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Use the SecurityContextManager to make sure we process an un-sealed security context. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:02:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 12:02:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-494) Allow the installer's password prompt to be skipped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-494 started by Brett Meyer. > Allow the installer's password prompt to be skipped > --------------------------------------------------- > > Key: SRAMP-494 > URL: https://issues.jboss.org/browse/SRAMP-494 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The integration tests, automated installers, etc., move the password prompt into a separate target. Skip it if the password property is already set. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:42:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 12:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-494) Allow the installer's password prompt to be skipped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-494. ------------------------------- Resolution: Done > Allow the installer's password prompt to be skipped > --------------------------------------------------- > > Key: SRAMP-494 > URL: https://issues.jboss.org/browse/SRAMP-494 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The integration tests, automated installers, etc., move the password prompt into a separate target. Skip it if the password property is already set. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:42:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 12:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-494) Allow the installer's password prompt to be skipped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-494: ------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/81 > Allow the installer's password prompt to be skipped > --------------------------------------------------- > > Key: SRAMP-494 > URL: https://issues.jboss.org/browse/SRAMP-494 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The integration tests, automated installers, etc., move the password prompt into a separate target. Skip it if the password property is already set. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:54:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 12:54:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Artifact Content (download) link not working in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982732#comment-12982732 ] Brett Meyer commented on SRAMP-495: ----------------------------------- Might be limited to the ext model or the specific dtgov type. Just tried with an XSD and it's working: http://localhost:8080/s-ramp-server/s-ramp/core/XsdDocument/30e9f508-c299-448e-b1cb-aa4aa0cb5aa0/media > Artifact Content (download) link not working in s-ramp > ------------------------------------------------------ > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 12:56:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 12:56:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Artifact Content (download) link not working in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982734#comment-12982734 ] Brett Meyer commented on SRAMP-495: ----------------------------------- [~virchete], any more info available? > Artifact Content (download) link not working in s-ramp > ------------------------------------------------------ > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 13:00:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 13:00:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Artifact Content (download) link not working in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982737#comment-12982737 ] Brett Meyer commented on SRAMP-495: ----------------------------------- Doesn't appear to be an issue with /ext either. This works: http://localhost:8080/s-ramp-server/s-ramp/ext/FooType/afd193bb-c071-4c25-b96a-e4ed4912a392/media > Artifact Content (download) link not working in s-ramp > ------------------------------------------------------ > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 13:16:28 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 13:16:28 -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:comment-tabpanel&focusedCommentId=12982744#comment-12982744 ] Eric Wittmann commented on SRAMP-433: ------------------------------------- One thing I would add is that I don't think queue or topic configuration should be done by storing that information in s-ramp itself. While it's true that we are moving some of the DTGov config information from dtgov.properties into S-RAMP artifacts, I don't necessarily think this config is applicable. On the S-RAMP (producer) side, there is no precedent for storing config in the repo. On the DTGov (consumer) side, it might make more sense but thus far we have only moved configuration into the S-RAMP repo for stuff that users are likely to "frequently" change (ie more than just initial app config time). > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 13:18:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 7 Jul 2014 13:18:24 -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:comment-tabpanel&focusedCommentId=12982745#comment-12982745 ] Eric Wittmann commented on SRAMP-433: ------------------------------------- What are we trying to avoid by installing S-RAMP with a default "dtgov" queue? Is it hard to configure queues? Will the DTGov installer not be able to set up its own queue in S-RAMP? Just trying to understand. Logically I would expect S-RAMP to be configured with a default notification topic and a simple way to support multiple named queues (for each of the consumers, of which dtgov is one). A named queue should be relatively easy to create, such that the DTGov installer would add it to the S-RAMP config during DTGov install time. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 13:22:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 13:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-497) Exclude s-ramp-demos-assembly from all distro zips In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982746#comment-12982746 ] Brett Meyer commented on SRAMP-497: ----------------------------------- [~virchete], what ZIP did you see s-ramp-demos-assembly in? I just ran a build and don't see it in s-ramp-distro/assembly's s-ramp-[VERSION].zip > Exclude s-ramp-demos-assembly from all distro zips > -------------------------------------------------- > > Key: SRAMP-497 > URL: https://issues.jboss.org/browse/SRAMP-497 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (0.5.0.Beta1 Testing): > This is not a demo, but rather a packaging of the other demos. It should be excluded from all zips. Ensure that it is. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 14:12:23 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 14:12:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-458) Integration tests: Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-458. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done Completed on https://github.com/brmeyer/s-ramp/compare/integration-tests and will be a part of SRAMP-431 > Integration tests: Tomcat > ------------------------- > > Key: SRAMP-458 > URL: https://issues.jboss.org/browse/SRAMP-458 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 15:50:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 15:50:24 -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:comment-tabpanel&focusedCommentId=12982786#comment-12982786 ] Brett Meyer commented on SRAMP-433: ----------------------------------- {quote} Logically I would expect S-RAMP to be configured with a default notification topic and a simple way to support multiple named queues (for each of the consumers, of which dtgov is one). A named queue should be relatively easy to create, such that the DTGov installer would add it to the S-RAMP config during DTGov install time. {quote} +1, that was my original intention. All topics would be predefined. Queues would be a simple list of names in the S-RAMP properties file. DTGov queue support would be "out of the box" in that the DTGov installer would automatically add a queue name to the list. > 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. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 16:22:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 16:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-168) Create a TCK test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982799#comment-12982799 ] Brett Meyer commented on SRAMP-168: ----------------------------------- Remove the current tck from s-ramp. Create a new tck repo in Overlord. The tck should have no dependencies on overlord whatsoever. Keep it limited to simple REST, xmlunit, xpath, etc. > Create a TCK test suite > ----------------------- > > Key: SRAMP-168 > URL: https://issues.jboss.org/browse/SRAMP-168 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Kurt Stam > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Adding a Technical Compatibility Kit. > - add examples from spec docs > - add tests to validate the implementation adheres to the spec -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 16:24:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 16:24:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-168) Create a TCK test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982799#comment-12982799 ] Brett Meyer edited comment on SRAMP-168 at 7/7/14 4:22 PM: ----------------------------------------------------------- Remove the current tck from s-ramp. Create a new tck repo in Overlord (Governance/s-ramp-tck). The tck should have no dependencies on overlord whatsoever. Keep it limited to simple REST, xmlunit, xpath, etc. was (Author: brmeyer): Remove the current tck from s-ramp. Create a new tck repo in Overlord. The tck should have no dependencies on overlord whatsoever. Keep it limited to simple REST, xmlunit, xpath, etc. > Create a TCK test suite > ----------------------- > > Key: SRAMP-168 > URL: https://issues.jboss.org/browse/SRAMP-168 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Kurt Stam > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Adding a Technical Compatibility Kit. > - add examples from spec docs > - add tests to validate the implementation adheres to the spec -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 18:39:23 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 18:39:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-461) Integration tests: EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-461. ------------------------------- Fix Version/s: 0.6.0 Resolution: Done Completed on https://github.com/brmeyer/s-ramp/compare/integration-tests and will be a part of SRAMP-431 > Integration tests: EAP > ---------------------- > > Key: SRAMP-461 > URL: https://issues.jboss.org/browse/SRAMP-461 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > May need to split this into EAP 6.1 and 6.3 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 18:41:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 18:41:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-502) Upgrade arquillian-tomcat-managed-7 to 1.0.0.Final In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-502: --------------------------------- Summary: Upgrade arquillian-tomcat-managed-7 to 1.0.0.Final Key: SRAMP-502 URL: https://issues.jboss.org/browse/SRAMP-502 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Once arquillian-tomcat-managed-7 1.0.0.Final is out, upgrade it in s-ramp-test. (If SRAMP-431 is not yet merged, update brmeyer's integration-test branch.) Note that the following line can then be removed in arquillian.xml: target/apache-tomcat-7.0.54 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 18:43:41 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 18:43:41 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-503) Create JBoss EAP 6.2/6.3 integration tests In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-503: --------------------------------- Summary: Create JBoss EAP 6.2/6.3 integration tests Key: SRAMP-503 URL: https://issues.jboss.org/browse/SRAMP-503 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Arquillian does not currently support EAP 6.2/6.3. Once it does, add *both* to the integration tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 7 18:43:41 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 7 Jul 2014 18:43:41 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982823#comment-12982823 ] Brett Meyer commented on SRAMP-431: ----------------------------------- EAP 6.1 tests completed. 6.2 & 6.3 are unfortunately not currently supported by Arquillian. > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 05:52:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Tue, 8 Jul 2014 05:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-462) Explore whether ElasticSearch server can be embedded into container (EAP) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982936#comment-12982936 ] ivan mckinley commented on RTGOV-462: ------------------------------------- Hey, The PR RTGOV-462 contains the basic functionality for a embedded ES. by default it will start a embedded server but this is configurable Open points/Todo, - Port mapping of ES, Although ES will automatically take another port if defaults are not available. It would be prefered to configure this with EAP - Possibly move the configuration from rtgov-es.properties to standalone.xml and domain.xml (this file is can be overwritten much like overlord-rtgov.properties ) > Explore whether ElasticSearch server can be embedded into container (EAP) > ------------------------------------------------------------------------- > > Key: RTGOV-462 > URL: https://issues.jboss.org/browse/RTGOV-462 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Determine whether ElasticSearch could be embedded within EAP/Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 10:45:39 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 10:45:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982823#comment-12982823 ] Brett Meyer edited comment on SRAMP-431 at 7/8/14 10:44 AM: ------------------------------------------------------------ EAP 6.1/6.2 tests completed. 6.3 isn't working with Arquillian -- holding off on that until the GA release. was (Author: brmeyer): EAP 6.1 tests completed. 6.2 & 6.3 are unfortunately not currently supported by Arquillian. > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 10:45:42 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 10:45:42 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-503) Create JBoss EAP 6.3 integration test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-503: ------------------------------ Summary: Create JBoss EAP 6.3 integration test (was: Create JBoss EAP 6.2/6.3 integration tests) Description: Arquillian was not working with the EAP 6.3 beta. After the 6.3 GA release, try again. (was: Arquillian does not currently support EAP 6.2/6.3. Once it does, add *both* to the integration tests.) > Create JBoss EAP 6.3 integration test > ------------------------------------- > > Key: SRAMP-503 > URL: https://issues.jboss.org/browse/SRAMP-503 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Arquillian was not working with the EAP 6.3 beta. After the 6.3 GA release, try again. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 10:55:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 10:55:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983175#comment-12983175 ] Brett Meyer commented on SRAMP-431: ----------------------------------- Investigating moving all AbstractJCRPersistenceTest, BaseResourceTest, etc. into s-ramp-test. Basically, anything that spins up a server needs to be an "integration test". Only true, pure, unit tests will be left behind. This should also mean that we can strip out RestEasy's test framework, TJWS, etc., since we should instead be relying on the Arquillian container > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 10:59:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 8 Jul 2014 10:59:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-497) Exclude s-ramp-demos-assembly from all distro zips In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983178#comment-12983178 ] David virgil naranjo commented on SRAMP-497: -------------------------------------------- close this issue then. The s-ramp-demos-assembly project should not be included in the distro. So you checked and it is not included. So this can be closed, as this is not an issue. > Exclude s-ramp-demos-assembly from all distro zips > -------------------------------------------------- > > Key: SRAMP-497 > URL: https://issues.jboss.org/browse/SRAMP-497 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (0.5.0.Beta1 Testing): > This is not a demo, but rather a packaging of the other demos. It should be excluded from all zips. Ensure that it is. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:01:29 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 8 Jul 2014 11:01:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Artifact Content (download) link not working in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983180#comment-12983180 ] David virgil naranjo commented on SRAMP-495: -------------------------------------------- Maybe this is an issue with the DtgovWorkflowQuery artifacts. Need to be rechecked. For trying this is quite easy. Just install dtgov, s-ramp and seed dtgov. Then some artifacts of type DtgovWorkflowQuery will appear in the S-ramp Artifact List. > Artifact Content (download) link not working in s-ramp > ------------------------------------------------------ > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:15:27 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 11:15:27 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Artifact Content (download) link not working in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983188#comment-12983188 ] Brett Meyer commented on SRAMP-495: ----------------------------------- (11:02:31 AM) ewittman: virchete, brmeyer : Oh! DtgovWorkflowQuery doesn't have any content. It's a non-Document style artifact. (11:02:47 AM) ewittman: virchete, brmeyer : So the bug is probably that for non-document artifacts we should hide that link. > Artifact Content (download) link not working in s-ramp > ------------------------------------------------------ > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:15:28 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 11:15:28 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Hide the download link for artifacts with no content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-495: ------------------------------ Summary: Hide the download link for artifacts with no content (was: Artifact Content (download) link not working in s-ramp) > Hide the download link for artifacts with no content > ---------------------------------------------------- > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 11:50:26 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 11:50:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-497) Exclude s-ramp-demos-assembly from all distro zips In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-497. ----------------------------- Fix Version/s: (was: 0.5.0) Resolution: Cannot Reproduce Bug > Exclude s-ramp-demos-assembly from all distro zips > -------------------------------------------------- > > Key: SRAMP-497 > URL: https://issues.jboss.org/browse/SRAMP-497 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Eric Wittmann > Assignee: Brett Meyer > > Reported by David (0.5.0.Beta1 Testing): > This is not a demo, but rather a packaging of the other demos. It should be excluded from all zips. Ensure that it is. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 14:26:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Tue, 8 Jul 2014 14:26:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-520) Set "not_analyzed" as the default setting for fields added to rtgov. In-Reply-To: References: Message-ID: ivan mckinley created RTGOV-520: ----------------------------------- Summary: Set "not_analyzed" as the default setting for fields added to rtgov. Key: RTGOV-520 URL: https://issues.jboss.org/browse/RTGOV-520 Project: RTGov (Run Time Governance) Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: ivan mckinley Assignee: ivan mckinley Fix For: 2.0.0.Final As discussed in forum post (point 3), as the ElasticSearch capabilities are now encapsulated in the KeyValueStore implementation, it makes sense to make the EventProcessor more generic to cater for any key/store implementation. As pointed out by Ivan, some custom capabilities may be required by particular KeyValueStore implementations (e.g. MongoDB, Cassandra), but these can be added later as extensions to the generic event processor. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 14:28:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Tue, 8 Jul 2014 14:28:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-520) Set "not_analyzed" as the default setting for fields added to rtgov. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-520: -------------------------------- Description: In rtgov-mapping.json. have the mapping set all fields to Not_analyzed. this avoids the issue outlined in https://issues.jboss.org/browse/RTGOV-461 in there are mappings that required the field to be analyzed then they should be explicitly configured. was: As discussed in forum post (point 3), as the ElasticSearch capabilities are now encapsulated in the KeyValueStore implementation, it makes sense to make the EventProcessor more generic to cater for any key/store implementation. As pointed out by Ivan, some custom capabilities may be required by particular KeyValueStore implementations (e.g. MongoDB, Cassandra), but these can be added later as extensions to the generic event processor. > Set "not_analyzed" as the default setting for fields added to rtgov. > --------------------------------------------------------------------- > > Key: RTGOV-520 > URL: https://issues.jboss.org/browse/RTGOV-520 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: ivan mckinley > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > > In rtgov-mapping.json. have the mapping set all fields to Not_analyzed. this avoids the issue outlined in https://issues.jboss.org/browse/RTGOV-461 > in there are mappings that required the field to be analyzed then they should be explicitly configured. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 14:28:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Tue, 8 Jul 2014 14:28:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-520) Set "not_analyzed" as the default setting for fields added to rtgov. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-520: -------------------------------- Priority: Minor (was: Major) > Set "not_analyzed" as the default setting for fields added to rtgov. > --------------------------------------------------------------------- > > Key: RTGOV-520 > URL: https://issues.jboss.org/browse/RTGOV-520 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: ivan mckinley > Assignee: ivan mckinley > Priority: Minor > Fix For: 2.0.0.Final > > > In rtgov-mapping.json. have the mapping set all fields to Not_analyzed. this avoids the issue outlined in https://issues.jboss.org/browse/RTGOV-461 > in there are mappings that required the field to be analyzed then they should be explicitly configured. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 17:45:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 17:45:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-179) Remove our version of the RESTEasy test classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-179: --------------------------------- Assignee: Brett Meyer (was: David virgil naranjo) > Remove our version of the RESTEasy test classes > ----------------------------------------------- > > Key: SRAMP-179 > URL: https://issues.jboss.org/browse/SRAMP-179 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Kurt Stam > Assignee: Brett Meyer > > RESTEasy 2.3.5 does not support setting the hostname in the test classes: > https://issues.jboss.org/browse/RESTEASY-845 > Four classes where copied from RESTEasy and support for setting the hostname was added: > https://github.com/KurtStam/s-ramp/tree/master/s-ramp-common/src/test/java/org/overlord/sramp/common/test/resteasy > This was also submitted as a patch to RESTEasy. Once this patch is accepted, and we use this release, our version of these classes should be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 17:45:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 17:45:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-179) Remove our version of the RESTEasy test classes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-179. ----------------------------- Fix Version/s: (was: 0.6.0) Resolution: Duplicate Issue SRAMP-431 is removing our dependency on RESTEasy test and TJWS entirely. > Remove our version of the RESTEasy test classes > ----------------------------------------------- > > Key: SRAMP-179 > URL: https://issues.jboss.org/browse/SRAMP-179 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Kurt Stam > Assignee: Brett Meyer > > RESTEasy 2.3.5 does not support setting the hostname in the test classes: > https://issues.jboss.org/browse/RESTEASY-845 > Four classes where copied from RESTEasy and support for setting the hostname was added: > https://github.com/KurtStam/s-ramp/tree/master/s-ramp-common/src/test/java/org/overlord/sramp/common/test/resteasy > This was also submitted as a patch to RESTEasy. Once this patch is accepted, and we use this release, our version of these classes should be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 8 18:01:28 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 8 Jul 2014 18:01:28 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-168) Create a TCK test suite In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983310#comment-12983310 ] Brett Meyer commented on SRAMP-168: ----------------------------------- See subclasses of AbstractResourceTest for RESTEasy-based client examples > Create a TCK test suite > ----------------------- > > Key: SRAMP-168 > URL: https://issues.jboss.org/browse/SRAMP-168 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Distro > Reporter: Kurt Stam > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Adding a Technical Compatibility Kit. > - add examples from spec docs > - add tests to validate the implementation adheres to the spec -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 07:22:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 9 Jul 2014 07:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-462) Explore whether ElasticSearch server can be embedded into container (EAP) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-462: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/143 > Explore whether ElasticSearch server can be embedded into container (EAP) > ------------------------------------------------------------------------- > > Key: RTGOV-462 > URL: https://issues.jboss.org/browse/RTGOV-462 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Determine whether ElasticSearch could be embedded within EAP/Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 07:22:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 9 Jul 2014 07:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-462) Explore whether ElasticSearch server can be embedded into container (EAP) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-462. ------------------------------ Resolution: Done > Explore whether ElasticSearch server can be embedded into container (EAP) > ------------------------------------------------------------------------- > > Key: RTGOV-462 > URL: https://issues.jboss.org/browse/RTGOV-462 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Determine whether ElasticSearch could be embedded within EAP/Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 07:22:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 9 Jul 2014 07:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-346) Explore whether ElasticSearch server can be embedded into container (Karaf) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-346: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/143 > Explore whether ElasticSearch server can be embedded into container (Karaf) > --------------------------------------------------------------------------- > > Key: RTGOV-346 > URL: https://issues.jboss.org/browse/RTGOV-346 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Determine whether ElasticSearch could be embedded within EAP/Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 07:22:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 9 Jul 2014 07:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-346) Explore whether ElasticSearch server can be embedded into container (Karaf) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-346. ------------------------------ Resolution: Done > Explore whether ElasticSearch server can be embedded into container (Karaf) > --------------------------------------------------------------------------- > > Key: RTGOV-346 > URL: https://issues.jboss.org/browse/RTGOV-346 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: ivan mckinley > Fix For: 2.0.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Determine whether ElasticSearch could be embedded within EAP/Karaf. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 9 10:51:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Wed, 9 Jul 2014 10:51:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-521) Clarify the purpose of the Type processors defined in ip.json files In-Reply-To: References: Message-ID: ivan mckinley created RTGOV-521: ----------------------------------- Summary: Clarify the purpose of the Type processors defined in ip.json files Key: RTGOV-521 URL: https://issues.jboss.org/browse/RTGOV-521 Project: RTGov (Run Time Governance) Issue Type: Documentation Security Level: Public (Everyone can see) Components: Activity Collector Reporter: ivan mckinley Assignee: Gary Brown Priority: Minor Fix For: 2.0.0.Final Its not clear from the current documentation what the purpose of the TypeProcessors are. The documentation is a bit too detailed and verbose regarding what they do. recommend adding a general summary of what type processors do. ----------------- ------------------------------------------------------------- Activity events can optionally carry the message payload. It may not be desired to submit the entire message payload to Rtgov(security, load, size). Type processors allow you to define what specific data gets extracted from the message and submitted to Rtgov for processing. (correlationid, customerid, contractID etc) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 03:16:27 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 03:16:27 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-522) RTGovSituationsUtil.getSituationBean throws NPE In-Reply-To: References: Message-ID: ivan mckinley created RTGOV-522: ----------------------------------- Summary: RTGovSituationsUtil.getSituationBean throws NPE Key: RTGOV-522 URL: https://issues.jboss.org/browse/RTGOV-522 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Components: Activity Server Affects Versions: 2.0.0.Final Reporter: ivan mckinley Assignee: Gary Brown in RTGovSituationsUtil Line 61. A null pointer is thrown when calling context.getType().name(), - No check performed against the context.getType - The first item of the contextlist been iterated over has a context type of null, see [1] Reproduced by - Deploy SLA example - Execute the actvity client until situations are generated - Open the situation UI. The null pointer is invoked from here Additionaly place a break point on line 61 RTGovSituationsUtil [1]List of Contexts [Context[null:1:0], Context[Message:1-1-6:0], Context[Message:1-1-1:0]] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 03:20:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 03:20:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-522) RTGovSituationsUtil.getSituationBean throws NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983743#comment-12983743 ] ivan mckinley commented on RTGOV-522: ------------------------------------- Also, Review the contents of ES shows that the all situations in ES have the same problem with the context list. one entry does not have a type defined {"value":"81-81-1","type":"Message"}, {"value":"81"}, {"value":"81-81-6","type":"Message"} {"value":"52-52-1","type":"Message"}, {"value":"52"}, {"value":"52-52-6","type":"Message"} {"value":"24"}, {"value":"24-24-1","type":"Message"}, {"value":"24-24-6","type":"Message"} {"value":"7"}, {"value":"7-7-1","type":"Message"}, {"value":"7-7-6","type":"Message"} > RTGovSituationsUtil.getSituationBean throws NPE > ------------------------------------------------ > > Key: RTGOV-522 > URL: https://issues.jboss.org/browse/RTGOV-522 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > > in RTGovSituationsUtil Line 61. A null pointer is thrown when calling > context.getType().name(), > - No check performed against the context.getType > - The first item of the contextlist been iterated over has a context type of null, see [1] > Reproduced by > - Deploy SLA example > - Execute the actvity client until situations are generated > - Open the situation UI. The null pointer is invoked from here > Additionaly place a break point on line 61 RTGovSituationsUtil > [1]List of Contexts > [Context[null:1:0], Context[Message:1-1-6:0], Context[Message:1-1-1:0]] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 03:38:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 03:38:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-522) RTGovSituationsUtil.getSituationBean throws NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983745#comment-12983745 ] ivan mckinley commented on RTGOV-522: ------------------------------------- it would appear the Activity client data is at fault! The templates in activity client which generate the data have an extra context value, without a type entry. Removing this extra entry fixes the issue. [~objectiser] is extra context value intetend ====== from ===== [{ "type":"RequestReceived", "interface":"{urn:switchyard-quickstart-demo:orders:1.0}OrderService", "operation":"submitOrder", "serviceType":"{urn:switchyard-quickstart-demo:orders:0.1.0}OrderService", "messageType":"{urn:switchyard-quickstart-demo:orders:1.0}submitOrder", "context":[{ "value":"{ID}-1", "type":"Message" },{ "value":"{ID}" }], "properties":{ "item":"JAM", "customer":"{CUSTOMER}" } } ======= to ========= [{ "type":"RequestReceived", "interface":"{urn:switchyard-quickstart-demo:orders:1.0}OrderService", "operation":"submitOrder", "serviceType":"{urn:switchyard-quickstart-demo:orders:0.1.0}OrderService", "messageType":"{urn:switchyard-quickstart-demo:orders:1.0}submitOrder", "context":[{ "value":"{ID}-1", "type":"Message" }], "properties":{ "item":"JAM", "customer":"{CUSTOMER}" } } > RTGovSituationsUtil.getSituationBean throws NPE > ------------------------------------------------ > > Key: RTGOV-522 > URL: https://issues.jboss.org/browse/RTGOV-522 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > > in RTGovSituationsUtil Line 61. A null pointer is thrown when calling > context.getType().name(), > - No check performed against the context.getType > - The first item of the contextlist been iterated over has a context type of null, see [1] > Reproduced by > - Deploy SLA example > - Execute the actvity client until situations are generated > - Open the situation UI. The null pointer is invoked from here > Additionaly place a break point on line 61 RTGovSituationsUtil > [1]List of Contexts > [Context[null:1:0], Context[Message:1-1-6:0], Context[Message:1-1-1:0]] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 04:04:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 04:04:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-522) RTGovSituationsUtil.getSituationBean throws NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley reassigned RTGOV-522: ----------------------------------- Assignee: ivan mckinley (was: Gary Brown) > RTGovSituationsUtil.getSituationBean throws NPE > ------------------------------------------------ > > Key: RTGOV-522 > URL: https://issues.jboss.org/browse/RTGOV-522 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: ivan mckinley > > in RTGovSituationsUtil Line 61. A null pointer is thrown when calling > context.getType().name(), > - No check performed against the context.getType > - The first item of the contextlist been iterated over has a context type of null, see [1] > Reproduced by > - Deploy SLA example > - Execute the actvity client until situations are generated > - Open the situation UI. The null pointer is invoked from here > Additionaly place a break point on line 61 RTGovSituationsUtil > [1]List of Contexts > [Context[null:1:0], Context[Message:1-1-6:0], Context[Message:1-1-1:0]] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 04:33:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 04:33:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-522) RTGovSituationsUtil.getSituationBean throws NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983769#comment-12983769 ] Gary Brown commented on RTGOV-522: ---------------------------------- Hi Ivan Thanks for finding the original problem. In RTGov 1.0 the context type had a default value of 'Conversation' - so in these cases the json serialized representing didn't include the type field for any Context object with type=Conversation. Although this reduced the size of the serialized representation (as it didn't include unnecessary default values), the json representation wasn't as clear. Therefore it was changed to remove the default value - so the sample data needs to be updated to explicitly include the conversation type. The initial npe also needs a guard, as if RTGov 2 is reading json serialized data produced by RTGov 1, then it may still find a null type. > RTGovSituationsUtil.getSituationBean throws NPE > ------------------------------------------------ > > Key: RTGOV-522 > URL: https://issues.jboss.org/browse/RTGOV-522 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: ivan mckinley > > in RTGovSituationsUtil Line 61. A null pointer is thrown when calling > context.getType().name(), > - No check performed against the context.getType > - The first item of the contextlist been iterated over has a context type of null, see [1] > Reproduced by > - Deploy SLA example > - Execute the actvity client until situations are generated > - Open the situation UI. The null pointer is invoked from here > Additionaly place a break point on line 61 RTGovSituationsUtil > [1]List of Contexts > [Context[null:1:0], Context[Message:1-1-6:0], Context[Message:1-1-1:0]] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 05:29:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 05:29:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-393) DroolsEventProcessor. Support Drools STREAM and CLOUD event processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-393: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/147 > DroolsEventProcessor. Support Drools STREAM and CLOUD event processing > ---------------------------------------------------------------------- > > Key: RTGOV-393 > URL: https://issues.jboss.org/browse/RTGOV-393 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Event Processor > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When attempting to using sliding window rules, see[1]. Results in a runtime exception as the DroolsEventprocessor does not support a Stream of events. > Recommend fix is making the DroolsEventprocessor configurable from the EPN to use either stream or cloud. > http://docs.jboss.org/jbpm/v6.0.1/javadocs/org/kie/api/builder/model/KieBaseModel.html#setEventProcessingMode(org.kie.api.conf.EventProcessingOption) > Browsing through the history shows this functionality was removed. > https://github.com/Governance/rtgov/commit/43c81c8a4a1702ad43ec42a9dff7be8ae57018fd#diff-f6be73565fb61bfda14a8ad1165ee70e > [1] > rule "Sliding widow rule" > when > Number( doubleValue > 2 ) from accumulate( > Situation( $t : properties["customer"] == 'Ivan' ) over window:time( 5m ) , count($t) > ) > then > epc.logError("\r\n\r\n**** SUPERRRRRRRR ****\r\n"); > end > [2] > 14:20:42,970 SEVERE [org.overlord.rtgov.ep.drools.DroolsEventProcessor] (ServerService Thread Pool -- 88) Failed to load Drools rules 'timeWindow.drl' for Event Processor 'timeWindow': java.lang.RuntimeException: The requested KieBase "defaultKieBase" has been set to run in CLOUD mode but requires features only available in STREAM mode > at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:258) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:204) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:193) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:199) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.createSession(DroolsEventProcessor.java:146) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.init(DroolsEventProcessor.java:56) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Node.init(Node.java:229) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Network.preInit(Network.java:202) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.AbstractEPNLoader.preInit(AbstractEPNLoader.java:34) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.internal.epn.loader.jee.JEEEPNLoader.init(JEEEPNLoader.java:92) [epn-loader-jee-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [classes.jar:1.6.0_65] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [classes.jar:1.6.0_65] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [classes.jar:1.6.0_65] > at java.lang.reflect.Method.invoke(Method.java:597) [classes.jar:1.6.0_65] > at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:248) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:344) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:66) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:126) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:141) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [classes.jar:1.6.0_65] > at java.lang.Thread.run(Thread.java:695) [classes.jar:1.6.0_65] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > 14:20:43,022 SEVERE [org.overlord.rtgov.internal.epn.loader.jee.JEEEPNLoader] (ServerService Thread Pool -- 88) Failed to register network: java.lang.Exception: Failed to load Drools rules 'timeWindow.drl' for Event Processor 'timeWindow' > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:209) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.createSession(DroolsEventProcessor.java:146) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.init(DroolsEventProcessor.java:56) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Node.init(Node.java:229) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Network.preInit(Network.java:202) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.AbstractEPNLoader.preInit(AbstractEPNLoader.java:34) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.internal.epn.loader.jee.JEEEPNLoader.init(JEEEPNLoader.java:92) [epn-loader-jee-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [classes.jar:1.6.0_65] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [classes.jar:1.6.0_65] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [classes.jar:1.6.0_65] > at java.lang.reflect.Method.invoke(Method.java:597) [classes.jar:1.6.0_65] > at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:248) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:344) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:66) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:126) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:141) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [classes.jar:1.6.0_65] > at java.lang.Thread.run(Thread.java:695) [classes.jar:1.6.0_65] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > Caused by: java.lang.RuntimeException: The requested KieBase "defaultKieBase" has been set to run in CLOUD mode but requires features only available in STREAM mode > at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:258) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:204) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:193) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:199) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > ... 43 more -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 05:31:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 05:31:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-393) DroolsEventProcessor. Support Drools STREAM and CLOUD event processing In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-393. ------------------------------ Resolution: Done Added properties for 'eventProcessingMode' (default cloud, other valid value is 'stream'), 'asynchronous' (default is 'false') and 'clockType' (default and only valid value currently is 'realtime'). > DroolsEventProcessor. Support Drools STREAM and CLOUD event processing > ---------------------------------------------------------------------- > > Key: RTGOV-393 > URL: https://issues.jboss.org/browse/RTGOV-393 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Event Processor > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When attempting to using sliding window rules, see[1]. Results in a runtime exception as the DroolsEventprocessor does not support a Stream of events. > Recommend fix is making the DroolsEventprocessor configurable from the EPN to use either stream or cloud. > http://docs.jboss.org/jbpm/v6.0.1/javadocs/org/kie/api/builder/model/KieBaseModel.html#setEventProcessingMode(org.kie.api.conf.EventProcessingOption) > Browsing through the history shows this functionality was removed. > https://github.com/Governance/rtgov/commit/43c81c8a4a1702ad43ec42a9dff7be8ae57018fd#diff-f6be73565fb61bfda14a8ad1165ee70e > [1] > rule "Sliding widow rule" > when > Number( doubleValue > 2 ) from accumulate( > Situation( $t : properties["customer"] == 'Ivan' ) over window:time( 5m ) , count($t) > ) > then > epc.logError("\r\n\r\n**** SUPERRRRRRRR ****\r\n"); > end > [2] > 14:20:42,970 SEVERE [org.overlord.rtgov.ep.drools.DroolsEventProcessor] (ServerService Thread Pool -- 88) Failed to load Drools rules 'timeWindow.drl' for Event Processor 'timeWindow': java.lang.RuntimeException: The requested KieBase "defaultKieBase" has been set to run in CLOUD mode but requires features only available in STREAM mode > at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:258) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:204) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:193) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:199) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.createSession(DroolsEventProcessor.java:146) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.init(DroolsEventProcessor.java:56) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Node.init(Node.java:229) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Network.preInit(Network.java:202) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.AbstractEPNLoader.preInit(AbstractEPNLoader.java:34) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.internal.epn.loader.jee.JEEEPNLoader.init(JEEEPNLoader.java:92) [epn-loader-jee-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [classes.jar:1.6.0_65] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [classes.jar:1.6.0_65] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [classes.jar:1.6.0_65] > at java.lang.reflect.Method.invoke(Method.java:597) [classes.jar:1.6.0_65] > at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:248) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:344) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:66) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:126) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:141) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [classes.jar:1.6.0_65] > at java.lang.Thread.run(Thread.java:695) [classes.jar:1.6.0_65] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > 14:20:43,022 SEVERE [org.overlord.rtgov.internal.epn.loader.jee.JEEEPNLoader] (ServerService Thread Pool -- 88) Failed to register network: java.lang.Exception: Failed to load Drools rules 'timeWindow.drl' for Event Processor 'timeWindow' > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:209) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.createSession(DroolsEventProcessor.java:146) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.init(DroolsEventProcessor.java:56) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Node.init(Node.java:229) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.Network.preInit(Network.java:202) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.epn.AbstractEPNLoader.preInit(AbstractEPNLoader.java:34) [epn-core-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at org.overlord.rtgov.internal.epn.loader.jee.JEEEPNLoader.init(JEEEPNLoader.java:92) [epn-loader-jee-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [classes.jar:1.6.0_65] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [classes.jar:1.6.0_65] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [classes.jar:1.6.0_65] > at java.lang.reflect.Method.invoke(Method.java:597) [classes.jar:1.6.0_65] > at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptorFactory$ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptorFactory.java:130) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:73) [jboss-as-weld-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.ManagedReferenceInterceptorFactory$ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptorFactory.java:95) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:248) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:344) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:66) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.2.Final-redhat-1.jar:1.1.2.Final-redhat-1] > at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:126) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:141) [jboss-as-ejb3-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54) [jboss-as-ee-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:439) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [classes.jar:1.6.0_65] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) [classes.jar:1.6.0_65] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) [classes.jar:1.6.0_65] > at java.lang.Thread.run(Thread.java:695) [classes.jar:1.6.0_65] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > Caused by: java.lang.RuntimeException: The requested KieBase "defaultKieBase" has been set to run in CLOUD mode but requires features only available in STREAM mode > at org.drools.compiler.kie.builder.impl.KieContainerImpl.createKieBase(KieContainerImpl.java:258) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:204) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:193) [drools-compiler-6.0.0-redhat-9.jar:6.0.0-redhat-9] > at org.overlord.rtgov.ep.drools.DroolsEventProcessor.loadRuleBase(DroolsEventProcessor.java:199) [ep-drools-1.0.1.Final-redhat-4.jar:1.0.1.Final-redhat-4] > ... 43 more -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 05:45:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 05:45:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-522) RTGovSituationsUtil.getSituationBean throws NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-522: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/146 > RTGovSituationsUtil.getSituationBean throws NPE > ------------------------------------------------ > > Key: RTGOV-522 > URL: https://issues.jboss.org/browse/RTGOV-522 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: ivan mckinley > > in RTGovSituationsUtil Line 61. A null pointer is thrown when calling > context.getType().name(), > - No check performed against the context.getType > - The first item of the contextlist been iterated over has a context type of null, see [1] > Reproduced by > - Deploy SLA example > - Execute the actvity client until situations are generated > - Open the situation UI. The null pointer is invoked from here > Additionaly place a break point on line 61 RTGovSituationsUtil > [1]List of Contexts > [Context[null:1:0], Context[Message:1-1-6:0], Context[Message:1-1-1:0]] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 05:45:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 05:45:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-522) RTGovSituationsUtil.getSituationBean throws NPE In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-522. ------------------------------ Resolution: Done > RTGovSituationsUtil.getSituationBean throws NPE > ------------------------------------------------ > > Key: RTGOV-522 > URL: https://issues.jboss.org/browse/RTGOV-522 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: ivan mckinley > > in RTGovSituationsUtil Line 61. A null pointer is thrown when calling > context.getType().name(), > - No check performed against the context.getType > - The first item of the contextlist been iterated over has a context type of null, see [1] > Reproduced by > - Deploy SLA example > - Execute the actvity client until situations are generated > - Open the situation UI. The null pointer is invoked from here > Additionaly place a break point on line 61 RTGovSituationsUtil > [1]List of Contexts > [Context[null:1:0], Context[Message:1-1-6:0], Context[Message:1-1-1:0]] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 06:53:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 06:53:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-444) Swiitchyard services integration test fails due to missing JMS queue In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-444: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Swiitchyard services integration test fails due to missing JMS queue > -------------------------------------------------------------------- > > Key: RTGOV-444 > URL: https://issues.jboss.org/browse/RTGOV-444 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Appears that the multi-app switchyard demo has changed and now requires a JMS queue to be configured. Have disabled the tests until a suitable solution can be found. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 06:55:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 06:55:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-459) Call Trace integration test not working with Elasticsearch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-459: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Call Trace integration test not working with Elasticsearch > ---------------------------------------------------------- > > Key: RTGOV-459 > URL: https://issues.jboss.org/browse/RTGOV-459 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Following change to use Elasticsearch as the default activity store (RTGOV-439), the call trace integration test "testCallTraceWithException" causes itself and the other test in the class to stop working. If this test is ignored, then the other test works. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:11:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 07:11:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-484) IOException in SPFilter when authenticating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-484 started by Eric Wittmann. > IOException in SPFilter when authenticating > ------------------------------------------- > > Key: SRAMP-484 > URL: https://issues.jboss.org/browse/SRAMP-484 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > {noformat} > 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | > javax.servlet.ServletException: java.io.IOException: Closed > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > Caused by: java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > ... 28 more > 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error > java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:47:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 07:47:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-484) IOException in SPFilter when authenticating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-484: -------------------------------- Description: {noformat} 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | javax.servlet.ServletException: java.io.IOException: Closed at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] Caused by: java.io.IOException: Closed at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] ... 28 more 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error java.io.IOException: Closed at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] {noformat} was: {noformat} 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | javax.servlet.ServletException: java.io.IOException: Closed at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] Caused by: java.io.IOException: Closed at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] ... 28 more 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error java.io.IOException: Closed at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] {noformat} Git Pull Request: https://github.com/Governance/overlord-commons/pull/82, https://github.com/Governance/s-ramp/pull/450, https://github.com/Governance/dtgov/pull/199 > IOException in SPFilter when authenticating > ------------------------------------------- > > Key: SRAMP-484 > URL: https://issues.jboss.org/browse/SRAMP-484 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > {noformat} > 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | > javax.servlet.ServletException: java.io.IOException: Closed > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > Caused by: java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > ... 28 more > 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error > java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:47:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 07:47:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-484) IOException in SPFilter when authenticating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-484. --------------------------------- Resolution: Done There was a bug in the picketlink PostBindingUtil class which was responsible for writing an HTML snippet to the http response object. It was not setting the content-length properly (it was one byte too small). For this reason the browser was hanging up before the final byte was written and causing the stack trace. > IOException in SPFilter when authenticating > ------------------------------------------- > > Key: SRAMP-484 > URL: https://issues.jboss.org/browse/SRAMP-484 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > {noformat} > 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | > javax.servlet.ServletException: java.io.IOException: Closed > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > Caused by: java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > ... 28 more > 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error > java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:49:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 07:49:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-484) IOException in SPFilter when authenticating In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-484. ------------------------------- > IOException in SPFilter when authenticating > ------------------------------------------- > > Key: SRAMP-484 > URL: https://issues.jboss.org/browse/SRAMP-484 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > {noformat} > 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | > javax.servlet.ServletException: java.io.IOException: Closed > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > Caused by: java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > ... 28 more > 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error > java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 07:49:26 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 07:49:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-485) Remove s-ramp-ui-widgets project In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-485 started by Eric Wittmann. > Remove s-ramp-ui-widgets project > -------------------------------- > > Key: SRAMP-485 > URL: https://issues.jboss.org/browse/SRAMP-485 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > Move the last of the s-ramp-ui-widgets code (only a single class now) into overlord-commons and remove this project. > Note: the class *may* be used in dtgov-ui and/or rtgov-ui. Verify prior to moving. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 09:25:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 09:25:29 -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: Eric Wittmann created SRAMP-504: ----------------------------------- Summary: 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 Security Level: Public (Everyone can see) 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.2.6#6264) From issues at jboss.org Thu Jul 10 09:29:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 09:29:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-485) Remove s-ramp-ui-widgets project In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-485: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/83, https://github.com/Governance/s-ramp/pull/451, https://github.com/Governance/dtgov/pull/200 > Remove s-ramp-ui-widgets project > -------------------------------- > > Key: SRAMP-485 > URL: https://issues.jboss.org/browse/SRAMP-485 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > Move the last of the s-ramp-ui-widgets code (only a single class now) into overlord-commons and remove this project. > Note: the class *may* be used in dtgov-ui and/or rtgov-ui. Verify prior to moving. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 09:29:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 09:29:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-485) Remove s-ramp-ui-widgets project In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-485. --------------------------------- Resolution: Done > Remove s-ramp-ui-widgets project > -------------------------------- > > Key: SRAMP-485 > URL: https://issues.jboss.org/browse/SRAMP-485 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > Move the last of the s-ramp-ui-widgets code (only a single class now) into overlord-commons and remove this project. > Note: the class *may* be used in dtgov-ui and/or rtgov-ui. Verify prior to moving. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 09:29:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 09:29:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-485) Remove s-ramp-ui-widgets project In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-485. ------------------------------- > Remove s-ramp-ui-widgets project > -------------------------------- > > Key: SRAMP-485 > URL: https://issues.jboss.org/browse/SRAMP-485 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > Move the last of the s-ramp-ui-widgets code (only a single class now) into overlord-commons and remove this project. > Note: the class *may* be used in dtgov-ui and/or rtgov-ui. Verify prior to moving. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 10:10:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 10:10:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-445) SSO not working on Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-445 stopped by Eric Wittmann. > SSO not working on Tomcat > ------------------------- > > Key: SRAMP-445 > URL: https://issues.jboss.org/browse/SRAMP-445 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce: > 1) run both s-ramp and dtgov on tomcat > 2) open browser, navigate to s-ramp-ui > 3) log in > 4) click on Design Time Governance > At this point you will have to authenticate again. This is wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 10:26:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 10:26:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-445) SSO not working on Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983943#comment-12983943 ] Gary Brown commented on SRAMP-445: ---------------------------------- Would it be worth logging the bug with a simple test case on the tomcat jira to see whether there are any suggestions? Although it is unlikely to get fixed quickly - so are there any other interim solutions, even if not so user friendly? like going back to form authentication per project? > SSO not working on Tomcat > ------------------------- > > Key: SRAMP-445 > URL: https://issues.jboss.org/browse/SRAMP-445 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce: > 1) run both s-ramp and dtgov on tomcat > 2) open browser, navigate to s-ramp-ui > 3) log in > 4) click on Design Time Governance > At this point you will have to authenticate again. This is wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 10:30:27 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 10:30:27 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-523) Situation Call trace UI shows traces for all situations in system In-Reply-To: References: Message-ID: ivan mckinley created RTGOV-523: ----------------------------------- Summary: Situation Call trace UI shows traces for all situations in system Key: RTGOV-523 URL: https://issues.jboss.org/browse/RTGOV-523 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Components: User Interface Affects Versions: 2.0.0.Final Reporter: ivan mckinley Assignee: Gary Brown See screenshot. Reproduce - build and deploy ordermanagement example - build and deploy SLA example -in the order managemen app/ folder run the order3 which generates SLA situations mvn exec:java -Dreq=order3 -Dcount=10 Naviate to the situation UI and select any of the 10 SLAs show. the call trace of the selected situation shows call traces of other situations see screen shot -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 10:32:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 10:32:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-523) Situation Call trace UI shows traces for all situations in system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-523: -------------------------------- Attachment: screenshot-1.png > Situation Call trace UI shows traces for all situations in system > ------------------------------------------------------------------ > > Key: RTGOV-523 > URL: https://issues.jboss.org/browse/RTGOV-523 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > > See screenshot. > Reproduce > - build and deploy ordermanagement example > - build and deploy SLA example > -in the order managemen app/ folder run the order3 which generates SLA situations > mvn exec:java -Dreq=order3 -Dcount=10 > Naviate to the situation UI and select any of the 10 SLAs show. the call trace of the selected situation shows call traces of other situations > see screen shot -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 10:32:25 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 10:32:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-523) Situation Call trace UI shows traces for all situations in system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-523: -------------------------------- Attachment: (was: screenshot-1.png) > Situation Call trace UI shows traces for all situations in system > ------------------------------------------------------------------ > > Key: RTGOV-523 > URL: https://issues.jboss.org/browse/RTGOV-523 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > > See screenshot. > Reproduce > - build and deploy ordermanagement example > - build and deploy SLA example > -in the order managemen app/ folder run the order3 which generates SLA situations > mvn exec:java -Dreq=order3 -Dcount=10 > Naviate to the situation UI and select any of the 10 SLAs show. the call trace of the selected situation shows call traces of other situations > see screen shot -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 10:34:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 10:34:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-523) Situation Call trace UI shows traces for all situations in system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-523: -------------------------------- Attachment: calltrace.png > Situation Call trace UI shows traces for all situations in system > ------------------------------------------------------------------ > > Key: RTGOV-523 > URL: https://issues.jboss.org/browse/RTGOV-523 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Attachments: calltrace.png > > > See screenshot. > Reproduce > - build and deploy ordermanagement example > - build and deploy SLA example > -in the order managemen app/ folder run the order3 which generates SLA situations > mvn exec:java -Dreq=order3 -Dcount=10 > Naviate to the situation UI and select any of the 10 SLAs show. the call trace of the selected situation shows call traces of other situations > see screen shot -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 11:23:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 11:23:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-445) SSO not working on Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983975#comment-12983975 ] Eric Wittmann commented on SRAMP-445: ------------------------------------- Yeah it's on my to-do list to create a standalone reproducer and then log a bug for tomcat. I don't know how hard that will be. However, to be clear the impact of this is that the user has to authenticate separately for each project (s-ramp, dtgov, rtgov). It does not *prevent* authentication at the moment. It may also mean that users will need to re-authenticate when their (e.g.) s-ramp UI session expires. These sessions don't expire easily, however, due to errai chattiness. For this reason I think we can defer this. However, if we think this is critical for the next Overlord release then I suggest we revert the IDP and SPs to their Tomcat Valve-specific implementations. This requires changes to the various WARs as well as the installer (as mentioned earlier). > SSO not working on Tomcat > ------------------------- > > Key: SRAMP-445 > URL: https://issues.jboss.org/browse/SRAMP-445 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce: > 1) run both s-ramp and dtgov on tomcat > 2) open browser, navigate to s-ramp-ui > 3) log in > 4) click on Design Time Governance > At this point you will have to authenticate again. This is wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 11:55:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 11:55:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-445) SSO not working on Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983982#comment-12983982 ] Gary Brown commented on SRAMP-445: ---------------------------------- My vote is to leave as is - it is inconvenient to log into the separate project UIs, but not a show stopper, especially when a lot of users may only be using a single project. > SSO not working on Tomcat > ------------------------- > > Key: SRAMP-445 > URL: https://issues.jboss.org/browse/SRAMP-445 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce: > 1) run both s-ramp and dtgov on tomcat > 2) open browser, navigate to s-ramp-ui > 3) log in > 4) click on Design Time Governance > At this point you will have to authenticate again. This is wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 11:59:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 10 Jul 2014 11:59:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-523) Situation Call trace UI shows traces for all situations in system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-523. ------------------------------ Resolution: Rejected Sorry Ivan, I should have checked more details before asking you to raise an issue. The call trace is built up based on correlation between activities. In this case, you have generated 10 business transactions with the same 'conversation' id (i.e. orderId = 3), and therefore from the call trace perspective, they are all part of the same business transaction. > Situation Call trace UI shows traces for all situations in system > ------------------------------------------------------------------ > > Key: RTGOV-523 > URL: https://issues.jboss.org/browse/RTGOV-523 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Attachments: calltrace.png > > > See screenshot. > Reproduce > - build and deploy ordermanagement example > - build and deploy SLA example > -in the order managemen app/ folder run the order3 which generates SLA situations > mvn exec:java -Dreq=order3 -Dcount=10 > Naviate to the situation UI and select any of the 10 SLAs show. the call trace of the selected situation shows call traces of other situations > see screen shot -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 12:03:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Thu, 10 Jul 2014 12:03:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-523) Situation Call trace UI shows traces for all situations in system In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983991#comment-12983991 ] ivan mckinley commented on RTGOV-523: ------------------------------------- gotcha, .. Guess I should be generating random data :) > Situation Call trace UI shows traces for all situations in system > ------------------------------------------------------------------ > > Key: RTGOV-523 > URL: https://issues.jboss.org/browse/RTGOV-523 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Attachments: calltrace.png > > > See screenshot. > Reproduce > - build and deploy ordermanagement example > - build and deploy SLA example > -in the order managemen app/ folder run the order3 which generates SLA situations > mvn exec:java -Dreq=order3 -Dcount=10 > Naviate to the situation UI and select any of the 10 SLAs show. the call trace of the selected situation shows call traces of other situations > see screen shot -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 10 13:29:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 10 Jul 2014 13:29:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-505) maven:deploy CLI command missing maven.type property sometimes In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-505: ----------------------------------- Summary: maven:deploy CLI command missing maven.type property sometimes Key: SRAMP-505 URL: https://issues.jboss.org/browse/SRAMP-505 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: Shell Reporter: Eric Wittmann Assignee: David virgil naranjo Fix For: 0.5.0 The maven:deploy s-ramp cli command does not currently set the maven.type property under all circumstances. A requirement is that maven.type always be set. Currently the CLI command gets this information from the arguments to the command. In some cases the user will not include the "type" information on the command line. In this case the type should be pulled from the file extension of the file being uploaded. If the file being uploaded does *not* have an extension and the maven.type is not provided as part of the GAV argument, then the command should fail. Note: the name of the artifact should also include the file's extension - this is currently being left off. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 04:50:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 04:50:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-451) Support deployment on Karaf3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-451: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Support deployment on Karaf3 > ---------------------------- > > Key: RTGOV-451 > URL: https://issues.jboss.org/browse/RTGOV-451 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 04:50:27 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 04:50:27 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-453) Create JPA EPN integration test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-453: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Create JPA EPN integration test > ------------------------------- > > Key: RTGOV-453 > URL: https://issues.jboss.org/browse/RTGOV-453 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > RTGOV-374 improved JPA/ORM support, including the ability for an EPN to pass either a JPA persistence.xml or a native Hibernate hibernate.cfg.xml. This is unit tested, but needs incorporated into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 04:52:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 04:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-336) Combine activities recorded across multiple threads In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-336: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Combine activities recorded across multiple threads > --------------------------------------------------- > > Key: RTGOV-336 > URL: https://issues.jboss.org/browse/RTGOV-336 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Minor > Fix For: 2.1.0.Final > > Original Estimate: 2 days > Remaining Estimate: 2 days > > When capturing activity events via proxies in JBoss Fuse, found that when a service returned an exception, it was handled in a separate thread. > This resulted in two separate activity units, one for the activities up until the exception, and the other for the activities following the exception. > This will cause issues with correlation currently, where request/response pairs are expected to be in the same activity unit. > Two possible solutions: > (1) work on the correlation of requests/responses across activity units - which will be useful in a wider range of cases. > (2) enable activities across multiple threads to be combined - i.e. if a subsequent thread is new, allow its relationship with a previous activity event (e.g. the request) to link it to the same activity unit. Not sure of the implications on the API for this. > This work is related to RTGOV-325. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 04:54:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 04:54:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-520) Set "not_analyzed" as the default setting for fields added to rtgov. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-520: ----------------------------- Parent: (was: RTGOV-419) Issue Type: Enhancement (was: Sub-task) > Set "not_analyzed" as the default setting for fields added to rtgov. > --------------------------------------------------------------------- > > Key: RTGOV-520 > URL: https://issues.jboss.org/browse/RTGOV-520 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: ivan mckinley > Assignee: ivan mckinley > Priority: Minor > Fix For: 2.0.0.Final > > > In rtgov-mapping.json. have the mapping set all fields to Not_analyzed. this avoids the issue outlined in https://issues.jboss.org/browse/RTGOV-461 > in there are mappings that required the field to be analyzed then they should be explicitly configured. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 04:54:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 04:54:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-520) Set "not_analyzed" as the default setting for fields added to rtgov. In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-520: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Set "not_analyzed" as the default setting for fields added to rtgov. > --------------------------------------------------------------------- > > Key: RTGOV-520 > URL: https://issues.jboss.org/browse/RTGOV-520 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: ivan mckinley > Assignee: ivan mckinley > Priority: Minor > Fix For: 2.1.0.Final > > > In rtgov-mapping.json. have the mapping set all fields to Not_analyzed. this avoids the issue outlined in https://issues.jboss.org/browse/RTGOV-461 > in there are mappings that required the field to be analyzed then they should be explicitly configured. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 05:10:25 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Fri, 11 Jul 2014 05:10:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-524) Drools processor : Steam mode does handle results of async rule activation In-Reply-To: References: Message-ID: ivan mckinley created RTGOV-524: ----------------------------------- Summary: Drools processor : Steam mode does handle results of async rule activation Key: RTGOV-524 URL: https://issues.jboss.org/browse/RTGOV-524 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Components: Event Processor Affects Versions: 2.0.0.Final Reporter: ivan mckinley Assignee: Gary Brown When a sliding rule is defined of Steam mode and Async Mode of the droolsEventprocessor. Rule is activated but the handling of the results fails with a NPE. NPE traced back to the Node object responsible for handling the forward of the serialized object as the passed in _container object is null; See, https://issues.jboss.org/browse/RTGOV-393 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 05:12:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Fri, 11 Jul 2014 05:12:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-524) Drools processor : Steam mode does handle results of async rule activation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-524: -------------------------------- Attachment: ordermgmt-demo.zip simple quick start > Drools processor : Steam mode does handle results of async rule activation > --------------------------------------------------------------------------- > > Key: RTGOV-524 > URL: https://issues.jboss.org/browse/RTGOV-524 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Attachments: ordermgmt-demo.zip > > > When a sliding rule is defined of Steam mode and Async Mode of the droolsEventprocessor. Rule is activated but the handling of the results fails with a NPE. > NPE traced back to the Node object responsible for handling the forward of the serialized object as the passed in _container object is null; > See, > https://issues.jboss.org/browse/RTGOV-393 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 05:16:30 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Fri, 11 Jul 2014 05:16:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-524) Drools processor : Steam mode does not handle results of async rule activation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ivan mckinley updated RTGOV-524: -------------------------------- Summary: Drools processor : Steam mode does not handle results of async rule activation (was: Drools processor : Steam mode does handle results of async rule activation ) > Drools processor : Steam mode does not handle results of async rule activation > ------------------------------------------------------------------------------- > > Key: RTGOV-524 > URL: https://issues.jboss.org/browse/RTGOV-524 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Attachments: ordermgmt-demo.zip > > > When a sliding rule is defined of Steam mode and Async Mode of the droolsEventprocessor. Rule is activated but the handling of the results fails with a NPE. > NPE traced back to the Node object responsible for handling the forward of the serialized object as the passed in _container object is null; > See, > https://issues.jboss.org/browse/RTGOV-393 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 05:24:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 05:24:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-480) Refactor out bridging UI classes from EAP6 UI into separate module that can be included in Fuse and FSW60 UI wars In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-480: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/148 > Refactor out bridging UI classes from EAP6 UI into separate module that can be included in Fuse and FSW60 UI wars > ----------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-480 > URL: https://issues.jboss.org/browse/RTGOV-480 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently ServicesProviderServiceImpl, SituationEventGenerator and SituationsProviderServiceImpl are duplicated in EAP6, Fuse6 and FSW60 UI wars - need to refactor into shared module. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 05:24:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 05:24:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-480) Refactor out bridging UI classes from EAP6 UI into separate module that can be included in Fuse and FSW60 UI wars In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-480. ------------------------------ Resolution: Done > Refactor out bridging UI classes from EAP6 UI into separate module that can be included in Fuse and FSW60 UI wars > ----------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-480 > URL: https://issues.jboss.org/browse/RTGOV-480 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently ServicesProviderServiceImpl, SituationEventGenerator and SituationsProviderServiceImpl are duplicated in EAP6, Fuse6 and FSW60 UI wars - need to refactor into shared module. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 05:26:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 05:26:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-524) Drools processor : Steam mode does not handle results of async rule activation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-524: ----------------------------- Fix Version/s: 2.0.0.Final > Drools processor : Steam mode does not handle results of async rule activation > ------------------------------------------------------------------------------- > > Key: RTGOV-524 > URL: https://issues.jboss.org/browse/RTGOV-524 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: ordermgmt-demo.zip > > > When a sliding rule is defined of Steam mode and Async Mode of the droolsEventprocessor. Rule is activated but the handling of the results fails with a NPE. > NPE traced back to the Node object responsible for handling the forward of the serialized object as the passed in _container object is null; > See, > https://issues.jboss.org/browse/RTGOV-393 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 06:39:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 06:39:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-521) Clarify the purpose of the Type processors defined in ip.json files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-521. ------------------------------ Resolution: Done The updated description can be found on the source wiki page, in the Integrated Activity Collector/Information Processor section: https://github.com/Governance/rtgov/wiki/UGReportActivityInformation > Clarify the purpose of the Type processors defined in ip.json files > ------------------------------------------------------------------- > > Key: RTGOV-521 > URL: https://issues.jboss.org/browse/RTGOV-521 > Project: RTGov (Run Time Governance) > Issue Type: Documentation > Security Level: Public(Everyone can see) > Components: Activity Collector > Reporter: ivan mckinley > Assignee: Gary Brown > Priority: Minor > Fix For: 2.0.0.Final > > > Its not clear from the current documentation what the purpose of the TypeProcessors are. The documentation is a bit too detailed and verbose regarding what they do. > recommend adding a general summary of what type processors do. > ----------------- ------------------------------------------------------------- > Activity events can optionally carry the message payload. It may not be desired to submit the entire message payload to Rtgov(security, load, size). Type processors allow you to define what specific data gets extracted from the message and submitted to Rtgov for processing. (correlationid, customerid, contractID etc) > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 06:39:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 11 Jul 2014 06:39:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-506: ------------------------------------------ Summary: Maven repository facade. Add extended type Key: SRAMP-506 URL: https://issues.jboss.org/browse/SRAMP-506 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) 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.2.6#6264) From issues at jboss.org Fri Jul 11 06:51:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 06:51:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-524) Drools processor : Steam mode does not handle results of async rule activation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-524: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/149 > Drools processor : Steam mode does not handle results of async rule activation > ------------------------------------------------------------------------------- > > Key: RTGOV-524 > URL: https://issues.jboss.org/browse/RTGOV-524 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: ordermgmt-demo.zip > > > When a sliding rule is defined of Steam mode and Async Mode of the droolsEventprocessor. Rule is activated but the handling of the results fails with a NPE. > NPE traced back to the Node object responsible for handling the forward of the serialized object as the passed in _container object is null; > See, > https://issues.jboss.org/browse/RTGOV-393 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 06:51:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 06:51:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-524) Drools processor : Steam mode does not handle results of async rule activation In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-524. ------------------------------ Resolution: Done > Drools processor : Steam mode does not handle results of async rule activation > ------------------------------------------------------------------------------- > > Key: RTGOV-524 > URL: https://issues.jboss.org/browse/RTGOV-524 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 2.0.0.Final > Reporter: ivan mckinley > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: ordermgmt-demo.zip > > > When a sliding rule is defined of Steam mode and Async Mode of the droolsEventprocessor. Rule is activated but the handling of the results fails with a NPE. > NPE traced back to the Node object responsible for handling the forward of the serialized object as the passed in _container object is null; > See, > https://issues.jboss.org/browse/RTGOV-393 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 06:55:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 06:55:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-525) Resubmit function for sample order app no longer working In-Reply-To: References: Message-ID: Gary Brown created RTGOV-525: -------------------------------- Summary: Resubmit function for sample order app no longer working Key: RTGOV-525 URL: https://issues.jboss.org/browse/RTGOV-525 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When issuing the 'order5bad' request from the ordermgmt/app, it creates an exception due to an invalid message content. The user should then be able to edit the content and resubmit. However currently the resubmit button is disabled. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 07:31:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 07:31:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-525) Resubmit function for sample order app no longer working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-525: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/150 > Resubmit function for sample order app no longer working > -------------------------------------------------------- > > Key: RTGOV-525 > URL: https://issues.jboss.org/browse/RTGOV-525 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When issuing the 'order5bad' request from the ordermgmt/app, it creates an exception due to an invalid message content. The user should then be able to edit the content and resubmit. > However currently the resubmit button is disabled. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 07:31:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 11 Jul 2014 07:31:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-525) Resubmit function for sample order app no longer working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-525. ------------------------------ Resolution: Done > Resubmit function for sample order app no longer working > -------------------------------------------------------- > > Key: RTGOV-525 > URL: https://issues.jboss.org/browse/RTGOV-525 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When issuing the 'order5bad' request from the ordermgmt/app, it creates an exception due to an invalid message content. The user should then be able to edit the content and resubmit. > However currently the resubmit button is disabled. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 11 20:02:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 11 Jul 2014 20:02:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-445) SSO not working on Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-445: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0) > SSO not working on Tomcat > ------------------------- > > Key: SRAMP-445 > URL: https://issues.jboss.org/browse/SRAMP-445 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.6.0 > > > The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce: > 1) run both s-ramp and dtgov on tomcat > 2) open browser, navigate to s-ramp-ui > 3) log in > 4) click on Design Time Governance > At this point you will have to authenticate again. This is wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 07:16:32 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 14 Jul 2014 07:16:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-505) maven:deploy CLI command missing maven.type property sometimes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-505: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/453 > maven:deploy CLI command missing maven.type property sometimes > -------------------------------------------------------------- > > Key: SRAMP-505 > URL: https://issues.jboss.org/browse/SRAMP-505 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > The maven:deploy s-ramp cli command does not currently set the maven.type property under all circumstances. A requirement is that maven.type always be set. Currently the CLI command gets this information from the arguments to the command. In some cases the user will not include the "type" information on the command line. In this case the type should be pulled from the file extension of the file being uploaded. > If the file being uploaded does *not* have an extension and the maven.type is not provided as part of the GAV argument, then the command should fail. > Note: the name of the artifact should also include the file's extension - this is currently being left off. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 07:54:29 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 14 Jul 2014 07:54:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984668#comment-12984668 ] David virgil naranjo commented on SRAMP-506: -------------------------------------------- The extended type has to be included for example for uploading switchyard applications. In that case, it is needed an extra param to specify the extended type. I have been checking the maven deploy:deploy-file plugin: http://maven.apache.org/plugins/maven-deploy-plugin/deploy-file-mojo.html The easier solution is to add a classifier, and in the server side check if the classifier correspond to a extended type used by us, or check if the classifier is different than the common maven classifiers, test, sources... In case it is different than test or sources ( I do not know if by default they are more), then we could set the extended type. This is the easy solution.. But maybe it could be confusing, because maybe sometimes we want to add a classifier, that is not really an extended type. Another solution could be (thanks to Mark Savy), it is to include the artifact type in the META-INF MANIFEST file. Then the user should add this info to the jar, before deploying. Another option maybe could be to create our custom deploy plugin, that extends from the official one, and extends the functionality to add a param in the urls like artifactType. Here the only problem is that the user, when he wants to include an extended artifact type has to disable the official maven deploy plugin (skip) and include the s-ramp one. > Maven repository facade. Add extended type > ------------------------------------------ > > Key: SRAMP-506 > URL: https://issues.jboss.org/browse/SRAMP-506 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Mon Jul 14 08:22:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 14 Jul 2014 08:22:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984692#comment-12984692 ] Eric Wittmann commented on SRAMP-506: ------------------------------------- Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want. I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin. The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places: * META-INF/maven/${groupId}/${artifactId}/pom.xml * META-INF/MANIFEST.MF * META-INF/maven/${groupId}/${artifactId}/pom.properties I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary. The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them). > Maven repository facade. Add extended type > ------------------------------------------ > > Key: SRAMP-506 > URL: https://issues.jboss.org/browse/SRAMP-506 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Mon Jul 14 08:24:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 14 Jul 2014 08:24:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984692#comment-12984692 ] Eric Wittmann edited comment on SRAMP-506 at 7/14/14 8:24 AM: -------------------------------------------------------------- Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want. I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin. The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places: * META-INF/maven/groupId/artifactId/pom.xml * META-INF/MANIFEST.MF * META-INF/maven/groupId/artifactId/pom.properties I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary. The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them). was (Author: eric.wittmann): Couple thoughts on this. The first is that I don't think the classifier approach will work, because the main point of this feature is to set the S-RAMP ArtifactType for the *primary* artifact produced by a maven build. Setting a maven classifier changes the maven semantics, which is not what we want. I also don't think a custom deploy plugin is the way to go, since the value of this feature is to avoid having to configure a custom plugin in the pom.xml. We already have a custom deploy plugin that can be used today! :) This maven facade is supposed to allow deployments without such a custom plugin. The solution I think needs to come from the content of the artifact being deployed, as [~msavy] suggested. I think the best thing would be for us to look for a property set in one of the following three places: * META-INF/maven/${groupId}/${artifactId}/pom.xml * META-INF/MANIFEST.MF * META-INF/maven/${groupId}/${artifactId}/pom.properties I have listed them in the order I think makes sense. We should consider what's easiest for the end user. I think the easiest is to allow them to set a property in their pom.xml which we will consume. Alternatively we could check the manifest or the pom.properties. I think the pom.xml is the best because it's the easiest for the end user to configure - they simply add a property to their pom.xml. No further configuration necessary. The downside to this approach is that the maven facade will need to save a full copy of the inbound artifact content locally so it can be cracked open and interrogated. It will also need to know what kind of artifact it is - because this approach will only work for primary artifacts that are some form of Zip file (which is most of them). > Maven repository facade. Add extended type > ------------------------------------------ > > Key: SRAMP-506 > URL: https://issues.jboss.org/browse/SRAMP-506 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Mon Jul 14 08:40:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 14 Jul 2014 08:40:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984705#comment-12984705 ] David virgil naranjo commented on SRAMP-380: -------------------------------------------- I did not find information in google about this, so i wrote a post in the fuse forum: https://community.jboss.org/message/881181 > 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.2.6#6264) From issues at jboss.org Mon Jul 14 09:52:30 2014 From: issues at jboss.org (Marc Savy (JIRA)) Date: Mon, 14 Jul 2014 09:52:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-506) Maven repository facade. Add extended type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984745#comment-12984745 ] Marc Savy commented on SRAMP-506: --------------------------------- Having spent ages having to meddle with this metadata on a previous project - I should mention that it can be extremely tricky to get the results you would expect (unless maven metadata is available). For instance, in my experience the following aren't uncommon in externally provided JARs: - `META-INF` directory to be missing entirely (essentially not a valid JAR) - Manifest data often doesn't correspond with what you would expect, because the user decided can some arbitrary value in there (e.g. Bundle-Version => 2.1.0.201209190230-r instead of 2.1.0, presumably someone decided it'd be nice to have date and time in there). [1] - There may be correct data available, but it might not be stored in the key you'd expect (sometimes people put them in Bundle-Version other times in Specification-Version) - If there is a 'meta jar' (i.e. Jar wrapping a whole load of other Jars), it may not even have a `properties.pom`/maven metadata which is useful. Ultimately for the worst cases I ended up having to use a heuristic based approach, with regexp for the ultimate fallback if all other methods failed (would we just reject completely malformed ones?). While I was developing the aforementioned tooling, I wrote a little program which will scan through a directory tree, cracks open all of the jars and builds a set of keys (and values) from all the manifest files. This gives you a very good idea of which fields you may want to look at to derive the data you need, in addition to the sort of rubbish data it may contain you'll have to try to avoid! Sample output (huge set): https://gist.github.com/msavy/cefc9c9b01416176128f Note format is: key => { v0, v1, ..., Vn } I'll post a source link as a priv comment as I haven't put any copyright headers and whatnot on it. > Maven repository facade. Add extended type > ------------------------------------------ > > Key: SRAMP-506 > URL: https://issues.jboss.org/browse/SRAMP-506 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Mon Jul 14 11:02:29 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 14 Jul 2014 11:02:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-507: ------------------------------------------ Summary: Modify way the snapshot artifacts are stored in s-ramp Key: SRAMP-507 URL: https://issues.jboss.org/browse/SRAMP-507 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 Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 11:04:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 14 Jul 2014 11:04:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-508: ------------------------------------------ Summary: Restrict s-ramp artifacts depends on the environment Key: SRAMP-508 URL: https://issues.jboss.org/browse/SRAMP-508 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: David virgil naranjo The main idea proposed by Gary is to avoid snapshots artifacts in production. The solution proposed by Eric is to recognize if the s-ramp artifact deployed contains the SNAPSHOT keyword. Then: In case it contains SNAPSHOT: allow Snapshots and Released artifacts. Not contains SNAPSHOT: allow just Released artifacts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 21:20:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 14 Jul 2014 21:20:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984948#comment-12984948 ] Brett Meyer commented on SRAMP-507: ----------------------------------- Relates to SRAMP-487 > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > 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 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 21:20:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 14 Jul 2014 21:20:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984949#comment-12984949 ] Brett Meyer commented on SRAMP-508: ----------------------------------- Relates to SRAMP-487 > Restrict s-ramp artifacts depends on the environment > ----------------------------------------------------- > > Key: SRAMP-508 > URL: https://issues.jboss.org/browse/SRAMP-508 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > The main idea proposed by Gary is to avoid snapshots artifacts in production. > The solution proposed by Eric is to recognize if the s-ramp artifact deployed contains the SNAPSHOT keyword. Then: > In case it contains SNAPSHOT: allow Snapshots and Released artifacts. > Not contains SNAPSHOT: allow just Released artifacts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 14 21:32:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 14 Jul 2014 21:32:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984950#comment-12984950 ] Brett Meyer commented on SRAMP-380: ----------------------------------- >From Claus: "I think etc/users.properties gets encrypted when fuse 6.1 startup. So you can add the users with cleartext password, but fuse should resave the file with encrypted passwords." If that's the case, we may want to look into appending *all* of our user properties into Fuse's etc/user.properties, rather than copying over our own file. > 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.2.6#6264) From issues at jboss.org Tue Jul 15 01:42:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 01:42:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-445) SSO not working on Tomcat In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984962#comment-12984962 ] Brett Meyer commented on SRAMP-445: ----------------------------------- +1, especially if reverting would be fairly invasive. Outside of possibly Fuse/EAP, SSO seems like a "really nice to have", but definitely not a blocker. Would creating a Tomcat issue, providing some context, and simply attaching an overlord-idp.war suffice? I'm wondering if creating a from-scratch standalone test would be worth the effort, depending on what they actually need to debug... > SSO not working on Tomcat > ------------------------- > > Key: SRAMP-445 > URL: https://issues.jboss.org/browse/SRAMP-445 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.6.0 > > > The IDP isn't quite working as an SSO provider when running in Tomcat. The SP properly redirects to the IDP but the IDP is requiring the user to authenticate again, even though they already have. To reproduce: > 1) run both s-ramp and dtgov on tomcat > 2) open browser, navigate to s-ramp-ui > 3) log in > 4) click on Design Time Governance > At this point you will have to authenticate again. This is wrong. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 05:58:32 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 15 Jul 2014 05:58:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-507: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/454 > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > 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 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 10:20:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 10:20:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-436: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455 > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:06:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 11:06:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-508: -------------------------------- Description: By default the S-RAMP Maven integration should not allow maven snapshots to be deployed to the s-ramp repository (since this is not a use-case we want to encourage). However, we are planning to support maven snapshots in the code via a flag to enable/disable the support. This flag will be consumed by the maven repository facade. The flag (e.g. s-ramp.maven.enable-snapshots) will default to *false* unless the S-RAMP runtime itself is a SNAPSHOT. This will make it easier for us during development of s-ramp and dtgov to test out our demos and dtgov seed data without changing the versions of those artifacts in their respective pom.xml files. So in summary - the maven repo facade will not allow SNAPSHOT artifacts to be deployed unless the flag is set to true *or* the current s-ramp runtime version is a snapshot version. was: The main idea proposed by Gary is to avoid snapshots artifacts in production. The solution proposed by Eric is to recognize if the s-ramp artifact deployed contains the SNAPSHOT keyword. Then: In case it contains SNAPSHOT: allow Snapshots and Released artifacts. Not contains SNAPSHOT: allow just Released artifacts. > Restrict s-ramp artifacts depends on the environment > ----------------------------------------------------- > > Key: SRAMP-508 > URL: https://issues.jboss.org/browse/SRAMP-508 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > By default the S-RAMP Maven integration should not allow maven snapshots to be deployed to the s-ramp repository (since this is not a use-case we want to encourage). However, we are planning to support maven snapshots in the code via a flag to enable/disable the support. This flag will be consumed by the maven repository facade. The flag (e.g. s-ramp.maven.enable-snapshots) will default to *false* unless the S-RAMP runtime itself is a SNAPSHOT. > This will make it easier for us during development of s-ramp and dtgov to test out our demos and dtgov seed data without changing the versions of those artifacts in their respective pom.xml files. > So in summary - the maven repo facade will not allow SNAPSHOT artifacts to be deployed unless the flag is set to true *or* the current s-ramp runtime version is a snapshot version. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:08:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 11:08:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-507: -------------------------------- Description: Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: h4. Release artifacts * If this artifact (GAV) already exists in s-ramp, fail * If this artifact doesn't yet exist, add it h4. Snapshot artifacts * If this artifact (GAV + timestamp) already exists in s-ramp, fail * If this artifact doesn't yet exist, add it along with its timestamp information was: Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) Create a new artifact every time a different timestamp of the same artifact is uploaded. It would be exactly as maven is doing. Right now we update the content of the artifact instead of creating a new one. > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > 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 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: > h4. Release artifacts > * If this artifact (GAV) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it > h4. Snapshot artifacts > * If this artifact (GAV + timestamp) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it along with its timestamp information -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:14:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 11:14:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-436: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455, https://github.com/Governance/dtgov/pull/206 (was: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455) > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:18:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 11:18:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-487) Improved handling of artifact updates In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-487. ----------------------------- Fix Version/s: (was: 0.6.0) Resolution: Duplicate Issue Closing this -- SRAMP-507 and SRAMP-508 encapsulate and expand upon the concepts. > Improved handling of artifact updates > ------------------------------------- > > Key: SRAMP-487 > URL: https://issues.jboss.org/browse/SRAMP-487 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, artifacts can be deployed multiple times, duplicating extracted/derived content. [~eric.wittmann] pointed out that the spec is a little ambiguous with regards to updating artifacts. My gut reaction is that it probably shouldn't be allowed (think Nexus). However, snapshots should probably be updatable, and therefore would need extracted/derived content (and their relationships) removed prior to updating. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:18:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 15 Jul 2014 11:18:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-507: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060773 > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > 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 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: > h4. Release artifacts > * If this artifact (GAV) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it > h4. Snapshot artifacts > * If this artifact (GAV + timestamp) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it along with its timestamp information -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 11:48:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 11:48:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-436: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455, https://github.com/Governance/dtgov/pull/206, https://github.com/Governance/rtgov/pull/151 (was: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455, https://github.com/Governance/dtgov/pull/206) > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 12:24:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 12:24:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-436: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455, https://github.com/Governance/dtgov/pull/206, https://github.com/Governance/rtgov/pull/151, https://github.com/bpmc/bpm-console/pull/36 (was: https://github.com/Governance/overlord-commons/pull/85, https://github.com/Governance/s-ramp/pull/455, https://github.com/Governance/dtgov/pull/206, https://github.com/Governance/rtgov/pull/151) > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 13:24:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 15 Jul 2014 13:24:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-257) Allow parametrization of (not only) MVEL scripts in EPN In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-257: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/152 > Allow parametrization of (not only) MVEL scripts in EPN > ------------------------------------------------------- > > Key: RTGOV-257 > URL: https://issues.jboss.org/browse/RTGOV-257 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > EPN allows to use MVEL or Java class as processor or predicate. > It would be great addition to re-usability of the scripts and classe if it > would be possible to pass a set of parameters from epn.json to the > processor/evaluator for the instance. > It could work in a similar way as injection of services - via EPNContext. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 13:24:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 15 Jul 2014 13:24:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-257) Allow parametrization of (not only) MVEL scripts in EPN In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-257. ------------------------------ Resolution: Done > Allow parametrization of (not only) MVEL scripts in EPN > ------------------------------------------------------- > > Key: RTGOV-257 > URL: https://issues.jboss.org/browse/RTGOV-257 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > EPN allows to use MVEL or Java class as processor or predicate. > It would be great addition to re-usability of the scripts and classe if it > would be possible to pass a set of parameters from epn.json to the > processor/evaluator for the instance. > It could work in a similar way as injection of services - via EPNContext. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 13:26:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 15 Jul 2014 13:26:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-526) Use parameterisation to make SLA EPN customisable In-Reply-To: References: Message-ID: Gary Brown created RTGOV-526: -------------------------------- Summary: Use parameterisation to make SLA EPN customisable Key: RTGOV-526 URL: https://issues.jboss.org/browse/RTGOV-526 Project: RTGov (Run Time Governance) Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Try to pass in a list of response time to situation status values, and change the rule to loop through to determine if a situation should be created. The information should be configured in highest response time order. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 13:30:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 15 Jul 2014 13:30:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-257) Allow parametrization of (not only) MVEL scripts in EPN In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985312#comment-12985312 ] RH Bugzilla Integration commented on RTGOV-257: ----------------------------------------------- Gary Brown changed the Status of [bug 1000312|https://bugzilla.redhat.com/show_bug.cgi?id=1000312] from NEW to ASSIGNED > Allow parametrization of (not only) MVEL scripts in EPN > ------------------------------------------------------- > > Key: RTGOV-257 > URL: https://issues.jboss.org/browse/RTGOV-257 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Event Processor > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > EPN allows to use MVEL or Java class as processor or predicate. > It would be great addition to re-usability of the scripts and classe if it > would be possible to pass a set of parameters from epn.json to the > processor/evaluator for the instance. > It could work in a similar way as injection of services - via EPNContext. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 14:04:32 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 14:04:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-436. --------------------------------- Resolution: Done > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 14:06:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 15 Jul 2014 14:06:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-436) Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-436. ------------------------------- > Overlord SSO (IDP/SP) needs to have SAML assertion sigs enabled by default > -------------------------------------------------------------------------- > > Key: SRAMP-436 > URL: https://issues.jboss.org/browse/SRAMP-436 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently we're not signing the saml assertions. We need to do that. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 15:00:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 15:00:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-431: ------------------------------ Fix Version/s: 0.6.0 > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 15:00:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 15:00:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-459) Integration tests: Jetty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-459: ------------------------------ Parent: (was: SRAMP-431) Issue Type: Feature Request (was: Sub-task) > Integration tests: Jetty > ------------------------ > > Key: SRAMP-459 > URL: https://issues.jboss.org/browse/SRAMP-459 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 15:00:32 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 15:00:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-460) Integration tests: Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-460: ------------------------------ Parent: (was: SRAMP-431) Issue Type: Feature Request (was: Sub-task) > Integration tests: Fuse > ----------------------- > > Key: SRAMP-460 > URL: https://issues.jboss.org/browse/SRAMP-460 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 15:02:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 15:02:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-459) Integration tests: Jetty In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985351#comment-12985351 ] Brett Meyer commented on SRAMP-459: ----------------------------------- I'm deferring this for now. Arquillian does not have a Jetty 8 container (only 7 & 9). Further, embedded mode is the only option. I'm not sure if Jetty has the capacity to be run in a managed mode, period. If it's determined that there would be enough value in this to make it worth the effort, significant portions of s-ramp-dev-server could be reused, conceptually. But, since Tomcat is fully tested, ignoring Jetty altogether might be "good enough." > Integration tests: Jetty > ------------------------ > > Key: SRAMP-459 > URL: https://issues.jboss.org/browse/SRAMP-459 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 15:04:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 15:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-460) Integration tests: Fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985352#comment-12985352 ] Brett Meyer commented on SRAMP-460: ----------------------------------- SRAMP-431's PR is complete. Ping me to show you around the concepts. Setting up an embedded Fuse container shouldn't be too terrible. > Integration tests: Fuse > ----------------------- > > Key: SRAMP-460 > URL: https://issues.jboss.org/browse/SRAMP-460 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 15 15:08:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 15 Jul 2014 15:08:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-431: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/457 > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 04:28:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 04:28:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-513) List gateway bindings in Reference List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-513: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/153 > List gateway bindings in Reference List, colour coded to reflect the gateway state > ---------------------------------------------------------------------------------- > > Key: RTGOV-513 > URL: https://issues.jboss.org/browse/RTGOV-513 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the reference list table is empty. This needs to be populated with the gateway value(s). > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 04:28:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 04:28:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-513) List gateway bindings in Reference List, colour coded to reflect the gateway state In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-513. ------------------------------ Resolution: Done > List gateway bindings in Reference List, colour coded to reflect the gateway state > ---------------------------------------------------------------------------------- > > Key: RTGOV-513 > URL: https://issues.jboss.org/browse/RTGOV-513 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > Currently the 'binding' column in the reference list table is empty. This needs to be populated with the gateway value(s). > The gateway state (enabled/disabled) should be reflected in the presentation (possibly colour coded). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 09:04:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 09:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-526) Use parameterisation to make SLA EPN customisable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-526: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/154 > Use parameterisation to make SLA EPN customisable > ------------------------------------------------- > > Key: RTGOV-526 > URL: https://issues.jboss.org/browse/RTGOV-526 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Try to pass in a list of response time to situation status values, and change the rule to loop through to determine if a situation should be created. > The information should be configured in highest response time order. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 09:04:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 09:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-526) Use parameterisation to make SLA EPN customisable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-526. ------------------------------ Resolution: Done > Use parameterisation to make SLA EPN customisable > ------------------------------------------------- > > Key: RTGOV-526 > URL: https://issues.jboss.org/browse/RTGOV-526 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Try to pass in a list of response time to situation status values, and change the rule to loop through to determine if a situation should be created. > The information should be configured in highest response time order. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 09:22:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 09:22:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-486) Align deployment targets with other overlord sub-projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985622#comment-12985622 ] Gary Brown commented on RTGOV-486: ---------------------------------- Most places have been changed to reflect the target. Currently samples are still split as jbossas and karaf. As more platforms are supported, may need to rethink this. Ant script now used at top level, with the platform using consistent names for the targets. > Align deployment targets with other overlord sub-projects > --------------------------------------------------------- > > Key: RTGOV-486 > URL: https://issues.jboss.org/browse/RTGOV-486 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Change deployment targets to be consistent with other overlord sub-projects. For example, instead of jbossas, it should be eap6 (or eap61/63 if split required), and fuse61 instead of karaf - although support for Karaf will also be required. > As part of this change, change the deployment approach to use ant script at top level, instead of maven - again for consistency with sramp/dtgov. Quickstarts could still use maven, unless deployment across targets is more consistent with ant. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 09:22:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 09:22:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-486) Align deployment targets with other overlord sub-projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-486. ------------------------------ Resolution: Done > Align deployment targets with other overlord sub-projects > --------------------------------------------------------- > > Key: RTGOV-486 > URL: https://issues.jboss.org/browse/RTGOV-486 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Change deployment targets to be consistent with other overlord sub-projects. For example, instead of jbossas, it should be eap6 (or eap61/63 if split required), and fuse61 instead of karaf - although support for Karaf will also be required. > As part of this change, change the deployment approach to use ant script at top level, instead of maven - again for consistency with sramp/dtgov. Quickstarts could still use maven, unless deployment across targets is more consistent with ant. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:12:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 16 Jul 2014 10:12:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-431. ------------------------------- Resolution: Done > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:12:32 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 16 Jul 2014 10:12:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Arquillian-based integration tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985655#comment-12985655 ] Brett Meyer commented on SRAMP-431: ----------------------------------- Pushed to 0.6 branch > Arquillian-based integration tests > ---------------------------------- > > Key: SRAMP-431 > URL: https://issues.jboss.org/browse/SRAMP-431 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Create a new s-ramp-test module to contain all integration tests. Thoughts: > - 1 central ant script, executed by the POM, should be in charge of downloading the Jetty and and Tomcat distros, then unpacking them. Arquillian would then use them in a "managed mode." > - The ant script will eventually be in charge of downloading EAP as well, but not until we have CI hardware within the RH network. Until then, we'll need to do something similar to RTGov's current tests: require the distro be manually downloaded and unpacked, then set $JBOSS_HOME > - Fuse should be run in embedded mode. > - No tests should run by default. Hide all behind container-specific profiles, enabled only on the CI job(s). > - Include a simple s-ramp-client based test to at least ensure the app comes up, auth works, and uploading/querying works. > - Pull in any functional tests from the other modules requiring the server to be spun-up. Leave behind only pure *unit* tests. > The work-in-progress: https://github.com/brmeyer/s-ramp/compare/integration-tests -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:26:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 16 Jul 2014 10:26:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-509) Unify s-ramp maven code In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-509: ------------------------------------------ Summary: Unify s-ramp maven code Key: SRAMP-509 URL: https://issues.jboss.org/browse/SRAMP-509 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: Brett Meyer Both the S-ramp Wagon, Maven Repository Servlet Facade and Deploy Command (shell) uses the s-ramp client to store maven artifacts in the system. They make more or less the same, use the same methods to find existing artifacts and to save the artifact. Also all of them have methods that parse the input string that contains the gav, and store this info in different mojos. This means there is lot of common duplicate code. The idea is to create in s-ramp common project a new package maven and there include only one MavenMetadata class, and include one Factory class that transform from Metadata to BaseArtifactType. Also it is required a MavenUtil class where will be included the common operations. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:26:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 16 Jul 2014 10:26:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-509) Unify s-ramp maven code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo reassigned SRAMP-509: ------------------------------------------ Assignee: David virgil naranjo (was: Brett Meyer) > Unify s-ramp maven code > ----------------------- > > Key: SRAMP-509 > URL: https://issues.jboss.org/browse/SRAMP-509 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Both the S-ramp Wagon, Maven Repository Servlet Facade and Deploy Command (shell) uses the s-ramp client to store maven artifacts in the system. > They make more or less the same, use the same methods to find existing artifacts and to save the artifact. Also all of them have methods that parse the input string that contains the gav, and store this info in different mojos. > This means there is lot of common duplicate code. The idea is to create in s-ramp common project a new package maven and there include only one MavenMetadata class, and include one Factory class that transform from Metadata to BaseArtifactType. > Also it is required a MavenUtil class where will be included the common operations. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:26:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 16 Jul 2014 10:26:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-505) maven:deploy CLI command missing maven.type property sometimes In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-505. ------------------------------- Resolution: Done > maven:deploy CLI command missing maven.type property sometimes > -------------------------------------------------------------- > > Key: SRAMP-505 > URL: https://issues.jboss.org/browse/SRAMP-505 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > The maven:deploy s-ramp cli command does not currently set the maven.type property under all circumstances. A requirement is that maven.type always be set. Currently the CLI command gets this information from the arguments to the command. In some cases the user will not include the "type" information on the command line. In this case the type should be pulled from the file extension of the file being uploaded. > If the file being uploaded does *not* have an extension and the maven.type is not provided as part of the GAV argument, then the command should fail. > Note: the name of the artifact should also include the file's extension - this is currently being left off. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:54:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 10:54:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-527) Create Service for accessing active collections from event processors In-Reply-To: References: Message-ID: Gary Brown created RTGOV-527: -------------------------------- Summary: Create Service for accessing active collections from event processors Key: RTGOV-527 URL: https://issues.jboss.org/browse/RTGOV-527 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Need to be able to reference information in active collections from an event processor. So information derived from some previous processing, and stored in an active collection, can then be used in subsequent EPNs or AVs. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 10:56:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 16 Jul 2014 10:56:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-509) Unify s-ramp maven code In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985675#comment-12985675 ] Brett Meyer commented on SRAMP-509: ----------------------------------- See https://github.com/Governance/s-ramp/pull/454/files for examples > Unify s-ramp maven code > ----------------------- > > Key: SRAMP-509 > URL: https://issues.jboss.org/browse/SRAMP-509 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Both the S-ramp Wagon, Maven Repository Servlet Facade and Deploy Command (shell) uses the s-ramp client to store maven artifacts in the system. > They make more or less the same, use the same methods to find existing artifacts and to save the artifact. Also all of them have methods that parse the input string that contains the gav, and store this info in different mojos. > This means there is lot of common duplicate code. The idea is to create in s-ramp common project a new package maven and there include only one MavenMetadata class, and include one Factory class that transform from Metadata to BaseArtifactType. > Also it is required a MavenUtil class where will be included the common operations. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 11:06:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 16 Jul 2014 11:06:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-510) Fully audit the S-RAMP Maven structure and dependencies In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-510: --------------------------------- Summary: Fully audit the S-RAMP Maven structure and dependencies Key: SRAMP-510 URL: https://issues.jboss.org/browse/SRAMP-510 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 0.6.0 Completely audit: 1.) The project architecture, ensuring proper module structure, parents, etc. 2.) Module dependencies 3.) Parent dependencyManagement -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 12:04:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 16 Jul 2014 12:04:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-507. ------------------------------- Resolution: Done > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > 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 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: > h4. Release artifacts > * If this artifact (GAV) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it > h4. Snapshot artifacts > * If this artifact (GAV + timestamp) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it along with its timestamp information -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 12:06:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 16 Jul 2014 12:06:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985705#comment-12985705 ] RH Bugzilla Integration commented on SRAMP-507: ----------------------------------------------- Brett Meyer changed the Status of [bug 1060773|https://bugzilla.redhat.com/show_bug.cgi?id=1060773] from NEW to POST > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > 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 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: > h4. Release artifacts > * If this artifact (GAV) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it > h4. Snapshot artifacts > * If this artifact (GAV + timestamp) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it along with its timestamp information -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 13:16:32 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 16 Jul 2014 13:16:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-511) Create a Fuse console command for creating the SAML keystore In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-511: ----------------------------------- Summary: Create a Fuse console command for creating the SAML keystore Key: SRAMP-511 URL: https://issues.jboss.org/browse/SRAMP-511 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: David virgil naranjo Fix For: 0.5.0 The console command should create a keystore and populate it with a new KeyPair. It should prompt the user for the password(s) and store the result in the correct place for Fuse/Fabric8. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 19:36:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 19:36:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-511) Fuse sample order mgmt OSGi app needs to check customer suspend status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-511: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/155 > Fuse sample order mgmt OSGi app needs to check customer suspend status > ---------------------------------------------------------------------- > > Key: RTGOV-511 > URL: https://issues.jboss.org/browse/RTGOV-511 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The async policy evaluates the customer's debt level and sets the suspend property, but the order app does not check the suspend proerty or act upon it. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 19:36:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 19:36:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-511) Fuse sample order mgmt OSGi app needs to check customer suspend status In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-511. ------------------------------ Resolution: Done > Fuse sample order mgmt OSGi app needs to check customer suspend status > ---------------------------------------------------------------------- > > Key: RTGOV-511 > URL: https://issues.jboss.org/browse/RTGOV-511 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The async policy evaluates the customer's debt level and sets the suspend property, but the order app does not check the suspend proerty or act upon it. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 19:36:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 19:36:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-527) Create Service for accessing active collections from event processors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-527. ------------------------------ Resolution: Done > Create Service for accessing active collections from event processors > --------------------------------------------------------------------- > > Key: RTGOV-527 > URL: https://issues.jboss.org/browse/RTGOV-527 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Need to be able to reference information in active collections from an event processor. So information derived from some previous processing, and stored in an active collection, can then be used in subsequent EPNs or AVs. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 16 19:36:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 16 Jul 2014 19:36:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-527) Create Service for accessing active collections from event processors In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-527: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/155 > Create Service for accessing active collections from event processors > --------------------------------------------------------------------- > > Key: RTGOV-527 > URL: https://issues.jboss.org/browse/RTGOV-527 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Need to be able to reference information in active collections from an event processor. So information derived from some previous processing, and stored in an active collection, can then be used in subsequent EPNs or AVs. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 15:34:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 17 Jul 2014 15:34:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-510) Fully audit the S-RAMP Maven structure and dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-510 started by Brett Meyer. > Fully audit the S-RAMP Maven structure and dependencies > ------------------------------------------------------- > > Key: SRAMP-510 > URL: https://issues.jboss.org/browse/SRAMP-510 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Completely audit: > 1.) The project architecture, ensuring proper module structure, parents, etc. > 2.) Module dependencies > 3.) Parent dependencyManagement -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 19:52:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 17 Jul 2014 19:52:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-510) Fully audit the S-RAMP Maven structure and dependencies In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-510. ------------------------------- Resolution: Done > Fully audit the S-RAMP Maven structure and dependencies > ------------------------------------------------------- > > Key: SRAMP-510 > URL: https://issues.jboss.org/browse/SRAMP-510 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Completely audit: > 1.) The project architecture, ensuring proper module structure, parents, etc. > 2.) Module dependencies > 3.) Parent dependencyManagement -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 17 20:06:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 17 Jul 2014 20:06:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-512) Cleanup and improve all datasources In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-512: --------------------------------- Summary: Cleanup and improve all datasources Key: SRAMP-512 URL: https://issues.jboss.org/browse/SRAMP-512 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 0.6.0 Connection pooling, stale connection testing, etc. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 07:24:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 18 Jul 2014 07:24:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-516) Document how to deploy EPN, ACS, AV, IP in OSGi In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-516. ------------------------------ Resolution: Done > Document how to deploy EPN, ACS, AV, IP in OSGi > ----------------------------------------------- > > Key: RTGOV-516 > URL: https://issues.jboss.org/browse/RTGOV-516 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Document the OSGi variant for the packing of EPN, AV, ACS and IP. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 07:42:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 18 Jul 2014 07:42:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-528) Installing rtgov-client feature complains about overlord-rtgov-war-all-fuse6 dependency In-Reply-To: References: Message-ID: Gary Brown created RTGOV-528: -------------------------------- Summary: Installing rtgov-client feature complains about overlord-rtgov-war-all-fuse6 dependency Key: RTGOV-528 URL: https://issues.jboss.org/browse/RTGOV-528 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When installing rtgov-client feature I get: {noformat} JBossFuse:karaf at root> features:install rtgov-client Refreshing bundles org.apache.servicemix.bundles.jaxb-xjc (152), org.ops4j.pax.url.war (239), org.ops4j.pax.web.pax-web-jsp (169), org.eclipse.jetty.aggregate.jetty-all-server (92), org.apache.servicemix.bundles.jaxb-impl (128) Error executing command: Could not start bundle mvn:org.overlord.rtgov/overlord-rtgov-war-all-fuse6/2.0.0-SNAPSHOT/war in feature(s) rtgov-dependencies-2.0.0-SNAPSHOT, rtgov-services-2.0.0-SNAPSHOT: Unresolved constraint in bundle org.overlord.rtgov.overlord-rtgov-war-all-fuse6 [272]: Unable to resolve 272.0: missing requirement [272.0] osgi.wiring.package; (osgi.wiring.package=org.overlord.rtgov.activity.server.rest) {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 08:48:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 18 Jul 2014 08:48:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-513) Workflow is being created for -sources JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer moved DTGOV-173 to SRAMP-513: ----------------------------------------- Project: S-RAMP (was: DTGov (Design Time Governance)) Key: SRAMP-513 (was: DTGOV-173) Fix Version/s: 0.5.0 (was: 1.3) > Workflow is being created for -sources JAR > ------------------------------------------ > > Key: SRAMP-513 > URL: https://issues.jboss.org/browse/SRAMP-513 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > Reported by David via his 1.3.0.Beta1 Testing: > "Do we want the sources jar to be executed in the dtgov workflow? > I executed the s-ramp-demos/s-ramp-demos-switchyard and then 2 switchyard artifacts were upload, the jar, and the sources-jar. Then 2 tasks appeared in the dtgov tasks." > The answer is "no" - the -sources.jar should *not* trigger a workflow. We need to figure out why that is happening. Perhaps the s-ramp wagon is not setting the correct ArtifactType for the -sources JAR artifact? The primary artifact in the maven build should be a SwitchYardApplication. The -sources JAR should be added to s-ramp as JavaArchive (most likely). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 08:50:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 18 Jul 2014 08:50:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-513) s-ramp-wagon should use sources JAR In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-513: ------------------------------ Summary: s-ramp-wagon should use sources JAR (was: Workflow is being created for -sources JAR) > s-ramp-wagon should use sources JAR > ------------------------------------ > > Key: SRAMP-513 > URL: https://issues.jboss.org/browse/SRAMP-513 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > Reported by David via his 1.3.0.Beta1 Testing: > "Do we want the sources jar to be executed in the dtgov workflow? > I executed the s-ramp-demos/s-ramp-demos-switchyard and then 2 switchyard artifacts were upload, the jar, and the sources-jar. Then 2 tasks appeared in the dtgov tasks." > The answer is "no" - the -sources.jar should *not* trigger a workflow. We need to figure out why that is happening. Perhaps the s-ramp wagon is not setting the correct ArtifactType for the -sources JAR artifact? The primary artifact in the maven build should be a SwitchYardApplication. The -sources JAR should be added to s-ramp as JavaArchive (most likely). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 08:50:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 18 Jul 2014 08:50:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-513) s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-513: ------------------------------ Summary: s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType (was: s-ramp-wagon should use sources JAR ) > s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType > -------------------------------------------------------------------- > > Key: SRAMP-513 > URL: https://issues.jboss.org/browse/SRAMP-513 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > Reported by David via his 1.3.0.Beta1 Testing: > "Do we want the sources jar to be executed in the dtgov workflow? > I executed the s-ramp-demos/s-ramp-demos-switchyard and then 2 switchyard artifacts were upload, the jar, and the sources-jar. Then 2 tasks appeared in the dtgov tasks." > The answer is "no" - the -sources.jar should *not* trigger a workflow. We need to figure out why that is happening. Perhaps the s-ramp wagon is not setting the correct ArtifactType for the -sources JAR artifact? The primary artifact in the maven build should be a SwitchYardApplication. The -sources JAR should be added to s-ramp as JavaArchive (most likely). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 09:48:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 18 Jul 2014 09:48:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-514) Allow generate-features-xml to use dirs on the classpath, rather than artifact jars only In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-514: --------------------------------- Summary: Allow generate-features-xml to use dirs on the classpath, rather than artifact jars only Key: SRAMP-514 URL: https://issues.jboss.org/browse/SRAMP-514 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Eric Wittmann Priority: Optional Definitely a low priority... https://overlord.ci.cloudbees.com/job/s-ramp.master.integration/job/s-ramp.master.integration.tomcat/2/console When that's configured to use "mvn clean test", generate-features-xml blows up. But, it works with "mvn clean install". Oddly enough, "test" works perfectly locally. {quote} [ERROR] Failed to execute goal org.overlord:overlord-commons-maven-plugin:2.0.3-SNAPSHOT:generate-features-xml (default) on project s-ramp-distro-fuse61: Resolved artifact is not a file: /scratch/jenkins/workspace/s-ramp.master.integration/s-ramp.master.integration.tomcat/s-ramp-api/target/classes {quote} I'm not at all sure what's causing the artifact to resolve to /classes, rather than the actual jar. But, theoretically, we should be able to improve the mojo to use directories, rather than require jars. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 10:04:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 18 Jul 2014 10:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-514) Allow generate-features-xml to use dirs on the classpath, rather than artifact jars only In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986297#comment-12986297 ] Brett Meyer commented on SRAMP-514: ----------------------------------- May not even be worth the effort, especially if it's limited to the Jenkins/Hudson reactor. > Allow generate-features-xml to use dirs on the classpath, rather than artifact jars only > ---------------------------------------------------------------------------------------- > > Key: SRAMP-514 > URL: https://issues.jboss.org/browse/SRAMP-514 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Eric Wittmann > Priority: Optional > > Definitely a low priority... > https://overlord.ci.cloudbees.com/job/s-ramp.master.integration/job/s-ramp.master.integration.tomcat/2/console > When that's configured to use "mvn clean test", generate-features-xml blows up. But, it works with "mvn clean install". Oddly enough, "test" works perfectly locally. > {quote} > [ERROR] Failed to execute goal org.overlord:overlord-commons-maven-plugin:2.0.3-SNAPSHOT:generate-features-xml (default) on project s-ramp-distro-fuse61: Resolved artifact is not a file: /scratch/jenkins/workspace/s-ramp.master.integration/s-ramp.master.integration.tomcat/s-ramp-api/target/classes > {quote} > I'm not at all sure what's causing the artifact to resolve to /classes, rather than the actual jar. But, theoretically, we should be able to improve the mojo to use directories, rather than require jars. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 10:48:29 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 18 Jul 2014 10:48:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-515: ------------------------------------------ Summary: overlord commons installer saml password filtering Key: SRAMP-515 URL: https://issues.jboss.org/browse/SRAMP-515 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: David virgil naranjo The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 14:02:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 18 Jul 2014 14:02:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-528) Installing rtgov-client feature complains about overlord-rtgov-war-all-fuse6 dependency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-528: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/156 > Installing rtgov-client feature complains about overlord-rtgov-war-all-fuse6 dependency > --------------------------------------------------------------------------------------- > > Key: RTGOV-528 > URL: https://issues.jboss.org/browse/RTGOV-528 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When installing rtgov-client feature I get: > {noformat} > JBossFuse:karaf at root> features:install rtgov-client > Refreshing bundles org.apache.servicemix.bundles.jaxb-xjc (152), org.ops4j.pax.url.war (239), org.ops4j.pax.web.pax-web-jsp (169), org.eclipse.jetty.aggregate.jetty-all-server (92), org.apache.servicemix.bundles.jaxb-impl (128) > Error executing command: Could not start bundle mvn:org.overlord.rtgov/overlord-rtgov-war-all-fuse6/2.0.0-SNAPSHOT/war in feature(s) rtgov-dependencies-2.0.0-SNAPSHOT, rtgov-services-2.0.0-SNAPSHOT: Unresolved constraint in bundle org.overlord.rtgov.overlord-rtgov-war-all-fuse6 [272]: Unable to resolve 272.0: missing requirement [272.0] osgi.wiring.package; (osgi.wiring.package=org.overlord.rtgov.activity.server.rest) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 18 14:02:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 18 Jul 2014 14:02:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-528) Installing rtgov-client feature complains about overlord-rtgov-war-all-fuse6 dependency In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-528. ------------------------------ Resolution: Done > Installing rtgov-client feature complains about overlord-rtgov-war-all-fuse6 dependency > --------------------------------------------------------------------------------------- > > Key: RTGOV-528 > URL: https://issues.jboss.org/browse/RTGOV-528 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When installing rtgov-client feature I get: > {noformat} > JBossFuse:karaf at root> features:install rtgov-client > Refreshing bundles org.apache.servicemix.bundles.jaxb-xjc (152), org.ops4j.pax.url.war (239), org.ops4j.pax.web.pax-web-jsp (169), org.eclipse.jetty.aggregate.jetty-all-server (92), org.apache.servicemix.bundles.jaxb-impl (128) > Error executing command: Could not start bundle mvn:org.overlord.rtgov/overlord-rtgov-war-all-fuse6/2.0.0-SNAPSHOT/war in feature(s) rtgov-dependencies-2.0.0-SNAPSHOT, rtgov-services-2.0.0-SNAPSHOT: Unresolved constraint in bundle org.overlord.rtgov.overlord-rtgov-war-all-fuse6 [272]: Unable to resolve 272.0: missing requirement [272.0] osgi.wiring.package; (osgi.wiring.package=org.overlord.rtgov.activity.server.rest) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 08:39:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 21 Jul 2014 08:39:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-529) Add more traditional rule version of SLA example In-Reply-To: References: Message-ID: Gary Brown created RTGOV-529: -------------------------------- Summary: Add more traditional rule version of SLA example Key: RTGOV-529 URL: https://issues.jboss.org/browse/RTGOV-529 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Current version of the SLA example shows using parameterised EPN to configure a single rule. However more traditional rules should determine the decision in the lefthand side of the rule, not in the body of the rule. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:45:33 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 10:45:33 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-516) Consider an "uber war" with basic functionality for any app server In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-516: --------------------------------- Summary: Consider an "uber war" with basic functionality for any app server Key: SRAMP-516 URL: https://issues.jboss.org/browse/SRAMP-516 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer For *basic* users, an "uber war", containing all dependencies, configurations, etc., could be incredibly helpful. It would most likely have to fall back on basic auth. It could possibly skip the UI entirely and instead focus purely on the repo/server/cli. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:47:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 10:47:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-517) Support Wildfly In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-517: --------------------------------- Summary: Support Wildfly Key: SRAMP-517 URL: https://issues.jboss.org/browse/SRAMP-517 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 10:47:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 21 Jul 2014 10:47:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-516) Consider an "uber war" with basic functionality for any app server In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986700#comment-12986700 ] Eric Wittmann commented on SRAMP-516: ------------------------------------- The UI is no problem to support as long as we can figure out a way to drop back to BASIC auth instead of SSO. Admittedly the server would be easier to support in this mode, as it *already* supports BASIC auth. It's possible that nothing in the server's web.xml needs to change for this. The UI's web.xml would *definitely* need to change, however. > Consider an "uber war" with basic functionality for any app server > ------------------------------------------------------------------ > > Key: SRAMP-516 > URL: https://issues.jboss.org/browse/SRAMP-516 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > For *basic* users, an "uber war", containing all dependencies, configurations, etc., could be incredibly helpful. It would most likely have to fall back on basic auth. It could possibly skip the UI entirely and instead focus purely on the repo/server/cli. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 11:03:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 11:03:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986710#comment-12986710 ] Brett Meyer commented on SRAMP-474: ----------------------------------- https://github.com/Governance/s-ramp/wiki/GuideOverlordSrampCLI#log-to-file > CLI: Add a log-to-file option > ----------------------------- > > Key: SRAMP-474 > URL: https://issues.jboss.org/browse/SRAMP-474 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Currently CLI batch files must be created by hand. This isn't too much of a hardship, but it might be convenient for the interactive console to help out with this by allowing the user to log all commands executed to a file. This could be the basis for a CLI batch file that the user could include in some sort of integration scenario. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 11:19:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 21 Jul 2014 11:19:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-530) Resubmit doesn't work with latest swyd snapshot In-Reply-To: References: Message-ID: Gary Brown created RTGOV-530: -------------------------------- Summary: Resubmit doesn't work with latest swyd snapshot Key: RTGOV-530 URL: https://issues.jboss.org/browse/RTGOV-530 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When resubmitting, we get: {noformat} 16:12:41,495 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/switchyard-remote].[SwitchYardRemotingServlet]] (http-localhost.localdomain/127.0.0.1:8080-6) JBWEB000236: Servlet.service() for servlet SwitchYardRemotingServlet threw exception: org.codehaus.jackson.map.JsonMappingException: Can not construct instance of org.switchyard.serial.graph.node.AccessNode, problem: abstract types can only be instantiated with additional type information at [Source: org.apache.catalina.connector.CoyoteInputStream at 168f643; line: 1, column: 93] (through reference chain: org.switchyard.serial.graph.Graph["references"]) at org.codehaus.jackson.map.JsonMappingException.from(JsonMappingException.java:163) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.StdDeserializationContext.instantiationException(StdDeserializationContext.java:233) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.AbstractDeserializer.deserialize(AbstractDeserializer.java:60) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromAny(AsArrayTypeDeserializer.java:69) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserializeWithType(UntypedObjectDeserializer.java:106) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.std.MapDeserializer._readAndBind(MapDeserializer.java:321) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:249) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:33) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromObject(AsArrayTypeDeserializer.java:55) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.std.MapDeserializer.deserializeWithType(MapDeserializer.java:273) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:297) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:414) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:697) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2732) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1909) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] at org.switchyard.serial.jackson.format.JSONJacksonSerializer.deserialize(JSONJacksonSerializer.java:82) [switchyard-serial-jackson-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] at org.switchyard.serial.graph.GraphSerializer.deserialize(GraphSerializer.java:60) [switchyard-serial-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] at org.switchyard.component.sca.SwitchYardRemotingServlet.doPost(SwitchYardRemotingServlet.java:78) [switchyard-component-sca-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 11:21:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 21 Jul 2014 11:21:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-530) Resubmit doesn't work with latest swyd snapshot In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-530: ----------------------------- Attachment: server.log > Resubmit doesn't work with latest swyd snapshot > ----------------------------------------------- > > Key: RTGOV-530 > URL: https://issues.jboss.org/browse/RTGOV-530 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: server.log > > > When resubmitting, we get: > {noformat} > 16:12:41,495 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/switchyard-remote].[SwitchYardRemotingServlet]] (http-localhost.localdomain/127.0.0.1:8080-6) JBWEB000236: Servlet.service() for servlet SwitchYardRemotingServlet threw exception: org.codehaus.jackson.map.JsonMappingException: Can not construct instance of org.switchyard.serial.graph.node.AccessNode, problem: abstract types can only be instantiated with additional type information > at [Source: org.apache.catalina.connector.CoyoteInputStream at 168f643; line: 1, column: 93] (through reference chain: org.switchyard.serial.graph.Graph["references"]) > at org.codehaus.jackson.map.JsonMappingException.from(JsonMappingException.java:163) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.StdDeserializationContext.instantiationException(StdDeserializationContext.java:233) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.AbstractDeserializer.deserialize(AbstractDeserializer.java:60) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromAny(AsArrayTypeDeserializer.java:69) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserializeWithType(UntypedObjectDeserializer.java:106) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer._readAndBind(MapDeserializer.java:321) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:249) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:33) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromObject(AsArrayTypeDeserializer.java:55) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserializeWithType(MapDeserializer.java:273) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:297) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:414) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:697) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2732) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1909) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.switchyard.serial.jackson.format.JSONJacksonSerializer.deserialize(JSONJacksonSerializer.java:82) [switchyard-serial-jackson-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at org.switchyard.serial.graph.GraphSerializer.deserialize(GraphSerializer.java:60) [switchyard-serial-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at org.switchyard.component.sca.SwitchYardRemotingServlet.doPost(SwitchYardRemotingServlet.java:78) [switchyard-component-sca-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 12:15:34 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 12:15:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-513) s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-513. ------------------------------- Resolution: Done > s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType > -------------------------------------------------------------------- > > Key: SRAMP-513 > URL: https://issues.jboss.org/browse/SRAMP-513 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > Reported by David via his 1.3.0.Beta1 Testing: > "Do we want the sources jar to be executed in the dtgov workflow? > I executed the s-ramp-demos/s-ramp-demos-switchyard and then 2 switchyard artifacts were upload, the jar, and the sources-jar. Then 2 tasks appeared in the dtgov tasks." > The answer is "no" - the -sources.jar should *not* trigger a workflow. We need to figure out why that is happening. Perhaps the s-ramp wagon is not setting the correct ArtifactType for the -sources JAR artifact? The primary artifact in the maven build should be a SwitchYardApplication. The -sources JAR should be added to s-ramp as JavaArchive (most likely). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 15:33:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 15:33:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-501) Improve the Shell Command demo README In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986818#comment-12986818 ] Brett Meyer commented on SRAMP-501: ----------------------------------- Agree with [~virchete] that it was a bit confusing. Re-worked it > Improve the Shell Command demo README > ------------------------------------- > > Key: SRAMP-501 > URL: https://issues.jboss.org/browse/SRAMP-501 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Distro, Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The README for the s-ramp-demo-shell-command is apparently not very clear. David was unable to successfully test this demo in 0.5.0.Beta1: > "Can not execute s-ramp-demos-shell-command > Copy the to s-ramp-demos-shell-command-0.5.0.Beta1.jar s-ramp-shell/s-ramp/commands > Then execute the s-ramp-shell/sramp.sh > Is not well explain the README file or at least I am not understanding how to do it." -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 15:33:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 15:33:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-501) Improve the Shell Command demo README In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-501. ------------------------------- Resolution: Done > Improve the Shell Command demo README > ------------------------------------- > > Key: SRAMP-501 > URL: https://issues.jboss.org/browse/SRAMP-501 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Distro, Shell > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The README for the s-ramp-demo-shell-command is apparently not very clear. David was unable to successfully test this demo in 0.5.0.Beta1: > "Can not execute s-ramp-demos-shell-command > Copy the to s-ramp-demos-shell-command-0.5.0.Beta1.jar s-ramp-shell/s-ramp/commands > Then execute the s-ramp-shell/sramp.sh > Is not well explain the README file or at least I am not understanding how to do it." -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 15:35:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 15:35:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Hide the download link for artifacts with no content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-495 started by Brett Meyer. > Hide the download link for artifacts with no content > ---------------------------------------------------- > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 15:39:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 15:39:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-518) s-ramp-dev-server 404's the UI root context In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-518: --------------------------------- Summary: s-ramp-dev-server 404's the UI root context Key: SRAMP-518 URL: https://issues.jboss.org/browse/SRAMP-518 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Eric Wittmann Priority: Optional 404: http://localhost:8080/s-ramp-ui works: http://localhost:8080/s-ramp-ui/index.html Really, really low priority, but we could probably make the root context work. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 21 17:07:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 21 Jul 2014 17:07:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-495) Hide the download link for artifacts with no content In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-495. ------------------------------- Resolution: Done > Hide the download link for artifacts with no content > ---------------------------------------------------- > > Key: SRAMP-495 > URL: https://issues.jboss.org/browse/SRAMP-495 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API, UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Reported by David (Beta1 testing): > The artifact content link in the s-ramp artifact details is not working: > Image related: artifact_content_link.jpeg > Link not working: http://localhost:8080/s-ramp-server/s-ramp/ext/DtgovWorkflowQuery/9e62a3ab-8a8e-4444-a198-b3070880e0e4/media -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 07:03:31 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 07:03:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-529) Add more traditional rule version of SLA example In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-529: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/160 > Add more traditional rule version of SLA example > ------------------------------------------------ > > Key: RTGOV-529 > URL: https://issues.jboss.org/browse/RTGOV-529 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Current version of the SLA example shows using parameterised EPN to configure a single rule. However more traditional rules should determine the decision in the lefthand side of the rule, not in the body of the rule. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 07:03:31 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 07:03:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-529) Add more traditional rule version of SLA example In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-529. ------------------------------ Resolution: Done > Add more traditional rule version of SLA example > ------------------------------------------------ > > Key: RTGOV-529 > URL: https://issues.jboss.org/browse/RTGOV-529 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Current version of the SLA example shows using parameterised EPN to configure a single rule. However more traditional rules should determine the decision in the lefthand side of the rule, not in the body of the rule. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 07:55:29 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Wed, 23 Jul 2014 07:55:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-531) RTGov is not properly installed on EAP 6.3 In-Reply-To: References: Message-ID: Jiri Pechanec created RTGOV-531: ----------------------------------- Summary: RTGov is not properly installed on EAP 6.3 Key: RTGOV-531 URL: https://issues.jboss.org/browse/RTGOV-531 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.Final Reporter: Jiri Pechanec Assignee: Gary Brown Priority: Blocker When a user installs the RTGov into EAP 6.3 it will modify standalone*.xml with elements that contain namespaces like {code:xml} {code} when the server is started it modifies the content of the config file into {code:xml} {code} which prevents EAP from starting second time -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 08:47:31 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Wed, 23 Jul 2014 08:47:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-532) Path for Elasticsearch node data is relative In-Reply-To: References: Message-ID: Jiri Pechanec created RTGOV-532: ----------------------------------- Summary: 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 Security Level: Public (Everyone can see) Reporter: Jiri Pechanec Assignee: Gary Brown 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.2.6#6264) From issues at jboss.org Wed Jul 23 08:49:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 08:49:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-514) Document how to use/install rtgov client in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-514. ------------------------------ Resolution: Done > Document how to use/install rtgov client in fuse > ------------------------------------------------ > > Key: RTGOV-514 > URL: https://issues.jboss.org/browse/RTGOV-514 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 08:51:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 08:51:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-533) Document rtgov (and elasticsearch) properties in standalone/domain xml In-Reply-To: References: Message-ID: Gary Brown created RTGOV-533: -------------------------------- Summary: Document rtgov (and elasticsearch) properties in standalone/domain xml Key: RTGOV-533 URL: https://issues.jboss.org/browse/RTGOV-533 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Components: Documentation Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 08:53:29 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Wed, 23 Jul 2014 08:53:29 -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 ] Jiri Pechanec updated RTGOV-532: -------------------------------- Affects 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 > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > > 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.2.6#6264) From issues at jboss.org Wed Jul 23 09:09:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 09:09:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-531) RTGov is not properly installed on EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-531: ----------------------------- Assignee: Eric Wittmann (was: Gary Brown) > RTGov is not properly installed on EAP 6.3 > ------------------------------------------ > > Key: RTGOV-531 > URL: https://issues.jboss.org/browse/RTGOV-531 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Eric Wittmann > Priority: Blocker > > When a user installs the RTGov into EAP 6.3 it will modify standalone*.xml with elements that contain namespaces like > {code:xml} > > > > > > > {code} > when the server is started it modifies the content of the config file into > {code:xml} > > > > > > > {code} > which prevents EAP from starting second time -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 09:37:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 09:37:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-534) PicketLink linkage error when rtgov installed with switchyard in EAP 6.3 In-Reply-To: References: Message-ID: Gary Brown created RTGOV-534: -------------------------------- Summary: PicketLink linkage error when rtgov installed with switchyard in EAP 6.3 Key: RTGOV-534 URL: https://issues.jboss.org/browse/RTGOV-534 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Priority: Blocker Fix For: 2.0.0.Final When rtgov is installed with swyd in EAP 6.3, the following exception occurs on startup: {noformat} 09:54:00,117 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/rtgov-ui]] (ServerService Thread Pool -- 76) JBWEB000284: Exception starting filter AuthenticationFilter: java.lang.LinkageError: loader constraint violation: when resolving method "org.picketlink.identity.federation.web.util.ConfigurationUtil.getConfiguration(Ljava/io/InputStreamLorg/picketlink/config/federation/PicketLinkType;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/picketlink/identity/federation/web/filters/SamlSPFilter, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for resolved class, org/picketlink/identity/federation/web/util/ConfigurationUtil, have different Class objects for the type org/picketlink/config/federation/PicketLinkType used in the signature at org.picketlink.identity.federation.web.filters.SamlSPFilter.init(SamlSPFilter.java:391) [overlord-commons-auth-2.0.3-SNAPSHOT.jar:2.0.3-SNAPSHOT] at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:416) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3225) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3791) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:154) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:58) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:91) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_25] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_25] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25] at org.jboss.threads.JBossThread.run(JBossThread.java:122) {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 10:13:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 23 Jul 2014 10:13:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-531) RTGov is not properly installed on EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated RTGOV-531: -------------------------------- Issue Type: Bug (was: Feature Request) > RTGov is not properly installed on EAP 6.3 > ------------------------------------------ > > Key: RTGOV-531 > URL: https://issues.jboss.org/browse/RTGOV-531 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Eric Wittmann > Priority: Blocker > > When a user installs the RTGov into EAP 6.3 it will modify standalone*.xml with elements that contain namespaces like > {code:xml} > > > > > > > {code} > when the server is started it modifies the content of the config file into > {code:xml} > > > > > > > {code} > which prevents EAP from starting second time -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 10:33:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 10:33:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-535) SLA monitor integration test failing In-Reply-To: References: Message-ID: Gary Brown created RTGOV-535: -------------------------------- Summary: SLA monitor integration test failing Key: RTGOV-535 URL: https://issues.jboss.org/browse/RTGOV-535 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Test indicates that it receives 6 situations but expecting 3. {noformat} org.overlord.rtgov.tests.platforms.jbossas.slamonitor.JBossASSLAMonitorTest.testActivityEventsProcessed: java.lang.AssertionError: Expecting 3 (sla situations) processed events, but got: 6 {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 12:07:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 12:07:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-534) PicketLink linkage error when rtgov installed with switchyard in EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-534: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/164 > PicketLink linkage error when rtgov installed with switchyard in EAP 6.3 > ------------------------------------------------------------------------ > > Key: RTGOV-534 > URL: https://issues.jboss.org/browse/RTGOV-534 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Blocker > Fix For: 2.0.0.Final > > > When rtgov is installed with swyd in EAP 6.3, the following exception occurs on startup: > {noformat} > 09:54:00,117 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/rtgov-ui]] (ServerService Thread Pool -- 76) JBWEB000284: Exception starting filter AuthenticationFilter: java.lang.LinkageError: loader constraint violation: when resolving method "org.picketlink.identity.federation.web.util.ConfigurationUtil.getConfiguration(Ljava/io/InputStreamLorg/picketlink/config/federation/PicketLinkType;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/picketlink/identity/federation/web/filters/SamlSPFilter, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for resolved class, org/picketlink/identity/federation/web/util/ConfigurationUtil, have different Class objects for the type org/picketlink/config/federation/PicketLinkType used in the signature > at org.picketlink.identity.federation.web.filters.SamlSPFilter.init(SamlSPFilter.java:391) [overlord-commons-auth-2.0.3-SNAPSHOT.jar:2.0.3-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:416) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3225) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3791) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:154) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:58) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:91) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_25] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 12:07:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 23 Jul 2014 12:07:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-534) PicketLink linkage error when rtgov installed with switchyard in EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-534. ------------------------------ Resolution: Done > PicketLink linkage error when rtgov installed with switchyard in EAP 6.3 > ------------------------------------------------------------------------ > > Key: RTGOV-534 > URL: https://issues.jboss.org/browse/RTGOV-534 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Blocker > Fix For: 2.0.0.Final > > > When rtgov is installed with swyd in EAP 6.3, the following exception occurs on startup: > {noformat} > 09:54:00,117 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/rtgov-ui]] (ServerService Thread Pool -- 76) JBWEB000284: Exception starting filter AuthenticationFilter: java.lang.LinkageError: loader constraint violation: when resolving method "org.picketlink.identity.federation.web.util.ConfigurationUtil.getConfiguration(Ljava/io/InputStreamLorg/picketlink/config/federation/PicketLinkType;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/picketlink/identity/federation/web/filters/SamlSPFilter, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for resolved class, org/picketlink/identity/federation/web/util/ConfigurationUtil, have different Class objects for the type org/picketlink/config/federation/PicketLinkType used in the signature > at org.picketlink.identity.federation.web.filters.SamlSPFilter.init(SamlSPFilter.java:391) [overlord-commons-auth-2.0.3-SNAPSHOT.jar:2.0.3-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:416) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3225) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContext.start(StandardContext.java:3791) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:154) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.jboss.as.web.deployment.WebDeploymentService.access$000(WebDeploymentService.java:58) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.jboss.as.web.deployment.WebDeploymentService$1.run(WebDeploymentService.java:91) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [rt.jar:1.6.0_25] > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [rt.jar:1.6.0_25] > at java.util.concurrent.FutureTask.run(FutureTask.java:138) [rt.jar:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_25] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_25] > at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_25] > at org.jboss.threads.JBossThread.run(JBossThread.java:122) > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 13:57:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 23 Jul 2014 13:57:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-531) RTGov is not properly installed on EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987491#comment-12987491 ] Eric Wittmann commented on RTGOV-531: ------------------------------------- I can reproduce this by making any change in the JBoss Admin UI, which presumably results in the standalone.xml file being marshaled to file. My guess is that the overlord extension(s) need to do *something* in response to this event. I will investigate. > RTGov is not properly installed on EAP 6.3 > ------------------------------------------ > > Key: RTGOV-531 > URL: https://issues.jboss.org/browse/RTGOV-531 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Eric Wittmann > Priority: Blocker > > When a user installs the RTGov into EAP 6.3 it will modify standalone*.xml with elements that contain namespaces like > {code:xml} > > > > > > > {code} > when the server is started it modifies the content of the config file into > {code:xml} > > > > > > > {code} > which prevents EAP from starting second time -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 15:07:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 23 Jul 2014 15:07:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-531) RTGov is not properly installed on EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated RTGOV-531: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/92 > RTGov is not properly installed on EAP 6.3 > ------------------------------------------ > > Key: RTGOV-531 > URL: https://issues.jboss.org/browse/RTGOV-531 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Eric Wittmann > Priority: Blocker > > When a user installs the RTGov into EAP 6.3 it will modify standalone*.xml with elements that contain namespaces like > {code:xml} > > > > > > > {code} > when the server is started it modifies the content of the config file into > {code:xml} > > > > > > > {code} > which prevents EAP from starting second time -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 15:09:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 23 Jul 2014 15:09:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-531) RTGov is not properly installed on EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved RTGOV-531. --------------------------------- Resolution: Done This was simply a bug in the subsystem parsing (marshaling) code. All fixed now, thanks for finding this [~jpechanec]. > RTGov is not properly installed on EAP 6.3 > ------------------------------------------ > > Key: RTGOV-531 > URL: https://issues.jboss.org/browse/RTGOV-531 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Eric Wittmann > Priority: Blocker > > When a user installs the RTGov into EAP 6.3 it will modify standalone*.xml with elements that contain namespaces like > {code:xml} > > > > > > > {code} > when the server is started it modifies the content of the config file into > {code:xml} > > > > > > > {code} > which prevents EAP from starting second time -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 23 15:09:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 23 Jul 2014 15:09:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-531) RTGov is not properly installed on EAP 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed RTGOV-531. ------------------------------- > RTGov is not properly installed on EAP 6.3 > ------------------------------------------ > > Key: RTGOV-531 > URL: https://issues.jboss.org/browse/RTGOV-531 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.0.0.Final > Reporter: Jiri Pechanec > Assignee: Eric Wittmann > Priority: Blocker > > When a user installs the RTGov into EAP 6.3 it will modify standalone*.xml with elements that contain namespaces like > {code:xml} > > > > > > > {code} > when the server is started it modifies the content of the config file into > {code:xml} > > > > > > > {code} > which prevents EAP from starting second time -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 02:35:29 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Thu, 24 Jul 2014 02:35:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-536) Login does not work in EAP 4.3 for Kibana UI In-Reply-To: References: Message-ID: Jiri Pechanec created RTGOV-536: ----------------------------------- Summary: Login does not work in EAP 4.3 for Kibana UI Key: RTGOV-536 URL: https://issues.jboss.org/browse/RTGOV-536 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Components: User Interface Reporter: Jiri Pechanec Assignee: Gary Brown Priority: Critical When the RTGov is installed to EAP 4.3 it is not possible to log in into Kibana UI. The probalem is that web.xml is configured to use FORM-based auth using files * login.html * loginerror.html but the aforementioned fles are nowhere to be found in the war file -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 04:45:32 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Thu, 24 Jul 2014 04:45:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-537) RTGov property files should be configurable using cmd line In-Reply-To: References: Message-ID: Jiri Pechanec created RTGOV-537: ----------------------------------- Summary: RTGov property files should be configurable using cmd line Key: RTGOV-537 URL: https://issues.jboss.org/browse/RTGOV-537 Project: RTGov (Run Time Governance) Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Jiri Pechanec Assignee: Gary Brown RTGov should use OSGi admin service to allow its config files to be configurable from Karaf terminal using config:* commands -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 04:55:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 04:55:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-537) RTGov property files should be configurable using cmd line In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-537: ----------------------------- Fix Version/s: 2.1.0.Final > RTGov property files should be configurable using cmd line > ---------------------------------------------------------- > > Key: RTGOV-537 > URL: https://issues.jboss.org/browse/RTGOV-537 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > RTGov should use OSGi admin service to allow its config files to be configurable from Karaf terminal using config:* commands -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 04:57:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 04:57:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-536) Login does not work in EAP 6.3 for Kibana UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-536: ----------------------------- Summary: Login does not work in EAP 6.3 for Kibana UI (was: Login does not work in EAP 4.3 for Kibana UI) > Login does not work in EAP 6.3 for Kibana UI > -------------------------------------------- > > Key: RTGOV-536 > URL: https://issues.jboss.org/browse/RTGOV-536 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > > When the RTGov is installed to EAP 4.3 it is not possible to log in into Kibana UI. The probalem is that web.xml is configured to use FORM-based auth using files > * login.html > * loginerror.html > but the aforementioned fles are nowhere to be found in the war file -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 04:57:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 04:57:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-536) Login does not work in EAP 6.3 for Kibana UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987596#comment-12987596 ] Gary Brown commented on RTGOV-536: ---------------------------------- Hi Jiri - can you confirm how you are logging in? Are you going via the /rtgov-ui context or more direct, in which case what URL are you using? > Login does not work in EAP 6.3 for Kibana UI > -------------------------------------------- > > Key: RTGOV-536 > URL: https://issues.jboss.org/browse/RTGOV-536 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > > When the RTGov is installed to EAP 4.3 it is not possible to log in into Kibana UI. The probalem is that web.xml is configured to use FORM-based auth using files > * login.html > * loginerror.html > but the aforementioned fles are nowhere to be found in the war file -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 04:59:30 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Thu, 24 Jul 2014 04:59:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-536) Login does not work in EAP 6.3 for Kibana UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987598#comment-12987598 ] Jiri Pechanec commented on RTGOV-536: ------------------------------------- Hi, I Am going through /rtgov-ui context. I've even tried rtgov-ui/index.html > Login does not work in EAP 6.3 for Kibana UI > -------------------------------------------- > > Key: RTGOV-536 > URL: https://issues.jboss.org/browse/RTGOV-536 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > > When the RTGov is installed to EAP 4.3 it is not possible to log in into Kibana UI. The probalem is that web.xml is configured to use FORM-based auth using files > * login.html > * loginerror.html > but the aforementioned fles are nowhere to be found in the war file -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 05:17:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 05:17:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-530) Resubmit doesn't work with latest swyd snapshot In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-530: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/165 > Resubmit doesn't work with latest swyd snapshot > ----------------------------------------------- > > Key: RTGOV-530 > URL: https://issues.jboss.org/browse/RTGOV-530 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: server.log > > > When resubmitting, we get: > {noformat} > 16:12:41,495 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/switchyard-remote].[SwitchYardRemotingServlet]] (http-localhost.localdomain/127.0.0.1:8080-6) JBWEB000236: Servlet.service() for servlet SwitchYardRemotingServlet threw exception: org.codehaus.jackson.map.JsonMappingException: Can not construct instance of org.switchyard.serial.graph.node.AccessNode, problem: abstract types can only be instantiated with additional type information > at [Source: org.apache.catalina.connector.CoyoteInputStream at 168f643; line: 1, column: 93] (through reference chain: org.switchyard.serial.graph.Graph["references"]) > at org.codehaus.jackson.map.JsonMappingException.from(JsonMappingException.java:163) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.StdDeserializationContext.instantiationException(StdDeserializationContext.java:233) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.AbstractDeserializer.deserialize(AbstractDeserializer.java:60) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromAny(AsArrayTypeDeserializer.java:69) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserializeWithType(UntypedObjectDeserializer.java:106) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer._readAndBind(MapDeserializer.java:321) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:249) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:33) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromObject(AsArrayTypeDeserializer.java:55) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserializeWithType(MapDeserializer.java:273) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:297) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:414) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:697) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2732) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1909) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.switchyard.serial.jackson.format.JSONJacksonSerializer.deserialize(JSONJacksonSerializer.java:82) [switchyard-serial-jackson-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at org.switchyard.serial.graph.GraphSerializer.deserialize(GraphSerializer.java:60) [switchyard-serial-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at org.switchyard.component.sca.SwitchYardRemotingServlet.doPost(SwitchYardRemotingServlet.java:78) [switchyard-component-sca-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 05:17:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 05:17:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-530) Resubmit doesn't work with latest swyd snapshot In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-530. ------------------------------ Resolution: Done > Resubmit doesn't work with latest swyd snapshot > ----------------------------------------------- > > Key: RTGOV-530 > URL: https://issues.jboss.org/browse/RTGOV-530 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Attachments: server.log > > > When resubmitting, we get: > {noformat} > 16:12:41,495 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/switchyard-remote].[SwitchYardRemotingServlet]] (http-localhost.localdomain/127.0.0.1:8080-6) JBWEB000236: Servlet.service() for servlet SwitchYardRemotingServlet threw exception: org.codehaus.jackson.map.JsonMappingException: Can not construct instance of org.switchyard.serial.graph.node.AccessNode, problem: abstract types can only be instantiated with additional type information > at [Source: org.apache.catalina.connector.CoyoteInputStream at 168f643; line: 1, column: 93] (through reference chain: org.switchyard.serial.graph.Graph["references"]) > at org.codehaus.jackson.map.JsonMappingException.from(JsonMappingException.java:163) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.StdDeserializationContext.instantiationException(StdDeserializationContext.java:233) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.AbstractDeserializer.deserialize(AbstractDeserializer.java:60) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromAny(AsArrayTypeDeserializer.java:69) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.UntypedObjectDeserializer.deserializeWithType(UntypedObjectDeserializer.java:106) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer._readAndBind(MapDeserializer.java:321) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:249) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserialize(MapDeserializer.java:33) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer._deserialize(AsArrayTypeDeserializer.java:88) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.jsontype.impl.AsArrayTypeDeserializer.deserializeTypedFromObject(AsArrayTypeDeserializer.java:55) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.std.MapDeserializer.deserializeWithType(MapDeserializer.java:273) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:297) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.SettableBeanProperty$MethodProperty.deserializeAndSet(SettableBeanProperty.java:414) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:697) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.deser.BeanDeserializer.deserialize(BeanDeserializer.java:580) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2732) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1909) [jackson-mapper-asl-1.9.9-redhat-2.jar:1.9.9-redhat-2] > at org.switchyard.serial.jackson.format.JSONJacksonSerializer.deserialize(JSONJacksonSerializer.java:82) [switchyard-serial-jackson-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at org.switchyard.serial.graph.GraphSerializer.deserialize(GraphSerializer.java:60) [switchyard-serial-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at org.switchyard.component.sca.SwitchYardRemotingServlet.doPost(SwitchYardRemotingServlet.java:78) [switchyard-component-sca-2.0.0-SNAPSHOT.jar:2.0.0-SNAPSHOT] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:754) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) > at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 05:21:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 05:21:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-536) Login does not work in EAP 6.3 for Kibana UI In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-536. ------------------------------ Resolution: Rejected Assume you were using snapshot from master. In which case it was due to a sync issue between a change made in overlord-commons and the relevant updates being applied in rtgov. I've just committed a change that brings rtgov back in line, and uses the 2.0.3.Final version of overlord-commons, so should be more stable now. If the issue still occurs after doing an update on rtgov and rebuilding, then please reopen this issue. However I've just tested before merging the change and it worked fine. > Login does not work in EAP 6.3 for Kibana UI > -------------------------------------------- > > Key: RTGOV-536 > URL: https://issues.jboss.org/browse/RTGOV-536 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Jiri Pechanec > Assignee: Gary Brown > Priority: Critical > > When the RTGov is installed to EAP 4.3 it is not possible to log in into Kibana UI. The probalem is that web.xml is configured to use FORM-based auth using files > * login.html > * loginerror.html > but the aforementioned fles are nowhere to be found in the war file -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 05:27:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 05:27:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-538) Update installer to support fuse6.1 In-Reply-To: References: Message-ID: Gary Brown created RTGOV-538: -------------------------------- Summary: Update installer to support fuse6.1 Key: RTGOV-538 URL: https://issues.jboss.org/browse/RTGOV-538 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final RTGov now requires a keystore to be created when installing in fuse. So will need to update the distribution and ant script to invoke overlord-commons installer for fuse, and then can also copy over the initial property files. Documentation will need to be updated to reflect the change in installation approach. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 07:11:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 07:11:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-423) Support domain mode in EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-423. ------------------------------ Resolution: Done > Support domain mode in EAP > -------------------------- > > Key: RTGOV-423 > URL: https://issues.jboss.org/browse/RTGOV-423 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Kevin Conner > Fix For: 2.0.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > > Support domain mode deployment of RTGov. This will involve deploying the rtgov war as a module, and obtaining the properties the xml file (?). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 08:39:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 08:39:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reopened SRAMP-490: --------------------------------- Assignee: Eric Wittmann (was: Brett Meyer) I need to also do this for overlord commons and possibly dtgov. > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 08:39:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 08:39:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-489) Remove newlines from WAR bundle classpaths in pom.xml files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reopened SRAMP-489: --------------------------------- Assignee: Eric Wittmann (was: Brett Meyer) I need to also do this for overlord commons. > Remove newlines from WAR bundle classpaths in pom.xml files > ----------------------------------------------------------- > > Key: SRAMP-489 > URL: https://issues.jboss.org/browse/SRAMP-489 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > We use the WAR plugin to add manifest entries to support osgi in all our WARs. Currently the import packages, export packages, and bundle classpath all have newlines in their content. This is throwing off the maven pipeline for certain versions of the war plugin. > Remove all newlines from pom.xml bundle entries. > Do this for all projects: overlord-commons, s-ramp, dtgov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 09:41:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 24 Jul 2014 09:41:30 -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 updated SRAMP-380: ------------------------------ Fix Version/s: 0.5.0 (was: 0.6.0) > 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.5.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.2.6#6264) From issues at jboss.org Thu Jul 24 09:41:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 24 Jul 2014 09:41:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987709#comment-12987709 ] Brett Meyer commented on SRAMP-380: ----------------------------------- [~virchete], just a heads up, we may need to make this a priority for 0.5.0.Final... > 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.5.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.2.6#6264) From issues at jboss.org Thu Jul 24 10:33:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 10:33:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-489) Remove newlines from WAR bundle classpaths in pom.xml files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-489. --------------------------------- Resolution: Done Also this commit in overlord-commons: https://github.com/Governance/overlord-commons/commit/e562254238330348a1be6ce3ca5d631d2da8c5ff > Remove newlines from WAR bundle classpaths in pom.xml files > ----------------------------------------------------------- > > Key: SRAMP-489 > URL: https://issues.jboss.org/browse/SRAMP-489 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > We use the WAR plugin to add manifest entries to support osgi in all our WARs. Currently the import packages, export packages, and bundle classpath all have newlines in their content. This is throwing off the maven pipeline for certain versions of the war plugin. > Remove all newlines from pom.xml bundle entries. > Do this for all projects: overlord-commons, s-ramp, dtgov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:33:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 10:33:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-490) Remove version overrides for plugins (inherit from jboss-parent) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-490. --------------------------------- Resolution: Done Now resolved for overlord commons as well as dtgov. > Remove version overrides for plugins (inherit from jboss-parent) > ---------------------------------------------------------------- > > Key: SRAMP-490 > URL: https://issues.jboss.org/browse/SRAMP-490 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > In some cases we are overriding the versions of plugins in various projects (overlord-commons, s-ramp, dtgov). > We should remove any version overrides unless they are actually necessary. I don't know of any required overrides, so I think they can all be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:37:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 24 Jul 2014 10:37:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-515: ------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/87 > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:37:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 24 Jul 2014 10:37:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-515. ------------------------------- Fix Version/s: 0.5.0 Resolution: Done > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > 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 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:37:32 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 10:37:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-515: ----------------------------------- Assignee: Eric Wittmann (was: David virgil naranjo) > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:37:32 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 10:37:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987751#comment-12987751 ] Eric Wittmann commented on SRAMP-515: ------------------------------------- This was discovered to be broken in the Beta2 release. I fixed it: https://github.com/Governance/overlord-commons/commit/e562254238330348a1be6ce3ca5d631d2da8c5ff > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:39:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 10:39:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987751#comment-12987751 ] Eric Wittmann edited comment on SRAMP-515 at 7/24/14 10:37 AM: --------------------------------------------------------------- This was discovered to *still* be broken in the Beta2 release. I fixed it: https://github.com/Governance/overlord-commons/commit/e562254238330348a1be6ce3ca5d631d2da8c5ff was (Author: eric.wittmann): This was discovered to be broken in the Beta2 release. I fixed it: https://github.com/Governance/overlord-commons/commit/e562254238330348a1be6ce3ca5d631d2da8c5ff > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:39:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 10:39:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-515. ------------------------------- > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 10:47:32 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 24 Jul 2014 10:47:32 -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=12987763#comment-12987763 ] 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 POST to ON_QA > 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 > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Alpha1, 0.5.0 > > > 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.2.6#6264) From issues at jboss.org Thu Jul 24 11:49:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 11:49:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-519) Change pom.xml version property format to "version.x.y.x" In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-519: ----------------------------------- Summary: Change pom.xml version property format to "version.x.y.x" Key: SRAMP-519 URL: https://issues.jboss.org/browse/SRAMP-519 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.5.0 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.2.6#6264) From issues at jboss.org Thu Jul 24 11:55:29 2014 From: issues at jboss.org (Nick Cross (JIRA)) Date: Thu, 24 Jul 2014 11:55:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-519) Change pom.xml version property format to "version.x.y.x" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987806#comment-12987806 ] Nick Cross commented on SRAMP-519: ---------------------------------- If we could use the same format as https://github.com/jboss-integration/jboss-integration-platform-bom i.e. {{version.}} e.g. {{version.org.modeshape}} > Change pom.xml version property format to "version.x.y.x" > --------------------------------------------------------- > > Key: SRAMP-519 > URL: https://issues.jboss.org/browse/SRAMP-519 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > 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.2.6#6264) From issues at jboss.org Thu Jul 24 12:05:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 24 Jul 2014 12:05:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-520) Use BOM version of guava-gwt In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-520: ----------------------------------- Summary: Use BOM version of guava-gwt Key: SRAMP-520 URL: https://issues.jboss.org/browse/SRAMP-520 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.5.0 We're currently overriding the version of guava-gwt in s-ramp and dtgov to 14.0.1. The BOM uses 13. I don't think we need to override it to the newer version. Need to test both s-ramp and dtgov to verify. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 24 12:13:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 12:13:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-521) Change pom.xml version property format to "version.x.y.x" In-Reply-To: References: Message-ID: Gary Brown created SRAMP-521: -------------------------------- Summary: Change pom.xml version property format to "version.x.y.x" Key: SRAMP-521 URL: https://issues.jboss.org/browse/SRAMP-521 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Eric Wittmann Fix For: 0.5.0 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.2.6#6264) From issues at jboss.org Thu Jul 24 12:15:31 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 12:15:31 -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 moved SRAMP-521 to RTGOV-539: ---------------------------------------- Project: RTGov (Run Time Governance) (was: S-RAMP) Key: RTGOV-539 (was: SRAMP-521) Issue Type: Task (was: Feature Request) Fix Version/s: 2.0.0.Final (was: 0.5.0) > 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 > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Eric Wittmann > 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.2.6#6264) From issues at jboss.org Thu Jul 24 12:15:31 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 24 Jul 2014 12:15:31 -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 reassigned RTGOV-539: -------------------------------- Assignee: Gary Brown (was: Eric Wittmann) > 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 > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > 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.2.6#6264) From issues at jboss.org Fri Jul 25 02:49:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 02:49:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-394) Support domain mode in EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved SRAMP-394. ------------------------------ Fix Version/s: 0.5.0 Resolution: Done > Support domain mode in EAP > -------------------------- > > Key: SRAMP-394 > URL: https://issues.jboss.org/browse/SRAMP-394 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Kevin Conner > Fix For: 0.5.0 > > > Support domain mode deployment of SRAMP and Overlord Commons. This will involve deploying the sramp etc wars as modules, and obtaining the properties from the domain.xml file (?). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 02:51:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 02:51:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-152) Create Event Processor Network derived artifact handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987922#comment-12987922 ] Gary Brown commented on SRAMP-152: ---------------------------------- The EPN should be scanned to see whether it mentions a service type, and if so, a relationship should be established between the EPN artifact and the service(s). It should be possible to construct queries, such as: a) list all of the services that a runtime governed b) list all of the runtime governance artifacts associated with a particular service > Create Event Processor Network derived artifact handler > ------------------------------------------------------- > > Key: SRAMP-152 > URL: https://issues.jboss.org/browse/SRAMP-152 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.6.0 > > > Derive EPN as a Policy Document, from the war deployable artifact. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 02:51:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 02:51:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-152) Create Event Processor Network derived artifact handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987922#comment-12987922 ] Gary Brown edited comment on SRAMP-152 at 7/25/14 2:51 AM: ----------------------------------------------------------- The EPN should be scanned to see whether it mentions a service type, and if so, a relationship should be established between the EPN artifact and the service(s). It should be possible to construct queries, such as: a) list all of the services that a runtime governed b) list all of the runtime governance artifacts associated with a particular service (Idea came from discussion between Rick and Alan). was (Author: objectiser): The EPN should be scanned to see whether it mentions a service type, and if so, a relationship should be established between the EPN artifact and the service(s). It should be possible to construct queries, such as: a) list all of the services that a runtime governed b) list all of the runtime governance artifacts associated with a particular service > Create Event Processor Network derived artifact handler > ------------------------------------------------------- > > Key: SRAMP-152 > URL: https://issues.jboss.org/browse/SRAMP-152 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.6.0 > > > Derive EPN as a Policy Document, from the war deployable artifact. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 08:37:29 2014 From: issues at jboss.org (Nick Cross (JIRA)) Date: Fri, 25 Jul 2014 08:37:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Distribution and Modeshape In-Reply-To: References: Message-ID: Nick Cross created SRAMP-522: -------------------------------- Summary: Distribution and Modeshape Key: SRAMP-522 URL: https://issues.jboss.org/browse/SRAMP-522 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Nick Cross Assignee: Brett Meyer Fix For: 0.5.0 This is related to SRAMP-493. Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 08:49:29 2014 From: issues at jboss.org (Nick Cross (JIRA)) Date: Fri, 25 Jul 2014 08:49:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Distribution and Modeshape In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988003#comment-12988003 ] Nick Cross commented on SRAMP-522: ---------------------------------- Pull request https://github.com/Governance/s-ramp/pull/463 > Distribution and Modeshape > --------------------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 09:13:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 09:13:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-540) Enable rtgov client username and password to be supplied on the installer's commandline In-Reply-To: References: Message-ID: Gary Brown created RTGOV-540: -------------------------------- Summary: Enable rtgov client username and password to be supplied on the installer's commandline Key: RTGOV-540 URL: https://issues.jboss.org/browse/RTGOV-540 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final To enable installer to be invoked from within a common installer (e.g. IzPack). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 09:13:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 09:13:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-541) Set the JMSEPNManager password (in Fuse) based on the user input In-Reply-To: References: Message-ID: Gary Brown created RTGOV-541: -------------------------------- Summary: Set the JMSEPNManager password (in Fuse) based on the user input Key: RTGOV-541 URL: https://issues.jboss.org/browse/RTGOV-541 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Currently the JMSEPNManager password is not set to the password entered by the user in the RTGov installer. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 09:41:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 09:41:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-538) Update installer to support fuse6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-538: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/166 > Update installer to support fuse6.1 > ----------------------------------- > > Key: RTGOV-538 > URL: https://issues.jboss.org/browse/RTGOV-538 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > RTGov now requires a keystore to be created when installing in fuse. So will need to update the distribution and ant script to invoke overlord-commons installer for fuse, and then can also copy over the initial property files. > Documentation will need to be updated to reflect the change in installation approach. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 09:41:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 09:41:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-538) Update installer to support fuse6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-538. ------------------------------ Resolution: Done > Update installer to support fuse6.1 > ----------------------------------- > > Key: RTGOV-538 > URL: https://issues.jboss.org/browse/RTGOV-538 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > RTGov now requires a keystore to be created when installing in fuse. So will need to update the distribution and ant script to invoke overlord-commons installer for fuse, and then can also copy over the initial property files. > Documentation will need to be updated to reflect the change in installation approach. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 09:41:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 09:41:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-533) Document rtgov (and elasticsearch) properties in standalone/domain xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-533. ------------------------------ Resolution: Done > Document rtgov (and elasticsearch) properties in standalone/domain xml > ---------------------------------------------------------------------- > > Key: RTGOV-533 > URL: https://issues.jboss.org/browse/RTGOV-533 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Documentation > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:09:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 13:09:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Distribution and Modeshape In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-522 started by Brett Meyer. > Distribution and Modeshape > --------------------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:09:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 13:09:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Distribution and Modeshape In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-522: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/463 > Distribution and Modeshape > --------------------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:13:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 13:13:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Remove Modeshape In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-522: ------------------------------ Summary: Remove Modeshape (was: Distribution and Modeshape ) > Remove Modeshape > ----------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:13:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 13:13:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Include Modeshape 3.6 only in the community assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-522: ------------------------------ Summary: Include Modeshape 3.6 only in the community assembly (was: Remove Modeshape ) > Include Modeshape 3.6 only in the community assembly > ---------------------------------------------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:33:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 13:33:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Include Modeshape 3.6 only in the community assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-522. ------------------------------- Resolution: Done > Include Modeshape 3.6 only in the community assembly > ---------------------------------------------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:41:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 13:41:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-542) Fix integration tests to use coniguration in standalone-full.xml In-Reply-To: References: Message-ID: Gary Brown created RTGOV-542: -------------------------------- Summary: Fix integration tests to use coniguration in standalone-full.xml Key: RTGOV-542 URL: https://issues.jboss.org/browse/RTGOV-542 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Tests no longer work due to missing configuration information. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:43:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 13:43:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-523: --------------------------------- Summary: GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name Key: SRAMP-523 URL: https://issues.jboss.org/browse/SRAMP-523 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: Bundle-Name=${extension.name} API v.${spec.version} If unresolved variables exist, period, fall back on using the GAV for the name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:45:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 25 Jul 2014 13:45:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-523: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1118698 > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > Bundle-Name=${extension.name} API v.${spec.version} > If unresolved variables exist, period, fall back on using the GAV for the name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:45:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 25 Jul 2014 13:45:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988099#comment-12988099 ] RH Bugzilla Integration commented on SRAMP-523: ----------------------------------------------- Brett Meyer changed the Status of [bug 1118698|https://bugzilla.redhat.com/show_bug.cgi?id=1118698] from NEW to ASSIGNED > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > Bundle-Name=${extension.name} API v.${spec.version} > If unresolved variables exist, period, fall back on using the GAV for the name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 13:45:32 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 13:45:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-523: ------------------------------ Description: Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: {code} Bundle-Name=${extension.name} API v.${spec.version} {code} If unresolved variables exist, period, fall back on using the GAV for the name was: Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: Bundle-Name=${extension.name} API v.${spec.version} If unresolved variables exist, period, fall back on using the GAV for the name > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > {code} > Bundle-Name=${extension.name} API v.${spec.version} > {code} > If unresolved variables exist, period, fall back on using the GAV for the name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 14:55:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 14:55:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-523: ------------------------------ Description: Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: {code} Bundle-Name=${extension.name} API v.${spec.version} {code} If unresolved variables exist, period, just leave off the Bundle-Name was: Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: {code} Bundle-Name=${extension.name} API v.${spec.version} {code} If unresolved variables exist, period, fall back on using the GAV for the name > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > {code} > Bundle-Name=${extension.name} API v.${spec.version} > {code} > If unresolved variables exist, period, just leave off the Bundle-Name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 14:59:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 25 Jul 2014 14:59:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-523. ------------------------------- Fix Version/s: 0.5.0 Resolution: Done > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > {code} > Bundle-Name=${extension.name} API v.${spec.version} > {code} > If unresolved variables exist, period, just leave off the Bundle-Name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 15:03:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 25 Jul 2014 15:03:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988111#comment-12988111 ] RH Bugzilla Integration commented on SRAMP-523: ----------------------------------------------- Brett Meyer changed the Status of [bug 1118698|https://bugzilla.redhat.com/show_bug.cgi?id=1118698] from ASSIGNED to MODIFIED > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > {code} > Bundle-Name=${extension.name} API v.${spec.version} > {code} > If unresolved variables exist, period, just leave off the Bundle-Name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 17:01:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 17:01:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-543) Async sample does not work in EAP 6.1 In-Reply-To: References: Message-ID: Gary Brown created RTGOV-543: -------------------------------- Summary: Async sample does not work in EAP 6.1 Key: RTGOV-543 URL: https://issues.jboss.org/browse/RTGOV-543 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final The infinispan active map implementation is not being recognised as an active map, and therefore being returned as null to the switchyard quickstart. This means that the principal's suspend status is not being checked. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 17:05:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 17:05:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-543) Async sample does not work in EAP 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-543: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/168 > Async sample does not work in EAP 6.1 > ------------------------------------- > > Key: RTGOV-543 > URL: https://issues.jboss.org/browse/RTGOV-543 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The infinispan active map implementation is not being recognised as an active map, and therefore being returned as null to the switchyard quickstart. This means that the principal's suspend status is not being checked. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 17:05:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 17:05:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-543) Async sample does not work in EAP 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-543. ------------------------------ Resolution: Done > Async sample does not work in EAP 6.1 > ------------------------------------- > > Key: RTGOV-543 > URL: https://issues.jboss.org/browse/RTGOV-543 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The infinispan active map implementation is not being recognised as an active map, and therefore being returned as null to the switchyard quickstart. This means that the principal's suspend status is not being checked. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 17:07:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 17:07:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-544) RTGov install with no parameters fails to install in EAP due to path problem In-Reply-To: References: Message-ID: Gary Brown created RTGOV-544: -------------------------------- Summary: RTGov install with no parameters fails to install in EAP due to path problem Key: RTGOV-544 URL: https://issues.jboss.org/browse/RTGOV-544 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When the path is specified when prompted by the installer script, it is incorrectly passed to the overlord-commons installer - it appears that the path is specified twice, one appended to the other. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 17:07:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 17:07:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-544) RTGov install with no parameters fails to install in EAP due to path problem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-544: ----------------------------- Priority: Critical (was: Major) > RTGov install with no parameters fails to install in EAP due to path problem > ---------------------------------------------------------------------------- > > Key: RTGOV-544 > URL: https://issues.jboss.org/browse/RTGOV-544 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > When the path is specified when prompted by the installer script, it is incorrectly passed to the overlord-commons installer - it appears that the path is specified twice, one appended to the other. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 19:17:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 19:17:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-544) RTGov install with no parameters fails to install in EAP due to path problem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-544: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/169 > RTGov install with no parameters fails to install in EAP due to path problem > ---------------------------------------------------------------------------- > > Key: RTGOV-544 > URL: https://issues.jboss.org/browse/RTGOV-544 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > When the path is specified when prompted by the installer script, it is incorrectly passed to the overlord-commons installer - it appears that the path is specified twice, one appended to the other. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jul 25 19:17:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 25 Jul 2014 19:17:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-544) RTGov install with no parameters fails to install in EAP due to path problem In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-544. ------------------------------ Resolution: Done > RTGov install with no parameters fails to install in EAP due to path problem > ---------------------------------------------------------------------------- > > Key: RTGOV-544 > URL: https://issues.jboss.org/browse/RTGOV-544 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Critical > Fix For: 2.0.0.Final > > > When the path is specified when prompted by the installer script, it is incorrectly passed to the overlord-commons installer - it appears that the path is specified twice, one appended to the other. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 26 03:41:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sat, 26 Jul 2014 03:41:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-541) Set the JMSEPNManager password (in Fuse) based on the user input In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-541. ------------------------------ Resolution: Done > Set the JMSEPNManager password (in Fuse) based on the user input > ---------------------------------------------------------------- > > Key: RTGOV-541 > URL: https://issues.jboss.org/browse/RTGOV-541 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently the JMSEPNManager password is not set to the password entered by the user in the RTGov installer. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 26 03:41:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sat, 26 Jul 2014 03:41:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-541) Set the JMSEPNManager password (in Fuse) based on the user input In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-541: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/170 > Set the JMSEPNManager password (in Fuse) based on the user input > ---------------------------------------------------------------- > > Key: RTGOV-541 > URL: https://issues.jboss.org/browse/RTGOV-541 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently the JMSEPNManager password is not set to the password entered by the user in the RTGov installer. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 26 03:41:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sat, 26 Jul 2014 03:41:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-535) Update integration tests to use config in xml and fix SLA monitor test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-535: ----------------------------- Summary: Update integration tests to use config in xml and fix SLA monitor test (was: SLA monitor integration test failing) > Update integration tests to use config in xml and fix SLA monitor test > ---------------------------------------------------------------------- > > Key: RTGOV-535 > URL: https://issues.jboss.org/browse/RTGOV-535 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Test indicates that it receives 6 situations but expecting 3. > {noformat} > org.overlord.rtgov.tests.platforms.jbossas.slamonitor.JBossASSLAMonitorTest.testActivityEventsProcessed: java.lang.AssertionError: Expecting 3 (sla situations) processed events, but got: 6 > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 26 03:43:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sat, 26 Jul 2014 03:43:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-535) Update integration tests to use config in xml and fix SLA monitor test In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988151#comment-12988151 ] Gary Brown commented on RTGOV-535: ---------------------------------- Integration test framework needs to be updated to make use of the config in xml - or see whether old property based files will still work, as otherwise deployments need to be placed in the module structure. > Update integration tests to use config in xml and fix SLA monitor test > ---------------------------------------------------------------------- > > Key: RTGOV-535 > URL: https://issues.jboss.org/browse/RTGOV-535 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Test indicates that it receives 6 situations but expecting 3. > {noformat} > org.overlord.rtgov.tests.platforms.jbossas.slamonitor.JBossASSLAMonitorTest.testActivityEventsProcessed: java.lang.AssertionError: Expecting 3 (sla situations) processed events, but got: 6 > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jul 26 03:45:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Sat, 26 Jul 2014 03:45:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-542) Fix integration tests to use coniguration in standalone-full.xml In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-542. ------------------------------ Fix Version/s: (was: 2.0.0.Final) Resolution: Duplicate Issue Combined issue with other integration test problem RTGOV-535. > Fix integration tests to use coniguration in standalone-full.xml > ---------------------------------------------------------------- > > Key: RTGOV-542 > URL: https://issues.jboss.org/browse/RTGOV-542 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Tests no longer work due to missing configuration information. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 05:59:32 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 28 Jul 2014 05:59:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988218#comment-12988218 ] David virgil naranjo commented on SRAMP-380: -------------------------------------------- As they commented in the forum post, the encryption can be enabled modifying one configuration file located in the etc folder. The encryption is done when the user is added throw the karaf console, using the jaas commands. When a user is added, appended to the etc/users.properties, the new user line is not getting encrypted. Possibilities: Add the user/password information encrypted. By default the fuse 6.1 encryption is the MD5/Hexadecimal. The format would be something like: admin = {CRYPT}73550311dcde010200eadb8a42ef1a96{CRYPT} But if the users are added encrypted in the users.properties is MANDATORY that the encryption is enabled in the {fuse_home}/etc/org.apache.karaf.jaas.cfg > 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.5.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.2.6#6264) From issues at jboss.org Mon Jul 28 08:55:32 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 08:55:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988280#comment-12988280 ] Brett Meyer commented on SRAMP-380: ----------------------------------- Pasting some comments from [~eric.wittmann]: {quote} I'm skeptical that users.properties will be useful, although I hope I'm wrong. The reason is that users.properties is the file used by fuse/jetty to set up the default realm users and their roles. The format is: username=password,csv,list,of,roles I do not know if it can be used as a general place to stash encrypted values. While it is great if they auto-encrypt the passwords in that file on startup that only solves 1/2 of the problem. The other .5 is that we store passwords to other systems (e.g. dtgov stores an s-ramp user/password combo) that our code needs to access to work properly. RTGov client does the same thing (needs to store credentials of a potentially remote rtgov server). Again - hopefully I'm wrong but wanted you guys to understand the full scope. In EAP what we do is store the passwords in the EAP Vault, which results in a vault-string that we store in our .properties files as: ${vault:VAULT_STRING_HERE} We have a property resolver that knows how to resolve ${vault:} style properties from our .properties files (custom property resolvers is a commons-config feature). {quote} > 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.5.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.2.6#6264) From issues at jboss.org Mon Jul 28 08:55:32 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 08:55:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988280#comment-12988280 ] Brett Meyer edited comment on SRAMP-380 at 7/28/14 8:54 AM: ------------------------------------------------------------ Pasting some comments from [~eric.wittmann]: {quote} I'm skeptical that users.properties will be useful, although I hope I'm wrong. The reason is that users.properties is the file used by fuse/jetty to set up the default realm users and their roles. The format is: username=password,csv,list,of,roles I do not know if it can be used as a general place to stash encrypted values. While it is great if they auto-encrypt the passwords in that file on startup that only solves 1/2 of the problem. The other .5 is that we store passwords to other systems (e.g. dtgov stores an s-ramp user/password combo) that our code needs to access to work properly. RTGov client does the same thing (needs to store credentials of a potentially remote rtgov server). Again - hopefully I'm wrong but wanted you guys to understand the full scope. In EAP what we do is store the passwords in the EAP Vault, which results in a vault-string that we store in our .properties files as: $\{vault:VAULT_STRING_HERE\} We have a property resolver that knows how to resolve $\{vault:\} style properties from our .properties files (custom property resolvers is a commons-config feature). {quote} was (Author: brmeyer): Pasting some comments from [~eric.wittmann]: {quote} I'm skeptical that users.properties will be useful, although I hope I'm wrong. The reason is that users.properties is the file used by fuse/jetty to set up the default realm users and their roles. The format is: username=password,csv,list,of,roles I do not know if it can be used as a general place to stash encrypted values. While it is great if they auto-encrypt the passwords in that file on startup that only solves 1/2 of the problem. The other .5 is that we store passwords to other systems (e.g. dtgov stores an s-ramp user/password combo) that our code needs to access to work properly. RTGov client does the same thing (needs to store credentials of a potentially remote rtgov server). Again - hopefully I'm wrong but wanted you guys to understand the full scope. In EAP what we do is store the passwords in the EAP Vault, which results in a vault-string that we store in our .properties files as: ${vault:VAULT_STRING_HERE} We have a property resolver that knows how to resolve ${vault:} style properties from our .properties files (custom property resolvers is a commons-config feature). {quote} > 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.5.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.2.6#6264) From issues at jboss.org Mon Jul 28 10:01:32 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 10:01:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-511) Create a Fuse console command for creating the SAML keystore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-511: ------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/88 > Create a Fuse console command for creating the SAML keystore > ------------------------------------------------------------ > > Key: SRAMP-511 > URL: https://issues.jboss.org/browse/SRAMP-511 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0 > > > The console command should create a keystore and populate it with a new KeyPair. It should prompt the user for the password(s) and store the result in the correct place for Fuse/Fabric8. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 10:29:32 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 28 Jul 2014 10:29:32 -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 ] David virgil naranjo updated SRAMP-380: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/94 > 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.5.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.2.6#6264) From issues at jboss.org Mon Jul 28 11:53:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 11:53:30 -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 updated SRAMP-380: ------------------------------ Fix Version/s: 0.6.0 (was: 0.5.0) > 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.2.6#6264) From issues at jboss.org Mon Jul 28 11:53:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 11:53:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-380) Passwords in clear text when running in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988372#comment-12988372 ] Brett Meyer commented on SRAMP-380: ----------------------------------- I'm pulling this out of 0.5 and delaying until 0.6. 0.5 has been pretty volatile and this seems like a somewhat risky change across all projects. > 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.2.6#6264) From issues at jboss.org Mon Jul 28 12:05:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 12:05:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-524) Hide DTGov and Gadget Server links on UI if dtgov/rtgov aren't reachable In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-524: --------------------------------- Summary: Hide DTGov and Gadget Server links on UI if dtgov/rtgov aren't reachable Key: SRAMP-524 URL: https://issues.jboss.org/browse/SRAMP-524 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Eric Wittmann If DTGov isn't installed, can we hide the "DTGov" link from the S-RAMP UI nav? Similarly, does "Gadget Server" == RTGov? Should that be renamed and also dynamically hidden? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 13:33:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 28 Jul 2014 13:33:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-524) Hide DTGov and Gadget Server links on UI if dtgov/rtgov aren't reachable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988414#comment-12988414 ] Eric Wittmann commented on SRAMP-524: ------------------------------------- The other tabs should not show up if those projects are not installed. The UI header tabs are dynamically driven through configuration files/properties. It is possible that the Dev Server is over-configuring the header (assuming that is where you are seeing the extra tabs). But if deployed to EAP or any other runtime you should only see those tabs if the configuration exists for them. Not sure we want to be going out and pinging the configured tab endpoints to see if they are live... > Hide DTGov and Gadget Server links on UI if dtgov/rtgov aren't reachable > ------------------------------------------------------------------------ > > Key: SRAMP-524 > URL: https://issues.jboss.org/browse/SRAMP-524 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Eric Wittmann > > If DTGov isn't installed, can we hide the "DTGov" link from the S-RAMP UI nav? Similarly, does "Gadget Server" == RTGov? Should that be renamed and also dynamically hidden? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 13:59:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 13:59:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-524) Hide DTGov and Gadget Server links on UI if dtgov/rtgov aren't reachable In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-524. ----------------------------- Resolution: Rejected Yep, you're right -- only seeing it with the dev server, but not on a real install. Thanks > Hide DTGov and Gadget Server links on UI if dtgov/rtgov aren't reachable > ------------------------------------------------------------------------ > > Key: SRAMP-524 > URL: https://issues.jboss.org/browse/SRAMP-524 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Eric Wittmann > > If DTGov isn't installed, can we hide the "DTGov" link from the S-RAMP UI nav? Similarly, does "Gadget Server" == RTGov? Should that be renamed and also dynamically hidden? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 16:11:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 16:11:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-525) Release plugin not changing the artifact versions In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-525: --------------------------------- Summary: Release plugin not changing the artifact versions Key: SRAMP-525 URL: https://issues.jboss.org/browse/SRAMP-525 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) 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.2.6#6264) From issues at jboss.org Mon Jul 28 16:25:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 16:25:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-526: --------------------------------- Summary: s-ramp-ui.war includes .junit_symbolMaps Key: SRAMP-526 URL: https://issues.jboss.org/browse/SRAMP-526 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer The s-ramp-ui.war distribution contains a directory: app/.junit_symbolMaps which contains a number of *.symbolMap files. If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 16:27:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 28 Jul 2014 16:27:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-526: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1076450 > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 16:27:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 16:27:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-526: ------------------------------ Fix Version/s: 0.5.0 > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 16:27:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 28 Jul 2014 16:27:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988461#comment-12988461 ] RH Bugzilla Integration commented on SRAMP-526: ----------------------------------------------- Brett Meyer changed the Status of [bug 1076450|https://bugzilla.redhat.com/show_bug.cgi?id=1076450] from NEW to ASSIGNED > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 17:21:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 17:21:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-526 started by Brett Meyer. > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 17:47:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 28 Jul 2014 17:47:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-526. ------------------------------- Resolution: Done > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jul 28 17:47:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 28 Jul 2014 17:47:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988471#comment-12988471 ] RH Bugzilla Integration commented on SRAMP-526: ----------------------------------------------- Brett Meyer changed the Status of [bug 1076450|https://bugzilla.redhat.com/show_bug.cgi?id=1076450] from ASSIGNED to POST > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 04:22:31 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 29 Jul 2014 04:22:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-508) Restrict s-ramp artifacts depends on the environment In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-508: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/464 > Restrict s-ramp artifacts depends on the environment > ----------------------------------------------------- > > Key: SRAMP-508 > URL: https://issues.jboss.org/browse/SRAMP-508 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > By default the S-RAMP Maven integration should not allow maven snapshots to be deployed to the s-ramp repository (since this is not a use-case we want to encourage). However, we are planning to support maven snapshots in the code via a flag to enable/disable the support. This flag will be consumed by the maven repository facade. The flag (e.g. s-ramp.maven.enable-snapshots) will default to *false* unless the S-RAMP runtime itself is a SNAPSHOT. > This will make it easier for us during development of s-ramp and dtgov to test out our demos and dtgov seed data without changing the versions of those artifacts in their respective pom.xml files. > So in summary - the maven repo facade will not allow SNAPSHOT artifacts to be deployed unless the flag is set to true *or* the current s-ramp runtime version is a snapshot version. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 06:50:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 29 Jul 2014 06:50:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-527) Add overlord.properties to fuse fabric profile In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-527: ------------------------------------------ Summary: 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: Brett Meyer -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 06:50:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 29 Jul 2014 06:50:30 -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 ] David virgil naranjo reassigned SRAMP-527: ------------------------------------------ Assignee: David virgil naranjo (was: Brett Meyer) > 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 > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 06:52:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 29 Jul 2014 06:52:30 -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 ] David virgil naranjo updated SRAMP-527: --------------------------------------- Description: Add the overlord.properties file to the overlord fuse fabric profile. Try the deployment in fuse fabric. > 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 > > 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.2.6#6264) From issues at jboss.org Tue Jul 29 07:02:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 29 Jul 2014 07:02:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-528) Include fuse fabric installer for sramp and dtgov In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-528: ------------------------------------------ Summary: Include fuse fabric installer for sramp and dtgov Key: SRAMP-528 URL: https://issues.jboss.org/browse/SRAMP-528 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: David virgil naranjo Include a new entry in the sramp-distro and dtgov-distro assembly projects. It will generate the profiles to be deployed in fuse fabric. It will ask the user for the keystore password and generate the overlord-saml.keystore -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 09:38:31 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 29 Jul 2014 09:38:31 -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:comment-tabpanel&focusedCommentId=12988665#comment-12988665 ] David virgil naranjo commented on SRAMP-527: -------------------------------------------- The implementation is gonna be done adding the overlord.properties and keystore file to the profile. > 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 > > 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.2.6#6264) From issues at jboss.org Tue Jul 29 12:00:34 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 12:00:34 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-486) s-ramp.sh should not require JAVA_HOME to be set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988727#comment-12988727 ] RH Bugzilla Integration commented on SRAMP-486: ----------------------------------------------- Brett Meyer changed the Status of [bug 1057022|https://bugzilla.redhat.com/show_bug.cgi?id=1057022] from MODIFIED to POST > s-ramp.sh should not require JAVA_HOME to be set > ------------------------------------------------ > > Key: SRAMP-486 > URL: https://issues.jboss.org/browse/SRAMP-486 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > s-ramp.sh is the only FSW script that requires JAVA_HOME to be set. As RHEL installations by default do not set it, the requirement should be relaxed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:18:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:18:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-440) Add a final redirect filter to overlord SPs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reopened SRAMP-440: ------------------------------- > Add a final redirect filter to overlord SPs > ------------------------------------------- > > Key: SRAMP-440 > URL: https://issues.jboss.org/browse/SRAMP-440 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0 > > > The IDP (when running in tomcat, jetty, fuse) causes the browser to do a POST of the SAML assertion to the SP (e.g. s-ramp-ui). This POST is consumed by the SPFilter and the assertion is consumed. At this point the user is authenticated and the UI is loaded. > However, if the user then tries to refresh the page, the browser will likely ask if the user wishes to Resend data. > To avoid this problem we should have a filter that does a final redirect (only after a POST to the SPFilter) so that the browser finishes up with a GET request to the UI rather than a POST. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:20:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:20:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-440) Add a final redirect filter to overlord SPs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-440: ------------------------------ Fix Version/s: (was: 0.5.0) > Add a final redirect filter to overlord SPs > ------------------------------------------- > > Key: SRAMP-440 > URL: https://issues.jboss.org/browse/SRAMP-440 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > > The IDP (when running in tomcat, jetty, fuse) causes the browser to do a POST of the SAML assertion to the SP (e.g. s-ramp-ui). This POST is consumed by the SPFilter and the assertion is consumed. At this point the user is authenticated and the UI is loaded. > However, if the user then tries to refresh the page, the browser will likely ask if the user wishes to Resend data. > To avoid this problem we should have a filter that does a final redirect (only after a POST to the SPFilter) so that the browser finishes up with a GET request to the UI rather than a POST. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:20:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:20:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-440) Add a final redirect filter to overlord SPs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-440: ------------------------------ Fix Version/s: 0.5.0.Beta1 > Add a final redirect filter to overlord SPs > ------------------------------------------- > > Key: SRAMP-440 > URL: https://issues.jboss.org/browse/SRAMP-440 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Beta1 > > > The IDP (when running in tomcat, jetty, fuse) causes the browser to do a POST of the SAML assertion to the SP (e.g. s-ramp-ui). This POST is consumed by the SPFilter and the assertion is consumed. At this point the user is authenticated and the UI is loaded. > However, if the user then tries to refresh the page, the browser will likely ask if the user wishes to Resend data. > To avoid this problem we should have a filter that does a final redirect (only after a POST to the SPFilter) so that the browser finishes up with a GET request to the UI rather than a POST. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:20:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:20:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-440) Add a final redirect filter to overlord SPs In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-440. ----------------------------- Resolution: Done > Add a final redirect filter to overlord SPs > ------------------------------------------- > > Key: SRAMP-440 > URL: https://issues.jboss.org/browse/SRAMP-440 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Beta1 > > > The IDP (when running in tomcat, jetty, fuse) causes the browser to do a POST of the SAML assertion to the SP (e.g. s-ramp-ui). This POST is consumed by the SPFilter and the assertion is consumed. At this point the user is authenticated and the UI is loaded. > However, if the user then tries to refresh the page, the browser will likely ask if the user wishes to Resend data. > To avoid this problem we should have a filter that does a final redirect (only after a POST to the SPFilter) so that the browser finishes up with a GET request to the UI rather than a POST. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:32:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:32:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Include Modeshape 3.6 only in the community assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-522: ------------------------------ Fix Version/s: 0.5.0.Beta3 (was: 0.5.0) > Include Modeshape 3.6 only in the community assembly > ---------------------------------------------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0.Beta3 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:32:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:32:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-522) Include Modeshape 3.6 only in the community assembly In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-522. ----------------------------- > Include Modeshape 3.6 only in the community assembly > ---------------------------------------------------- > > Key: SRAMP-522 > URL: https://issues.jboss.org/browse/SRAMP-522 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Nick Cross > Assignee: Brett Meyer > Fix For: 0.5.0.Beta3 > > > This is related to SRAMP-493. > Rather than having to pull in two versions of modeshape even in the product version would it be possible to use a profile so that the 3.6.0 version is only required in the community distribution? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:32:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 29 Jul 2014 12:32:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-545) Console did not prompt user for password In-Reply-To: References: Message-ID: Gary Brown created RTGOV-545: -------------------------------- Summary: Console did not prompt user for password Key: RTGOV-545 URL: https://issues.jboss.org/browse/RTGOV-545 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Eric Wittmann Fix For: 2.0.0.Final When testing new EAP 6.3 with rtgov installed, went to rtgov-ui URL in chrome and it logged straight in without prompting for user to enter their password. In this case, it showed the full UI and was able to navigate to the services page and see a quickstart (switchyard) service that had been installed. But on other occasions I have just see the overlord header. When doing a browser refresh it then goes to the overlord login page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:34:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:34:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-526: ------------------------------ Fix Version/s: 0.5.0.Beta4 (was: 0.5.0) > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:36:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:36:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-437) Getting a 404 on the first attempt to access s-ramp-ui when in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reopened SRAMP-437: ------------------------------- > Getting a 404 on the first attempt to access s-ramp-ui when in Fuse 6.1 > ----------------------------------------------------------------------- > > Key: SRAMP-437 > URL: https://issues.jboss.org/browse/SRAMP-437 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > After the first time it works ok. Probably has something to do with the ;jessionid= that is getting dumped onto the end of the URL. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:36:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:36:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-437) Getting a 404 on the first attempt to access s-ramp-ui when in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-437: ------------------------------ Fix Version/s: 0.5.0.Beta1 (was: 0.5.0) > Getting a 404 on the first attempt to access s-ramp-ui when in Fuse 6.1 > ----------------------------------------------------------------------- > > Key: SRAMP-437 > URL: https://issues.jboss.org/browse/SRAMP-437 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Beta1 > > > After the first time it works ok. Probably has something to do with the ;jessionid= that is getting dumped onto the end of the URL. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:36:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:36:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-437) Getting a 404 on the first attempt to access s-ramp-ui when in Fuse 6.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-437. ----------------------------- Resolution: Done > Getting a 404 on the first attempt to access s-ramp-ui when in Fuse 6.1 > ----------------------------------------------------------------------- > > Key: SRAMP-437 > URL: https://issues.jboss.org/browse/SRAMP-437 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Beta1 > > > After the first time it works ok. Probably has something to do with the ;jessionid= that is getting dumped onto the end of the URL. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:36:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:36:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-473) S-ramp logout 500 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reopened SRAMP-473: ------------------------------- > S-ramp logout 500 error > ----------------------- > > Key: SRAMP-473 > URL: https://issues.jboss.org/browse/SRAMP-473 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > When logging out of s-ramp, it appears a 500 error: > {code} > 16:35:36,078 ERROR [org.picketlink.identity.federation.web.filters.SPFilter] (http-localhost.localdomain/127.0.0.1:8080-3) Server Exception:: java.lang.NullPointerException > at org.overlord.commons.auth.handlers.RoleCachingHandler.handleStatusResponseType(RoleCachingHandler.java:83) [overlord-commons-auth-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:296) [picketlink-federation-2.5.3.SP5-redhat-1.jar:2.5.3.SP5-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > 16:35:36,079 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-localhost.localdomain/127.0.0.1:8080-3) JBWEB000236: Servlet.service() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server Exception > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) [picketlink-federation-2.5.3.SP5-redhat-1.jar:2.5.3.SP5-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:36:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:36:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-473) S-ramp logout 500 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-473: ------------------------------ Fix Version/s: 0.5.0.Beta1 (was: 0.5.0) > S-ramp logout 500 error > ----------------------- > > Key: SRAMP-473 > URL: https://issues.jboss.org/browse/SRAMP-473 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Beta1 > > > When logging out of s-ramp, it appears a 500 error: > {code} > 16:35:36,078 ERROR [org.picketlink.identity.federation.web.filters.SPFilter] (http-localhost.localdomain/127.0.0.1:8080-3) Server Exception:: java.lang.NullPointerException > at org.overlord.commons.auth.handlers.RoleCachingHandler.handleStatusResponseType(RoleCachingHandler.java:83) [overlord-commons-auth-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:296) [picketlink-federation-2.5.3.SP5-redhat-1.jar:2.5.3.SP5-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > 16:35:36,079 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-localhost.localdomain/127.0.0.1:8080-3) JBWEB000236: Servlet.service() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server Exception > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) [picketlink-federation-2.5.3.SP5-redhat-1.jar:2.5.3.SP5-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:36:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:36:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-473) S-ramp logout 500 error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-473. ----------------------------- Resolution: Done > S-ramp logout 500 error > ----------------------- > > Key: SRAMP-473 > URL: https://issues.jboss.org/browse/SRAMP-473 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Beta1 > > > When logging out of s-ramp, it appears a 500 error: > {code} > 16:35:36,078 ERROR [org.picketlink.identity.federation.web.filters.SPFilter] (http-localhost.localdomain/127.0.0.1:8080-3) Server Exception:: java.lang.NullPointerException > at org.overlord.commons.auth.handlers.RoleCachingHandler.handleStatusResponseType(RoleCachingHandler.java:83) [overlord-commons-auth-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:296) [picketlink-federation-2.5.3.SP5-redhat-1.jar:2.5.3.SP5-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > 16:35:36,079 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/s-ramp-ui].[default]] (http-localhost.localdomain/127.0.0.1:8080-3) JBWEB000236: Servlet.service() for servlet default threw exception: javax.servlet.ServletException: PL00032: Service Provider :: Server Exception > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) [picketlink-federation-2.5.3.SP5-redhat-1.jar:2.5.3.SP5-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) [overlord-commons-gwt-2.0.2-SNAPSHOT.jar:2.0.2-SNAPSHOT] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.4.0.Final-redhat-11.jar:7.4.0.Final-redhat-11] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:340) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.4.2.Final-redhat-1.jar:7.4.2.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_55] > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:40:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:40:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reopened SRAMP-515: ------------------------------- > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:40:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:40:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-515: ------------------------------ Fix Version/s: 0.5.0.Beta3 (was: 0.5.0) > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Beta3 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:40:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:40:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-515) overlord commons installer saml password filtering In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-515. ----------------------------- Resolution: Done > overlord commons installer saml password filtering > -------------------------------------------------- > > Key: SRAMP-515 > URL: https://issues.jboss.org/browse/SRAMP-515 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Beta3 > > > The filtering in the overlord-commons installer for the properties saml-keystore password and saml-keystore alias password is not getting done in the overlord.properties file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:40:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:40:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-494) Allow the installer's password prompt to be skipped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-494: ------------------------------ Fix Version/s: 0.5.0.Beta2 (was: 0.5.0) > Allow the installer's password prompt to be skipped > --------------------------------------------------- > > Key: SRAMP-494 > URL: https://issues.jboss.org/browse/SRAMP-494 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta2 > > > The integration tests, automated installers, etc., move the password prompt into a separate target. Skip it if the password property is already set. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:40:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:40:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-513) s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-513: ------------------------------ Fix Version/s: 0.5.0.Beta2 (was: 0.5.0) > s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType > -------------------------------------------------------------------- > > Key: SRAMP-513 > URL: https://issues.jboss.org/browse/SRAMP-513 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Beta2 > > > Reported by David via his 1.3.0.Beta1 Testing: > "Do we want the sources jar to be executed in the dtgov workflow? > I executed the s-ramp-demos/s-ramp-demos-switchyard and then 2 switchyard artifacts were upload, the jar, and the sources-jar. Then 2 tasks appeared in the dtgov tasks." > The answer is "no" - the -sources.jar should *not* trigger a workflow. We need to figure out why that is happening. Perhaps the s-ramp wagon is not setting the correct ArtifactType for the -sources JAR artifact? The primary artifact in the maven build should be a SwitchYardApplication. The -sources JAR should be added to s-ramp as JavaArchive (most likely). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:42:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:42:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-394) Support domain mode in EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-394: ------------------------------ Fix Version/s: 0.5.0.Beta3 (was: 0.5.0) > Support domain mode in EAP > -------------------------- > > Key: SRAMP-394 > URL: https://issues.jboss.org/browse/SRAMP-394 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Kevin Conner > Fix For: 0.5.0.Beta3 > > > Support domain mode deployment of SRAMP and Overlord Commons. This will involve deploying the sramp etc wars as modules, and obtaining the properties from the domain.xml file (?). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:42:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:42:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-523: ------------------------------ Fix Version/s: 0.5.0.Beta3 (was: 0.5.0) > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta3 > > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > {code} > Bundle-Name=${extension.name} API v.${spec.version} > {code} > If unresolved variables exist, period, just leave off the Bundle-Name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:42:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:42:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-494) Allow the installer's password prompt to be skipped In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-494. ----------------------------- > Allow the installer's password prompt to be skipped > --------------------------------------------------- > > Key: SRAMP-494 > URL: https://issues.jboss.org/browse/SRAMP-494 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta2 > > > The integration tests, automated installers, etc., move the password prompt into a separate target. Skip it if the password property is already set. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:42:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:42:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-513) s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-513. ----------------------------- > s-ramp-wagon should use JavaArchive for a sources JAR's ArtifactType > -------------------------------------------------------------------- > > Key: SRAMP-513 > URL: https://issues.jboss.org/browse/SRAMP-513 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Beta2 > > > Reported by David via his 1.3.0.Beta1 Testing: > "Do we want the sources jar to be executed in the dtgov workflow? > I executed the s-ramp-demos/s-ramp-demos-switchyard and then 2 switchyard artifacts were upload, the jar, and the sources-jar. Then 2 tasks appeared in the dtgov tasks." > The answer is "no" - the -sources.jar should *not* trigger a workflow. We need to figure out why that is happening. Perhaps the s-ramp wagon is not setting the correct ArtifactType for the -sources JAR artifact? The primary artifact in the maven build should be a SwitchYardApplication. The -sources JAR should be added to s-ramp as JavaArchive (most likely). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:42:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:42:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-523) GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-523. ----------------------------- > GenerateFeaturesXmlMojo should prevent illegal chars in Bundle-Name > ------------------------------------------------------------------- > > Key: SRAMP-523 > URL: https://issues.jboss.org/browse/SRAMP-523 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta3 > > > Productization apparently overrides the Maven project names. When they reach GenerateFeaturesXmlMojo, there are un-resolved variables. The Bundle-Name ends up looking like: > {code} > Bundle-Name=${extension.name} API v.${spec.version} > {code} > If unresolved variables exist, period, just leave off the Bundle-Name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:42:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 12:42:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-394) Support domain mode in EAP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer closed SRAMP-394. ----------------------------- > Support domain mode in EAP > -------------------------- > > Key: SRAMP-394 > URL: https://issues.jboss.org/browse/SRAMP-394 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Kevin Conner > Fix For: 0.5.0.Beta3 > > > Support domain mode deployment of SRAMP and Overlord Commons. This will involve deploying the sramp etc wars as modules, and obtaining the properties from the domain.xml file (?). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:52:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 12:52:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-526) s-ramp-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988740#comment-12988740 ] RH Bugzilla Integration commented on SRAMP-526: ----------------------------------------------- Brett Meyer changed the Status of [bug 1076450|https://bugzilla.redhat.com/show_bug.cgi?id=1076450] from POST to MODIFIED > s-ramp-ui.war includes .junit_symbolMaps > ---------------------------------------- > > Key: SRAMP-526 > URL: https://issues.jboss.org/browse/SRAMP-526 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > The s-ramp-ui.war distribution contains a directory: > app/.junit_symbolMaps > which contains a number of *.symbolMap files. > If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:52:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 12:52:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-507) Modify way the snapshot artifacts are stored in s-ramp In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988741#comment-12988741 ] RH Bugzilla Integration commented on SRAMP-507: ----------------------------------------------- Brett Meyer changed the Status of [bug 1060773|https://bugzilla.redhat.com/show_bug.cgi?id=1060773] from POST to MODIFIED > Modify way the snapshot artifacts are stored in s-ramp > ------------------------------------------------------ > > Key: SRAMP-507 > URL: https://issues.jboss.org/browse/SRAMP-507 > 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.Beta2 > > > Include a property mvn.snapshot.timestamp (in case the name contains the timestamp) > When deploying a snapshot artifact, maven will include a timestamp in the filename. The maven repository facade *and* the s-ramp wagon should be updated to store this timestamp info in a new s-ramp property (see above). In addition, the s-ramp wagon should no longer *ever* attempt to update an artifact. Here is what it should do: > h4. Release artifacts > * If this artifact (GAV) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it > h4. Snapshot artifacts > * If this artifact (GAV + timestamp) already exists in s-ramp, fail > * If this artifact doesn't yet exist, add it along with its timestamp information -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 12:54:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 12:54:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-486) s-ramp.sh should not require JAVA_HOME to be set In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-486?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988743#comment-12988743 ] RH Bugzilla Integration commented on SRAMP-486: ----------------------------------------------- Brett Meyer changed the Status of [bug 1057022|https://bugzilla.redhat.com/show_bug.cgi?id=1057022] from POST to MODIFIED > s-ramp.sh should not require JAVA_HOME to be set > ------------------------------------------------ > > Key: SRAMP-486 > URL: https://issues.jboss.org/browse/SRAMP-486 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta2 > > > s-ramp.sh is the only FSW script that requires JAVA_HOME to be set. As RHEL installations by default do not set it, the requirement should be relaxed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:04:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 13:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-529: --------------------------------- Summary: Changing the ModeShape repo or local-cache name breaks S-RAMP Key: SRAMP-529 URL: https://issues.jboss.org/browse/SRAMP-529 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer https://bugzilla.redhat.com/show_bug.cgi?id=1060678 https://bugzilla.redhat.com/show_bug.cgi?id=1028951 First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:06:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 13:06:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-529: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > https://bugzilla.redhat.com/show_bug.cgi?id=1028951 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:06:30 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 13:06:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-529: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060678, https://bugzilla.redhat.com/show_bug.cgi?id=1028951 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1060678) > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > https://bugzilla.redhat.com/show_bug.cgi?id=1028951 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:06:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 13:06:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988747#comment-12988747 ] RH Bugzilla Integration commented on SRAMP-529: ----------------------------------------------- Brett Meyer changed the Status of [bug 1028951|https://bugzilla.redhat.com/show_bug.cgi?id=1028951] from NEW to ASSIGNED > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > https://bugzilla.redhat.com/show_bug.cgi?id=1028951 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:06:31 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 13:06:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988748#comment-12988748 ] RH Bugzilla Integration commented on SRAMP-529: ----------------------------------------------- Brett Meyer changed the Status of [bug 1060678|https://bugzilla.redhat.com/show_bug.cgi?id=1060678] from NEW to ASSIGNED > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > https://bugzilla.redhat.com/show_bug.cgi?id=1028951 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:06:31 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 29 Jul 2014 13:06:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-530) dtgov-ui.war includes .junit_symbolMaps In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-530: ----------------------------------- Summary: dtgov-ui.war includes .junit_symbolMaps Key: SRAMP-530 URL: https://issues.jboss.org/browse/SRAMP-530 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Fix For: 0.5.0.Beta4 The s-ramp-ui.war distribution contains a directory: app/.junit_symbolMaps which contains a number of *.symbolMap files. If these files aren't needed at run time, they should be removed from the deployed war. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:08:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 13:08:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-529: ------------------------------ Fix Version/s: 0.5.0.Beta4 > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > https://bugzilla.redhat.com/show_bug.cgi?id=1028951 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:38:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 13:38:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-529: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060678 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1060678, https://bugzilla.redhat.com/show_bug.cgi?id=1028951) > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > https://bugzilla.redhat.com/show_bug.cgi?id=1028951 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:40:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 13:40:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-529: ------------------------------ Description: https://bugzilla.redhat.com/show_bug.cgi?id=1060678 First, try setting it up to fully rebuild the indexes upon restart... was: https://bugzilla.redhat.com/show_bug.cgi?id=1060678 https://bugzilla.redhat.com/show_bug.cgi?id=1028951 First, try setting it up to fully rebuild the indexes upon restart... > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:40:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 13:40:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo or local-cache name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-529: ------------------------------ Comment: was deleted (was: Brett Meyer changed the Status of [bug 1028951|https://bugzilla.redhat.com/show_bug.cgi?id=1028951] from NEW to ASSIGNED) > Changing the ModeShape repo or local-cache name breaks S-RAMP > ------------------------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 13:40:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 13:40:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-529: ------------------------------ Summary: Changing the ModeShape repo name breaks S-RAMP (was: Changing the ModeShape repo or local-cache name breaks S-RAMP) > Changing the ModeShape repo name breaks S-RAMP > ---------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 14:04:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 14:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated SRAMP-529: ------------------------------------------ Bugzilla Update: (was: Perform) Bugzilla References: (was: https://bugzilla.redhat.com/show_bug.cgi?id=1060678) > Changing the ModeShape repo name breaks S-RAMP > ---------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 14:06:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 14:06:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-529) Changing the ModeShape repo name breaks S-RAMP In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer deleted SRAMP-529: ------------------------------ > Changing the ModeShape repo name breaks S-RAMP > ---------------------------------------------- > > Key: SRAMP-529 > URL: https://issues.jboss.org/browse/SRAMP-529 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > https://bugzilla.redhat.com/show_bug.cgi?id=1060678 > First, try setting it up to fully rebuild the indexes upon restart... -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 14:08:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 14:08:29 -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: Brett Meyer created OVERLORD-117: ------------------------------------ Summary: 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 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 14:08:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 14:08:30 -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 updated OVERLORD-117: --------------------------------- Description: Similar to S-RAMP, DTGov, and RTGov, pull the Fabric profiles into a separate dist within overlord-commons. > 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.2.6#6264) From issues at jboss.org Tue Jul 29 14:28:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 29 Jul 2014 14:28:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-546) Deadlock when installing rtgov and switchyard in fuse In-Reply-To: References: Message-ID: Gary Brown created RTGOV-546: -------------------------------- Summary: Deadlock when installing rtgov and switchyard in fuse Key: RTGOV-546 URL: https://issues.jboss.org/browse/RTGOV-546 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final [~kconner] found a deadlock when trying to install rtgov and switchyard into fuse. Seems to be related to a known karaf issue: https://issues.apache.org/jira/browse/KARAF-2256 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 16:08:29 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 29 Jul 2014 16:08:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-479) Enable SRAMP (modeshape) to use remote data cache provided by JDG In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988778#comment-12988778 ] RH Bugzilla Integration commented on SRAMP-479: ----------------------------------------------- Brett Meyer changed the Status of [bug 1029034|https://bugzilla.redhat.com/show_bug.cgi?id=1029034] from NEW to CLOSED > Enable SRAMP (modeshape) to use remote data cache provided by JDG > ----------------------------------------------------------------- > > Key: SRAMP-479 > URL: https://issues.jboss.org/browse/SRAMP-479 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > > Exception occurs when modeshape configured to use remote JDG. > See BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1029034 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 16:30:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 16:30:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-450) S-ramp installer && S-ramp-distro add fabric as a new target In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-450. ------------------------------- Resolution: Done > S-ramp installer && S-ramp-distro add fabric as a new target > ------------------------------------------------------------ > > Key: SRAMP-450 > URL: https://issues.jboss.org/browse/SRAMP-450 > 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.Beta4 > > > Create a new target deployment in both the s-ramp-installer and s-ramp-distro-assembly. > The Fabric deployment needs to unzip the overlord-commons.profile zip and the s-ramp-profile.zip inside the fabric installation. > The question is, what to do with the keystore and the references to the keystore from the sramp-ui.properties? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 16:32:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 29 Jul 2014 16:32:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-547) Policy quickstarts not working fabric In-Reply-To: References: Message-ID: Gary Brown created RTGOV-547: -------------------------------- Summary: Policy quickstarts not working fabric Key: RTGOV-547 URL: https://issues.jboss.org/browse/RTGOV-547 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final When rtgov installed in fabric, the SLA quickstart works (records errors in the log), but the policy examples don't work and don't register any exceptions. The common aspect with the policy quickstarts is that they use mvel, whereas the SLA quickstart uses drools. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 16:34:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 29 Jul 2014 16:34:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-545) Console did not prompt user for password In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988780#comment-12988780 ] Gary Brown commented on RTGOV-545: ---------------------------------- Tried the same thing on Fuse/Chrome and it worked fine - prompted for username/password straightaway. > Console did not prompt user for password > ---------------------------------------- > > Key: RTGOV-545 > URL: https://issues.jboss.org/browse/RTGOV-545 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Eric Wittmann > Fix For: 2.0.0.Final > > > When testing new EAP 6.3 with rtgov installed, went to rtgov-ui URL in chrome and it logged straight in without prompting for user to enter their password. > In this case, it showed the full UI and was able to navigate to the services page and see a quickstart (switchyard) service that had been installed. But on other occasions I have just see the overlord header. > When doing a browser refresh it then goes to the overlord login page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 16:48:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 16:48:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-511) Create a Fuse console command for creating the SAML keystore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-511?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-511. ------------------------------- Resolution: Done > Create a Fuse console command for creating the SAML keystore > ------------------------------------------------------------ > > Key: SRAMP-511 > URL: https://issues.jboss.org/browse/SRAMP-511 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Beta4 > > > The console command should create a keystore and populate it with a new KeyPair. It should prompt the user for the password(s) and store the result in the correct place for Fuse/Fabric8. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jul 29 16:56:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Tue, 29 Jul 2014 16:56:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-519) Change pom.xml version property format to "version.x.y.x" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-519: --------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > Change pom.xml version property format to "version.x.y.x" > --------------------------------------------------------- > > Key: SRAMP-519 > URL: https://issues.jboss.org/browse/SRAMP-519 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > 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.2.6#6264) From issues at jboss.org Wed Jul 30 06:04:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 30 Jul 2014 06:04:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-548) Create maven archetypes for RTGov In-Reply-To: References: Message-ID: Gary Brown created RTGOV-548: -------------------------------- Summary: Create maven archetypes for RTGov Key: RTGOV-548 URL: https://issues.jboss.org/browse/RTGOV-548 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: David virgil naranjo Fix For: 2.1.0.Final Create maven archetypes for the RTGov governance artifacts for JEE and OSGi. The archetypes intended for JEE will create war files, the ones intended for OSGi will create jars. The samples can be used to identify the contents of these wars/jars. The archetypes will be required to create a basic template for the Event Processor Networks (EPN), Activity Validators (AV), Information Processors (IP) and Active Collection Sources (ACS). Users will then add specific details manually, including details in the relevant json files, and any additional dependencies. One specific note - when a war is deployed in EAP (and eventually WildFly), it will use the dependency (currently defined in the manifest) on overlord-rtgov.war to obtain its dependencies. When we support other JEE containers, then we may need to ask the user for the specific container and change the created maven project accordingly. So this work can either create a single archetype which requests details about which artifact is being created, and whether OSGi or JEE, or could be separate archetypes. I think my preference currently is a single archetype that asks questions to determine what should be created, as this can then easily evolve as changes are required. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 10:02:32 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 30 Jul 2014 10:02:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-531) Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-531: --------------------------------- Summary: Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side Key: SRAMP-531 URL: https://issues.jboss.org/browse/SRAMP-531 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Currently, artifacts are expanded w/ ZipToSrampArchiveRegistry/ZipToSrampArchive in multiple locations client-side. See: - shell's UploadArtifactCommand and DeployCommand - ui's ArtifactUploadServlet - wagon's SrampWagon - server's Maven facade (MavenRepositoryServiceImpl) Consider moving the expansion somewhere central and server-side. If the concern was that it's not spec-compliant, consider moving the expanders out of the atom module and create something isolated. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 10:02:32 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 30 Jul 2014 10:02:32 -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 ] David virgil naranjo updated SRAMP-527: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/95 > 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 > > 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.2.6#6264) From issues at jboss.org Wed Jul 30 10:04:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 30 Jul 2014 10:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-531) Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989140#comment-12989140 ] Brett Meyer commented on SRAMP-531: ----------------------------------- [~eric.wittmann], any other thoughts? > Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side > --------------------------------------------------------------------------- > > Key: SRAMP-531 > URL: https://issues.jboss.org/browse/SRAMP-531 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, artifacts are expanded w/ ZipToSrampArchiveRegistry/ZipToSrampArchive in multiple locations client-side. See: > - shell's UploadArtifactCommand and DeployCommand > - ui's ArtifactUploadServlet > - wagon's SrampWagon > - server's Maven facade (MavenRepositoryServiceImpl) > Consider moving the expansion somewhere central and server-side. > If the concern was that it's not spec-compliant, consider moving the expanders out of the atom module and create something isolated. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 10:26:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 30 Jul 2014 10:26:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-548) Create maven archetypes for RTGov In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989147#comment-12989147 ] Gary Brown commented on RTGOV-548: ---------------------------------- Initially should create pom's using the sramp wagon (if the user wants to deploy to sramp and then can also be requested to enter the sramp URL). Instructions here: http://docs.jboss.org/overlord/sramp/0.5.0.Beta3/html/_overlord_s_ramp_maven_integration.html > Create maven archetypes for RTGov > --------------------------------- > > Key: RTGOV-548 > URL: https://issues.jboss.org/browse/RTGOV-548 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 2.1.0.Final > > > Create maven archetypes for the RTGov governance artifacts for JEE and OSGi. > The archetypes intended for JEE will create war files, the ones intended for OSGi will create jars. The samples can be used to identify the contents of these wars/jars. > The archetypes will be required to create a basic template for the Event Processor Networks (EPN), Activity Validators (AV), Information Processors (IP) and Active Collection Sources (ACS). Users will then add specific details manually, including details in the relevant json files, and any additional dependencies. > One specific note - when a war is deployed in EAP (and eventually WildFly), it will use the dependency (currently defined in the manifest) on overlord-rtgov.war to obtain its dependencies. When we support other JEE containers, then we may need to ask the user for the specific container and change the created maven project accordingly. > So this work can either create a single archetype which requests details about which artifact is being created, and whether OSGi or JEE, or could be separate archetypes. > I think my preference currently is a single archetype that asks questions to determine what should be created, as this can then easily evolve as changes are required. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 10:26:29 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 30 Jul 2014 10:26:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-118) xmlsec problem in fuse fabric overlord deployments In-Reply-To: References: Message-ID: David virgil naranjo created OVERLORD-118: --------------------------------------------- Summary: xmlsec problem in fuse fabric overlord deployments Key: OVERLORD-118 URL: https://issues.jboss.org/browse/OVERLORD-118 Project: Overlord Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: Eric Wittmann There is a ClassCastException when, for example s-ramp is deployed. It is related to the xmlsec library used by picketlink library: https://gist.github.com/dvirgiln/9aab25fe9f69effbf3f9 It is related to this issue: https://issues.jboss.org/browse/ENTESB-1620 But making the changes specified as solution, the same exception continues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 10:34:30 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 30 Jul 2014 10:34:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-532) Tag RTGov deployable artifacts with appropriate type In-Reply-To: References: Message-ID: Gary Brown created SRAMP-532: -------------------------------- Summary: Tag RTGov deployable artifacts with appropriate type Key: SRAMP-532 URL: https://issues.jboss.org/browse/SRAMP-532 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Brett Meyer Fix For: 0.5.0.Beta4 RTGov deployable artifacts can be created as jars (for OSGi) and wars (for JEE). There are four types of artifact, identified by a JSON file in their root: Event Processor Network - epn.json Activity Validator - av.json Information Processor - ip.json Active Collection Source - acs.json If each of these types can have a classification. Additionally, as part of the RTGov tooling work, a templating approach is likely to be used to help create instances of these deployable artifacts from parameterised versions. These templated instances would need to be classified differently. To identify a templated approach, a "-template.json" name will be used, e.g. the Event Processor Network template would be "epn-template.json". So if each of these file names could be used to classify the templated versions. Therefore 8 classifications in total should be catered for. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 10:36:44 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 30 Jul 2014 10:36:44 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-118) xmlsec problem in fuse fabric overlord deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reassigned OVERLORD-118: ----------------------------------- Assignee: Gary Brown (was: Eric Wittmann) > xmlsec problem in fuse fabric overlord deployments > -------------------------------------------------- > > Key: OVERLORD-118 > URL: https://issues.jboss.org/browse/OVERLORD-118 > Project: Overlord > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Gary Brown > > There is a ClassCastException when, for example s-ramp is deployed. It is related to the xmlsec library used by picketlink library: > https://gist.github.com/dvirgiln/9aab25fe9f69effbf3f9 > It is related to this issue: > https://issues.jboss.org/browse/ENTESB-1620 > But making the changes specified as solution, the same exception continues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 14:54:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 30 Jul 2014 14:54:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (OVERLORD-118) xmlsec problem in fuse fabric overlord deployments In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/OVERLORD-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989259#comment-12989259 ] Eric Wittmann commented on OVERLORD-118: ---------------------------------------- An xmlsec bundle may be getting installed somewhere along the lines. I would recommend scouring through the profile and see if one is being installed accidentally. > xmlsec problem in fuse fabric overlord deployments > -------------------------------------------------- > > Key: OVERLORD-118 > URL: https://issues.jboss.org/browse/OVERLORD-118 > Project: Overlord > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Gary Brown > > There is a ClassCastException when, for example s-ramp is deployed. It is related to the xmlsec library used by picketlink library: > https://gist.github.com/dvirgiln/9aab25fe9f69effbf3f9 > It is related to this issue: > https://issues.jboss.org/browse/ENTESB-1620 > But making the changes specified as solution, the same exception continues. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 15:14:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 30 Jul 2014 15:14:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-531) Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-531?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989263#comment-12989263 ] Eric Wittmann commented on SRAMP-531: ------------------------------------- I'm in favor of this in general. I think it's very problematic to have it working client-side. The advantage of course would be that our clients would provide the expander feature regardless of the server impl. Not sure that's much of one. > Consider moving ZipToSrampArchiveRegistry/ZipToSrampArchive use server-side > --------------------------------------------------------------------------- > > Key: SRAMP-531 > URL: https://issues.jboss.org/browse/SRAMP-531 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > Currently, artifacts are expanded w/ ZipToSrampArchiveRegistry/ZipToSrampArchive in multiple locations client-side. See: > - shell's UploadArtifactCommand and DeployCommand > - ui's ArtifactUploadServlet > - wagon's SrampWagon > - server's Maven facade (MavenRepositoryServiceImpl) > Consider moving the expansion somewhere central and server-side. > If the concern was that it's not spec-compliant, consider moving the expanders out of the atom module and create something isolated. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 15:22:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 30 Jul 2014 15:22:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-533) Wire ZipToSrampArchiveProvider#getArchiveTypeHints up to the UI In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-533: --------------------------------- Summary: Wire ZipToSrampArchiveProvider#getArchiveTypeHints up to the UI Key: SRAMP-533 URL: https://issues.jboss.org/browse/SRAMP-533 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Uploading an artifact through the UI doesn't kick off ZipToSrampArchiveProvider#getArchiveTypeHints to go through all the integration projects and attempt to discover what to use. Make it so! -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 18:02:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 30 Jul 2014 18:02:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-532) Create RTGov artifact types and expander In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-532: ------------------------------ Summary: Create RTGov artifact types and expander (was: Tag RTGov deployable artifacts with appropriate type) > Create RTGov artifact types and expander > ---------------------------------------- > > Key: SRAMP-532 > URL: https://issues.jboss.org/browse/SRAMP-532 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > RTGov deployable artifacts can be created as jars (for OSGi) and wars (for JEE). > There are four types of artifact, identified by a JSON file in their root: > Event Processor Network - epn.json > Activity Validator - av.json > Information Processor - ip.json > Active Collection Source - acs.json > If each of these types can have a classification. > Additionally, as part of the RTGov tooling work, a templating approach is likely to be used to help create instances of these deployable artifacts from parameterised versions. These templated instances would need to be classified differently. To identify a templated approach, a "-template.json" name will be used, e.g. the Event Processor Network template would be "epn-template.json". > So if each of these file names could be used to classify the templated versions. > Therefore 8 classifications in total should be catered for. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 18:04:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 30 Jul 2014 18:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-532) Create RTGov artifact types and expander In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-532: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/465 > Create RTGov artifact types and expander > ---------------------------------------- > > Key: SRAMP-532 > URL: https://issues.jboss.org/browse/SRAMP-532 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > RTGov deployable artifacts can be created as jars (for OSGi) and wars (for JEE). > There are four types of artifact, identified by a JSON file in their root: > Event Processor Network - epn.json > Activity Validator - av.json > Information Processor - ip.json > Active Collection Source - acs.json > If each of these types can have a classification. > Additionally, as part of the RTGov tooling work, a templating approach is likely to be used to help create instances of these deployable artifacts from parameterised versions. These templated instances would need to be classified differently. To identify a templated approach, a "-template.json" name will be used, e.g. the Event Processor Network template would be "epn-template.json". > So if each of these file names could be used to classify the templated versions. > Therefore 8 classifications in total should be catered for. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jul 30 18:04:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 30 Jul 2014 18:04:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-532) Create RTGov artifact types and expander In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989292#comment-12989292 ] Brett Meyer commented on SRAMP-532: ----------------------------------- The initial artifact types and expander are complete. Note that I'm not currently deriving anything specific from the json. We could eventually look into defining new relationships, etc. Also note that this should currently be used from the Maven *wagon*, not the facade. > Create RTGov artifact types and expander > ---------------------------------------- > > Key: SRAMP-532 > URL: https://issues.jboss.org/browse/SRAMP-532 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > RTGov deployable artifacts can be created as jars (for OSGi) and wars (for JEE). > There are four types of artifact, identified by a JSON file in their root: > Event Processor Network - epn.json > Activity Validator - av.json > Information Processor - ip.json > Active Collection Source - acs.json > If each of these types can have a classification. > Additionally, as part of the RTGov tooling work, a templating approach is likely to be used to help create instances of these deployable artifacts from parameterised versions. These templated instances would need to be classified differently. To identify a templated approach, a "-template.json" name will be used, e.g. the Event Processor Network template would be "epn-template.json". > So if each of these file names could be used to classify the templated versions. > Therefore 8 classifications in total should be catered for. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 04:30:30 2014 From: issues at jboss.org (Stefan Bunciak (JIRA)) Date: Thu, 31 Jul 2014 04:30:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command In-Reply-To: References: Message-ID: Stefan Bunciak created SRAMP-534: ------------------------------------ Summary: Content assist in S-RAMP shell not working well for maven command Key: SRAMP-534 URL: https://issues.jboss.org/browse/SRAMP-534 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: Shell Affects Versions: 0.5.0.Beta3 Reporter: Stefan Bunciak Assignee: Brett Meyer Priority: Minor Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 08:24:30 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 31 Jul 2014 08:24:30 -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 ] David virgil naranjo updated SRAMP-380: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/94, https://github.com/Governance/s-ramp/pull/466 (was: https://github.com/Governance/overlord-commons/pull/94) > 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.2.6#6264) From issues at jboss.org Thu Jul 31 08:26:29 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 31 Jul 2014 08:26:29 -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 ] David virgil naranjo updated SRAMP-380: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/94, https://github.com/Governance/s-ramp/pull/466, https://github.com/Governance/overlord-commons/pull/96, https://github.com/Governance/dtgov/pull/214 (was: https://github.com/Governance/overlord-commons/pull/94, https://github.com/Governance/s-ramp/pull/466) > 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.2.6#6264) From issues at jboss.org Thu Jul 31 09:24:31 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 09:24:31 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-532) Create RTGov artifact types and expander In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-532. ------------------------------- Resolution: Done > Create RTGov artifact types and expander > ---------------------------------------- > > Key: SRAMP-532 > URL: https://issues.jboss.org/browse/SRAMP-532 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > RTGov deployable artifacts can be created as jars (for OSGi) and wars (for JEE). > There are four types of artifact, identified by a JSON file in their root: > Event Processor Network - epn.json > Activity Validator - av.json > Information Processor - ip.json > Active Collection Source - acs.json > If each of these types can have a classification. > Additionally, as part of the RTGov tooling work, a templating approach is likely to be used to help create instances of these deployable artifacts from parameterised versions. These templated instances would need to be classified differently. To identify a templated approach, a "-template.json" name will be used, e.g. the Event Processor Network template would be "epn-template.json". > So if each of these file names could be used to classify the templated versions. > Therefore 8 classifications in total should be catered for. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 11:40:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 11:40:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-519) Change pom.xml version property format to "version.x.y.x" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-519. ------------------------------- Resolution: Done > Change pom.xml version property format to "version.x.y.x" > --------------------------------------------------------- > > Key: SRAMP-519 > URL: https://issues.jboss.org/browse/SRAMP-519 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > 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.2.6#6264) From issues at jboss.org Thu Jul 31 11:42:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 11:42:29 -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 ] Brett Meyer reassigned RTGOV-539: --------------------------------- Assignee: Brett Meyer (was: Gary Brown) > 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 > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Thu Jul 31 11:50:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 11:50:30 -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 ] Work on RTGOV-539 started by Brett Meyer. > 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 > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Thu Jul 31 11:58:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 31 Jul 2014 11:58:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-535) Reset UUID of artifact when it is deleted In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-535: ----------------------------------- Summary: 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 Security Level: Public (Everyone can see) Components: Core Affects Versions: 0.5.0.Beta3 Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0.Beta4 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.2.6#6264) From issues at jboss.org Thu Jul 31 13:54:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 13:54:29 -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 ] Brett Meyer updated RTGOV-539: ------------------------------ Git Pull Request: https://github.com/Governance/rtgov/pull/175 > 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 > Security Level: Public(Everyone can see) > 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.2.6#6264) From issues at jboss.org Thu Jul 31 14:04:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 31 Jul 2014 14:04:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-519) Change pom.xml version property format to "version.x.y.z" In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-519: -------------------------------- Summary: Change pom.xml version property format to "version.x.y.z" (was: Change pom.xml version property format to "version.x.y.x") > Change pom.xml version property format to "version.x.y.z" > --------------------------------------------------------- > > Key: SRAMP-519 > URL: https://issues.jboss.org/browse/SRAMP-519 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > 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.2.6#6264) From issues at jboss.org Thu Jul 31 14:08:30 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 14:08:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-536) Change pom.xml version property format to "version.x.y.z" In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-536: --------------------------------- Summary: Change pom.xml version property format to "version.x.y.z" Key: SRAMP-536 URL: https://issues.jboss.org/browse/SRAMP-536 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0.Beta4 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.2.6#6264) From issues at jboss.org Thu Jul 31 15:20:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 15:20:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989664#comment-12989664 ] Brett Meyer commented on SRAMP-534: ----------------------------------- Others are screwed up as well: audit: jvm: Note that audit, jvm, and maven each have 1 single entry. It looks like the tab completion is chopping of chars. Example audit:showAuditTrail -> audit:ditTrail > Content assist in S-RAMP shell not working well for maven command > ----------------------------------------------------------------- > > Key: SRAMP-534 > URL: https://issues.jboss.org/browse/SRAMP-534 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > Priority: Minor > > Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 15:20:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 15:20:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-534: ------------------------------ Priority: Major (was: Minor) > Content assist in S-RAMP shell not working well for maven command > ----------------------------------------------------------------- > > Key: SRAMP-534 > URL: https://issues.jboss.org/browse/SRAMP-534 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 15:22:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 15:22:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-534 started by Brett Meyer. > Content assist in S-RAMP shell not working well for maven command > ----------------------------------------------------------------- > > Key: SRAMP-534 > URL: https://issues.jboss.org/browse/SRAMP-534 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 15:52:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 15:52:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989674#comment-12989674 ] Brett Meyer commented on SRAMP-534: ----------------------------------- Hey [~stalep], it appears that if command namespace results in a CompleteOperation with > 1 completionCandidates, tab completion works great. If there's only 1 command in the namespace, it's getting chopped off. Examples: audit:[TAB] -> audit:ditTrail (should be audit:showAuditTrail) jvm:[TAB] -> jvm:us (should be jvm:status) maven:[TAB] -> maven: (should be maven:deploy) It looks like it's chopping off namespaces.length()+1 (includes the colon). Are we expected to manually call CompleteOperation#setOffset? When Console#completeOperation hands us the CompleteOperation, #cursor == 4 and #offset == 0 (using jvm: as an example). If I include the following, it works as expected: {code} if (completeOperation.getCompletionCandidates().size() == 1) { completeOperation.setOffset(completeOperation.getCursor()); } {code} > Content assist in S-RAMP shell not working well for maven command > ----------------------------------------------------------------- > > Key: SRAMP-534 > URL: https://issues.jboss.org/browse/SRAMP-534 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 16:24:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 16:24:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989679#comment-12989679 ] Brett Meyer commented on SRAMP-534: ----------------------------------- Talked to Stale on IRC. We're expected to do that in this version of aesh, but won't have to in later versions. Correcting... > Content assist in S-RAMP shell not working well for maven command > ----------------------------------------------------------------- > > Key: SRAMP-534 > URL: https://issues.jboss.org/browse/SRAMP-534 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > > Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jul 31 16:26:29 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 31 Jul 2014 16:26:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-534) Content assist in S-RAMP shell not working well for maven command In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-534. ------------------------------- Fix Version/s: 0.5.0.Beta4 Resolution: Done > Content assist in S-RAMP shell not working well for maven command > ----------------------------------------------------------------- > > Key: SRAMP-534 > URL: https://issues.jboss.org/browse/SRAMP-534 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shell > Affects Versions: 0.5.0.Beta3 > Reporter: Stefan Bunciak > Assignee: Brett Meyer > Fix For: 0.5.0.Beta4 > > > Content assist/command completion in S-RAMP shell did not provide me with possible commands for 'maven' namespace. -- This message was sent by Atlassian JIRA (v6.2.6#6264)