From issues at jboss.org Mon Jun 2 05:01:19 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 2 Jun 2014 05:01:19 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-476) java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972265#comment-12972265 ] David virgil naranjo commented on RTGOV-476: -------------------------------------------- This error appears in the normal flow of fuse fabric deploying. But it dissapears when the deployment is debugged and there are breakpoints in to the jetty-all jar. Steps to follow to deploy without error and check that the application is deployed correctly: Steps - The s-ramp commit has not been merged yet. You can download my development from: https://github.com/dvirgiln/s-ramp/tree/SRAMP-423 Or we can wait Brett will merge on monday. Compile s-ramp and overlord-commons (the head is ok). -Extract the zip in the fuse profiles folder - Execute karaf console. Inside karaf execute these commands: fabric:create --zookeeper-password admin fabric:container-create-child --jvm-opts '-Xms1000m -Xmx1000m -agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n' root dd -Debug the s-ramp code in eclipse as remote application port 8787. -Download the jetty-all jar attach as source in the eclipse debug. -Import the breakpoints from the file attached. In case there is an error in the importing, the important ones are: - AggregateLifeCycle 184 - LoginAuthenticator 59 and 61 --> The one that throws the Login Service Not found - SegurityHandler 121 259 287 --> The one that calls the findLoginService - org.eclipse.jetty.server.Server 513 --> Reads the data from the overlord-jetty.xml. Then in the karaf console: fabric:container-add-profile dd overlord-sramp If you debug the code, in the logs: fuse_install/instances/dd/data/log/karaf.log you ll not see any exception. If you add the profile in the child container without debugging, then the exception appears. If the application is deployed without any error and you want to test s-ramp in the browser you have to add to the user that you created the fabric the overlorduser role: jaas:manage --index 3 jaas:roleadd user_name overlorduser jaas:update Then normally in the http://localhost:8182/s-ramp-ui/ should be deployed the application. > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ > ----------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-476 > URL: https://issues.jboss.org/browse/RTGOV-476 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 2.0.0.Final > > > When RTGov all configuration is deployed in a fabric child container we get the following exception: > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator at 3afffabb in org.eclipse.jetty.security.ConstraintSecurityHandler at 7ba6293f > at org.eclipse.jetty.security.authentication.LoginAuthenticator.setConfiguration(LoginAuthenticator.java:61) -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 2 10:27:16 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 2 Jun 2014 10:27:16 -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: David virgil naranjo created SRAMP-450: ------------------------------------------ Summary: 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 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.3#6260) From issues at jboss.org Mon Jun 2 10:43:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 2 Jun 2014 10:43:16 -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:comment-tabpanel&focusedCommentId=12972494#comment-12972494 ] Gary Brown commented on SRAMP-450: ---------------------------------- We need to make sure any common tasks for fabric are placed in the overlord-commons installer. Currently RTGov doesn't require the keystore, so possibly it doesn't need to go in commons. If DTGov leverages the configuration done by SRAMP, then maybe it only needs to be in SRAMP for now? Otherwise the keystore should be created in commons, and the sramp installer just setup the property file. The other thing to note is that the overlord-commons installer may be called multiple times, if different overlord sub-projects are being installed. So we need to ensure it only runs once. > 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 > > 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.3#6260) From issues at jboss.org Mon Jun 2 11:53:18 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 2 Jun 2014 11:53:18 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-486) Align deployment targets with other overlord sub-projects In-Reply-To: References: Message-ID: Gary Brown created RTGOV-486: -------------------------------- Summary: 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 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.3#6260) From issues at jboss.org Mon Jun 2 12:11:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 2 Jun 2014 12:11:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-472) Commons httpclient 3.1 vulnerability detected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-472: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/105 > Commons httpclient 3.1 vulnerability detected > --------------------------------------------- > > Key: RTGOV-472 > URL: https://issues.jboss.org/browse/RTGOV-472 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > rtgov-switchyard and karaf/features modules are reporting: > {noformat} > [WARNING] The dependency commons-httpclient-3.1 matches a vulnerability recorded in the victims database. [CVE-2012-5783] > [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > +=======================+ > |VULNERABILITY DETECTED!| > +=======================+ > For more information visit: > - https://access.redhat.com/security/cve/CVE-2012-5783 > {noformat} -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 2 12:11:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 2 Jun 2014 12:11:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-472) Commons httpclient 3.1 vulnerability detected In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-472. ------------------------------ Resolution: Done > Commons httpclient 3.1 vulnerability detected > --------------------------------------------- > > Key: RTGOV-472 > URL: https://issues.jboss.org/browse/RTGOV-472 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > rtgov-switchyard and karaf/features modules are reporting: > {noformat} > [WARNING] The dependency commons-httpclient-3.1 matches a vulnerability recorded in the victims database. [CVE-2012-5783] > [WARNING] Rule 0: com.redhat.victims.VictimsRule failed with message: > +=======================+ > |VULNERABILITY DETECTED!| > +=======================+ > For more information visit: > - https://access.redhat.com/security/cve/CVE-2012-5783 > {noformat} -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 2 12:37:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 2 Jun 2014 12:37:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-487) The JAR/ZIP file geronimo-jta_1.0.1B_spec-1.0.1.jar seems corrupted, error In-Reply-To: References: Message-ID: Gary Brown created RTGOV-487: -------------------------------- Summary: The JAR/ZIP file geronimo-jta_1.0.1B_spec-1.0.1.jar seems corrupted, error Key: RTGOV-487 URL: https://issues.jboss.org/browse/RTGOV-487 Project: RTGov (Run Time Governance) Issue Type: Bug Reporter: Gary Brown Assignee: Gary Brown Error when building in hudson: {noformat} [ERROR] Failed to execute goal org.apache.felix:maven-bundle-plugin:2.3.7:bundle (default-bundle) on project rtgov-switchyard: Error calculating classpath for project MavenProject: org.overlord.rtgov.integration:rtgov-switchyard:2.0.0-SNAPSHOT @ /qa/hudson_ws/workspace/overlord-rtgov/sources/integration/switchyard/pom.xml: The JAR/ZIP file (/qa/hudson_ws/workspace/overlord-rtgov/m2-repository/org/apache/geronimo/specs/geronimo-jta_1.0.1B_spec/1.0.1/geronimo-jta_1.0.1B_spec-1.0.1.jar) seems corrupted, error: error in opening zip file -> [Help 1] {noformat} Full log: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/overlord-rtgov/19/console -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 03:33:16 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 03:33:16 -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:comment-tabpanel&focusedCommentId=12972687#comment-12972687 ] David virgil naranjo commented on SRAMP-450: -------------------------------------------- Ok, gary, Going to do the following: - Place the keystore in the s-ramp-profile. Set the sramp-ui.properties with the default keystore references and properties. About the note you mentioned at the end of your message, I do not think it would affect that different overlord-subprojects are being installed sharing overlord-commons. We need to think fuse fabric profiles, like adding features to the container. If we add the overlord-commons-profile features to the same container multiple times, the result is gonna be the same, because the features related the profile would be only added once. > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 04:13:16 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 04:13:16 -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 ] David virgil naranjo updated SRAMP-450: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/426, https://github.com/Governance/overlord-commons/pull/75 > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 04:19:18 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 3 Jun 2014 04:19:18 -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:comment-tabpanel&focusedCommentId=12972703#comment-12972703 ] Gary Brown commented on SRAMP-450: ---------------------------------- Hi David A bit premature :) we haven't got agreement on where the keystore should be placed. That was only my opinion - we need [~ewittmann] to give his thoughts. I've also been considering this more, and wondering whether (even though not used currently) it may be better for the keystore to be in commons - and change where sramp obtains the keystore information from - to be in a commons property file. > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 04:21:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 3 Jun 2014 04:21:16 -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:comment-tabpanel&focusedCommentId=12972706#comment-12972706 ] Gary Brown commented on SRAMP-450: ---------------------------------- Another question - is the commons installer going to setup the 'admin' user, with the password entered by the user? > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 04:23:15 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 04:23:15 -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:comment-tabpanel&focusedCommentId=12972707#comment-12972707 ] David virgil naranjo commented on SRAMP-450: -------------------------------------------- Noo, I decoupled the fuse ant script just to call to the generate-keystore target. > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 04:27:16 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 04:27:16 -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:comment-tabpanel&focusedCommentId=12972709#comment-12972709 ] David virgil naranjo commented on SRAMP-450: -------------------------------------------- You know I am quick! I think for this release this would be ok. It would not be big change. But even right now I could change the files from one folder to another, no problem. I consider also that could be maybe better to have the overlord.keystore in the commons profile. Even if we place the file there, it would not affect rtgov, as you are not using that file. > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 04:27:16 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 04:27:16 -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:comment-tabpanel&focusedCommentId=12972711#comment-12972711 ] David virgil naranjo commented on SRAMP-450: -------------------------------------------- Another point about the keystore generation I think would be good to ask the user for introducing these two properties: Right now these 2 values are placed manually in the overlord-commons and in the s-ramp installer. > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 07:16:17 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 3 Jun 2014 07:16:17 -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:comment-tabpanel&focusedCommentId=12972790#comment-12972790 ] Eric Wittmann commented on SRAMP-450: ------------------------------------- We should prompt the user for the keystore password - I agree. Let's use the same password for both the keystore and the key. No loss of security there I don't think. The prompt should be added for all platforms I think. The keystore should be installed by the overlord-commons installer, definitely. And we should create the admin user (if possible) in the commons installer. If not possible/easy to create the admin user, then no user should be created at all. The s-ramp installer should never create users. However the dtgov installer should create the 'dtgovworkflows' user. > 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 > > 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.3#6260) From issues at jboss.org Tue Jun 3 07:50:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 3 Jun 2014 07:50:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-487) The JAR/ZIP file geronimo-jta_1.0.1B_spec-1.0.1.jar seems corrupted, error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-487: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/107 > The JAR/ZIP file geronimo-jta_1.0.1B_spec-1.0.1.jar seems corrupted, error > -------------------------------------------------------------------------- > > Key: RTGOV-487 > URL: https://issues.jboss.org/browse/RTGOV-487 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > > Error when building in hudson: > {noformat} > [ERROR] Failed to execute goal org.apache.felix:maven-bundle-plugin:2.3.7:bundle (default-bundle) on project rtgov-switchyard: Error calculating classpath for project MavenProject: org.overlord.rtgov.integration:rtgov-switchyard:2.0.0-SNAPSHOT @ /qa/hudson_ws/workspace/overlord-rtgov/sources/integration/switchyard/pom.xml: The JAR/ZIP file (/qa/hudson_ws/workspace/overlord-rtgov/m2-repository/org/apache/geronimo/specs/geronimo-jta_1.0.1B_spec/1.0.1/geronimo-jta_1.0.1B_spec-1.0.1.jar) seems corrupted, error: error in opening zip file -> [Help 1] > {noformat} > Full log: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/overlord-rtgov/19/console -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 07:50:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 3 Jun 2014 07:50:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-487) The JAR/ZIP file geronimo-jta_1.0.1B_spec-1.0.1.jar seems corrupted, error In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-487. ------------------------------ Resolution: Done > The JAR/ZIP file geronimo-jta_1.0.1B_spec-1.0.1.jar seems corrupted, error > -------------------------------------------------------------------------- > > Key: RTGOV-487 > URL: https://issues.jboss.org/browse/RTGOV-487 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > > Error when building in hudson: > {noformat} > [ERROR] Failed to execute goal org.apache.felix:maven-bundle-plugin:2.3.7:bundle (default-bundle) on project rtgov-switchyard: Error calculating classpath for project MavenProject: org.overlord.rtgov.integration:rtgov-switchyard:2.0.0-SNAPSHOT @ /qa/hudson_ws/workspace/overlord-rtgov/sources/integration/switchyard/pom.xml: The JAR/ZIP file (/qa/hudson_ws/workspace/overlord-rtgov/m2-repository/org/apache/geronimo/specs/geronimo-jta_1.0.1B_spec/1.0.1/geronimo-jta_1.0.1B_spec-1.0.1.jar) seems corrupted, error: error in opening zip file -> [Help 1] > {noformat} > Full log: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/overlord-rtgov/19/console -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 09:26:15 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 09:26:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-476) java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated RTGOV-476: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/73, https://github.com/Governance/rtgov/pull/99, https://github.com/Governance/s-ramp/pull/427 (was: https://github.com/Governance/overlord-commons/pull/73, https://github.com/Governance/rtgov/pull/99) > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ > ----------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-476 > URL: https://issues.jboss.org/browse/RTGOV-476 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 2.0.0.Final > > > When RTGov all configuration is deployed in a fabric child container we get the following exception: > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator at 3afffabb in org.eclipse.jetty.security.ConstraintSecurityHandler at 7ba6293f > at org.eclipse.jetty.security.authentication.LoginAuthenticator.setConfiguration(LoginAuthenticator.java:61) -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 09:26:15 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 09:26:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-476) java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated RTGOV-476: --------------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/73, https://github.com/Governance/rtgov/pull/99, https://github.com/Governance/s-ramp/pull/427, https://github.com/Governance/rtgov/pull/108 (was: https://github.com/Governance/overlord-commons/pull/73, https://github.com/Governance/rtgov/pull/99, https://github.com/Governance/s-ramp/pull/427) > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ > ----------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-476 > URL: https://issues.jboss.org/browse/RTGOV-476 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 2.0.0.Final > > > When RTGov all configuration is deployed in a fabric child container we get the following exception: > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator at 3afffabb in org.eclipse.jetty.security.ConstraintSecurityHandler at 7ba6293f > at org.eclipse.jetty.security.authentication.LoginAuthenticator.setConfiguration(LoginAuthenticator.java:61) -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 10:52:15 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 3 Jun 2014 10:52:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-451: ------------------------------------------ Summary: S-ramp maven facade for fuse fabric Key: SRAMP-451 URL: https://issues.jboss.org/browse/SRAMP-451 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: David virgil naranjo Create a mvn-http facade component that will act as a intermediate between fuse fabric and s-ramp.. It should be just a servlet that dissects the inbound request's path to extract the GAV information. Then does a s-ramp repository query to find the appropriate artifact The GET side of that is very easy (pulling artifacts *from* s-ramp) The servlet would have to take a URL path like this: org/overlord/sramp/s-ramp-api/0.4.0.Final/s-ramp-api-0.4.0.Final.jar and parse that to get the GAV info of: org.overlord.sramp:s-ramp-api:0.4.0.Final:jar -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 12:05:18 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Tue, 3 Jun 2014 12:05:18 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-452) ElasticSearch activity store impl must return full activity unit In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12972949#comment-12972949 ] ivan mckinley commented on RTGOV-452: ------------------------------------- Not started it. Thanks for doing this :) Sent from my iPad > ElasticSearch activity store impl must return full activity unit > ---------------------------------------------------------------- > > Key: RTGOV-452 > URL: https://issues.jboss.org/browse/RTGOV-452 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > The new Elasticsearch ActivityStore implementation decomposes the ActivityUnit into the unit and separate ActivityType objects when persisting in ElasticSearch. > However when the implementation is returning the ActivityUnit, it only retrieves the unit part, and does not rebuild the child ActivityType objects. These also need to be retrieved to return the ActivityUnit in full. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 12:34:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 3 Jun 2014 12:34:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-488) Revert to drools 6.0.1 In-Reply-To: References: Message-ID: Gary Brown created RTGOV-488: -------------------------------- Summary: Revert to drools 6.0.1 Key: RTGOV-488 URL: https://issues.jboss.org/browse/RTGOV-488 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 13:44:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 3 Jun 2014 13:44:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-488) Revert to drools 6.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-488: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/109 > Revert to drools 6.0.1 > ---------------------- > > Key: RTGOV-488 > URL: https://issues.jboss.org/browse/RTGOV-488 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Tue Jun 3 13:44:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 3 Jun 2014 13:44:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-488) Revert to drools 6.0.1 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-488. ------------------------------ Resolution: Done > Revert to drools 6.0.1 > ---------------------- > > Key: RTGOV-488 > URL: https://issues.jboss.org/browse/RTGOV-488 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 05:32:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 05:32:16 -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: ----------------------------- Parent: (was: RTGOV-419) Issue Type: Feature Request (was: Sub-task) > 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 > 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.3#6260) From issues at jboss.org Wed Jun 4 05:32:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 05:32:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-454) Unify ElasticSearch sever configuration across proxy REST service and keyvalue store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-454: ----------------------------- Parent: (was: RTGOV-419) Issue Type: Task (was: Sub-task) > Unify ElasticSearch sever configuration across proxy REST service and keyvalue store > ------------------------------------------------------------------------------------ > > Key: RTGOV-454 > URL: https://issues.jboss.org/browse/RTGOV-454 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Currently the Elasticsearch.hosts property is a list of : values, while the REST service uses a single URL property. > See if ES client can take a URL rather than just host:port - and if so, have a single property that takes a list of URLs. > If possible, then need to see if REST service can use a list of URLs (failover). -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 05:32:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 05:32:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-419) ElasticSearch support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-419. ------------------------------ Resolution: Done > ElasticSearch support > --------------------- > > Key: RTGOV-419 > URL: https://issues.jboss.org/browse/RTGOV-419 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 05:54:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 05:54:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated SRAMP-451: ----------------------------- Original Estimate: 1 week Remaining Estimate: 1 week > S-ramp maven facade for fuse fabric > ----------------------------------- > > Key: SRAMP-451 > URL: https://issues.jboss.org/browse/SRAMP-451 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Original Estimate: 1 week > Remaining Estimate: 1 week > > Create a mvn-http facade component that will act as a intermediate between fuse fabric and s-ramp.. It should be just a servlet that dissects the inbound request's path to extract the GAV information. Then does a s-ramp repository query to find the appropriate artifact > The GET side of that is very easy (pulling artifacts *from* s-ramp) > The servlet would have to take a URL path like this: org/overlord/sramp/s-ramp-api/0.4.0.Final/s-ramp-api-0.4.0.Final.jar and parse that to get the GAV info of: org.overlord.sramp:s-ramp-api:0.4.0.Final:jar -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 06:44:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 06:44:16 -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=12973182#comment-12973182 ] Gary Brown commented on RTGOV-462: ---------------------------------- Previously discussed options for creating the server - possibly triggered by an EJB to leverage its lifecycle. However any Elasticsearch client will be dependent upon this being started. Wondering whether it is better to simplify this for now - for example in the ElasticsearchClient (https://github.com/Governance/rtgov/blob/master/modules/common/rtgov-elasticsearch/src/main/java/org/overlord/rtgov/common/elasticsearch/ElasticsearchClient.java#L252-L264) the 'embedded' host value is creating an instance for use in testing - but can this be enhanced to start a properly configured (and potentially clustered) local node? Statically stored in this ElasticsearchClient to avoid multiple embedded servers being started up? Issues would be, where it obtains the configuration from - probably best in overlord-rtgov.properties - so that the individual components using Elasticsearch don't need to provide this config details, which may end up varying across components - so they just provide host name "embedded" and the common details are obtained from the properties file. Could change the current 'embedded' entry to 'test' - if a lightweight server is required for test purposes? > 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 > 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.3#6260) From issues at jboss.org Wed Jun 4 06:48:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 06:48:16 -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:comment-tabpanel&focusedCommentId=12973184#comment-12973184 ] Gary Brown commented on RTGOV-346: ---------------------------------- The comment above is more relevant for the EAP embedded server, which is now in RTGOV-462. The profile could be bundled with a property file containing the config details for the server. Alternatively it may be best to initially reuse the same 'embedded' ES server properties used in RTGOV-462, and just include starting the server as part of the rtgov-all profile. Issues: if multiple rtgov-all profiles are started on the same machine, then the ports will conflict. Only solution to this would be to use dynamic ports somehow, which also means the other properties referencing ES would need to be dynamic. > 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 > 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.3#6260) From issues at jboss.org Wed Jun 4 07:10:15 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Wed, 4 Jun 2014 07:10:15 -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=12973194#comment-12973194 ] ivan mckinley commented on RTGOV-462: ------------------------------------- I see cases that have to be addressed. Its a trickier topic than simply starting a ES node First the easy one. 1) Test and Integration : A lightweight local jvm ES is started using the local node feature from the ES java api. This would require the entire ES dependency stack for our module. As opposed to currently where we only have the client api 2) Embedded out of the box. - Should start a single ES node - Should be singleton in the JVM. I have not reviewed the ElasticsearchClient but we need to ensure that only one ES instance is started per vm. Is ElasticsearchClient "singleton" or is it shared amongst Keyvalue stores. Starting additional embedded nodes in 1 jvm should not be allowed (hence singleton or static as you mentioned ) - Should be capable of joining a ES cluster(or any). This would allow us to scale horizontally by adding additional FSW or ES nodes as data/load grows. - Allow unique configuration per instance. Once again would support scalability as perhaps certain jboss nodes with embedded ES would be designated as been responsible for a particular model. for example in multiple node we store all situations objects on dedicated nodes(sharding etc). > 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 > 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.3#6260) From issues at jboss.org Wed Jun 4 07:38:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 07:38:15 -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=12973206#comment-12973206 ] Gary Brown commented on RTGOV-462: ---------------------------------- 1) If we are starting a full server for production use, this would also require the full stack, wouldn't it? So this would be the same for both production and test/integration requirements? 2) Singleton - yes, although the ElasticsearchClient is not a singleton, it could manage a 'singleton' for the embedded server, in cases where the specific ElasticsearchClient instance has referenced it (or possibly where the host is unspecified). If the embedded node's config is obtained from the overlord-rtgov.properties, this should enable clustering to be supported/updated as appropriate, without impacting the individual components using ES. Unique config per instance - this could be more complex. It may be possible via the overlord-rtgov.properties when running in standalone mode, but (as I understand it) when we use domain mode, this info will be obtained from the xml - which will be common across a cluster of servers (I assume). So we may need the embedded nodes (in this scenario) to use a common general config, and potentially the more specific config is applied to ES nodes outside of EAP? > 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 > 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.3#6260) From issues at jboss.org Wed Jun 4 08:04:16 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Wed, 4 Jun 2014 08:04:16 -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=12973216#comment-12973216 ] ivan mckinley commented on RTGOV-462: ------------------------------------- 1) If we are starting a full server for production use, this would also require the full stack, wouldn't it? So this would be the same for both production and test/integration requirements? - correct. but perhaps in remote client mode there will be no need to pull in the full stack 2) Singleton - yes, although the ElasticsearchClient is not a singleton, it could manage a 'singleton' for the embedded server, in cases where the specific ElasticsearchClient instance has referenced it (or possibly where the host is unspecified). If the embedded node's config is obtained from the overlord-rtgov.properties, this should enable clustering to be supported/updated as appropriate, without impacting the individual components using ES. Unique config per instance - this could be more complex. It may be possible via the overlord-rtgov.properties when running in standalone mode, but (as I understand it) when we use domain mode, this info will be obtained from the xml - which will be common across a cluster of servers (I assume). So we may need the embedded nodes (in this scenario) to use a common general config, and potentially the more specific config is applied to ES nodes outside of EAP? > Perhaps the best approach in the this case would be. - Domain mode. All ES nodes form a cluster based on config in xml(assumption). ES Configuration by default. Perhaps taking config from EAP clustering(if clustering in use). if another ES cluster or shard is required then a separate domain could be defined. what do you think? - Standalone. Flexible configuration using RTGov.properties. This is straight forward. > 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 > 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.3#6260) From issues at jboss.org Wed Jun 4 09:06:15 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 4 Jun 2014 09:06:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-452) Enhance s-ramp CLI property interpolation: support default values In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-452: ----------------------------------- Summary: Enhance s-ramp CLI property interpolation: support default values Key: SRAMP-452 URL: https://issues.jboss.org/browse/SRAMP-452 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Components: Shell Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.5.0.Final Currently the shell supports property interpolation so that variables can be used in CLI command files. This takes the following form (for example): {code} connect http://localhost:8080/s-ramp ${username} ${password} {code} The CLI can then be invoked like this: {code} sramp.sh -f path/to/cli.txt -Dusername=admin -Dpassword=adminp {code} This is good, but let's also support optional default values for the variables, like this: {code} connect http://localhost:8080/s-ramp ${username:admin} ${password:adminp} {code} This will continue to replace ${username} with whatever value is passed via -Dusername=blah. However, if -Dusername is *not* provided, then the default value of 'admin' will be used. This will result in more powerful CLI scripts with commands like this: {code} connect ${sramp.endpoint:http://localhost:8080/s-ramp} ${sramp.username:admin} ${sramp.password:adminp} {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 10:38:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 10:38:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-453: --------------------------------- Summary: Exception if using Backspace on CLI password prompt Key: SRAMP-453 URL: https://issues.jboss.org/browse/SRAMP-453 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) at java.lang.StringBuilder.insert(StringBuilder.java:336) at org.jboss.aesh.console.Buffer.write(Buffer.java:319) at org.jboss.aesh.console.Console.writeChar(Console.java:837) at org.jboss.aesh.console.Console.writeChars(Console.java:832) at org.jboss.aesh.console.Console.parseOperation(Console.java:515) at org.jboss.aesh.console.Console.read(Console.java:452) at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 10:42:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 10:42:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-423) Enable SRAMP to be deployed to fabric as a profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-423: ------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/69, https://github.com/Governance/s-ramp/pull/421, https://github.com/Governance/s-ramp/pull/424, https://github.com/Governance/s-ramp/pull/428 (was: https://github.com/Governance/overlord-commons/pull/69, https://github.com/Governance/s-ramp/pull/421, https://github.com/Governance/s-ramp/pull/424) > Enable SRAMP to be deployed to fabric as a profile > -------------------------------------------------- > > Key: SRAMP-423 > URL: https://issues.jboss.org/browse/SRAMP-423 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > Enable SRAMP to be deployed to fabric as a profile. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 10:44:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 10:44:16 -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=12973328#comment-12973328 ] Gary Brown commented on RTGOV-462: ---------------------------------- Domain mode - sounds possible, but I don't currently have any experience of EAP domain mode, or ES clustering/shard, so will require investigation. Standalone - this would be a good place to start :) > 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 > 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.3#6260) From issues at jboss.org Wed Jun 4 10:54:17 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 4 Jun 2014 10:54:17 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-454) CLI Command: Echo In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-454: ----------------------------------- Summary: CLI Command: Echo Key: SRAMP-454 URL: https://issues.jboss.org/browse/SRAMP-454 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Shell Reporter: Eric Wittmann Assignee: Brett Meyer Fix For: 0.5.0.Final Implement a new CLI command that simply takes 1 argument (an arbitrary string) and echos it back. This would be helpful when running a CLI command file. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 10:54:17 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 10:54:17 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-423) Enable SRAMP to be deployed to fabric as a profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-423: ------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/69, https://github.com/Governance/s-ramp/pull/421, https://github.com/Governance/s-ramp/pull/424, https://github.com/Governance/s-ramp/pull/428, https://github.com/Governance/s-ramp/pull/429 (was: https://github.com/Governance/overlord-commons/pull/69, https://github.com/Governance/s-ramp/pull/421, https://github.com/Governance/s-ramp/pull/424, https://github.com/Governance/s-ramp/pull/428) > Enable SRAMP to be deployed to fabric as a profile > -------------------------------------------------- > > Key: SRAMP-423 > URL: https://issues.jboss.org/browse/SRAMP-423 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > Enable SRAMP to be deployed to fabric as a profile. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 11:18:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 11:18:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Investigate using Arquillian for S-RAMP unit and 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=12973359#comment-12973359 ] Brett Meyer commented on SRAMP-431: ----------------------------------- https://community.jboss.org/wiki/S-RAMPContainerAdapterForArquillianAvailable > Investigate using Arquillian for S-RAMP unit and 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 > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 12:42:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 12:42:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-455) use artifact SHA1 computed by ModeShape In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-455: --------------------------------- Summary: use artifact SHA1 computed by ModeShape Key: SRAMP-455 URL: https://issues.jboss.org/browse/SRAMP-455 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer As suggested on https://issues.jboss.org/browse/MODE-2221, ModeShape already computes the SHA1 hash for artifacts. We could use that directly, rather than computing on our own. Note that the hash is a ModeShape-specific extension and not supported by JCR. So, create an SPI and a default impl in the jcr-repo, but override for ModeShape. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 15:20:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 15:20:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Re-split the installer into EAP 6.1 and 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973467#comment-12973467 ] Brett Meyer commented on SRAMP-447: ----------------------------------- Instead of splitting the installers back up, I'm wondering if we could do something simpler/smarter. At least with respect to S-RAMP, really the only *runtime* difference between EAP 6.1 and 6.3 was the ModeShape distro that the installer pulls down. Everything else, including compile time, IDP, etc. can stay the same. Knowing that, could we attempt to simply decide, during the installation, what ModeShape distro to grab, based on the EAP instance's full path (assuming it's not renamed and still contains the version within the dir name)? If that fails, fall back on the latest? Theoretically, that *should* allow S-RAMP to simultaneously support both, but not splitting up the installers in overlord, overlord-commons, and s-ramp. [~eric.wittmann]/[~objectiser], thoughts? > Re-split the installer into EAP 6.1 and 6.3 > ------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 15:36:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 15:36:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Re-split the installer into EAP 6.1 and 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973469#comment-12973469 ] Brett Meyer commented on SRAMP-447: ----------------------------------- On the other hand, splitting the installer back up isn't difficult either... > Re-split the installer into EAP 6.1 and 6.3 > ------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 15:38:15 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 4 Jun 2014 15:38:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Re-split the installer into EAP 6.1 and 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973471#comment-12973471 ] Eric Wittmann commented on SRAMP-447: ------------------------------------- I had this same thought last time we talked about this - I was thinking maybe we could peek into the EAP distro itself to figure out what version it might be. Not sure the best way to do that in Ant though. But in any case, having something in ant that figured out the specific version would be better than splitting up the installers IMHO. > Re-split the installer into EAP 6.1 and 6.3 > ------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 15:44:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 4 Jun 2014 15:44:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Re-split the installer into EAP 6.1 and 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973472#comment-12973472 ] Gary Brown commented on SRAMP-447: ---------------------------------- Would prefer single eap6 target but ok with split if difficult. > Re-split the installer into EAP 6.1 and 6.3 > ------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 15:50:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 15:50:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Re-split the installer into EAP 6.1 and 6.3 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973475#comment-12973475 ] Brett Meyer commented on SRAMP-447: ----------------------------------- Just realized $JBOSS_HOME/version.txt exists ;) On it. > Re-split the installer into EAP 6.1 and 6.3 > ------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 17:14:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 17:14:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Support both EAP 6.1 and 6.3 in the installer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-447: ------------------------------ Summary: Support both EAP 6.1 and 6.3 in the installer (was: Re-split the installer into EAP 6.1 and 6.3) Git Pull Request: https://github.com/Governance/s-ramp/pull/430 > Support both EAP 6.1 and 6.3 in the installer > --------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 17:14:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 17:14:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Support both EAP 6.1 and 6.3 in the installer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973507#comment-12973507 ] Brett Meyer commented on SRAMP-447: ----------------------------------- Can you both review https://github.com/Governance/s-ramp/pull/430? Comments appreciated. The only thing I don't like about it is that the s-ramp-distro-assembly now has to include both versions of ModeShape, but not sure if there's a way around that. > Support both EAP 6.1 and 6.3 in the installer > --------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 17:16:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 17:16:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Support both EAP 6.1 and 6.3 in the installer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-447 started by Brett Meyer. > Support both EAP 6.1 and 6.3 in the installer > --------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 17:44:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 17:44:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973513#comment-12973513 ] Brett Meyer commented on SRAMP-453: ----------------------------------- Looks like an aesh bug, but leaving open until I get confirmation on https://issues.jboss.org/browse/AESH-250 > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 18:52:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 18:52:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-455) use artifact SHA1 computed by ModeShape In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-455: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/431/files > use artifact SHA1 computed by ModeShape > --------------------------------------- > > Key: SRAMP-455 > URL: https://issues.jboss.org/browse/SRAMP-455 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > As suggested on https://issues.jboss.org/browse/MODE-2221, ModeShape already computes the SHA1 hash for artifacts. We could use that directly, rather than computing on our own. > Note that the hash is a ModeShape-specific extension and not supported by JCR. So, create an SPI and a default impl in the jcr-repo, but override for ModeShape. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Wed Jun 4 18:54:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Wed, 4 Jun 2014 18:54:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-455) use artifact SHA1 computed by ModeShape In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-455 started by Brett Meyer. > use artifact SHA1 computed by ModeShape > --------------------------------------- > > Key: SRAMP-455 > URL: https://issues.jboss.org/browse/SRAMP-455 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > As suggested on https://issues.jboss.org/browse/MODE-2221, ModeShape already computes the SHA1 hash for artifacts. We could use that directly, rather than computing on our own. > Note that the hash is a ModeShape-specific extension and not supported by JCR. So, create an SPI and a default impl in the jcr-repo, but override for ModeShape. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 05:38:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 05:38:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-426) Upgrade switchyard version to 2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown reassigned SRAMP-426: -------------------------------- Assignee: Gary Brown (was: Kurt Stam) > Upgrade switchyard version to 2.x > --------------------------------- > > Key: SRAMP-426 > URL: https://issues.jboss.org/browse/SRAMP-426 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.5.0.Final > > > While doing the upgrade to IP BOM CR8 (SRAMP-245) had problems with the s-ramp-demos-switchyard-multiapp/order-service WebServiceTest - possibly an incompatibility between the older version of switchyard and the newer version of cxf in BOM CR8. > Have ignored the test for now to complete the CR8 upgrade - but the switchyard version needs to be upgraded to the 2.x stream asap to sort out any issues. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 06:08:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 06:08:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-456) CXF version mismatch causing WebServiceTest to fail In-Reply-To: References: Message-ID: Gary Brown created SRAMP-456: -------------------------------- Summary: CXF version mismatch causing WebServiceTest to fail Key: SRAMP-456 URL: https://issues.jboss.org/browse/SRAMP-456 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Brett Meyer Fix For: 0.5.0.Final Switchyard is currently using an older version of the IP BOM (CR6), which has version 2.6.8, while current version for alpha is supposed to be CR9, which has cxf 2.7.11. This is causing a CNFE for org.apache.cxf.io.CopyingOutputStream. Currently ignoring the test until versions are aligned. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 06:18:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 06:18:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-426) Upgrade switchyard version to 2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated SRAMP-426: ----------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/432 > Upgrade switchyard version to 2.x > --------------------------------- > > Key: SRAMP-426 > URL: https://issues.jboss.org/browse/SRAMP-426 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.5.0.Final > > > While doing the upgrade to IP BOM CR8 (SRAMP-245) had problems with the s-ramp-demos-switchyard-multiapp/order-service WebServiceTest - possibly an incompatibility between the older version of switchyard and the newer version of cxf in BOM CR8. > Have ignored the test for now to complete the CR8 upgrade - but the switchyard version needs to be upgraded to the 2.x stream asap to sort out any issues. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 06:18:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 06:18:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-426) Upgrade switchyard version to 2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973671#comment-12973671 ] Gary Brown commented on SRAMP-426: ---------------------------------- WebServiceTest fails due to mismatch in cxf versions between switchyard (using old IP BOM version) and overlord using latest. > Upgrade switchyard version to 2.x > --------------------------------- > > Key: SRAMP-426 > URL: https://issues.jboss.org/browse/SRAMP-426 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.5.0.Final > > > While doing the upgrade to IP BOM CR8 (SRAMP-245) had problems with the s-ramp-demos-switchyard-multiapp/order-service WebServiceTest - possibly an incompatibility between the older version of switchyard and the newer version of cxf in BOM CR8. > Have ignored the test for now to complete the CR8 upgrade - but the switchyard version needs to be upgraded to the 2.x stream asap to sort out any issues. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 06:44:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 06:44:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-489) Enable overlord-commons plugin to be built independently In-Reply-To: References: Message-ID: Gary Brown created RTGOV-489: -------------------------------- Summary: Enable overlord-commons plugin to be built independently Key: RTGOV-489 URL: https://issues.jboss.org/browse/RTGOV-489 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Production build resolves plugins before doing the main build, so we need to be able to build the overlord-commons plugin before the other modules. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 07:00:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 07:00:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-489) Enable overlord-commons plugin to be built independently In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-489: ----------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/77 > Enable overlord-commons plugin to be built independently > -------------------------------------------------------- > > Key: RTGOV-489 > URL: https://issues.jboss.org/browse/RTGOV-489 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Production build resolves plugins before doing the main build, so we need to be able to build the overlord-commons plugin before the other modules. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 07:28:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 07:28:15 -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: ----------------------------- Original Estimate: 3 days Remaining Estimate: 3 days > 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 > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 3 days > Remaining Estimate: 3 days > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 08:38:16 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 5 Jun 2014 08:38:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-457) S-ramp installer error when installing over an existing server instance In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-457: ------------------------------------------ Summary: S-ramp installer error when installing over an existing server instance Key: SRAMP-457 URL: https://issues.jboss.org/browse/SRAMP-457 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: Brett Meyer Error in the s-ramp distro assembly for jboss eap: > > It happens when it is installed over a not clean jboss server instance: > Steps: > Unzip Jboss eap 6.3 Alpha > Install switchyard over eap > execute the ant s-ramp-distro assembly build > If you run now jboss eap it will work. > Install again s-ramp in jboss eap then causes the following error: https://gist.github.com/dvirgiln/b2f5f80234c97fc2b3b1 The overlord-commons installer will get skipped if run multiple times, but it does this by looking for the keystore. If it finds the keystore it assumes that it's already been run and skips itself. Nothing like this exists for s-ramp. So it will make all the standalone.xml changes (using XSLT) each time you run it. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 08:40:16 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 5 Jun 2014 08:40:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-457) S-ramp installer error when installing over an existing server instance In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo reassigned SRAMP-457: ------------------------------------------ Assignee: David virgil naranjo (was: Brett Meyer) > S-ramp installer error when installing over an existing server instance > ----------------------------------------------------------------------- > > Key: SRAMP-457 > URL: https://issues.jboss.org/browse/SRAMP-457 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > Error in the s-ramp distro assembly for jboss eap: > > > > It happens when it is installed over a not clean jboss server instance: > > Steps: > > Unzip Jboss eap 6.3 Alpha > > Install switchyard over eap > > execute the ant s-ramp-distro assembly build > > If you run now jboss eap it will work. > > Install again s-ramp in jboss eap then causes the following error: > https://gist.github.com/dvirgiln/b2f5f80234c97fc2b3b1 > The overlord-commons installer will get skipped if run multiple times, > but it does this by looking for the keystore. If it finds the keystore > it assumes that it's already been run and skips itself. > Nothing like this exists for s-ramp. So it will make all the > standalone.xml changes (using XSLT) each time you run it. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 10:44:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 10:44:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-489) Enable overlord-commons plugin to be built independently In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-489. ------------------------------ Resolution: Done > Enable overlord-commons plugin to be built independently > -------------------------------------------------------- > > Key: RTGOV-489 > URL: https://issues.jboss.org/browse/RTGOV-489 > Project: RTGov (Run Time Governance) > Issue Type: Task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Production build resolves plugins before doing the main build, so we need to be able to build the overlord-commons plugin before the other modules. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 12:00:17 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 12:00:17 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-426) Upgrade switchyard version to 2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved SRAMP-426. ------------------------------ Resolution: Done > Upgrade switchyard version to 2.x > --------------------------------- > > Key: SRAMP-426 > URL: https://issues.jboss.org/browse/SRAMP-426 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.5.0.Final > > > While doing the upgrade to IP BOM CR8 (SRAMP-245) had problems with the s-ramp-demos-switchyard-multiapp/order-service WebServiceTest - possibly an incompatibility between the older version of switchyard and the newer version of cxf in BOM CR8. > Have ignored the test for now to complete the CR8 upgrade - but the switchyard version needs to be upgraded to the 2.x stream asap to sort out any issues. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 12:10:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 12:10:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-426) Upgrade switchyard version to 2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-426: ------------------------------ Fix Version/s: 0.5.0.Alpha1 > Upgrade switchyard version to 2.x > --------------------------------- > > Key: SRAMP-426 > URL: https://issues.jboss.org/browse/SRAMP-426 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > While doing the upgrade to IP BOM CR8 (SRAMP-245) had problems with the s-ramp-demos-switchyard-multiapp/order-service WebServiceTest - possibly an incompatibility between the older version of switchyard and the newer version of cxf in BOM CR8. > Have ignored the test for now to complete the CR8 upgrade - but the switchyard version needs to be upgraded to the 2.x stream asap to sort out any issues. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 13:10:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 13:10:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-426) Upgrade switchyard version to 2.x In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973840#comment-12973840 ] Brett Meyer commented on SRAMP-426: ----------------------------------- Verified that s-ramp-demos-switchyard still works after the upgrade. Thanks Gary! > Upgrade switchyard version to 2.x > --------------------------------- > > Key: SRAMP-426 > URL: https://issues.jboss.org/browse/SRAMP-426 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > While doing the upgrade to IP BOM CR8 (SRAMP-245) had problems with the s-ramp-demos-switchyard-multiapp/order-service WebServiceTest - possibly an incompatibility between the older version of switchyard and the newer version of cxf in BOM CR8. > Have ignored the test for now to complete the CR8 upgrade - but the switchyard version needs to be upgraded to the 2.x stream asap to sort out any issues. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 13:24:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 13:24:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Support both EAP 6.1 and 6.3 in the installer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-447: ------------------------------ Fix Version/s: 0.5.0.Alpha1 > Support both EAP 6.1 and 6.3 in the installer > --------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 13:24:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 13:24:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-447) Support both EAP 6.1 and 6.3 in the installer In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-447. ------------------------------- Resolution: Done > Support both EAP 6.1 and 6.3 in the installer > --------------------------------------------- > > Key: SRAMP-447 > URL: https://issues.jboss.org/browse/SRAMP-447 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > SRAMP-382 combined EAP 6.1 and 6.3 support. For the most part, that's fine -- no compile issues, etc. However, the installer needs split back up in order to provide the correct ModeShape distro, etc. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 14:58:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 14:58:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-455) use artifact SHA1 computed by ModeShape In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-455. ------------------------------- Fix Version/s: 0.5.0.Final 0.5.0.Alpha1 Resolution: Done > use artifact SHA1 computed by ModeShape > --------------------------------------- > > Key: SRAMP-455 > URL: https://issues.jboss.org/browse/SRAMP-455 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > As suggested on https://issues.jboss.org/browse/MODE-2221, ModeShape already computes the SHA1 hash for artifacts. We could use that directly, rather than computing on our own. > Note that the hash is a ModeShape-specific extension and not supported by JCR. So, create an SPI and a default impl in the jcr-repo, but override for ModeShape. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 15:08:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 15:08:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-469) Update rtgov ui to use overlord-commons SSO In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-469: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/111 > Update rtgov ui to use overlord-commons SSO > ------------------------------------------- > > Key: RTGOV-469 > URL: https://issues.jboss.org/browse/RTGOV-469 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Support single signon in Fuse/Karaf. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 15:08:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 15:08:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-469) Update rtgov ui to use overlord-commons SSO In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-469. ------------------------------ Resolution: Done > Update rtgov ui to use overlord-commons SSO > ------------------------------------------- > > Key: RTGOV-469 > URL: https://issues.jboss.org/browse/RTGOV-469 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Support single signon in Fuse/Karaf. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 15:18:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 15:18:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12973869#comment-12973869 ] Brett Meyer commented on SRAMP-453: ----------------------------------- Fixed and to be released in aesh 0.33.13. Will upgrade under this ticket > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 15:44:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 15:44:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Investigate using Arquillian for S-RAMP unit and 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 abstract class 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. - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. > Investigate using Arquillian for S-RAMP unit and 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 15:50:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 15:50:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-484) Re-introduce REST services in Karaf when SSO sorted out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-484: ----------------------------- Original Estimate: 2 days Remaining Estimate: 2 days > Re-introduce REST services in Karaf when SSO sorted out > ------------------------------------------------------- > > Key: RTGOV-484 > URL: https://issues.jboss.org/browse/RTGOV-484 > Project: RTGov (Run Time Governance) > Issue Type: Sub-task > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > Original Estimate: 2 days > Remaining Estimate: 2 days > > Currently the war with the REST services has been removed from the karaf features until SSO is configured in RTGov. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 15:52:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 5 Jun 2014 15:52:16 -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: ----------------------------- Original Estimate: 1 week (was: 3 days) Remaining Estimate: 1 week (was: 3 days) > 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 > 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.3#6260) From issues at jboss.org Thu Jun 5 15:56:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 15:56:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-431) Investigate using Arquillian for S-RAMP unit and 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=12973359#comment-12973359 ] Brett Meyer edited comment on SRAMP-431 at 6/5/14 3:54 PM: ----------------------------------------------------------- This probably won't be too useful for this specific task, as we're more concerned with testing S-RAMP in various containers, but it's worth looking into. https://community.jboss.org/wiki/S-RAMPContainerAdapterForArquillianAvailable was (Author: brmeyer): https://community.jboss.org/wiki/S-RAMPContainerAdapterForArquillianAvailable > Investigate using Arquillian for S-RAMP unit and 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 16:06:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:06:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-458) Integration tests: Tomcat In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-458: --------------------------------- Summary: 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.3#6260) From issues at jboss.org Thu Jun 5 16:06:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:06:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-459) Integration tests: Jetty In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-459: --------------------------------- Summary: Integration tests: Jetty Key: SRAMP-459 URL: https://issues.jboss.org/browse/SRAMP-459 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.3#6260) From issues at jboss.org Thu Jun 5 16:08:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:08:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-460) Integration tests: Fuse In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-460: --------------------------------- Summary: Integration tests: Fuse Key: SRAMP-460 URL: https://issues.jboss.org/browse/SRAMP-460 Project: S-RAMP Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: David virgil naranjo -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 16:08:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:08:16 -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=12973877#comment-12973877 ] Brett Meyer commented on SRAMP-460: ----------------------------------- Hey [~virchete], initially assigning this to you. Checkout my ideas on SRAMP-431 and let me know what you think. I have a branch where I'm starting to work on some of the core ideas -- when you're ready to look at this a bit, ping me. > Integration tests: Fuse > ----------------------- > > Key: SRAMP-460 > URL: https://issues.jboss.org/browse/SRAMP-460 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 16:08:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:08:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-461) Integration tests: EAP In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-461: --------------------------------- Summary: 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 May need to split this into EAP 6.1 and 6.3 -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 16:10:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:10:15 -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: ------------------------------ Summary: Arquillian-based integration tests (was: Investigate using Arquillian for S-RAMP unit and 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 16:32:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:32:15 -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=12973885#comment-12973885 ] Brett Meyer commented on SRAMP-431: ----------------------------------- My initial thought was that none of these should use Arquillian's embedded containers. Each targeted container would be downloaded (if running the tests for the first time) and unpacked, then kick off the S-RAMP installer. Then, run Arquillian in a managed-container mode. I'd rather do something automated, w/ respect to the container distros, than require the tester to pull them down on their own and set an env var. > 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 16:48:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 16:48:15 -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=12973885#comment-12973885 ] Brett Meyer edited comment on SRAMP-431 at 6/5/14 4:47 PM: ----------------------------------------------------------- My initial thought was that none of these should use Arquillian's embedded containers. Each targeted container would be downloaded (if running the tests for the first time) and unpacked, then kick off the S-RAMP installer. Then, run Arquillian in a managed-container mode. I'd rather do something automated, w/ respect to the container distros, than require the tester to pull them down on their own and set an env var. The exception to that may be Fuse. Arquillian's OSGi containers work well and simply re-using our features.xml (or at least model the deployment after it) should be doable. was (Author: brmeyer): My initial thought was that none of these should use Arquillian's embedded containers. Each targeted container would be downloaded (if running the tests for the first time) and unpacked, then kick off the S-RAMP installer. Then, run Arquillian in a managed-container mode. I'd rather do something automated, w/ respect to the container distros, than require the tester to pull them down on their own and set an env var. > 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 17:28:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 17:28:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-443) The Teiid model deriver is not being used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-443: ------------------------------ Fix Version/s: 0.5.0.Alpha1 > The Teiid model deriver is not being used > ----------------------------------------- > > Key: SRAMP-443 > URL: https://issues.jboss.org/browse/SRAMP-443 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > The org.overlord.sramp.integration.teiid.deriver.ModelDeriverProvider class is not providing the correct deriver. I think this class was copy/pasted and never changed to return the correct provider type. > I think we just need to change from this: > {code} > return Collections.singletonMap(TeiidArtifactType.MODEL.extendedType(), (ArtifactDeriver)new VdbManifestDeriver()); > {code} > to this: > {code} > return Collections.singletonMap(TeiidArtifactType.MODEL.extendedType(), (ArtifactDeriver)new ModelDeriver()); > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Thu Jun 5 17:28:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Thu, 5 Jun 2014 17:28:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-443) The Teiid model deriver is not being used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-443. ------------------------------- Resolution: Done > The Teiid model deriver is not being used > ----------------------------------------- > > Key: SRAMP-443 > URL: https://issues.jboss.org/browse/SRAMP-443 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > The org.overlord.sramp.integration.teiid.deriver.ModelDeriverProvider class is not providing the correct deriver. I think this class was copy/pasted and never changed to return the correct provider type. > I think we just need to change from this: > {code} > return Collections.singletonMap(TeiidArtifactType.MODEL.extendedType(), (ArtifactDeriver)new VdbManifestDeriver()); > {code} > to this: > {code} > return Collections.singletonMap(TeiidArtifactType.MODEL.extendedType(), (ArtifactDeriver)new ModelDeriver()); > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 07:44:16 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 6 Jun 2014 07:44:16 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-295) Support deployment in EAP without switchyard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-295: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/112 > Support deployment in EAP without switchyard > -------------------------------------------- > > Key: RTGOV-295 > URL: https://issues.jboss.org/browse/RTGOV-295 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Minor > Fix For: 2.0.0.Final > > Original Estimate: 1 day > Remaining Estimate: 1 day > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 07:44:17 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 6 Jun 2014 07:44:17 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-295) Support deployment in EAP without switchyard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-295. ------------------------------ Resolution: Done Only issue is that currently the samples are built around a switchyard app - so when just used with EAP, we need another app (possibly REST service) that can be monitored. > Support deployment in EAP without switchyard > -------------------------------------------- > > Key: RTGOV-295 > URL: https://issues.jboss.org/browse/RTGOV-295 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Priority: Minor > Fix For: 2.0.0.Final > > Original Estimate: 1 day > Remaining Estimate: 1 day > -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 07:58:17 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 6 Jun 2014 07:58:17 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-392) Documentation: Use single quotes in S-RAMP query examples In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-392: -------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > Documentation: Use single quotes in S-RAMP query examples > --------------------------------------------------------- > > Key: SRAMP-392 > URL: https://issues.jboss.org/browse/SRAMP-392 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > The guide has a section on s-ramp query examples. These examples use double-quotes which makes it hard to copy/paste them into the CLI. Use single quotes instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 09:24:17 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 6 Jun 2014 09:24:17 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-490) Refactor to better support multiple installation targets In-Reply-To: References: Message-ID: Gary Brown created RTGOV-490: -------------------------------- Summary: Refactor to better support multiple installation targets Key: RTGOV-490 URL: https://issues.jboss.org/browse/RTGOV-490 Project: RTGov (Run Time Governance) Issue Type: Task Reporter: Gary Brown Assignee: Gary Brown Fix For: 2.0.0.Final Aim is to create a single distribution that will contain an installer for all supported platforms. Subject to changes in the overlord-commons installer, to setup the target environment, the rtgov installer should apply additional changes to the target location. As part of this refactor, the integration tests should be moved out into a separate top level folder - aim will be to support integration testing across all supported platform from the same set of arquillian tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 14:24:15 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 6 Jun 2014 14:24:15 -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=12974293#comment-12974293 ] Eric Wittmann commented on SRAMP-431: ------------------------------------- Can't auto-download EAP though, right? Do we use wildfly instead? Also, why not use the embedded containers? (question from an Arquillian n00b) > 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 14:38:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 14:38:15 -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=12974297#comment-12974297 ] Brett Meyer commented on SRAMP-431: ----------------------------------- Embedded would be ok for Tomcat/Jetty, I suppose, but I was leaning towards reproducing as "real-world" setups as possible, utilizing the actual installer on a local deployment. Good point about EAP. Technically, it's possible (at least it used to be, but that may be behind VPN), but there are certainly legal issues with that. If we have to do what RTGov currently does (download/unpack an EAP distro, set $JBOSS_HOME), so be it. I was hoping to have all this cooking in Jenkins, but we'd need to think through that. > 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 14:38:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 14:38:15 -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=12974297#comment-12974297 ] Brett Meyer edited comment on SRAMP-431 at 6/6/14 2:37 PM: ----------------------------------------------------------- Embedded would be ok for Tomcat/Jetty, I suppose, but I was leaning towards reproducing as "real-world" setups as possible, utilizing the actual installer on a local deployment. There are definitely pros/cons -- I could go either way. Good point about EAP. Technically, it's possible (at least it used to be, but that may be behind VPN), but there are certainly legal issues with that. If we have to do what RTGov currently does (download/unpack an EAP distro, set $JBOSS_HOME), so be it. I was hoping to have all this cooking in Jenkins, but we'd need to think through that. was (Author: brmeyer): Embedded would be ok for Tomcat/Jetty, I suppose, but I was leaning towards reproducing as "real-world" setups as possible, utilizing the actual installer on a local deployment. Good point about EAP. Technically, it's possible (at least it used to be, but that may be behind VPN), but there are certainly legal issues with that. If we have to do what RTGov currently does (download/unpack an EAP distro, set $JBOSS_HOME), so be it. I was hoping to have all this cooking in Jenkins, but we'd need to think through that. > 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:04:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:04:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-427) Victims rule disabled from enforcer plugin following IP BOM upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-427: --------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > Victims rule disabled from enforcer plugin following IP BOM upgrade > ------------------------------------------------------------------- > > Key: SRAMP-427 > URL: https://issues.jboss.org/browse/SRAMP-427 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > Following upgrade of IP BOM version to 6.0.0.CR8, the enforcer plugin's victims rule caused problems complaining about the dependency on jansi-1.9, related to https://access.redhat.com/security/cve/CVE-2013-2035. > The rule is currently ignored in the top level pom. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:04:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:04:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-427) Victims rule disabled from enforcer plugin following IP BOM upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974304#comment-12974304 ] Brett Meyer commented on SRAMP-427: ----------------------------------- Check and see if this is still an issue with CR9 > Victims rule disabled from enforcer plugin following IP BOM upgrade > ------------------------------------------------------------------- > > Key: SRAMP-427 > URL: https://issues.jboss.org/browse/SRAMP-427 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > Following upgrade of IP BOM version to 6.0.0.CR8, the enforcer plugin's victims rule caused problems complaining about the dependency on jansi-1.9, related to https://access.redhat.com/security/cve/CVE-2013-2035. > The rule is currently ignored in the top level pom. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:04:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:04:16 -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 reassigned SRAMP-433: --------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > 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.3#6260) From issues at jboss.org Fri Jun 6 15:06:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:06:15 -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=12974306#comment-12974306 ] Brett Meyer commented on SRAMP-433: ----------------------------------- Create an extendable API, but JMS will probably be the first impl. DTGov will be one subscriber (instead of the current polling). > 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.3#6260) From issues at jboss.org Fri Jun 6 15:12:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:12:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-449) Ontologies Page: download icon not being pulled fully right In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-449: ------------------------------ Git Pull Request: https://github.com/Governance/s-ramp/pull/425 > Ontologies Page: download icon not being pulled fully right > ----------------------------------------------------------- > > Key: SRAMP-449 > URL: https://issues.jboss.org/browse/SRAMP-449 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > The Ontologies page now has a download icon for each ontology. The icon is not being pulled fully to the right, because the table column it is being displayed within is too large. In other words, the icon is being displayed at the left-most part of the "icons" column of the table. A quick fix would be to set the column width for the icons column to 1%. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:12:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:12:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-449) Ontologies Page: download icon not being pulled fully right In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-449. ------------------------------- Fix Version/s: 0.5.0.Alpha1 Resolution: Done > Ontologies Page: download icon not being pulled fully right > ----------------------------------------------------------- > > Key: SRAMP-449 > URL: https://issues.jboss.org/browse/SRAMP-449 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: UI > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > The Ontologies page now has a download icon for each ontology. The icon is not being pulled fully to the right, because the table column it is being displayed within is too large. In other words, the icon is being displayed at the left-most part of the "icons" column of the table. A quick fix would be to set the column width for the icons column to 1%. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:14:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:14:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-462) S-RAMP 1.0 spec compliance and TCK In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-462: --------------------------------- Summary: S-RAMP 1.0 spec compliance and TCK Key: SRAMP-462 URL: https://issues.jboss.org/browse/SRAMP-462 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Parent task for tracking all S-RAMP 1.0 spec support and TCK development. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:18:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:18:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-167) Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-167: ------------------------------ Parent: SRAMP-462 Issue Type: Sub-task (was: Feature Request) > Add support for the logical models defined in the S-RAMP spec (SOA, ServiceImpl, etc) > ------------------------------------------------------------------------------------- > > Key: SRAMP-167 > URL: https://issues.jboss.org/browse/SRAMP-167 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > We need to make sure that we can support the logical (non-document) artifact types. The mechanism for creating them is different (there's no POST of a document). -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:18:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:18:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-169) Organization hierarchy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-169: ------------------------------ Parent: SRAMP-462 Issue Type: Sub-task (was: Feature Request) > Organization hierarchy > ---------------------- > > Key: SRAMP-169 > URL: https://issues.jboss.org/browse/SRAMP-169 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Kurt Stam > Fix For: 0.6.0 > > > The SRAMP spec defines an Organization entity (derived from HumanActor) that can be related to a ServiceImplementation using the 'provides' relationship. > In large organizations it may be necessary to define more of a organizational structure, to correctly associate the services with the appropriate business units, departments, etc. that are responsible for the service. > The other issue is whether a 'provides' relationship is enough. This may indicate the implementers of the service, but not necessarily the support contact if there is a problem with the service. So potentially there should also be a 'supports' relationship that can optionally be used where the support is provided by a different team. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:18:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:18:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-463) OpenShift cartridge In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-463: --------------------------------- Summary: OpenShift cartridge Key: SRAMP-463 URL: https://issues.jboss.org/browse/SRAMP-463 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.3#6260) From issues at jboss.org Fri Jun 6 15:20:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:20:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-464) Docker image In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-464: --------------------------------- Summary: Docker image Key: SRAMP-464 URL: https://issues.jboss.org/browse/SRAMP-464 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.3#6260) From issues at jboss.org Fri Jun 6 15:26:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:26:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-465) Investigate alternative methods for relationship resolution In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-465: --------------------------------- Summary: Investigate alternative methods for relationship resolution Key: SRAMP-465 URL: https://issues.jboss.org/browse/SRAMP-465 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Investigate increased automatic artifact relationships (ie, service A depends on service B), useful for impact analysis. Possibly include Java-specific improvements, such as custom annotations (and scanning). -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:28:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:28:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-466) Better utilize batch mode for relationship resolution In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-466: --------------------------------- Summary: Better utilize batch mode for relationship resolution Key: SRAMP-466 URL: https://issues.jboss.org/browse/SRAMP-466 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Better utilize "batch mode" during relationship resolution. Links within the batch would take priority over existing artifacts in the repo. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:28:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:28:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-467) UI: relationship visualizations In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-467: --------------------------------- Summary: UI: relationship visualizations Key: SRAMP-467 URL: https://issues.jboss.org/browse/SRAMP-467 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Components: UI Reporter: Brett Meyer Assignee: Brett Meyer -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:32:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 15:32:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-468) tab completion for UI queries In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-468: --------------------------------- Summary: tab completion for UI queries Key: SRAMP-468 URL: https://issues.jboss.org/browse/SRAMP-468 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer 'tab completion' by using popup while you type an S-RAMP query. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 15:52:15 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 6 Jun 2014 15:52:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-443) The Teiid model deriver is not being used In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974320#comment-12974320 ] RH Bugzilla Integration commented on SRAMP-443: ----------------------------------------------- Brett Meyer changed the Status of [bug 1101513|https://bugzilla.redhat.com/show_bug.cgi?id=1101513] from ASSIGNED to MODIFIED > The Teiid model deriver is not being used > ----------------------------------------- > > Key: SRAMP-443 > URL: https://issues.jboss.org/browse/SRAMP-443 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > The org.overlord.sramp.integration.teiid.deriver.ModelDeriverProvider class is not providing the correct deriver. I think this class was copy/pasted and never changed to return the correct provider type. > I think we just need to change from this: > {code} > return Collections.singletonMap(TeiidArtifactType.MODEL.extendedType(), (ArtifactDeriver)new VdbManifestDeriver()); > {code} > to this: > {code} > return Collections.singletonMap(TeiidArtifactType.MODEL.extendedType(), (ArtifactDeriver)new ModelDeriver()); > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 16:04:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 16:04:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-469) Make better use of SwitchYard SCA during relationship resolution In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-469: --------------------------------- Summary: Make better use of SwitchYard SCA during relationship resolution Key: SRAMP-469 URL: https://issues.jboss.org/browse/SRAMP-469 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Brett Meyer Assignee: Brett Meyer Lots of ideas here, but off the top of my head... @Reference: Service consumed by the CDI bean. Can be internal to the SwitchYard app or an external service (JMS, SOAP, or FTP). -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 16:58:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 16:58:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-189) Upload Switchyard SCA diagram automatically from maven In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974360#comment-12974360 ] Brett Meyer commented on SRAMP-189: ----------------------------------- Hey [~kcbabo], any info available on this? I'm not having any luck finding details. Thanks! > Upload Switchyard SCA diagram automatically from maven > ------------------------------------------------------ > > Key: SRAMP-189 > URL: https://issues.jboss.org/browse/SRAMP-189 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > Switchyard is planning on generating an SCA diagram for applications during build. When uploading the application to s-ramp this diagram should be included and appropriately linked. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 17:10:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 17:10:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-392) Documentation: Use single quotes in S-RAMP query examples In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-392. ------------------------------- Fix Version/s: 0.5.0.Alpha1 Resolution: Done Updated https://github.com/Governance/s-ramp/wiki/GuideSrampQueryLanguage > Documentation: Use single quotes in S-RAMP query examples > --------------------------------------------------------- > > Key: SRAMP-392 > URL: https://issues.jboss.org/browse/SRAMP-392 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > The guide has a section on s-ramp query examples. These examples use double-quotes which makes it hard to copy/paste them into the CLI. Use single quotes instead. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 17:32:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 17:32:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-427) Victims rule disabled from enforcer plugin following IP BOM upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12974370#comment-12974370 ] Brett Meyer commented on SRAMP-427: ----------------------------------- Appears to be corrected in Fuse (https://bugzilla.redhat.com/show_bug.cgi?id=958618) -- build passed. > Victims rule disabled from enforcer plugin following IP BOM upgrade > ------------------------------------------------------------------- > > Key: SRAMP-427 > URL: https://issues.jboss.org/browse/SRAMP-427 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > Following upgrade of IP BOM version to 6.0.0.CR8, the enforcer plugin's victims rule caused problems complaining about the dependency on jansi-1.9, related to https://access.redhat.com/security/cve/CVE-2013-2035. > The rule is currently ignored in the top level pom. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 17:32:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 17:32:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-427) Victims rule disabled from enforcer plugin following IP BOM upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer updated SRAMP-427: ------------------------------ Fix Version/s: 0.5.0.Alpha1 > Victims rule disabled from enforcer plugin following IP BOM upgrade > ------------------------------------------------------------------- > > Key: SRAMP-427 > URL: https://issues.jboss.org/browse/SRAMP-427 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > Following upgrade of IP BOM version to 6.0.0.CR8, the enforcer plugin's victims rule caused problems complaining about the dependency on jansi-1.9, related to https://access.redhat.com/security/cve/CVE-2013-2035. > The rule is currently ignored in the top level pom. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Fri Jun 6 17:32:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Fri, 6 Jun 2014 17:32:15 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-427) Victims rule disabled from enforcer plugin following IP BOM upgrade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-427. ------------------------------- Resolution: Done > Victims rule disabled from enforcer plugin following IP BOM upgrade > ------------------------------------------------------------------- > > Key: SRAMP-427 > URL: https://issues.jboss.org/browse/SRAMP-427 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.5.0.Final, 0.5.0.Alpha1 > > > Following upgrade of IP BOM version to 6.0.0.CR8, the enforcer plugin's victims rule caused problems complaining about the dependency on jansi-1.9, related to https://access.redhat.com/security/cve/CVE-2013-2035. > The rule is currently ignored in the top level pom. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 9 03:52:15 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 9 Jun 2014 03:52:15 -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=12974461#comment-12974461 ] Gary Brown commented on SRAMP-431: ---------------------------------- Agree using managed containers would be good for all but fuse, to replicate the installation process as well. Areas to consider: 1) As Eric said, EAP cannot be downloaded, so we need to work out an alternative approach for obtaining this distribution. Although we will want to support WildFly at some point, it would be good to have EAP as a separate test. 2) RTGov requires Switchyard to also be installed - atleast for EAP - however this should just be a case of adding its installation as an additional step before running the integration tests. 3) For RTGov we will need to partition the integration tests, as there are groups of tests that use different deployments. Although this may not be an issue for SRAMP or DTGov, it would be good to factor this in to the design, so we use a common approach across the sub-projects. > 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 9 09:34:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 9 Jun 2014 09:34:15 -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=12974611#comment-12974611 ] Brett Meyer commented on SRAMP-431: ----------------------------------- Thanks Gary. For now, we'll implement EAP similar to what you did for RTGov: require an installation to be unpacked, then set JBOSS_HOME. But eventually, once we have CI hardware within RH's network, we should also support automatically pulling it down. For Tomcat & Jetty, let's give automatically downloading the distros a shot. And yes, for Fuse, embedded. > 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 abstract class 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. > - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. > Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the integration tests. -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 9 10:40:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 9 Jun 2014 10:40:16 -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 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 was: Create a new s-ramp-test module to contain all integration tests. Thoughts: - 1 central abstract class 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. - None of them should run by default. Pull them all into a specific Maven profile, then setup a new CI job specifically for it. Also, many unit tests currently spin up a temporary S-RAMP server, once per test class. Eventually, investigate whether or not some of those test cases should instead be pulled into the 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 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 -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 9 10:40:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 9 Jun 2014 10:40:16 -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=12974638#comment-12974638 ] Brett Meyer commented on SRAMP-431: ----------------------------------- Updated the description with all combined thoughts > 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 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 -- This message was sent by Atlassian JIRA (v6.2.3#6260) From issues at jboss.org Mon Jun 9 15:25:16 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 9 Jun 2014 15:25:16 -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 ] Work on SRAMP-440 started by Brett Meyer. > 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.Final > > > 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.3#6260) From issues at jboss.org Mon Jun 9 15:27:15 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 9 Jun 2014 15:27:15 -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: ------------------------------ Git Pull Request: https://github.com/Governance/overlord-commons/pull/78, https://github.com/Governance/s-ramp/pull/433 Don't merge until after the alpha release! > 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.Final > > > 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.3#6260) From issues at jboss.org Wed Jun 11 09:39:42 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 11 Jun 2014 09:39:42 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12975285#comment-12975285 ] Gary Brown commented on RTGOV-461: ---------------------------------- Also reproduced the issue with the following sequence: 1) clean out ES data folder 2) start ES server and EAP (with rtgov installed) 3) submit order3 request 4) submit order5bad request 5) check call trace for exception situation, which will show the single request for order 5, followed by trace for order 3 > Call trace includes activities from other conversations when using ESActivityStore > ---------------------------------------------------------------------------------- > > Key: RTGOV-461 > URL: https://issues.jboss.org/browse/RTGOV-461 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 09:45:42 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 11 Jun 2014 09:45:42 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-398) Check whether switchyard service supports resubmission of message In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-398. ------------------------------ Resolution: Done > Check whether switchyard service supports resubmission of message > ----------------------------------------------------------------- > > Key: RTGOV-398 > URL: https://issues.jboss.org/browse/RTGOV-398 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Components: User Interface > Reporter: Gary Brown > Assignee: Michael Clay > Fix For: 2.0.0.Final > > > To support message resubmission, a switchyard service must have a SCA binding and the target operation must be oneway. > RTGOV-340 provides the mechanism for determining if a message can be resubmitted, and providing edit/resubmit support in the UI. > This issue updates the SwitchYardServicesProvider to correctly determine if the target service type and operation supports message resubmission. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:04:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:04:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-446) Browser seems to be caching the s-ramp-ui and dtgov-ui host page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-446: ----------------------------------- Assignee: Eric Wittmann (was: Brett Meyer) > Browser seems to be caching the s-ramp-ui and dtgov-ui host page > ---------------------------------------------------------------- > > Key: SRAMP-446 > URL: https://issues.jboss.org/browse/SRAMP-446 > 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.Final > > > Browser caching should be disabled for the host page otherwise authentication might not always work. We need a filter to set no-cache headers when serving the root of the UI or the index.html host page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:04:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:04:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-404) Create a Deriver for WADL files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-404: ----------------------------------- Assignee: Brett Meyer (was: Kurt Stam) > Create a Deriver for WADL files > ------------------------------- > > Key: SRAMP-404 > URL: https://issues.jboss.org/browse/SRAMP-404 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.5.0.Final > > > We currently have Derivers for WSDL and related SOA artifact types, but it would be nice to have a Deriver for WADL files. > This feature request initiated from: > https://community.jboss.org/message/869323 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:04:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:04:39 -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 ] Eric Wittmann reassigned SRAMP-380: ----------------------------------- Assignee: Eric Wittmann (was: Kurt Stam) > 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.5.0.Final > > > When we install into JBoss EAP we make sure that we don't have any clear text passwords in any configuration files. This is made possible by using the Vault, which allows us to store passwords in the vault and then refer to those vault locations from our config files. > I don't know if there is something similar to be done in Fuse 6.1 > In addition, the login credentials for supported users in EAP are not stored in clear text (the EAP Application Realm config files store an encrypted version of the passwords). > In Fuse 6.1 we are storing the login user credentials in a users.properties file in clear text. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:06:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:06:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-454) CLI Command: Echo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-454: ----------------------------------- Assignee: Eric Wittmann (was: Brett Meyer) > CLI Command: Echo > ----------------- > > Key: SRAMP-454 > URL: https://issues.jboss.org/browse/SRAMP-454 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Implement a new CLI command that simply takes 1 argument (an arbitrary string) and echos it back. This would be helpful when running a CLI command file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:06:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:06:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-454) CLI Command: Echo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-454 started by Eric Wittmann. > CLI Command: Echo > ----------------- > > Key: SRAMP-454 > URL: https://issues.jboss.org/browse/SRAMP-454 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Implement a new CLI command that simply takes 1 argument (an arbitrary string) and echos it back. This would be helpful when running a CLI command file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:30:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:30:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-454) CLI Command: Echo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-454: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/435 > CLI Command: Echo > ----------------- > > Key: SRAMP-454 > URL: https://issues.jboss.org/browse/SRAMP-454 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Implement a new CLI command that simply takes 1 argument (an arbitrary string) and echos it back. This would be helpful when running a CLI command file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:32:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:32:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-454) CLI Command: Echo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-454. --------------------------------- Resolution: Done > CLI Command: Echo > ----------------- > > Key: SRAMP-454 > URL: https://issues.jboss.org/browse/SRAMP-454 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Implement a new CLI command that simply takes 1 argument (an arbitrary string) and echos it back. This would be helpful when running a CLI command file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:32:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:32:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-454) CLI Command: Echo In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-454. ------------------------------- > CLI Command: Echo > ----------------- > > Key: SRAMP-454 > URL: https://issues.jboss.org/browse/SRAMP-454 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Implement a new CLI command that simply takes 1 argument (an arbitrary string) and echos it back. This would be helpful when running a CLI command file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 11 14:32:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 11 Jun 2014 14:32:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-452) Enhance s-ramp CLI property interpolation: support default values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-452 started by Eric Wittmann. > Enhance s-ramp CLI property interpolation: support default values > ------------------------------------------------------------------ > > Key: SRAMP-452 > URL: https://issues.jboss.org/browse/SRAMP-452 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the shell supports property interpolation so that variables can be used in CLI command files. This takes the following form (for example): > {code} > connect http://localhost:8080/s-ramp ${username} ${password} > {code} > The CLI can then be invoked like this: > {code} > sramp.sh -f path/to/cli.txt -Dusername=admin -Dpassword=adminp > {code} > This is good, but let's also support optional default values for the variables, like this: > {code} > connect http://localhost:8080/s-ramp ${username:admin} ${password:adminp} > {code} > This will continue to replace ${username} with whatever value is passed via -Dusername=blah. However, if -Dusername is *not* provided, then the default value of 'admin' will be used. This will result in more powerful CLI scripts with commands like this: > {code} > connect ${sramp.endpoint:http://localhost:8080/s-ramp} ${sramp.username:admin} ${sramp.password:adminp} > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 04:14:39 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 12 Jun 2014 04:14:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-451: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/436 > S-ramp maven facade for fuse fabric > ----------------------------------- > > Key: SRAMP-451 > URL: https://issues.jboss.org/browse/SRAMP-451 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Original Estimate: 1 week > Remaining Estimate: 1 week > > Create a mvn-http facade component that will act as a intermediate between fuse fabric and s-ramp.. It should be just a servlet that dissects the inbound request's path to extract the GAV information. Then does a s-ramp repository query to find the appropriate artifact > The GET side of that is very easy (pulling artifacts *from* s-ramp) > The servlet would have to take a URL path like this: org/overlord/sramp/s-ramp-api/0.4.0.Final/s-ramp-api-0.4.0.Final.jar and parse that to get the GAV info of: org.overlord.sramp:s-ramp-api:0.4.0.Final:jar -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 08:20:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:20:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-452) Enhance s-ramp CLI property interpolation: support default values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-452: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/437 > Enhance s-ramp CLI property interpolation: support default values > ------------------------------------------------------------------ > > Key: SRAMP-452 > URL: https://issues.jboss.org/browse/SRAMP-452 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the shell supports property interpolation so that variables can be used in CLI command files. This takes the following form (for example): > {code} > connect http://localhost:8080/s-ramp ${username} ${password} > {code} > The CLI can then be invoked like this: > {code} > sramp.sh -f path/to/cli.txt -Dusername=admin -Dpassword=adminp > {code} > This is good, but let's also support optional default values for the variables, like this: > {code} > connect http://localhost:8080/s-ramp ${username:admin} ${password:adminp} > {code} > This will continue to replace ${username} with whatever value is passed via -Dusername=blah. However, if -Dusername is *not* provided, then the default value of 'admin' will be used. This will result in more powerful CLI scripts with commands like this: > {code} > connect ${sramp.endpoint:http://localhost:8080/s-ramp} ${sramp.username:admin} ${sramp.password:adminp} > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 08:20:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:20:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-452) Enhance s-ramp CLI property interpolation: support default values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-452. --------------------------------- Resolution: Done > Enhance s-ramp CLI property interpolation: support default values > ------------------------------------------------------------------ > > Key: SRAMP-452 > URL: https://issues.jboss.org/browse/SRAMP-452 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the shell supports property interpolation so that variables can be used in CLI command files. This takes the following form (for example): > {code} > connect http://localhost:8080/s-ramp ${username} ${password} > {code} > The CLI can then be invoked like this: > {code} > sramp.sh -f path/to/cli.txt -Dusername=admin -Dpassword=adminp > {code} > This is good, but let's also support optional default values for the variables, like this: > {code} > connect http://localhost:8080/s-ramp ${username:admin} ${password:adminp} > {code} > This will continue to replace ${username} with whatever value is passed via -Dusername=blah. However, if -Dusername is *not* provided, then the default value of 'admin' will be used. This will result in more powerful CLI scripts with commands like this: > {code} > connect ${sramp.endpoint:http://localhost:8080/s-ramp} ${sramp.username:admin} ${sramp.password:adminp} > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 08:20:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:20:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-452) Enhance s-ramp CLI property interpolation: support default values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-452. ------------------------------- > Enhance s-ramp CLI property interpolation: support default values > ------------------------------------------------------------------ > > Key: SRAMP-452 > URL: https://issues.jboss.org/browse/SRAMP-452 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Shell > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the shell supports property interpolation so that variables can be used in CLI command files. This takes the following form (for example): > {code} > connect http://localhost:8080/s-ramp ${username} ${password} > {code} > The CLI can then be invoked like this: > {code} > sramp.sh -f path/to/cli.txt -Dusername=admin -Dpassword=adminp > {code} > This is good, but let's also support optional default values for the variables, like this: > {code} > connect http://localhost:8080/s-ramp ${username:admin} ${password:adminp} > {code} > This will continue to replace ${username} with whatever value is passed via -Dusername=blah. However, if -Dusername is *not* provided, then the default value of 'admin' will be used. This will result in more powerful CLI scripts with commands like this: > {code} > connect ${sramp.endpoint:http://localhost:8080/s-ramp} ${sramp.username:admin} ${sramp.password:adminp} > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 08:24:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:24:38 -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 ] Eric Wittmann resolved 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.Final > > > 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 Thu Jun 12 08:24:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:24:39 -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 ] Eric Wittmann closed 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.Final > > > 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 Thu Jun 12 08:24:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:24:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-434) Upgrade overlord-commons-services to use ServiceTracker in the osgi impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-434: ----------------------------------- Assignee: David virgil naranjo (was: Eric Wittmann) > Upgrade overlord-commons-services to use ServiceTracker in the osgi impl > ------------------------------------------------------------------------ > > Key: SRAMP-434 > URL: https://issues.jboss.org/browse/SRAMP-434 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Currently I'm going straight for the service refs in the osgi registry. Instead we should use ServiceTracker. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 08:26:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:26:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-434) Upgrade overlord-commons-services to use ServiceTracker in the osgi impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-434: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > Upgrade overlord-commons-services to use ServiceTracker in the osgi impl > ------------------------------------------------------------------------ > > Key: SRAMP-434 > URL: https://issues.jboss.org/browse/SRAMP-434 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > Currently I'm going straight for the service refs in the osgi registry. Instead we should use ServiceTracker. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 08:58:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 08:58:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-470) Maven Facade: Improve authentication In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-470: ----------------------------------- Summary: Maven Facade: Improve authentication Key: SRAMP-470 URL: https://issues.jboss.org/browse/SRAMP-470 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Components: S-RAMP API Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.5.0.Final Currently the maven facade requires authentication because we do not have a mechanism for providing selective read-only access to the JCR repository. However, the Maven Facade should be a read-only (for Maven GET operations) window into the s-ramp data. We need to do two things: 1) If the Maven Facade Request has authentication credentials associated with it, use them to log into the s-ramp repository 2) If the Maven Facade Request does *not* have authentication credentials associated with it, then log into JCR using read-only credentials -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:00:50 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:00:50 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-471) Maven Facade: Implement maven deploy support In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-471: ----------------------------------- Summary: Maven Facade: Implement maven deploy support Key: SRAMP-471 URL: https://issues.jboss.org/browse/SRAMP-471 Project: S-RAMP Issue Type: Enhancement Security Level: Public (Everyone can see) Components: S-RAMP API Reporter: Eric Wittmann Assignee: David virgil naranjo Fix For: 0.5.0.Final The maven facade currently only supports maven GET related operations (e.g. pulling artifacts out of s-ramp using the standard maven http protocol support). We should enhance the facade to also support the maven PUT/POST http protocol. In other words, support whatever maven does when you do this: {code} mvn deploy {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:02:39 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 12 Jun 2014 09:02:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-490) Refactor to better support multiple installation targets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-490: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/114 > Refactor to better support multiple installation targets > -------------------------------------------------------- > > Key: RTGOV-490 > URL: https://issues.jboss.org/browse/RTGOV-490 > 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 > > > Aim is to create a single distribution that will contain an installer for all supported platforms. > Subject to changes in the overlord-commons installer, to setup the target environment, the rtgov installer should apply additional changes to the target location. > As part of this refactor, the integration tests should be moved out into a separate top level folder - aim will be to support integration testing across all supported platform from the same set of arquillian tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:02:39 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 12 Jun 2014 09:02:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-490) Refactor to better support multiple installation targets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-490. ------------------------------ Resolution: Done > Refactor to better support multiple installation targets > -------------------------------------------------------- > > Key: RTGOV-490 > URL: https://issues.jboss.org/browse/RTGOV-490 > 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 > > > Aim is to create a single distribution that will contain an installer for all supported platforms. > Subject to changes in the overlord-commons installer, to setup the target environment, the rtgov installer should apply additional changes to the target location. > As part of this refactor, the integration tests should be moved out into a separate top level folder - aim will be to support integration testing across all supported platform from the same set of arquillian tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:04:37 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 12 Jun 2014 09:04:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-491) Performance tests In-Reply-To: References: Message-ID: Gary Brown created RTGOV-491: -------------------------------- Summary: Performance tests Key: RTGOV-491 URL: https://issues.jboss.org/browse/RTGOV-491 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 old performance tests reside in release folder, which has almost completely been removed due to restructure in RTGOV-490. Need to decide whether still required/useful, and if so relocate. If no required, then should be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:06:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 12 Jun 2014 09:06:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-492) Failed to retrieve situation when selecting situation for non-switchyard promoted service In-Reply-To: References: Message-ID: Gary Brown created RTGOV-492: -------------------------------- Summary: Failed to retrieve situation when selecting situation for non-switchyard promoted service Key: RTGOV-492 URL: https://issues.jboss.org/browse/RTGOV-492 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 selecting a situation for an unpromoted switchyard service, it results in a "Unable to retrieve situation" error in the UI. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:51:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:51:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-420) S-ramp shell modify error message when updating the content a non-Document style artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-420: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/438 > S-ramp shell modify error message when updating the content a non-Document style artifact > ----------------------------------------------------------------------------------------- > > Key: SRAMP-420 > URL: https://issues.jboss.org/browse/SRAMP-420 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > When the user try to update the content of an artifact without content the error message is not clear at all: > Unable to determine a valid node definition for the node "/s-ramp/artifacts/aa/88/72/8e-9803-454b-9c7b-335db96611dc/jcr:content" in workspace "default" of "sramp" > For testing this issue, for instance: > create DtgovEmailTemplate DeployedSubjectEmailTemplate "E-mail Subject processed when an artifact is getting deployed in dtgov." > property set template "deployed" > property set template-type "subject" > updateMetaData > updateContent dtgov-data/governance-email-templates/deployed.subject.tmpl -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:51:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:51:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-420) S-ramp shell modify error message when updating the content a non-Document style artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-420. --------------------------------- Resolution: Done > S-ramp shell modify error message when updating the content a non-Document style artifact > ----------------------------------------------------------------------------------------- > > Key: SRAMP-420 > URL: https://issues.jboss.org/browse/SRAMP-420 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > When the user try to update the content of an artifact without content the error message is not clear at all: > Unable to determine a valid node definition for the node "/s-ramp/artifacts/aa/88/72/8e-9803-454b-9c7b-335db96611dc/jcr:content" in workspace "default" of "sramp" > For testing this issue, for instance: > create DtgovEmailTemplate DeployedSubjectEmailTemplate "E-mail Subject processed when an artifact is getting deployed in dtgov." > property set template "deployed" > property set template-type "subject" > updateMetaData > updateContent dtgov-data/governance-email-templates/deployed.subject.tmpl -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:51:40 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:51:40 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-420) S-ramp shell modify error message when updating the content a non-Document style artifact In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-420. ------------------------------- > S-ramp shell modify error message when updating the content a non-Document style artifact > ----------------------------------------------------------------------------------------- > > Key: SRAMP-420 > URL: https://issues.jboss.org/browse/SRAMP-420 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > When the user try to update the content of an artifact without content the error message is not clear at all: > Unable to determine a valid node definition for the node "/s-ramp/artifacts/aa/88/72/8e-9803-454b-9c7b-335db96611dc/jcr:content" in workspace "default" of "sramp" > For testing this issue, for instance: > create DtgovEmailTemplate DeployedSubjectEmailTemplate "E-mail Subject processed when an artifact is getting deployed in dtgov." > property set template "deployed" > property set template-type "subject" > updateMetaData > updateContent dtgov-data/governance-email-templates/deployed.subject.tmpl -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:51:40 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:51:40 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-89) Create Policy derived artifact handler In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-89: ------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > Create Policy derived artifact handler > -------------------------------------- > > Key: SRAMP-89 > URL: https://issues.jboss.org/browse/SRAMP-89 > Project: S-RAMP > Issue Type: Sub-task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.6.0 > > > Create the handler that will produce the Derived Artifacts for ws-policy artifacts. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:57:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:57:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-393) S-RAMP Archive Util fails for out-of-order zip files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-393: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/439 > S-RAMP Archive Util fails for out-of-order zip files > ---------------------------------------------------- > > Key: SRAMP-393 > URL: https://issues.jboss.org/browse/SRAMP-393 > 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.Final > > > Bug in this line of code: > https://github.com/Governance/s-ramp/blob/master/s-ramp-atom/src/main/java/org/overlord/sramp/atom/archive/ArchiveUtils.java#L59 > If the zip file entries are out of order, that line could fail because the folder was already created. Simple fix is to check for the existence of that folder first before trying to create it. > Also, we probably need to do a mkdirs() on it, since it might occur before its parent directory entry. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:57:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:57:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-393) S-RAMP Archive Util fails for out-of-order zip files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-393. --------------------------------- Resolution: Done > S-RAMP Archive Util fails for out-of-order zip files > ---------------------------------------------------- > > Key: SRAMP-393 > URL: https://issues.jboss.org/browse/SRAMP-393 > 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.Final > > > Bug in this line of code: > https://github.com/Governance/s-ramp/blob/master/s-ramp-atom/src/main/java/org/overlord/sramp/atom/archive/ArchiveUtils.java#L59 > If the zip file entries are out of order, that line could fail because the folder was already created. Simple fix is to check for the existence of that folder first before trying to create it. > Also, we probably need to do a mkdirs() on it, since it might occur before its parent directory entry. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:57:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:57:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-393) S-RAMP Archive Util fails for out-of-order zip files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-393. ------------------------------- > S-RAMP Archive Util fails for out-of-order zip files > ---------------------------------------------------- > > Key: SRAMP-393 > URL: https://issues.jboss.org/browse/SRAMP-393 > 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.Final > > > Bug in this line of code: > https://github.com/Governance/s-ramp/blob/master/s-ramp-atom/src/main/java/org/overlord/sramp/atom/archive/ArchiveUtils.java#L59 > If the zip file entries are out of order, that line could fail because the folder was already created. Simple fix is to check for the existence of that folder first before trying to create it. > Also, we probably need to do a mkdirs() on it, since it might occur before its parent directory entry. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:57:40 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:57:40 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-381) tomcat INSP needs real transaction manager In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-381: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > tomcat INSP needs real transaction manager > ------------------------------------------ > > Key: SRAMP-381 > URL: https://issues.jboss.org/browse/SRAMP-381 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Persistence > Affects Versions: 0.4.0 - Tomcat Support > Reporter: Kurt Stam > Assignee: Kurt Stam > Fix For: 0.6.0 > > > The infinispan-configuration-tomcat.xml still references a dummy txn manager. > We have to switch that to use bitronix (btm), like jbpm for dtgov. We'd have to write something along the lines of https://github.com/ModeShape/modeshape/blob/master/modeshape-jcr/src/test/java/org/modeshape/transaction/lookup/AtomikosStandaloneJTAManagerLookup.java -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:59:40 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:59:40 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-214) When uploading a jar - upload a text file with the output of jar tv In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-214: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > When uploading a jar - upload a text file with the output of jar tv > ------------------------------------------------------------------- > > Key: SRAMP-214 > URL: https://issues.jboss.org/browse/SRAMP-214 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Kurt Stam > Assignee: David virgil naranjo > Fix For: 0.6.0 > > > It's nice to know the content of a jar/war/ear archive (for searching/diffing/or just to see what's in it etc). Would be nice to 'extract' a jar tf > jar-content.txt file and upload that to s-ramp too -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:59:40 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:59:40 -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 ] Eric Wittmann updated SRAMP-225: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > 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: Eric Wittmann > 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 Thu Jun 12 09:59:41 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:59:41 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-163) Authorization: Role based access to S-RAMP data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-163: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > Authorization: Role based access to S-RAMP data > ----------------------------------------------- > > Key: SRAMP-163 > URL: https://issues.jboss.org/browse/SRAMP-163 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.6.0 > > > Support role-based (fine-grained) access to s-ramp artifact data. The authenticated user should only see artifacts she has access to. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 09:59:42 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 09:59:42 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-163) Authorization: Role based access to S-RAMP data In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-163: -------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > Authorization: Role based access to S-RAMP data > ----------------------------------------------- > > Key: SRAMP-163 > URL: https://issues.jboss.org/browse/SRAMP-163 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Support role-based (fine-grained) access to s-ramp artifact data. The authenticated user should only see artifacts she has access to. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 10:01:44 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 10:01:44 -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 ] Eric Wittmann updated SRAMP-437: -------------------------------- Fix Version/s: (was: 0.5.0.Alpha1) > 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.Final > > > 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 Thu Jun 12 10:01:44 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 10:01:44 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-423) Enable SRAMP to be deployed to fabric as a profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-423: -------------------------------- Fix Version/s: (was: 0.5.0.Alpha1) > Enable SRAMP to be deployed to fabric as a profile > -------------------------------------------------- > > Key: SRAMP-423 > URL: https://issues.jboss.org/browse/SRAMP-423 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Enable SRAMP to be deployed to fabric as a profile. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 10:01:45 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 10:01:45 -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 ] Eric Wittmann updated SRAMP-179: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > 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: David virgil naranjo > Fix For: 0.6.0 > > > 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 Thu Jun 12 10:05:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 10:05:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-446) Browser seems to be caching the s-ramp-ui and dtgov-ui host page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-446 started by Eric Wittmann. > Browser seems to be caching the s-ramp-ui and dtgov-ui host page > ---------------------------------------------------------------- > > Key: SRAMP-446 > URL: https://issues.jboss.org/browse/SRAMP-446 > 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.Final > > > Browser caching should be disabled for the host page otherwise authentication might not always work. We need a filter to set no-cache headers when serving the root of the UI or the index.html host page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 10:34:38 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Thu, 12 Jun 2014 10:34:38 -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=12975691#comment-12975691 ] David virgil naranjo commented on SRAMP-431: -------------------------------------------- Hi Brett, I like how you structure the Arquillian Integration Tests. This post is useful: https://docs.jboss.org/author/display/ARQ/Container+adapters It does not say anything about eap 6.3, that is the latest one we support. Interesting post that explains difference between remote, embedded and managed containers. http://arquillian.org/blog/2012/04/13/the-danger-of-embedded-containers/ About UI testing. I have been reviewing today, selenium and arquillian: Selenium: There is a firefox plugin that generates the test suite code, recording the steps done in the browser. Then it generates java code. You need to specify the url (can be modified depending the profile). It also allow to run the same test in different browsers using the parameterized annotation. It would require that the server instance (tomcat, jetty, jboss...) is started. In continuous integration that could be done easily. Just adding the tomcat plugin, or jboss plugin and calling start and stop. As the selenium tests would be just junit tests, they would be located in the src/test folder of every ui project. Related Links: http://seleniumsimplified.com/get-started/ Good videos to show how easy could be to develop tests. http://blog.wedoqa.com/2013/10/parameterized-junit-tests-with-selenium-webdriver-2/ Arquillian Arquillian allows UI testing using Arquillian drone. But the problem here is that, it requires the test to create all the artifact to be deployed manually: https://community.jboss.org/en/arquillian/blog/2011/09/17/functional-testing-with-arquillian In our case we do not have just html files in the webapp folder. We have gwt as UI technology. I have seen another project arquillian-gwt-extension, but there is not so much documentation and the community is not big. https://community.jboss.org/thread/236077 It could be interesting because it would test the gwt ui as dev mode. But as ease of development, I prefer selenium. Why? Because you do not need to think a lot, just go to the browser, make the bunch of steps, generate the code and adapt it little bit. Maybe I could be wrong. Just waiting your comments and ideas. Thanks David > 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 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 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 10:44:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 12 Jun 2014 10:44:38 -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=12975696#comment-12975696 ] Gary Brown commented on SRAMP-431: ---------------------------------- "As the selenium tests would be just junit tests, they would be located in the src/test folder of every ui project." As they need to be run within the scope of a running target server, won't it just be easier to include these as part of the integration test infrastructure? QE also use selenium, so may be easier to exchange 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 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 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 10:56:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 10:56:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-446) Browser seems to be caching the s-ramp-ui and dtgov-ui host page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-446: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/440 > Browser seems to be caching the s-ramp-ui and dtgov-ui host page > ---------------------------------------------------------------- > > Key: SRAMP-446 > URL: https://issues.jboss.org/browse/SRAMP-446 > 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.Final > > > Browser caching should be disabled for the host page otherwise authentication might not always work. We need a filter to set no-cache headers when serving the root of the UI or the index.html host page. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 16:53:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 16:53:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-451: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/436, https://github.com/Governance/s-ramp/pull/441 (was: https://github.com/Governance/s-ramp/pull/436) > S-ramp maven facade for fuse fabric > ----------------------------------- > > Key: SRAMP-451 > URL: https://issues.jboss.org/browse/SRAMP-451 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Original Estimate: 1 week > Remaining Estimate: 1 week > > Create a mvn-http facade component that will act as a intermediate between fuse fabric and s-ramp.. It should be just a servlet that dissects the inbound request's path to extract the GAV information. Then does a s-ramp repository query to find the appropriate artifact > The GET side of that is very easy (pulling artifacts *from* s-ramp) > The servlet would have to take a URL path like this: org/overlord/sramp/s-ramp-api/0.4.0.Final/s-ramp-api-0.4.0.Final.jar and parse that to get the GAV info of: org.overlord.sramp:s-ramp-api:0.4.0.Final:jar -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 16:55:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 16:55:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-202) The not() function doesn't quite work with relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-202: ----------------------------------- Assignee: Brett Meyer (was: Eric Wittmann) > The not() function doesn't quite work with relationships > -------------------------------------------------------- > > Key: SRAMP-202 > URL: https://issues.jboss.org/browse/SRAMP-202 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.5.0.Final > > > The not() function works well with properties, but not quite with relationships. An example of what doesn't work: > /s-ramp/wsdl/Part[not(element)] > That should return all Parts that do *not* have an element relationship. Since relationships are found by doing a JOIN, it's actually tricky to invert. Right now I think the query engine will produce something that would return all Parts that have some *other* relationship - but it won't return Parts without any relationships at all. I'm not sure how to do the latter other than by using an IN with a subquery (which is supported by ModeShape but is non-standard). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 16:55:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 16:55:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-161) S-RAMP Client: obey endpoints found in /servicedocument In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-161: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > S-RAMP Client: obey endpoints found in /servicedocument > ------------------------------------------------------- > > Key: SRAMP-161 > URL: https://issues.jboss.org/browse/SRAMP-161 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > Fix For: 0.6.0 > > > Currently we use the non-normative URL formats suggested in the S-RAMP Atom Binding document as presumptive endpoints for the various artifact types. Instead, the Atom API Java client should obey the endpoints it finds in the /servicedocument. This means it will *always* query that service document. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 16:55:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 16:55:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-170) Atom feeds do not work very well in exisiting clients In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-170: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > Atom feeds do not work very well in exisiting clients > ----------------------------------------------------- > > Key: SRAMP-170 > URL: https://issues.jboss.org/browse/SRAMP-170 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Atom Binding > Affects Versions: 0.1.1 - Workflow Demo > Reporter: Kurt Stam > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > Attachments: Screen Shot 2013-03-10 at 12.08.22 PM.png > > > When using exiting atom clients our feed don't work very well. I think one should be able to follow links down into an entry for example, but the link is not populated. We should investigate why this is. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 16:55:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 16:55:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-182) Make artifact type detection less generic (atom layer) In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-182: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > Make artifact type detection less generic (atom layer) > ------------------------------------------------------ > > Key: SRAMP-182 > URL: https://issues.jboss.org/browse/SRAMP-182 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Atom Binding, Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > Fix For: 0.6.0 > > > Currently the artifact type detection methods are very generic and do not consider the context. There are two basic scenarios where an artifact type must be detected from an Atom Entry: > 1) atom summary entries > 2) full atom entries > In the former case we need to figure out the type based on meta-data in the Entry, such as the URL, or from the 'x-s-ramp:2010:type' Category (for example) > In the latter case, we should look at the wrapped artifact itself (there will be an custom element in the Atom Entry with a single child - that single child is the full artifact meta-data, and the element name will indicate the type). > Currently we just try both under all circumstances. I want to change from "getArtifactTypeFromEntry" to two methods: > getArtifactTypeFromSummaryEntry > getArtifactTypeFromFullEntry > Callers must know what they have (summary or full). This should be known in all cases. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 16:59:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 16:59:38 -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 ] Eric Wittmann updated SRAMP-387: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > 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: Kurt Stam > Fix For: 0.6.0 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 12 17:01:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Thu, 12 Jun 2014 17:01:38 -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 ] Work on SRAMP-437 started by Eric Wittmann. > 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.Final > > > 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 Fri Jun 13 02:44:38 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 13 Jun 2014 02:44:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-472) Selenium UI tests In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-472: ------------------------------------------ Summary: Selenium UI tests Key: SRAMP-472 URL: https://issues.jboss.org/browse/SRAMP-472 Project: S-RAMP Issue Type: Feature Request 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 Fri Jun 13 02:44:38 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 13 Jun 2014 02:44:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-472) Selenium UI tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo reassigned SRAMP-472: ------------------------------------------ Assignee: David virgil naranjo (was: Brett Meyer) > Selenium UI tests > ----------------- > > Key: SRAMP-472 > URL: https://issues.jboss.org/browse/SRAMP-472 > Project: S-RAMP > Issue Type: Feature Request > 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 Fri Jun 13 03:04:38 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 13 Jun 2014 03:04:38 -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=12975901#comment-12975901 ] David virgil naranjo commented on SRAMP-431: -------------------------------------------- I am not sure about this Gary. Normally the test should be in the src/test folder of the project that they are related. In my opinion the ui tests should be in the s-ramp-ui, and the integration tests should be (talking about s-ramp) in the s-ramp-server. Then if we want specific integration tests for every container supported, we could just place the specific tests in every s-ramp-server-container project. Why I am saying this? Because I just created a project s-ramp/s-ramp-test/s-ramp-test-ui and I realized would not be any code in the src/main/ folder. > 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 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 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 03:06:38 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 13 Jun 2014 03:06:38 -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 ] David virgil naranjo updated SRAMP-431: --------------------------------------- Comment: was deleted (was: I am not sure about this Gary. Normally the test should be in the src/test folder of the project that they are related. In my opinion the ui tests should be in the s-ramp-ui, and the integration tests should be (talking about s-ramp) in the s-ramp-server. Then if we want specific integration tests for every container supported, we could just place the specific tests in every s-ramp-server-container project. Why I am saying this? Because I just created a project s-ramp/s-ramp-test/s-ramp-test-ui and I realized would not be any code in the src/main/ folder. ) > 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 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 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 03:59:37 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 03:59:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-492) Failed to retrieve situation when selecting situation for non-switchyard promoted service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-492: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/115 > Failed to retrieve situation when selecting situation for non-switchyard promoted service > ----------------------------------------------------------------------------------------- > > Key: RTGOV-492 > URL: https://issues.jboss.org/browse/RTGOV-492 > 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 selecting a situation for an unpromoted switchyard service, it results in a "Unable to retrieve situation" error in the UI. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 03:59:37 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 03:59:37 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-492) Failed to retrieve situation when selecting situation for non-switchyard promoted service In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-492. ------------------------------ Resolution: Done > Failed to retrieve situation when selecting situation for non-switchyard promoted service > ----------------------------------------------------------------------------------------- > > Key: RTGOV-492 > URL: https://issues.jboss.org/browse/RTGOV-492 > 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 selecting a situation for an unpromoted switchyard service, it results in a "Unable to retrieve situation" error in the UI. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 04:01:40 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 04:01:40 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-493) Display conversation and endpoint context information on situation details page In-Reply-To: References: Message-ID: Gary Brown created RTGOV-493: -------------------------------- Summary: Display conversation and endpoint context information on situation details page Key: RTGOV-493 URL: https://issues.jboss.org/browse/RTGOV-493 Project: RTGov (Run Time Governance) Issue Type: Task Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Currently no context information is displayed for a selected situation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 05:51:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 05:51:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-493) Display conversation and endpoint context information on situation details page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-493: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/116 > Display conversation and endpoint context information on situation details page > ------------------------------------------------------------------------------- > > Key: RTGOV-493 > URL: https://issues.jboss.org/browse/RTGOV-493 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Currently no context information is displayed for a selected situation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 05:51:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 05:51:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-493) Display conversation and endpoint context information on situation details page In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-493. ------------------------------ Resolution: Done > Display conversation and endpoint context information on situation details page > ------------------------------------------------------------------------------- > > Key: RTGOV-493 > URL: https://issues.jboss.org/browse/RTGOV-493 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Currently no context information is displayed for a selected situation. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 09:08:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 09:08:38 -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:comment-tabpanel&focusedCommentId=12976001#comment-12976001 ] Eric Wittmann commented on SRAMP-437: ------------------------------------- Adding the following markup to web.xml fixes this issue: {code} org.eclipse.jetty.servlet.SessionIdPathParameterName none {code} > 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.Final > > > 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 Fri Jun 13 09:14:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 09:14:38 -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 ] Eric Wittmann updated SRAMP-437: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/79 > 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.Final > > > 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 Fri Jun 13 09:14:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 09:14:38 -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 ] Eric Wittmann resolved 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.Final > > > 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 Fri Jun 13 09:14:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 09:14:39 -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 ] Eric Wittmann closed 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.Final > > > 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 Fri Jun 13 09:18:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 09:18:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-389: ----------------------------------- Assignee: Eric Wittmann (was: David virgil naranjo) > Performance issue in s-ramp client when using custom properties in query results > -------------------------------------------------------------------------------- > > Key: SRAMP-389 > URL: https://issues.jboss.org/browse/SRAMP-389 > 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.Final > > > There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed. > We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list). > Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue). > I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation. > If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 09:18:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 09:18:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-389 started by Eric Wittmann. > Performance issue in s-ramp client when using custom properties in query results > -------------------------------------------------------------------------------- > > Key: SRAMP-389 > URL: https://issues.jboss.org/browse/SRAMP-389 > 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.Final > > > There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed. > We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list). > Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue). > I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation. > If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 09:20:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 09:20:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-494) Fix 404 when first visiting rtgov ui in fuse In-Reply-To: References: Message-ID: Gary Brown created RTGOV-494: -------------------------------- Summary: Fix 404 when first visiting rtgov ui in fuse Key: RTGOV-494 URL: https://issues.jboss.org/browse/RTGOV-494 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 -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 09:24:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 09:24:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-495) Enable Elasticsearch response size to be configured In-Reply-To: References: Message-ID: Gary Brown created RTGOV-495: -------------------------------- Summary: Enable Elasticsearch response size to be configured Key: RTGOV-495 URL: https://issues.jboss.org/browse/RTGOV-495 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 response size currently defaults to 10, which is not high enough for many queries (especially for activity types). We need to set a reasonable maximum, so will default to a higher value and enable it to be overridden by properties when necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:08:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 10:08:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-496) Fabric profile has hardcoded features.xml version In-Reply-To: References: Message-ID: Gary Brown created RTGOV-496: -------------------------------- Summary: Fabric profile has hardcoded features.xml version Key: RTGOV-496 URL: https://issues.jboss.org/browse/RTGOV-496 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 Need to use filtered resources to configure appropriate version. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:18:40 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 10:18:40 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-494) Fix 404 when first visiting rtgov ui in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-494. ------------------------------ Resolution: Rejected Fix is in overlord-commons. > Fix 404 when first visiting rtgov ui in fuse > -------------------------------------------- > > Key: RTGOV-494 > URL: https://issues.jboss.org/browse/RTGOV-494 > 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 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:20:39 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 10:20:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-494) Fix 404 when first visiting rtgov ui in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-494: ----------------------------- Fix Version/s: (was: 2.0.0.Final) > Fix 404 when first visiting rtgov ui in fuse > -------------------------------------------- > > Key: RTGOV-494 > URL: https://issues.jboss.org/browse/RTGOV-494 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:24:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 10:24:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-496) Fabric profile has hardcoded features.xml version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-496: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/117 > Fabric profile has hardcoded features.xml version > ------------------------------------------------- > > Key: RTGOV-496 > URL: https://issues.jboss.org/browse/RTGOV-496 > 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 > > > Need to use filtered resources to configure appropriate version. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:24:39 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 10:24:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-496) Fabric profile has hardcoded features.xml version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-496. ------------------------------ Resolution: Done > Fabric profile has hardcoded features.xml version > ------------------------------------------------- > > Key: RTGOV-496 > URL: https://issues.jboss.org/browse/RTGOV-496 > 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 > > > Need to use filtered resources to configure appropriate version. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:26:38 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 13 Jun 2014 10:26:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-473) S-ramp logout 500 error In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-473: ------------------------------------------ Summary: 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 When logging out of s-ramp, it appears a 500 error: javax.servlet.ServletException: PL00032: Service Provider :: Server Exception org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:28:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 10:28:38 -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 ] Eric Wittmann updated SRAMP-473: -------------------------------- Description: When logging out of s-ramp, it appears a 500 error: {code} javax.servlet.ServletException: PL00032: Service Provider :: Server Exception org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) {code} was: When logging out of s-ramp, it appears a 500 error: javax.servlet.ServletException: PL00032: Service Provider :: Server Exception org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) > 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 > > When logging out of s-ramp, it appears a 500 error: > {code} > javax.servlet.ServletException: PL00032: Service Provider :: Server Exception > org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) > org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) > org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:32:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 10:32:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976052#comment-12976052 ] Eric Wittmann commented on SRAMP-389: ------------------------------------- I have confirmed that the problem is due to the JAXB context being created every time we get the Artifact JAXB object from the Entry. This only happens for atom Feeds, and therefore only happens when the user needs to extract custom properties from an Entry in an Atom Feed. I believe a fix is needed in RestEasy to configure the Entry objects in an Atom Feed to include a JAXBContextFinder. This will allow the Entry to use that finder rather than create a new JAXB Context. > Performance issue in s-ramp client when using custom properties in query results > -------------------------------------------------------------------------------- > > Key: SRAMP-389 > URL: https://issues.jboss.org/browse/SRAMP-389 > 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.Final > > > There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed. > We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list). > Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue). > I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation. > If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 10:36:54 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 10:36:54 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-474) CLI: Add a log-to-file option In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-474: ----------------------------------- Summary: 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) 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 Jun 13 10:36:55 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 10:36:55 -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 ] Eric Wittmann updated SRAMP-474: -------------------------------- Component/s: Shell > 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 Jun 13 10:36:56 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 13 Jun 2014 10:36:56 -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 ] David virgil naranjo updated SRAMP-473: --------------------------------------- Description: When logging out of s-ramp, it appears a 500 error: 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] was: When logging out of s-ramp, it appears a 500 error: {code} javax.servlet.ServletException: PL00032: Service Provider :: Server Exception org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:325) org.overlord.commons.gwt.server.filters.ResourceCacheControlFilter.doFilter(ResourceCacheControlFilter.java:82) org.overlord.commons.gwt.server.filters.GWTCacheControlFilter.doFilter(GWTCacheControlFilter.java:76) {code} > 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 > > When logging out of s-ramp, it appears a 500 error: > 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] -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 11:31:40 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 11:31:40 -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 ] Eric Wittmann updated SRAMP-473: -------------------------------- Description: 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} was: When logging out of s-ramp, it appears a 500 error: 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] > 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 > > 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 Fri Jun 13 12:15:41 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 12:15:41 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-495) Enable Elasticsearch response size to be configured In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-495: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/118 > Enable Elasticsearch response size to be configured > --------------------------------------------------- > > Key: RTGOV-495 > URL: https://issues.jboss.org/browse/RTGOV-495 > 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 response size currently defaults to 10, which is not high enough for many queries (especially for activity types). > We need to set a reasonable maximum, so will default to a higher value and enable it to be overridden by properties when necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 12:15:41 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 12:15:41 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-495) Enable Elasticsearch response size to be configured In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-495. ------------------------------ Resolution: Done > Enable Elasticsearch response size to be configured > --------------------------------------------------- > > Key: RTGOV-495 > URL: https://issues.jboss.org/browse/RTGOV-495 > 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 response size currently defaults to 10, which is not high enough for many queries (especially for activity types). > We need to set a reasonable maximum, so will default to a higher value and enable it to be overridden by properties when necessary. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 12:23:38 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 13 Jun 2014 12:23:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-496) Fabric profile has hardcoded features.xml version In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-496: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/117, https://github.com/Governance/rtgov/pull/119 (was: https://github.com/Governance/rtgov/pull/117) > Fabric profile has hardcoded features.xml version > ------------------------------------------------- > > Key: RTGOV-496 > URL: https://issues.jboss.org/browse/RTGOV-496 > 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 > > > Need to use filtered resources to configure appropriate version. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 12:27:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 12:27:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-405) Documentation: add artifact model docs for SY model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-405 started by Eric Wittmann. > Documentation: add artifact model docs for SY model > --------------------------------------------------- > > Key: SRAMP-405 > URL: https://issues.jboss.org/browse/SRAMP-405 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > We document many of our models but we're missing documentation for the SY model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 12:27:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 12:27:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-407) Documentation: add artifact model docs for KIE model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-407 started by Eric Wittmann. > Documentation: add artifact model docs for KIE model > ---------------------------------------------------- > > Key: SRAMP-407 > URL: https://issues.jboss.org/browse/SRAMP-407 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Need to update the community documentation related to artifact models to include documentation about the KIE model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 12:27:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 12:27:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-406) Documentation: add artifact model documentation for Java model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-406 started by Eric Wittmann. > Documentation: add artifact model documentation for Java model > -------------------------------------------------------------- > > Key: SRAMP-406 > URL: https://issues.jboss.org/browse/SRAMP-406 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Need to update the community documentation related to artifact data models. We need to add information about the Java model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:10:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:10:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-405) Documentation: add artifact model docs for SY model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-405. --------------------------------- Resolution: Done > Documentation: add artifact model docs for SY model > --------------------------------------------------- > > Key: SRAMP-405 > URL: https://issues.jboss.org/browse/SRAMP-405 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > We document many of our models but we're missing documentation for the SY model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:10:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:10:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-407) Documentation: add artifact model docs for KIE model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-407. --------------------------------- Resolution: Done > Documentation: add artifact model docs for KIE model > ---------------------------------------------------- > > Key: SRAMP-407 > URL: https://issues.jboss.org/browse/SRAMP-407 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Need to update the community documentation related to artifact models to include documentation about the KIE model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:10:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:10:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-406) Documentation: add artifact model documentation for Java model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-406. --------------------------------- Resolution: Done > Documentation: add artifact model documentation for Java model > -------------------------------------------------------------- > > Key: SRAMP-406 > URL: https://issues.jboss.org/browse/SRAMP-406 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Need to update the community documentation related to artifact data models. We need to add information about the Java model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:10:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:10:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-405) Documentation: add artifact model docs for SY model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-405. ------------------------------- > Documentation: add artifact model docs for SY model > --------------------------------------------------- > > Key: SRAMP-405 > URL: https://issues.jboss.org/browse/SRAMP-405 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > We document many of our models but we're missing documentation for the SY model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:10:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:10:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-407) Documentation: add artifact model docs for KIE model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-407. ------------------------------- > Documentation: add artifact model docs for KIE model > ---------------------------------------------------- > > Key: SRAMP-407 > URL: https://issues.jboss.org/browse/SRAMP-407 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Need to update the community documentation related to artifact models to include documentation about the KIE model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:10:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:10:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-406) Documentation: add artifact model documentation for Java model In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-406. ------------------------------- > Documentation: add artifact model documentation for Java model > -------------------------------------------------------------- > > Key: SRAMP-406 > URL: https://issues.jboss.org/browse/SRAMP-406 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Need to update the community documentation related to artifact data models. We need to add information about the Java model. > https://github.com/Governance/s-ramp/wiki/GuideSrampDataModels -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:12:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:12:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-202) The not() function doesn't quite work with relationships In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-202: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > The not() function doesn't quite work with relationships > -------------------------------------------------------- > > Key: SRAMP-202 > URL: https://issues.jboss.org/browse/SRAMP-202 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Brett Meyer > Priority: Minor > Fix For: 0.6.0 > > > The not() function works well with properties, but not quite with relationships. An example of what doesn't work: > /s-ramp/wsdl/Part[not(element)] > That should return all Parts that do *not* have an element relationship. Since relationships are found by doing a JOIN, it's actually tricky to invert. Right now I think the query engine will produce something that would return all Parts that have some *other* relationship - but it won't return Parts without any relationships at all. I'm not sure how to do the latter other than by using an IN with a subquery (which is supported by ModeShape but is non-standard). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:12:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:12:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-203) Ensure the not() function works with classifiers In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-203: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > Ensure the not() function works with classifiers > ------------------------------------------------ > > Key: SRAMP-203 > URL: https://issues.jboss.org/browse/SRAMP-203 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > Fix For: 0.6.0 > > > Not sure if this is working or not (I expect not): > /s-ramp/core/Document[xp2:not(classifiedByAnyOf(., '#blue', '#red'))] > It shouldn't be too hard to support - but not sure if it's working ATM. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:28:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:28:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-389: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/442 > Performance issue in s-ramp client when using custom properties in query results > -------------------------------------------------------------------------------- > > Key: SRAMP-389 > URL: https://issues.jboss.org/browse/SRAMP-389 > 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.Final > > > There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed. > We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list). > Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue). > I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation. > If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:28:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:28:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-389 stopped by Eric Wittmann. > Performance issue in s-ramp client when using custom properties in query results > -------------------------------------------------------------------------------- > > Key: SRAMP-389 > URL: https://issues.jboss.org/browse/SRAMP-389 > 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.Final > > > There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed. > We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list). > Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue). > I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation. > If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:28:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:28:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-389. --------------------------------- Resolution: Done > Performance issue in s-ramp client when using custom properties in query results > -------------------------------------------------------------------------------- > > Key: SRAMP-389 > URL: https://issues.jboss.org/browse/SRAMP-389 > 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.Final > > > There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed. > We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list). > Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue). > I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation. > If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:28:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:28:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-389. ------------------------------- > Performance issue in s-ramp client when using custom properties in query results > -------------------------------------------------------------------------------- > > Key: SRAMP-389 > URL: https://issues.jboss.org/browse/SRAMP-389 > 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.Final > > > There is a feature in s-ramp queries where the client can request that each artifact returned by a query also include a specific subset of the artifact's custom properties. This is in addition to the standard set of meta-data that is always returned when a query is performed. > We currently use this feature in the dtgov WorkflowQueryService class to return the 'query' and 'workflow' custom properties (so they can be displayed in the UI list). > Getting these custom properties while processing the result set is very slow (see ArtifactSummary::getCustomPropertyValue). > I haven't actually verified this, but I *believe* the reason this is slow is because a new JAXB context is created for each ArtifactSummary in the query result list. Creating a JAXB context is a heavy weight operation. > If this is truly the cause, we should try to share the JAXB context in some way. We need to determine whether it is thread-safe, in which case we should have a single JAXB context (singleton). If not, we should create it on a ThreadLocal. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:30:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:30:38 -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 ] Eric Wittmann updated SRAMP-473: -------------------------------- Fix Version/s: 0.5.0.Final > 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.Final > > > 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 Fri Jun 13 13:30:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:30:38 -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 ] Eric Wittmann updated SRAMP-450: -------------------------------- Fix Version/s: 0.5.0.Final > 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.Final > > > 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 Fri Jun 13 13:32:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:32:38 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-451: -------------------------------- Fix Version/s: 0.5.0.Final > S-ramp maven facade for fuse fabric > ----------------------------------- > > Key: SRAMP-451 > URL: https://issues.jboss.org/browse/SRAMP-451 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Create a mvn-http facade component that will act as a intermediate between fuse fabric and s-ramp.. It should be just a servlet that dissects the inbound request's path to extract the GAV information. Then does a s-ramp repository query to find the appropriate artifact > The GET side of that is very easy (pulling artifacts *from* s-ramp) > The servlet would have to take a URL path like this: org/overlord/sramp/s-ramp-api/0.4.0.Final/s-ramp-api-0.4.0.Final.jar and parse that to get the GAV info of: org.overlord.sramp:s-ramp-api:0.4.0.Final:jar -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:32:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:32:38 -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.5.0.Final > 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: Brett Meyer > Fix For: 0.5.0.Final > > > 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 Fri Jun 13 13:32:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:32:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann reassigned SRAMP-453: ----------------------------------- Assignee: David virgil naranjo (was: Brett Meyer) > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:32:39 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:32:39 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-453: -------------------------------- Fix Version/s: 0.5.0.Final > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 13 13:36:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 13:36:38 -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 ] Work on SRAMP-473 started by Eric Wittmann. > 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.Final > > > 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 Fri Jun 13 15:08:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 15:08:38 -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 ] Eric Wittmann updated SRAMP-473: -------------------------------- Git Pull Request: https://github.com/Governance/overlord-commons/pull/80 > 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.Final > > > 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 Fri Jun 13 15:08:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 15:08:38 -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 ] Eric Wittmann resolved 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.Final > > > 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 Fri Jun 13 15:08:38 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 13 Jun 2014 15:08:38 -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 ] Eric Wittmann closed 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.Final > > > 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 Sun Jun 15 16:42:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Sun, 15 Jun 2014 16:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976355#comment-12976355 ] ivan mckinley commented on RTGOV-461: ------------------------------------- hey, not sure how you reproduced this. What exactly do you mean by submit order3, order5 bad.. etc Are you doing this via activity client? > Call trace includes activities from other conversations when using ESActivityStore > ---------------------------------------------------------------------------------- > > Key: RTGOV-461 > URL: https://issues.jboss.org/browse/RTGOV-461 > 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 doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 04:13:25 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Mon, 16 Jun 2014 04:13:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976426#comment-12976426 ] ivan mckinley commented on RTGOV-461: ------------------------------------- Using a simple http client Perform POST on http://localhost:9200/rtgov/_analyze?analyzer with payload = ID-gbrown-redhat-34752-1402652608663-0-3 Result , see below. This displays how the string is represented in eleasticsearch The default value of a string is analyzed, therefore ES splits it up into multiple tokens. which your search matches. recommendation is to set the mapping of that field to "not_analyzed". This will prevent the spliting into token. http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/analysis-intro.html#analyze-api http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/mapping-intro.html I can test this this evening. I think i it may be worth while evaluating this as a default setting for all the objects managed by RTGov. I think i have accommodated for such default requirement with the based rtgov.mapping file. Result of analyzed string {"tokens":[{"token":"id","start_offset":0,"end_offset":2,"type":"","position":1},{"token":"gbrown","start_offset":3,"end_offset":9,"type":"","position":2},{"token":"redhat","start_offset":10,"end_offset":16,"type":"","position":3},{"token":"34752","start_offset":17,"end_offset":22,"type":"","position":4},{"token":"1402652608663","start_offset":23,"end_offset":36,"type":"","position":5},{"token":"0","start_offset":37,"end_offset":38,"type":"","position":6},{"token":"3","start_offset":39,"end_offset":40,"type":"","position":7}]} > Call trace includes activities from other conversations when using ESActivityStore > ---------------------------------------------------------------------------------- > > Key: RTGOV-461 > URL: https://issues.jboss.org/browse/RTGOV-461 > 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 doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 04:15:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 04:15:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976427#comment-12976427 ] Gary Brown commented on RTGOV-461: ---------------------------------- When rtgov is installed in EAP, and the samples are deployed into the running server (using mvn jboss-as:deploy from the samples folder), then go to the ordermgmt/app folder and run: mvn exec:java -Dreq=order3 followed by mvn exec:java -Dreq=order5bad Were you able to use the zipped ES data folder content I sent? > Call trace includes activities from other conversations when using ESActivityStore > ---------------------------------------------------------------------------------- > > Key: RTGOV-461 > URL: https://issues.jboss.org/browse/RTGOV-461 > 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 doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 04:19:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 04:19:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976428#comment-12976428 ] Gary Brown commented on RTGOV-461: ---------------------------------- Comments crossed over :) That sounds like the problem - I'll defer to your expertise regarding whether best to default (and how to do it). The mapping file is located in the modules/common/rtgov-elasticsearch/src/main/resources. > Call trace includes activities from other conversations when using ESActivityStore > ---------------------------------------------------------------------------------- > > Key: RTGOV-461 > URL: https://issues.jboss.org/browse/RTGOV-461 > 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 doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 04:43:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Mon, 16 Jun 2014 04:43:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976438#comment-12976438 ] ivan mckinley commented on RTGOV-461: ------------------------------------- So, should i fix and test the mapping file(this evening) or is this topic blocking you? > Call trace includes activities from other conversations when using ESActivityStore > ---------------------------------------------------------------------------------- > > Key: RTGOV-461 > URL: https://issues.jboss.org/browse/RTGOV-461 > 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 doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 05:06:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 05:06:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-478) NPE when retrieving situation list from rtgov-ui in FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-478: ----------------------------- Fix Version/s: 2.0.0.Final > NPE when retrieving situation list from rtgov-ui in FSW 6.0 > ----------------------------------------------------------- > > Key: RTGOV-478 > URL: https://issues.jboss.org/browse/RTGOV-478 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When deploying the rtgov-ui to FSW 6.0 (war found in the ui/overlord-rtgov-ui-war-fsw60 module, accessing the situations page shows a null pointer exception in a popup window. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 07:35:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 07:35:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-497) Serivce dependency graph based on static and dynamic information In-Reply-To: References: Message-ID: Gary Brown created RTGOV-497: -------------------------------- Summary: Serivce dependency graph based on static and dynamic information Key: RTGOV-497 URL: https://issues.jboss.org/browse/RTGOV-497 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.1.0.Final The current service dependency graph is based on a rolling window of short term activity information, so if a service is not used during that period, then it will not show up on the graph. A more comprehensive graph would be useful that builds on static information available from sources such as switchyard or possibly sramp, enhanced with additional detail when available from sources such as rtgov. Its possible that just static information can be used to provide the graph structure, if the internal relationships between non-promoted services is available via JMX. The dynamic information can be used to help provide additional useful information, to help identify performance bottlenecks etc. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 07:41:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 07:41:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-403) Enable user to filter situations based on custom properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-403: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/97 > Enable user to filter situations based on custom properties > ----------------------------------------------------------- > > Key: RTGOV-403 > URL: https://issues.jboss.org/browse/RTGOV-403 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Michael Clay > Assignee: Michael Clay > Labels: bam > Fix For: 2.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 07:41:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 07:41:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-403) Enable user to filter situations based on custom properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-403. ------------------------------ Fix Version/s: 2.0.0.Final (was: 2.1.0.Final) Resolution: Done > Enable user to filter situations based on custom properties > ----------------------------------------------------------- > > Key: RTGOV-403 > URL: https://issues.jboss.org/browse/RTGOV-403 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Michael Clay > Assignee: Michael Clay > Labels: bam > Fix For: 2.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 08:46:27 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 08:46:27 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-461) Call trace includes activities from other conversations when using ESActivityStore In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-461. ------------------------------ Resolution: Done Resolved as part of commit (https://github.com/Governance/rtgov/commit/c07739b0349518a54fad60154973901b86ad9b79). Thanks to Ivan for suggesting the fix (making context value fields 'not_analyzed'). > Call trace includes activities from other conversations when using ESActivityStore > ---------------------------------------------------------------------------------- > > Key: RTGOV-461 > URL: https://issues.jboss.org/browse/RTGOV-461 > 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 doing order1 followed by order3, the order1 violation produced a correct trace, but the order3 situations resulted in a call trace that also included the trace for order1. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 09:57:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 09:57:25 -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 ] Eric Wittmann updated SRAMP-412: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > 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 > Fix For: 0.6.0 > > > 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 Mon Jun 16 09:57:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 09:57:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-456) CXF version mismatch causing WebServiceTest to fail In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-456: -------------------------------- Fix Version/s: 0.6.0 (was: 0.5.0.Final) > CXF version mismatch causing WebServiceTest to fail > --------------------------------------------------- > > Key: SRAMP-456 > URL: https://issues.jboss.org/browse/SRAMP-456 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Brett Meyer > Fix For: 0.6.0 > > > Switchyard is currently using an older version of the IP BOM (CR6), which has version 2.6.8, while current version for alpha is supposed to be CR9, which has cxf 2.7.11. > This is causing a CNFE for org.apache.cxf.io.CopyingOutputStream. > Currently ignoring the test until versions are aligned. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 10:45:32 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 16 Jun 2014 10:45:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-498) EPN for reporting responsetime events to Elasticsearch In-Reply-To: References: Message-ID: Gary Brown created RTGOV-498: -------------------------------- Summary: EPN for reporting responsetime events to Elasticsearch Key: RTGOV-498 URL: https://issues.jboss.org/browse/RTGOV-498 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 Elasticsearch is only available as part of the new RTGov UI that can be deployed as a separate component on FSW 6.0. Therefore this task will provide an EPN that will subscribe to the responsetime events and persist them in Elasticsearch. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 10:45:32 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 10:45:32 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-453: -------------------------------- Description: If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. {code} S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) at java.lang.StringBuilder.insert(StringBuilder.java:336) at org.jboss.aesh.console.Buffer.write(Buffer.java:319) at org.jboss.aesh.console.Console.writeChar(Console.java:837) at org.jboss.aesh.console.Console.writeChars(Console.java:832) at org.jboss.aesh.console.Console.parseOperation(Console.java:515) at org.jboss.aesh.console.Console.read(Console.java:452) at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) at java.lang.Thread.run(Thread.java:744) {code} was: If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException at java.lang.System.arraycopy(Native Method) at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) at java.lang.StringBuilder.insert(StringBuilder.java:336) at org.jboss.aesh.console.Buffer.write(Buffer.java:319) at org.jboss.aesh.console.Console.writeChar(Console.java:837) at org.jboss.aesh.console.Console.writeChars(Console.java:832) at org.jboss.aesh.console.Console.parseOperation(Console.java:515) at org.jboss.aesh.console.Console.read(Console.java:452) at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) at java.lang.Thread.run(Thread.java:744) > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > {code} > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 11:19:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 11:19:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-470) Maven Facade: Improve authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-470 started by Eric Wittmann. > Maven Facade: Improve authentication > ------------------------------------ > > Key: SRAMP-470 > URL: https://issues.jboss.org/browse/SRAMP-470 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the maven facade requires authentication because we do not have a mechanism for providing selective read-only access to the JCR repository. However, the Maven Facade should be a read-only (for Maven GET operations) window into the s-ramp data. > We need to do two things: > 1) If the Maven Facade Request has authentication credentials associated with it, use them to log into the s-ramp repository > 2) If the Maven Facade Request does *not* have authentication credentials associated with it, then log into JCR using read-only credentials -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 14:13:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 14:13:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-470) Maven Facade: Improve authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-470: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/443 > Maven Facade: Improve authentication > ------------------------------------ > > Key: SRAMP-470 > URL: https://issues.jboss.org/browse/SRAMP-470 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the maven facade requires authentication because we do not have a mechanism for providing selective read-only access to the JCR repository. However, the Maven Facade should be a read-only (for Maven GET operations) window into the s-ramp data. > We need to do two things: > 1) If the Maven Facade Request has authentication credentials associated with it, use them to log into the s-ramp repository > 2) If the Maven Facade Request does *not* have authentication credentials associated with it, then log into JCR using read-only credentials -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 14:13:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 14:13:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-470) Maven Facade: Improve authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-470. --------------------------------- Resolution: Done > Maven Facade: Improve authentication > ------------------------------------ > > Key: SRAMP-470 > URL: https://issues.jboss.org/browse/SRAMP-470 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the maven facade requires authentication because we do not have a mechanism for providing selective read-only access to the JCR repository. However, the Maven Facade should be a read-only (for Maven GET operations) window into the s-ramp data. > We need to do two things: > 1) If the Maven Facade Request has authentication credentials associated with it, use them to log into the s-ramp repository > 2) If the Maven Facade Request does *not* have authentication credentials associated with it, then log into JCR using read-only credentials -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 14:13:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 14:13:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-470) Maven Facade: Improve authentication In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-470. ------------------------------- > Maven Facade: Improve authentication > ------------------------------------ > > Key: SRAMP-470 > URL: https://issues.jboss.org/browse/SRAMP-470 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Currently the maven facade requires authentication because we do not have a mechanism for providing selective read-only access to the JCR repository. However, the Maven Facade should be a read-only (for Maven GET operations) window into the s-ramp data. > We need to do two things: > 1) If the Maven Facade Request has authentication credentials associated with it, use them to log into the s-ramp repository > 2) If the Maven Facade Request does *not* have authentication credentials associated with it, then log into JCR using read-only credentials -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 14:13:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 14:13:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-451. --------------------------------- Resolution: Done > S-ramp maven facade for fuse fabric > ----------------------------------- > > Key: SRAMP-451 > URL: https://issues.jboss.org/browse/SRAMP-451 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Create a mvn-http facade component that will act as a intermediate between fuse fabric and s-ramp.. It should be just a servlet that dissects the inbound request's path to extract the GAV information. Then does a s-ramp repository query to find the appropriate artifact > The GET side of that is very easy (pulling artifacts *from* s-ramp) > The servlet would have to take a URL path like this: org/overlord/sramp/s-ramp-api/0.4.0.Final/s-ramp-api-0.4.0.Final.jar and parse that to get the GAV info of: org.overlord.sramp:s-ramp-api:0.4.0.Final:jar -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 14:13:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 14:13:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-451. ------------------------------- > S-ramp maven facade for fuse fabric > ----------------------------------- > > Key: SRAMP-451 > URL: https://issues.jboss.org/browse/SRAMP-451 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > Original Estimate: 1 week > Remaining Estimate: 1 week > > Create a mvn-http facade component that will act as a intermediate between fuse fabric and s-ramp.. It should be just a servlet that dissects the inbound request's path to extract the GAV information. Then does a s-ramp repository query to find the appropriate artifact > The GET side of that is very easy (pulling artifacts *from* s-ramp) > The servlet would have to take a URL path like this: org/overlord/sramp/s-ramp-api/0.4.0.Final/s-ramp-api-0.4.0.Final.jar and parse that to get the GAV info of: org.overlord.sramp:s-ramp-api:0.4.0.Final:jar -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 16 15:16:26 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 15:16:26 -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 reassigned SRAMP-445: ----------------------------------- Assignee: Eric Wittmann (was: Brett Meyer) > 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.Final > > > 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 Jun 16 15:16:27 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 16 Jun 2014 15:16:27 -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 started 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.Final > > > 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 Jun 16 15:50:24 2014 From: issues at jboss.org (Michael Clay (JIRA)) Date: Mon, 16 Jun 2014 15:50:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-478) NPE when retrieving situation list from rtgov-ui in FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976741#comment-12976741 ] Michael Clay commented on RTGOV-478: ------------------------------------ the NPE is caused from a call to the RTGovSituationsProvider#search because SituationStore _situationStore is null -> the reason is SituationStoreFactory#getSituationStore can't find a SITUATION_STORE_CLASS property in the configured ./standalone/configuration/overlord-rtgov.properties > NPE when retrieving situation list from rtgov-ui in FSW 6.0 > ----------------------------------------------------------- > > Key: RTGOV-478 > URL: https://issues.jboss.org/browse/RTGOV-478 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When deploying the rtgov-ui to FSW 6.0 (war found in the ui/overlord-rtgov-ui-war-fsw60 module, accessing the situations page shows a null pointer exception in a popup window. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 03:35:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 17 Jun 2014 03:35:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-478) NPE when retrieving situation list from rtgov-ui in FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976851#comment-12976851 ] Gary Brown commented on RTGOV-478: ---------------------------------- Thanks for investigating this problem Michael - I'll try it out. > NPE when retrieving situation list from rtgov-ui in FSW 6.0 > ----------------------------------------------------------- > > Key: RTGOV-478 > URL: https://issues.jboss.org/browse/RTGOV-478 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When deploying the rtgov-ui to FSW 6.0 (war found in the ui/overlord-rtgov-ui-war-fsw60 module, accessing the situations page shows a null pointer exception in a popup window. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 03:37:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Tue, 17 Jun 2014 03:37:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-423) Enable SRAMP to be deployed to fabric as a profile In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo resolved SRAMP-423. ---------------------------------------- Resolution: Done > Enable SRAMP to be deployed to fabric as a profile > -------------------------------------------------- > > Key: SRAMP-423 > URL: https://issues.jboss.org/browse/SRAMP-423 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > Enable SRAMP to be deployed to fabric as a profile. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 06:10:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 17 Jun 2014 06:10:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-499) Change to use getSituationProperties when support for FSW60 no longer required In-Reply-To: References: Message-ID: Gary Brown created RTGOV-499: -------------------------------- Summary: Change to use getSituationProperties when support for FSW60 no longer required Key: RTGOV-499 URL: https://issues.jboss.org/browse/RTGOV-499 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 Currently using the deprecated Situation.getProperties method in a few places. This is to enable support for deploying the new RTGov UI, and an EPN for recording response time events in Elasticsearch, within FSW60. Once this support is no longer required, these should be changed to use the getSituationProperties method. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 07:43:28 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 17 Jun 2014 07:43:28 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-500) Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId@....' In-Reply-To: References: Message-ID: Gary Brown created RTGOV-500: -------------------------------- Summary: Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId at ....' Key: RTGOV-500 URL: https://issues.jboss.org/browse/RTGOV-500 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 deploying RTGov UI to FSW6.0, it is now possible to get the list of situations (after RTGOV-478 was fixed) but selecting a situation causes the error: Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId at ......'. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 08:26:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 08:26:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-475) Remove JAXBContext trickery from s-ramp atom utils In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-475: ----------------------------------- Summary: Remove JAXBContext trickery from s-ramp atom utils Key: SRAMP-475 URL: https://issues.jboss.org/browse/SRAMP-475 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Components: Core Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.6.0 There is currently an issue in RE where the JAXBContextFinder is not set on Entry objects inside an Atom Feed. This is a problem with the Feed unmarshaller. Once that is fixed in RE, we can remove the following method from s-ramp: SrampAtomUtils::setFinder() -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 09:05:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 09:05:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-476) Lazy-load of JCR repository incompatible with maven repo facade auth In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-476: ----------------------------------- Summary: Lazy-load of JCR repository incompatible with maven repo facade auth Key: SRAMP-476 URL: https://issues.jboss.org/browse/SRAMP-476 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.5.0.Final The maven repository facade authentication will create a read-only user for accessing the repository. However, we are lazy-loading the JCR repository. So if the read-only maven repository facade credentials are used for the very first request to s-ramp, then jcr repo creation will fail. The solution is to no longer lazy-load the repository. Instead, fabricate an admin-rights user on startup of the s-ramp WAR and use that to create the repository in a separate thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 09:15:30 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 09:15:30 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-476) Lazy-load of JCR repository incompatible with maven repo facade auth In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-476 started by Eric Wittmann. > Lazy-load of JCR repository incompatible with maven repo facade auth > -------------------------------------------------------------------- > > Key: SRAMP-476 > URL: https://issues.jboss.org/browse/SRAMP-476 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > The maven repository facade authentication will create a read-only user for accessing the repository. However, we are lazy-loading the JCR repository. So if the read-only maven repository facade credentials are used for the very first request to s-ramp, then jcr repo creation will fail. > The solution is to no longer lazy-load the repository. Instead, fabricate an admin-rights user on startup of the s-ramp WAR and use that to create the repository in a separate thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 09:21:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 17 Jun 2014 09:21:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-478) NPE when retrieving situation list from rtgov-ui in FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-478: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/121 > NPE when retrieving situation list from rtgov-ui in FSW 6.0 > ----------------------------------------------------------- > > Key: RTGOV-478 > URL: https://issues.jboss.org/browse/RTGOV-478 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When deploying the rtgov-ui to FSW 6.0 (war found in the ui/overlord-rtgov-ui-war-fsw60 module, accessing the situations page shows a null pointer exception in a popup window. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 09:21:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 17 Jun 2014 09:21:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-478) NPE when retrieving situation list from rtgov-ui in FSW 6.0 In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-478. ------------------------------ Resolution: Done Thanks for the pointer Michael. > NPE when retrieving situation list from rtgov-ui in FSW 6.0 > ----------------------------------------------------------- > > Key: RTGOV-478 > URL: https://issues.jboss.org/browse/RTGOV-478 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > When deploying the rtgov-ui to FSW 6.0 (war found in the ui/overlord-rtgov-ui-war-fsw60 module, accessing the situations page shows a null pointer exception in a popup window. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 09:21:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 17 Jun 2014 09:21:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-498) EPN for reporting responsetime events to Elasticsearch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-498: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/121 > EPN for reporting responsetime events to Elasticsearch > ------------------------------------------------------ > > Key: RTGOV-498 > URL: https://issues.jboss.org/browse/RTGOV-498 > 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 > > > Elasticsearch is only available as part of the new RTGov UI that can be deployed as a separate component on FSW 6.0. > Therefore this task will provide an EPN that will subscribe to the responsetime events and persist them in Elasticsearch. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 09:21:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 17 Jun 2014 09:21:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-498) EPN for reporting responsetime events to Elasticsearch In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-498. ------------------------------ Resolution: Done > EPN for reporting responsetime events to Elasticsearch > ------------------------------------------------------ > > Key: RTGOV-498 > URL: https://issues.jboss.org/browse/RTGOV-498 > 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 > > > Elasticsearch is only available as part of the new RTGov UI that can be deployed as a separate component on FSW 6.0. > Therefore this task will provide an EPN that will subscribe to the responsetime events and persist them in Elasticsearch. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 11:52:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 11:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-476) Lazy-load of JCR repository incompatible with maven repo facade auth In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-476: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/444 > Lazy-load of JCR repository incompatible with maven repo facade auth > -------------------------------------------------------------------- > > Key: SRAMP-476 > URL: https://issues.jboss.org/browse/SRAMP-476 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > The maven repository facade authentication will create a read-only user for accessing the repository. However, we are lazy-loading the JCR repository. So if the read-only maven repository facade credentials are used for the very first request to s-ramp, then jcr repo creation will fail. > The solution is to no longer lazy-load the repository. Instead, fabricate an admin-rights user on startup of the s-ramp WAR and use that to create the repository in a separate thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 11:52:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 11:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-476) Lazy-load of JCR repository incompatible with maven repo facade auth In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-476. --------------------------------- Resolution: Done > Lazy-load of JCR repository incompatible with maven repo facade auth > -------------------------------------------------------------------- > > Key: SRAMP-476 > URL: https://issues.jboss.org/browse/SRAMP-476 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > The maven repository facade authentication will create a read-only user for accessing the repository. However, we are lazy-loading the JCR repository. So if the read-only maven repository facade credentials are used for the very first request to s-ramp, then jcr repo creation will fail. > The solution is to no longer lazy-load the repository. Instead, fabricate an admin-rights user on startup of the s-ramp WAR and use that to create the repository in a separate thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 11:52:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 11:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-476) Lazy-load of JCR repository incompatible with maven repo facade auth In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-476. ------------------------------- > Lazy-load of JCR repository incompatible with maven repo facade auth > -------------------------------------------------------------------- > > Key: SRAMP-476 > URL: https://issues.jboss.org/browse/SRAMP-476 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > The maven repository facade authentication will create a read-only user for accessing the repository. However, we are lazy-loading the JCR repository. So if the read-only maven repository facade credentials are used for the very first request to s-ramp, then jcr repo creation will fail. > The solution is to no longer lazy-load the repository. Instead, fabricate an admin-rights user on startup of the s-ramp WAR and use that to create the repository in a separate thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 14:51:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 14:51: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=12977152#comment-12977152 ] Eric Wittmann commented on SRAMP-445: ------------------------------------- After doing some debugging, it appears that there may be a bug in Tomcat that is causing this. What's supposed to happen is that the overlord-idp context will set up a JSESSIONID cookie with the browser, so that each time the user goes back to that context she will get hooked up with the same session. This allows SSO because the container's form authentication will be bypassed due to the existence of authenticated user credentials in the session. Tomcat is correctly sending the Set-Cookie response header for the overlord-idp context. In addition, the browser is sending the proper Cookie request header when making requests to the overlord-idp context. For some reason, however, Tomcat is not using the session it told the client to utilize. So even though the session was created and the client sent the proper Cookie, Tomcat keeps responding with a new sessionid cookie. Note that this can easily be reproduced with only the overlord-idp.war deployed. Simply deploy that war and then hit this url: http://localhost:8080/overlord-idp/ This will prompt the user to log in and, if login was successful, it will display a simple JSP with several Overlord links. Simply refresh this page and you will be asked to log in again! At this point I don't know how to solve this issue and continue to use the PicketLink IDPFilter. I could instead revert back to using the PicketLink tomcat IDP valve. I am hesitant to do this because it means also reverting the installer to download and install JARs in tomcat/lib/ext. > 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.Final > > > 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 Jun 17 15:25:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 15:25:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-478) Restructure S-RAMP integration projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-478: -------------------------------- Fix Version/s: 0.5.0.Final > Restructure S-RAMP integration projects > --------------------------------------- > > Key: SRAMP-478 > URL: https://issues.jboss.org/browse/SRAMP-478 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp integration projects to be all together in a parent project call s-ramp-integration. > The projects to be moved to this parent project are: > s-ramp-integration-java > s-ramp-integration-kie > s-ramp-integration-switchyard > s-ramp-integration-teiid -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 17 15:25:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Tue, 17 Jun 2014 15:25:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-477) Restructure S-RAMP server projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-477: -------------------------------- Fix Version/s: 0.5.0.Final > Restructure S-RAMP server projects > ---------------------------------- > > Key: SRAMP-477 > URL: https://issues.jboss.org/browse/SRAMP-477 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp-server projects to be all together in a parent project call s-ramp-server. > The projects to be moved to this parent project are: > s-ramp-server-eap6 > s-ramp-server-fuse61 > s-ramp-server-jetty8 > s-ramp-server-tomcat7 > s-ramp-server -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 18 05:03:23 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 18 Jun 2014 05:03:23 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-500) Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId@....' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-500: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/123 > Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId at ....' > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-500 > URL: https://issues.jboss.org/browse/RTGOV-500 > 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 deploying RTGov UI to FSW6.0, it is now possible to get the list of situations (after RTGOV-478 was fixed) but selecting a situation causes the error: Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId at ......'. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 18 05:05:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 18 Jun 2014 05:05:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-500) Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId@....' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-500. ------------------------------ Resolution: Done > Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId at ....' > -------------------------------------------------------------------------------------------------- > > Key: RTGOV-500 > URL: https://issues.jboss.org/browse/RTGOV-500 > 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 deploying RTGov UI to FSW6.0, it is now possible to get the list of situations (after RTGOV-478 was fixed) but selecting a situation causes the error: Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId at ......'. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 18 06:11:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 18 Jun 2014 06:11:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-248) Maven mutliproject upload should recognize archive type In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977299#comment-12977299 ] RH Bugzilla Integration commented on SRAMP-248: ----------------------------------------------- Gary Brown changed the Status of [bug 1016644|https://bugzilla.redhat.com/show_bug.cgi?id=1016644] from ASSIGNED to MODIFIED > Maven mutliproject upload should recognize archive type > ------------------------------------------------------- > > Key: SRAMP-248 > URL: https://issues.jboss.org/browse/SRAMP-248 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Client > Affects Versions: 0.3.0 - JBPM6 Integration > Reporter: Kurt Stam > Assignee: Kurt Stam > Fix For: 0.4.0 - Tomcat Support > > > It should be possible to just specify the distribution url; without having to specify the Type in the URL. The expanders can ship with hints regarding certain files in the archive representing a certain type of Type. i.e. switchyard.xml -> SwitchYardApplication. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 18 06:51:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 18 Jun 2014 06:51:24 -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: Gary Brown created SRAMP-479: -------------------------------- Summary: 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 Wed Jun 18 06:51:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 18 Jun 2014 06:51:24 -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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-479: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1029034 > 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 Wed Jun 18 09:19:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 18 Jun 2014 09:19: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=12977364#comment-12977364 ] Gary Brown commented on SRAMP-433: ---------------------------------- Might be useful for DTGOV-123 to use notifications from SRAMP that are distributed via a JMS queue, to enable it to load balance its handling of the artifact events. This would mean that the SRAMP notifier (JMS impl) would need to be configurable to allow topics or queues to be used. Multiple notifiers may also be required with different impls and configurations - e.g. might have two JMS notifiers configured, one with a queue and one with topic. > 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 Jun 18 09:47:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 18 Jun 2014 09:47:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-388) Use jboss version of javax.servlet GAV consistently In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977383#comment-12977383 ] RH Bugzilla Integration commented on SRAMP-388: ----------------------------------------------- Gary Brown changed the Status of [bug 1081519|https://bugzilla.redhat.com/show_bug.cgi?id=1081519] from NEW to MODIFIED > Use jboss version of javax.servlet GAV consistently > --------------------------------------------------- > > Key: SRAMP-388 > URL: https://issues.jboss.org/browse/SRAMP-388 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Alpha1, 0.5.0.Final > > > EAP uses the GAV > {code} > > org.jboss.spec.javax.servlet > jboss-servlet-api_3.0_spec > > {code} > rather than > {code} > > javax.servlet > servlet-api > > {code} > This GAV is also available in the community BOM. > We need to remove all references to the javax.servlet:servlet-api dependency in all Overlord projects (s-ramp, dtgov, overlord-commons, etc). Anywhere we reference that GAV please change it to org.jboss.spec.javax.servlet:jboss-servlet-api_3.0_spec. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 18 09:51:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 18 Jun 2014 09:51: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=12977385#comment-12977385 ] RH Bugzilla Integration commented on SRAMP-395: ----------------------------------------------- Gary Brown changed the Status of [bug 1085429|https://bugzilla.redhat.com/show_bug.cgi?id=1085429] from NEW 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.Final > > > 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 Wed Jun 18 09:59:26 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 18 Jun 2014 09:59:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-393) S-RAMP Archive Util fails for out-of-order zip files In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977394#comment-12977394 ] RH Bugzilla Integration commented on SRAMP-393: ----------------------------------------------- Gary Brown changed the Status of [bug 1094181|https://bugzilla.redhat.com/show_bug.cgi?id=1094181] from NEW to MODIFIED > S-RAMP Archive Util fails for out-of-order zip files > ---------------------------------------------------- > > Key: SRAMP-393 > URL: https://issues.jboss.org/browse/SRAMP-393 > 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.Final > > > Bug in this line of code: > https://github.com/Governance/s-ramp/blob/master/s-ramp-atom/src/main/java/org/overlord/sramp/atom/archive/ArchiveUtils.java#L59 > If the zip file entries are out of order, that line could fail because the folder was already created. Simple fix is to check for the existence of that folder first before trying to create it. > Also, we probably need to do a mkdirs() on it, since it might occur before its parent directory entry. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 18 10:49:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 18 Jun 2014 10:49:24 -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: ----------------------------- Fix Version/s: 2.0.0.Final (was: 2.1.0.Final) > 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 Wed Jun 18 12:01:28 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 18 Jun 2014 12:01:28 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977482#comment-12977482 ] Gary Brown commented on RTGOV-328: ---------------------------------- Although the activity collector does not care about the return value, other applications using the REST API may. So it might be better to concurrency and asynchrony should possible just be handled on the client side? > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 18 12:01:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 18 Jun 2014 12:01:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977482#comment-12977482 ] Gary Brown edited comment on RTGOV-328 at 6/18/14 12:00 PM: ------------------------------------------------------------ Although the activity collector does not care about the return value, other applications using the REST API may. So it might be better that concurrency and asynchrony should possibly just be handled on the client side? was (Author: objectiser): Although the activity collector does not care about the return value, other applications using the REST API may. So it might be better to concurrency and asynchrony should possible just be handled on the client side? > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 03:19:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 03:19:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown closed RTGOV-328. ---------------------------- Resolution: Done Closing the issue - please reopen if you think there are valid reasons for implementing this. > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 03:19:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Thu, 19 Jun 2014 03:19:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977597#comment-12977597 ] RH Bugzilla Integration commented on RTGOV-328: ----------------------------------------------- Gary Brown changed the Status of [bug 1056447|https://bugzilla.redhat.com/show_bug.cgi?id=1056447] from NEW to CLOSED > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 03:49:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 03:49:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-329: ----------------------------- Attachment: Performance.java (1) Clear vs allocation Results: {noformat} TIME TAKEN (clear) arraysize=10 iterations=1000: 31 TIME TAKEN (alloc) arraysize=10 iterations=1000: 4 ----- TIME TAKEN (clear) arraysize=10 iterations=1000: 0 TIME TAKEN (alloc) arraysize=10 iterations=1000: 1 ----- TIME TAKEN (clear) arraysize=100 iterations=1000: 7 TIME TAKEN (alloc) arraysize=100 iterations=1000: 15 ----- TIME TAKEN (clear) arraysize=1000 iterations=1000: 36 TIME TAKEN (alloc) arraysize=1000 iterations=1000: 40 ----- TIME TAKEN (clear) arraysize=10000 iterations=1000: 448 TIME TAKEN (alloc) arraysize=10000 iterations=1000: 699 ----- TIME TAKEN (clear) arraysize=100000 iterations=1000: 3518 TIME TAKEN (alloc) arraysize=100000 iterations=1000: 3649 ----- {noformat} The first pair of results are just startup costs - so this test is repeated and the second run shows the more realistic results. So it shows with array sizes up to 100000, using clear performs better than reallocating each time. > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 04:05:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 04:05:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977607#comment-12977607 ] Gary Brown commented on RTGOV-329: ---------------------------------- (2) "There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess" True, but they are no important pieces of information - so if they slightly inaccurate because of concurrent update, it is no a significant issue - compared to the performance impact of synchronization on every failure report, just in case. > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 04:07:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 04:07:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977607#comment-12977607 ] Gary Brown edited comment on RTGOV-329 at 6/19/14 4:05 AM: ----------------------------------------------------------- (2) "There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess" True, but they are no important pieces of information - so if they are slightly inaccurate because of concurrent update, it is not a significant issue - compared to the performance impact of synchronization on every failure report, on the off chance a concurrent update is happening. was (Author: objectiser): (2) "There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess" True, but they are no important pieces of information - so if they slightly inaccurate because of concurrent update, it is no a significant issue - compared to the performance impact of synchronization on every failure report, just in case. > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 04:09:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 04:09:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977611#comment-12977611 ] Gary Brown commented on RTGOV-329: ---------------------------------- Can you be more specific about (3)? What problem do you see potentially occuring? > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 06:42:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 06:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-457) Situation json now includes 'properties' and 'situationProperties' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-457: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/124 > Situation json now includes 'properties' and 'situationProperties' > ------------------------------------------------------------------ > > Key: RTGOV-457 > URL: https://issues.jboss.org/browse/RTGOV-457 > 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 > > > In the recent move from JPA to Hibernate ORM it was found that queries could not work on properties, as 'properties' is a hibernate keyword - so the situationProperties property was added and the old properties getter/setter deprecated, to maintain programmatic backward compatibility. The db schema is ok as the column name is the same. > Moving forward it is probably better that the json reflects the object properties, so should use 'situationProperties' - so need to mark 'properties' as transient so not converted to json. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 06:42:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 06:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-457) Situation json now includes 'properties' and 'situationProperties' In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-457. ------------------------------ Resolution: Done > Situation json now includes 'properties' and 'situationProperties' > ------------------------------------------------------------------ > > Key: RTGOV-457 > URL: https://issues.jboss.org/browse/RTGOV-457 > 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 > > > In the recent move from JPA to Hibernate ORM it was found that queries could not work on properties, as 'properties' is a hibernate keyword - so the situationProperties property was added and the old properties getter/setter deprecated, to maintain programmatic backward compatibility. The db schema is ok as the column name is the same. > Moving forward it is probably better that the json reflects the object properties, so should use 'situationProperties' - so need to mark 'properties' as transient so not converted to json. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 10:31:26 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 10:31:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-473) Investigate moving .cfg fuse property file info into standard rtgov properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-473: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/125 > Investigate moving .cfg fuse property file info into standard rtgov properties > ------------------------------------------------------------------------------ > > Key: RTGOV-473 > URL: https://issues.jboss.org/browse/RTGOV-473 > 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 avoid additional files to configure, if no benefit, then add the info into the standard property file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 10:33:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 19 Jun 2014 10:33:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-473) Investigate moving .cfg fuse property file info into standard rtgov properties In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-473. ------------------------------ Resolution: Done > Investigate moving .cfg fuse property file info into standard rtgov properties > ------------------------------------------------------------------------------ > > Key: RTGOV-473 > URL: https://issues.jboss.org/browse/RTGOV-473 > 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 avoid additional files to configure, if no benefit, then add the info into the standard property file. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Thu Jun 19 22:46:26 2014 From: issues at jboss.org (Tadayoshi Sato (JIRA)) Date: Thu, 19 Jun 2014 22:46:26 -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 ] Tadayoshi Sato updated 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 > > 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 Thu Jun 19 22:46:27 2014 From: issues at jboss.org (Tadayoshi Sato (JIRA)) Date: Thu, 19 Jun 2014 22:46:27 -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 ] Tadayoshi Sato updated RTGOV-423: --------------------------------- > 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 Fri Jun 20 00:19:25 2014 From: issues at jboss.org (SBS JIRA Integration (JIRA)) Date: Fri, 20 Jun 2014 00:19:25 -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 ] SBS JIRA Integration updated RTGOV-423: --------------------------------------- Forum Reference: https://community.jboss.org/message/874824#874824 > 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 Fri Jun 20 00:19:25 2014 From: issues at jboss.org (SBS JIRA Integration (JIRA)) Date: Fri, 20 Jun 2014 00:19:25 -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 ] SBS JIRA Integration updated SRAMP-394: --------------------------------------- Forum Reference: https://community.jboss.org/message/874824#874824 > 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 > > 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 Jun 20 03:27:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 20 Jun 2014 03:27:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-480) maven artifact upload name in case maven deploy In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-480: ------------------------------------------ Summary: maven artifact upload name in case maven deploy Key: SRAMP-480 URL: https://issues.jboss.org/browse/SRAMP-480 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: Brett Meyer SCENARIO: - cd s-ramp/s-ramp-demos/s-ramp-demos-mvn-integration/s-ramp-demos-mvn-integration-artifacts -mvn clean deploy -Pdemo This artifact is going to be uploaded to s-ramp using the maven command. The version of this artifact is 0.4.1-SNAPSHOT. The name expected to be stored in s-ramp would be exactly the same format as maven is building the artifact name: artifactId-versionId-timestamp-classifier.type You can see the attached screenshot and verify that the SNAPSHOT keyword has been removed from the artifact name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 03:31:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 20 Jun 2014 03:31:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-480) maven artifact upload name in case maven deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-480: --------------------------------------- Attachment: non_snapshot_in_name1.jpeg non_snapshot_in_name.jpeg > maven artifact upload name in case maven deploy > ----------------------------------------------- > > Key: SRAMP-480 > URL: https://issues.jboss.org/browse/SRAMP-480 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Brett Meyer > Attachments: non_snapshot_in_name.jpeg, non_snapshot_in_name1.jpeg > > > SCENARIO: > - cd s-ramp/s-ramp-demos/s-ramp-demos-mvn-integration/s-ramp-demos-mvn-integration-artifacts > -mvn clean deploy -Pdemo > This artifact is going to be uploaded to s-ramp using the maven command. The version of this artifact is 0.4.1-SNAPSHOT. > The name expected to be stored in s-ramp would be exactly the same format as maven is building the artifact name: > artifactId-versionId-timestamp-classifier.type > You can see the attached screenshot and verify that the SNAPSHOT keyword has been removed from the artifact name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 05:42:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 20 Jun 2014 05:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-501) Change maven install to ant In-Reply-To: References: Message-ID: Gary Brown created RTGOV-501: -------------------------------- Summary: Change maven install to ant Key: RTGOV-501 URL: https://issues.jboss.org/browse/RTGOV-501 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 First step towards providing a consistent installer across sub-projects. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 07:18:25 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 20 Jun 2014 07:18:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-471) Maven Facade: Implement maven deploy support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-471: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/445 > Maven Facade: Implement maven deploy support > -------------------------------------------- > > Key: SRAMP-471 > URL: https://issues.jboss.org/browse/SRAMP-471 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > The maven facade currently only supports maven GET related operations (e.g. pulling artifacts out of s-ramp using the standard maven http protocol support). We should enhance the facade to also support the maven PUT/POST http protocol. In other words, support whatever maven does when you do this: > {code} > mvn deploy > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 08:00:33 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 20 Jun 2014 08:00:33 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-480) maven artifact upload name in case maven deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978050#comment-12978050 ] Eric Wittmann commented on SRAMP-480: ------------------------------------- This is how maven works for snapshot versions. When it uploads the file to the repository it replaces the SNAPSHOT keyword with the timestamp. > maven artifact upload name in case maven deploy > ----------------------------------------------- > > Key: SRAMP-480 > URL: https://issues.jboss.org/browse/SRAMP-480 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Brett Meyer > Attachments: non_snapshot_in_name.jpeg, non_snapshot_in_name1.jpeg > > > SCENARIO: > - cd s-ramp/s-ramp-demos/s-ramp-demos-mvn-integration/s-ramp-demos-mvn-integration-artifacts > -mvn clean deploy -Pdemo > This artifact is going to be uploaded to s-ramp using the maven command. The version of this artifact is 0.4.1-SNAPSHOT. > The name expected to be stored in s-ramp would be exactly the same format as maven is building the artifact name: > artifactId-versionId-timestamp-classifier.type > You can see the attached screenshot and verify that the SNAPSHOT keyword has been removed from the artifact name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 08:06:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 20 Jun 2014 08:06:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-480) maven artifact upload name in case maven deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978052#comment-12978052 ] David virgil naranjo commented on SRAMP-480: -------------------------------------------- we can close this issue. I used to find bugs where there are not... I have implemented the maven repository facade having this naming convention in consideration. > maven artifact upload name in case maven deploy > ----------------------------------------------- > > Key: SRAMP-480 > URL: https://issues.jboss.org/browse/SRAMP-480 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Brett Meyer > Attachments: non_snapshot_in_name.jpeg, non_snapshot_in_name1.jpeg > > > SCENARIO: > - cd s-ramp/s-ramp-demos/s-ramp-demos-mvn-integration/s-ramp-demos-mvn-integration-artifacts > -mvn clean deploy -Pdemo > This artifact is going to be uploaded to s-ramp using the maven command. The version of this artifact is 0.4.1-SNAPSHOT. > The name expected to be stored in s-ramp would be exactly the same format as maven is building the artifact name: > artifactId-versionId-timestamp-classifier.type > You can see the attached screenshot and verify that the SNAPSHOT keyword has been removed from the artifact name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 09:24:26 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 20 Jun 2014 09:24:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-480) maven artifact upload name in case maven deploy In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-480. ------------------------------- Resolution: Rejected > maven artifact upload name in case maven deploy > ----------------------------------------------- > > Key: SRAMP-480 > URL: https://issues.jboss.org/browse/SRAMP-480 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Brett Meyer > Attachments: non_snapshot_in_name.jpeg, non_snapshot_in_name1.jpeg > > > SCENARIO: > - cd s-ramp/s-ramp-demos/s-ramp-demos-mvn-integration/s-ramp-demos-mvn-integration-artifacts > -mvn clean deploy -Pdemo > This artifact is going to be uploaded to s-ramp using the maven command. The version of this artifact is 0.4.1-SNAPSHOT. > The name expected to be stored in s-ramp would be exactly the same format as maven is building the artifact name: > artifactId-versionId-timestamp-classifier.type > You can see the attached screenshot and verify that the SNAPSHOT keyword has been removed from the artifact name -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 09:52:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 20 Jun 2014 09:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-501) Change maven install to ant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-501: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/126 > Change maven install to ant > --------------------------- > > Key: RTGOV-501 > URL: https://issues.jboss.org/browse/RTGOV-501 > 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 > > > First step towards providing a consistent installer across sub-projects. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 09:52:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 20 Jun 2014 09:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-501) Change maven install to ant In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-501. ------------------------------ Resolution: Done > Change maven install to ant > --------------------------- > > Key: RTGOV-501 > URL: https://issues.jboss.org/browse/RTGOV-501 > 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 > > > First step towards providing a consistent installer across sub-projects. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 12:55:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 20 Jun 2014 12:55:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-502) ElasticsearchSituationStore query on properties not working In-Reply-To: References: Message-ID: Gary Brown created RTGOV-502: -------------------------------- Summary: ElasticsearchSituationStore query on properties not working Key: RTGOV-502 URL: https://issues.jboss.org/browse/RTGOV-502 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 Change for only supporting properties in JSON (rather than situationProperties) broke 3 of the ElasticsearchSituationStore query tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 13:27:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 20 Jun 2014 13:27:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-502) ElasticsearchSituationStore query on properties not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-502: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/127 > ElasticsearchSituationStore query on properties not working > ----------------------------------------------------------- > > Key: RTGOV-502 > URL: https://issues.jboss.org/browse/RTGOV-502 > 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 > > > Change for only supporting properties in JSON (rather than situationProperties) broke 3 of the ElasticsearchSituationStore query tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 13:27:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 20 Jun 2014 13:27:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-502) ElasticsearchSituationStore query on properties not working In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-502. ------------------------------ Resolution: Done > ElasticsearchSituationStore query on properties not working > ----------------------------------------------------------- > > Key: RTGOV-502 > URL: https://issues.jboss.org/browse/RTGOV-502 > 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 > > > Change for only supporting properties in JSON (rather than situationProperties) broke 3 of the ElasticsearchSituationStore query tests. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 20 13:29:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 20 Jun 2014 13:29:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-503) Filtered situation list caused all situations to be removed when doing bulk delete In-Reply-To: References: Message-ID: Gary Brown created RTGOV-503: -------------------------------- Summary: Filtered situation list caused all situations to be removed when doing bulk delete Key: RTGOV-503 URL: https://issues.jboss.org/browse/RTGOV-503 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 Need to reproduce, but when using the situation list with multiple SLA violations and single Exception, filtered based on the Exception type and then tried doing a bulk delete - it should have just deleted the single situation, but deleted 5. The confirmation message should show the number of situations that will be deleted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jun 21 17:43:24 2014 From: issues at jboss.org (ivan mckinley (JIRA)) Date: Sat, 21 Jun 2014 17:43: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 ] Work on RTGOV-462 started by ivan mckinley. > 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 Mon Jun 23 03:45:26 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Mon, 23 Jun 2014 03:45:26 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978453#comment-12978453 ] Jiri Pechanec commented on RTGOV-329: ------------------------------------- In case of 3) - I am not sure it is wise to mix two completely independent ways of synchronization - one handled by Java EE server and the second manual just via synchronized keyword. I would not be surprised if such a situation would lead to a rare but still possible deadlock hidden inside. > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 03:51:24 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Mon, 23 Jun 2014 03:51:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Pechanec reopened RTGOV-328: --------------------------------- The reason is pretty simple - I believe that activity collection should have as least impact as possible on the client system. If we delegate the async processing on the server then it is fire-and-forget on the side on client with a minimum performance impact. If we keep it on client then some of the CPU cycles of the monitored system will be spent on activity processing. > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 04:09:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 04:09:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-328) Activity Server should support async processing of submitted events In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978460#comment-12978460 ] Gary Brown commented on RTGOV-328: ---------------------------------- Currently the invocation on the server is performed within a txn, if there is a failure there is the potential to fail over and handle the activities on a different server. Using the approach you suggest, it would cause any queued activities awaiting processing to be lost, and no way to know what has been lost. In environments that don't care about lost activities, then possibly an option could be provided. > Activity Server should support async processing of submitted events > ------------------------------------------------------------------- > > Key: RTGOV-328 > URL: https://issues.jboss.org/browse/RTGOV-328 > Project: RTGov (Run Time Governance) > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Activity Server > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > > Activity Collector does not care about return value from activity server invocation. Thus the api should provide a method that will allow submit activities in one-way fashion. The REST invocation will return immediately and the activities will be stored in storage asynchronously in another thread. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 04:49:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 04:49:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978468#comment-12978468 ] Gary Brown commented on RTGOV-329: ---------------------------------- Not sure what JEE synchronization is in play here? > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 06:29:25 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Mon, 23 Jun 2014 06:29:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978495#comment-12978495 ] Jiri Pechanec commented on RTGOV-329: ------------------------------------- The @Singleton bean in question uses container managed concurrency >From the EJB spec - By default, the value of the lock associated with a method of a bean with container managed concurrency is a write lock (exclusive lock). When synchronization primitives are used the @Singleton bean should use bean managed concurrency using @ConcurrencyManagement(ConcurrencyManagementType.BEAN) See 4.8.5.2 and 4.8.5.4 in EJB spec > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 07:01:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 07:01:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978502#comment-12978502 ] Gary Brown commented on RTGOV-329: ---------------------------------- But the ActivityServerLogger is not an EJB. > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 07:07:24 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Mon, 23 Jun 2014 07:07:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978505#comment-12978505 ] Jiri Pechanec commented on RTGOV-329: ------------------------------------- I am sorry, I did not check imports and immediately projected @Singleton as being javax.ejb.Singleton not javax.inject.Singleton. Then all my comments are of course invalid > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 07:07:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 07:07:24 -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: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Use Declarative Services instead of Blueprint > --------------------------------------------- > > Key: RTGOV-383 > URL: https://issues.jboss.org/browse/RTGOV-383 > Project: RTGov (Run Time Governance) > Issue Type: Sub-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 Mon Jun 23 07:29:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 07:29:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978510#comment-12978510 ] Gary Brown commented on RTGOV-329: ---------------------------------- No problem - can this issue be closed? > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 07:36:24 2014 From: issues at jboss.org (Jiri Pechanec (JIRA)) Date: Mon, 23 Jun 2014 07:36:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Pechanec closed RTGOV-329. ------------------------------- Resolution: Done > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 10:10:25 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 23 Jun 2014 10:10:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-329) Consider refactoring/cleanup of ActivtyServerLogger In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978617#comment-12978617 ] RH Bugzilla Integration commented on RTGOV-329: ----------------------------------------------- Gary Brown changed the Status of [bug 1056449|https://bugzilla.redhat.com/show_bug.cgi?id=1056449] from NEW to CLOSED > Consider refactoring/cleanup of ActivtyServerLogger > --------------------------------------------------- > > Key: RTGOV-329 > URL: https://issues.jboss.org/browse/RTGOV-329 > Project: RTGov (Run Time Governance) > Issue Type: Quality Risk > Security Level: Public(Everyone can see) > Components: Activity Collector > Affects Versions: 1.0.0.Final > Reporter: Jiri Pechanec > Assignee: Gary Brown > Fix For: 2.1.0.Final > > Attachments: Performance.java > > > 1) I consider the code to be overcomplicated - are we really getting any performance boost with reusing the ArrayList of events? I found on the web that clear() might be even slower than new allocation > 2) There is unsynced access to fields _sequenceNumber and _failuresSinceLastSuccess > 3) I am not sure if it is wise to mix synchronization on Java level - _timer in BatchedActivityUnitLogger - and Java EE level - method synchornization on @Singleton -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:13:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 11:13:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-484) Re-introduce REST services in Karaf when SSO sorted out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-484: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/128 > Re-introduce REST services in Karaf when SSO sorted out > ------------------------------------------------------- > > Key: RTGOV-484 > URL: https://issues.jboss.org/browse/RTGOV-484 > 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: 2 days > Remaining Estimate: 2 days > > Currently the war with the REST services has been removed from the karaf features until SSO is configured in RTGov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:13:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 11:13:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-484) Re-introduce REST services in Karaf when SSO sorted out In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-484. ------------------------------ Resolution: Done > Re-introduce REST services in Karaf when SSO sorted out > ------------------------------------------------------- > > Key: RTGOV-484 > URL: https://issues.jboss.org/browse/RTGOV-484 > 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: 2 days > Remaining Estimate: 2 days > > Currently the war with the REST services has been removed from the karaf features until SSO is configured in RTGov. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:37:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 23 Jun 2014 11:37:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-481: ------------------------------------------ Summary: Maven View in S-ramp UI Artifact List Key: SRAMP-481 URL: https://issues.jboss.org/browse/SRAMP-481 Project: S-RAMP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: Eric Wittmann Attachments: s-ramp-artifacts.jpeg The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. If maven view is selected then there would be displayed the artifacts as a maven tree. It would improve the usability, and will be more user friendly. Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:37:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Mon, 23 Jun 2014 11:37:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-481: --------------------------------------- Attachment: s-ramp-artifacts.jpeg > Maven View in S-ramp UI Artifact List > ------------------------------------- > > Key: SRAMP-481 > URL: https://issues.jboss.org/browse/SRAMP-481 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Attachments: s-ramp-artifacts.jpeg > > > The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. > This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. > What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. > If maven view is selected then there would be displayed the artifacts as a maven tree. > It would improve the usability, and will be more user friendly. > Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:43:35 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 11:43:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-481: -------------------------------- Component/s: UI > Maven View in S-ramp UI Artifact List > ------------------------------------- > > Key: SRAMP-481 > URL: https://issues.jboss.org/browse/SRAMP-481 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: UI > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Attachments: s-ramp-artifacts.jpeg > > > The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. > This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. > What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. > If maven view is selected then there would be displayed the artifacts as a maven tree. > It would improve the usability, and will be more user friendly. > Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:43:35 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 11:43:35 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-481: -------------------------------- Fix Version/s: 0.6.0 > Maven View in S-ramp UI Artifact List > ------------------------------------- > > Key: SRAMP-481 > URL: https://issues.jboss.org/browse/SRAMP-481 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: UI > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.6.0 > > Attachments: s-ramp-artifacts.jpeg > > > The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. > This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. > What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. > If maven view is selected then there would be displayed the artifacts as a maven tree. > It would improve the usability, and will be more user friendly. > Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:47:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 11:47:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978664#comment-12978664 ] Gary Brown commented on SRAMP-481: ---------------------------------- Sounds like a reasonable suggestion, although rather than 'maven view' for the tree, I think it should be more general. When I deriver extracts artifacts from an uploaded artifact, this may also create many 'artifacts' with the same name. So I think it would be good to understand what is the main artifacts, and list them at the top level of the 'tree', and any derived artifacts are scoped to the main artifact? So this would apply regardless of whether the artifact was uploaded via maven or direct. > Maven View in S-ramp UI Artifact List > ------------------------------------- > > Key: SRAMP-481 > URL: https://issues.jboss.org/browse/SRAMP-481 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: UI > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.6.0 > > Attachments: s-ramp-artifacts.jpeg > > > The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. > This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. > What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. > If maven view is selected then there would be displayed the artifacts as a maven tree. > It would improve the usability, and will be more user friendly. > Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:55:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 11:55:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-504) Remove 'Processing State' from RTGov UI Service List In-Reply-To: References: Message-ID: Gary Brown created RTGOV-504: -------------------------------- Summary: 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: Gary Brown Fix For: 2.0.0.Final -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:57:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 11:57:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978669#comment-12978669 ] Eric Wittmann commented on SRAMP-481: ------------------------------------- I think the current UI is intended to be very generic, and certainly doesn't know about maven. I do understand and agree that the UI can be confusing when there are a lot of artifacts with the same name. I do not think the s-ramp UI will be (or should be) the primary interface for any particular use-case. This is why dtgov has specific UI pages to solve specific governance use cases. I think instead of implementing a custom UI to view the contents of the s-ramp repository as a Maven Repository, we should instead ensure that any existing maven repository browsing utilities work with the s-ramp maven repo facade. > Maven View in S-ramp UI Artifact List > ------------------------------------- > > Key: SRAMP-481 > URL: https://issues.jboss.org/browse/SRAMP-481 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: UI > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.6.0 > > Attachments: s-ramp-artifacts.jpeg > > > The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. > This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. > What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. > If maven view is selected then there would be displayed the artifacts as a maven tree. > It would improve the usability, and will be more user friendly. > Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 11:57:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 11:57: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: Gary Brown created RTGOV-505: -------------------------------- Summary: 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: Gary Brown 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 Mon Jun 23 12:00:29 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 12:00:29 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-481) Maven View in S-ramp UI Artifact List In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978671#comment-12978671 ] Eric Wittmann commented on SRAMP-481: ------------------------------------- On a different note - I'm not convinced that we should be storing the maven-metadata.xml file(s) in s-ramp. Instead I think perhaps we should be generating those files upon request (GET) and ignore the upload of those files (PUT). > Maven View in S-ramp UI Artifact List > ------------------------------------- > > Key: SRAMP-481 > URL: https://issues.jboss.org/browse/SRAMP-481 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: UI > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.6.0 > > Attachments: s-ramp-artifacts.jpeg > > > The s-ramp artifacts view display all the artifacts by name. But it can be not intuitive when there are many artifacts with the same name. > This is the case of the maven-metadata.xml that is uploaded every time a maven artifact is deployed. > What it is proposed is to create in the upper part of the artifact's list, two checkboxes, normal view (default) and maven view. > If maven view is selected then there would be displayed the artifacts as a maven tree. > It would improve the usability, and will be more user friendly. > Take a look to the current implementation (attached file) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 12:00:29 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 23 Jun 2014 12:00: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: Gary Brown created RTGOV-506: -------------------------------- Summary: 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: Gary Brown 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 Mon Jun 23 12:54:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 12:54:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-477) Restructure S-RAMP server projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-477 started by Eric Wittmann. > Restructure S-RAMP server projects > ---------------------------------- > > Key: SRAMP-477 > URL: https://issues.jboss.org/browse/SRAMP-477 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp-server projects to be all together in a parent project call s-ramp-server. > The projects to be moved to this parent project are: > s-ramp-server-eap6 > s-ramp-server-fuse61 > s-ramp-server-jetty8 > s-ramp-server-tomcat7 > s-ramp-server -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 14:42:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 14:42:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-477) Restructure S-RAMP server projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-477: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/446 > Restructure S-RAMP server projects > ---------------------------------- > > Key: SRAMP-477 > URL: https://issues.jboss.org/browse/SRAMP-477 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp-server projects to be all together in a parent project call s-ramp-server. > The projects to be moved to this parent project are: > s-ramp-server-eap6 > s-ramp-server-fuse61 > s-ramp-server-jetty8 > s-ramp-server-tomcat7 > s-ramp-server -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 14:42:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 14:42:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-477) Restructure S-RAMP server projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-477. --------------------------------- Resolution: Done I also restructured distro, ui, and integration for consistency. > Restructure S-RAMP server projects > ---------------------------------- > > Key: SRAMP-477 > URL: https://issues.jboss.org/browse/SRAMP-477 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp-server projects to be all together in a parent project call s-ramp-server. > The projects to be moved to this parent project are: > s-ramp-server-eap6 > s-ramp-server-fuse61 > s-ramp-server-jetty8 > s-ramp-server-tomcat7 > s-ramp-server -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 14:42:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 14:42:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-477) Restructure S-RAMP server projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-477. ------------------------------- > Restructure S-RAMP server projects > ---------------------------------- > > Key: SRAMP-477 > URL: https://issues.jboss.org/browse/SRAMP-477 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp-server projects to be all together in a parent project call s-ramp-server. > The projects to be moved to this parent project are: > s-ramp-server-eap6 > s-ramp-server-fuse61 > s-ramp-server-jetty8 > s-ramp-server-tomcat7 > s-ramp-server -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 14:42:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 14:42:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-478) Restructure S-RAMP integration projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann updated SRAMP-478: -------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/446 > Restructure S-RAMP integration projects > --------------------------------------- > > Key: SRAMP-478 > URL: https://issues.jboss.org/browse/SRAMP-478 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp integration projects to be all together in a parent project call s-ramp-integration. > The projects to be moved to this parent project are: > s-ramp-integration-java > s-ramp-integration-kie > s-ramp-integration-switchyard > s-ramp-integration-teiid -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 14:44:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 14:44:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-478) Restructure S-RAMP integration projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-478. --------------------------------- Resolution: Done > Restructure S-RAMP integration projects > --------------------------------------- > > Key: SRAMP-478 > URL: https://issues.jboss.org/browse/SRAMP-478 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp integration projects to be all together in a parent project call s-ramp-integration. > The projects to be moved to this parent project are: > s-ramp-integration-java > s-ramp-integration-kie > s-ramp-integration-switchyard > s-ramp-integration-teiid -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 14:44:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 14:44:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-478) Restructure S-RAMP integration projects In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-478. ------------------------------- > Restructure S-RAMP integration projects > --------------------------------------- > > Key: SRAMP-478 > URL: https://issues.jboss.org/browse/SRAMP-478 > Project: S-RAMP > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: Eric Wittmann > Fix For: 0.5.0.Final > > > Restructure the s-ramp integration projects to be all together in a parent project call s-ramp-integration. > The projects to be moved to this parent project are: > s-ramp-integration-java > s-ramp-integration-kie > s-ramp-integration-switchyard > s-ramp-integration-teiid -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 23 14:44:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 14:44:25 -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 ] Work on SRAMP-436 started by Eric Wittmann. > 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.Final > > 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 Mon Jun 23 15:33:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Mon, 23 Jun 2014 15:33:24 -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:comment-tabpanel&focusedCommentId=12978722#comment-12978722 ] Eric Wittmann commented on SRAMP-436: ------------------------------------- It appears that the keystore config is stored in picketlink.xml, which is located in the IDP WAR and the SP WAR. Fortunately there is a picketlink keystorekeymanager interface which I can implement to allow external configuration. In other words, I don't want users to have to crack open WAR files and modify picketlink.xml just to change the SAML signature config. > 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.Final > > 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 Jun 24 05:07:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 24 Jun 2014 05:07:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-454) Unify ElasticSearch sever configuration across proxy REST service and keyvalue store In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-454. ------------------------------ Fix Version/s: (was: 2.0.0.Final) Resolution: Rejected The two properties represent different access points to the server. Its possible knowledge of the different servers could be shared, but that would imply they used the same ports on each server. > Unify ElasticSearch sever configuration across proxy REST service and keyvalue store > ------------------------------------------------------------------------------------ > > Key: RTGOV-454 > URL: https://issues.jboss.org/browse/RTGOV-454 > Project: RTGov (Run Time Governance) > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Currently the Elasticsearch.hosts property is a list of : values, while the REST service uses a single URL property. > See if ES client can take a URL rather than just host:port - and if so, have a single property that takes a list of URLs. > If possible, then need to see if REST service can use a list of URLs (failover). -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 24 05:09:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 24 Jun 2014 05:09:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-476) java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-476. ------------------------------ Resolution: Partially Completed Closing this issue, as the actual issue is in the fuse platform. A fix should be available shortly. > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator@ > ----------------------------------------------------------------------------------------------------------------- > > Key: RTGOV-476 > URL: https://issues.jboss.org/browse/RTGOV-476 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: David virgil naranjo > Fix For: 2.0.0.Final > > > When RTGov all configuration is deployed in a fabric child container we get the following exception: > java.lang.IllegalStateException: No LoginService for org.eclipse.jetty.security.authentication.FormAuthenticator at 3afffabb in org.eclipse.jetty.security.ConstraintSecurityHandler at 7ba6293f > at org.eclipse.jetty.security.authentication.LoginAuthenticator.setConfiguration(LoginAuthenticator.java:61) -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 24 05:17:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 24 Jun 2014 05:17:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-503) Filtered situation list caused all situations to be removed when doing bulk delete In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-503. ------------------------------ Fix Version/s: (was: 2.0.0.Final) Resolution: Rejected Cannot reproduce. > Filtered situation list caused all situations to be removed when doing bulk delete > ---------------------------------------------------------------------------------- > > Key: RTGOV-503 > URL: https://issues.jboss.org/browse/RTGOV-503 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > > Need to reproduce, but when using the situation list with multiple SLA violations and single Exception, filtered based on the Exception type and then tried doing a bulk delete - it should have just deleted the single situation, but deleted 5. > The confirmation message should show the number of situations that will be deleted. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 24 05:29:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 24 Jun 2014 05:29:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-491) Performance tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978837#comment-12978837 ] Gary Brown commented on RTGOV-491: ---------------------------------- Moved to more appropriate location under /tests but still not included in the build. > Performance tests > ----------------- > > Key: RTGOV-491 > URL: https://issues.jboss.org/browse/RTGOV-491 > 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 old performance tests reside in release folder, which has almost completely been removed due to restructure in RTGOV-490. > Need to decide whether still required/useful, and if so relocate. If no required, then should be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 24 05:31:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 24 Jun 2014 05:31:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-491) Performance tests In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-491: ----------------------------- Fix Version/s: 2.1.0.Final (was: 2.0.0.Final) > Performance tests > ----------------- > > Key: RTGOV-491 > URL: https://issues.jboss.org/browse/RTGOV-491 > 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 > > > Currently old performance tests reside in release folder, which has almost completely been removed due to restructure in RTGOV-490. > Need to decide whether still required/useful, and if so relocate. If no required, then should be removed. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Tue Jun 24 07:25:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Tue, 24 Jun 2014 07:25:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-507) Deprecate activity server/store query method as dependent upon store impl In-Reply-To: References: Message-ID: Gary Brown created RTGOV-507: -------------------------------- Summary: Deprecate activity server/store query method as dependent upon store impl Key: RTGOV-507 URL: https://issues.jboss.org/browse/RTGOV-507 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 query method provides a QuerySpec instance that defined an expression and format - which exposes the store implementation. Deprecate the query methods on the REST service, ActivityServer API and ActivityStore API, as well as the QuerySpec class. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 02:22:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 25 Jun 2014 02:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-482) Errors maven repository facade In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-482: ------------------------------------------ Summary: Errors maven repository facade Key: SRAMP-482 URL: https://issues.jboss.org/browse/SRAMP-482 Project: S-RAMP Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David virgil naranjo Assignee: David virgil naranjo ome issues I found in no particular order: 1) the *.pom file is added with an artifact type of "Document" - it should be "MavenPom" 2) when uploading maven-metadata.xml the GAV properties are incorrect for the one in the parent folder (at least). For example, here is the s-ramp meta-data for maven-metadata.xml in the artifactId folder: maven.groupId: org.overlord maven.hash.sha1: 0e48bd3e6279b419c8d111763bfa88143fff9aff maven.artifactId: sramp maven.type: xml maven.hash.md5: 241a18e0cceb8dfc0ca01640dffc5db5 maven.version: maven-facade-test-api These properties are incorrect (artifactId, groupId, and version are all wrong). 3) I don't see an option to disable/enable SNAPSHOT support in the facade. I think we need this option for this release and I think it should default to "disabled". In other words, let's turn off SNAPSHOT support by default. It should be controlled via a property in sramp.properties. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 02:22:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 25 Jun 2014 02:22:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-482) Errors maven repository facade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-482: --------------------------------------- Description: 1) the *.pom file is added with an artifact type of "Document" - it should be "MavenPom" 2) when uploading maven-metadata.xml the GAV properties are incorrect for the one in the parent folder (at least). For example, here is the s-ramp meta-data for maven-metadata.xml in the artifactId folder: maven.groupId: org.overlord maven.hash.sha1: 0e48bd3e6279b419c8d111763bfa88143fff9aff maven.artifactId: sramp maven.type: xml maven.hash.md5: 241a18e0cceb8dfc0ca01640dffc5db5 maven.version: maven-facade-test-api These properties are incorrect (artifactId, groupId, and version are all wrong). 3) I don't see an option to disable/enable SNAPSHOT support in the facade. I think we need this option for this release and I think it should default to "disabled". In other words, let's turn off SNAPSHOT support by default. It should be controlled via a property in sramp.properties. was: ome issues I found in no particular order: 1) the *.pom file is added with an artifact type of "Document" - it should be "MavenPom" 2) when uploading maven-metadata.xml the GAV properties are incorrect for the one in the parent folder (at least). For example, here is the s-ramp meta-data for maven-metadata.xml in the artifactId folder: maven.groupId: org.overlord maven.hash.sha1: 0e48bd3e6279b419c8d111763bfa88143fff9aff maven.artifactId: sramp maven.type: xml maven.hash.md5: 241a18e0cceb8dfc0ca01640dffc5db5 maven.version: maven-facade-test-api These properties are incorrect (artifactId, groupId, and version are all wrong). 3) I don't see an option to disable/enable SNAPSHOT support in the facade. I think we need this option for this release and I think it should default to "disabled". In other words, let's turn off SNAPSHOT support by default. It should be controlled via a property in sramp.properties. > Errors maven repository facade > ------------------------------ > > Key: SRAMP-482 > URL: https://issues.jboss.org/browse/SRAMP-482 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > 1) the *.pom file is added with an artifact type of "Document" - it > should be "MavenPom" > 2) when uploading maven-metadata.xml the GAV properties are incorrect > for the one in the parent folder (at least). For example, here is the > s-ramp meta-data for maven-metadata.xml in the artifactId folder: > maven.groupId: org.overlord > maven.hash.sha1: 0e48bd3e6279b419c8d111763bfa88143fff9aff > maven.artifactId: sramp > maven.type: xml > maven.hash.md5: 241a18e0cceb8dfc0ca01640dffc5db5 > maven.version: maven-facade-test-api > These properties are incorrect (artifactId, groupId, and version are all > wrong). > 3) I don't see an option to disable/enable SNAPSHOT support in the > facade. I think we need this option for this release and I think it > should default to "disabled". In other words, let's turn off SNAPSHOT > support by default. It should be controlled via a property in > sramp.properties. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 02:30:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 25 Jun 2014 02:30:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-482) Errors maven repository facade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo closed SRAMP-482. -------------------------------------- Resolution: Rejected > Errors maven repository facade > ------------------------------ > > Key: SRAMP-482 > URL: https://issues.jboss.org/browse/SRAMP-482 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > 1) the *.pom file is added with an artifact type of "Document" - it > should be "MavenPom" > 2) when uploading maven-metadata.xml the GAV properties are incorrect > for the one in the parent folder (at least). For example, here is the > s-ramp meta-data for maven-metadata.xml in the artifactId folder: > maven.groupId: org.overlord > maven.hash.sha1: 0e48bd3e6279b419c8d111763bfa88143fff9aff > maven.artifactId: sramp > maven.type: xml > maven.hash.md5: 241a18e0cceb8dfc0ca01640dffc5db5 > maven.version: maven-facade-test-api > These properties are incorrect (artifactId, groupId, and version are all > wrong). > 3) I don't see an option to disable/enable SNAPSHOT support in the > facade. I think we need this option for this release and I think it > should default to "disabled". In other words, let's turn off SNAPSHOT > support by default. It should be controlled via a property in > sramp.properties. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 03:21:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Wed, 25 Jun 2014 03:21:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-482) Errors maven repository facade In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979133#comment-12979133 ] David virgil naranjo commented on SRAMP-482: -------------------------------------------- closed, because this work is related to an open issue not merged yet: https://issues.jboss.org/browse/SRAMP-471 > Errors maven repository facade > ------------------------------ > > Key: SRAMP-482 > URL: https://issues.jboss.org/browse/SRAMP-482 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > > 1) the *.pom file is added with an artifact type of "Document" - it > should be "MavenPom" > 2) when uploading maven-metadata.xml the GAV properties are incorrect > for the one in the parent folder (at least). For example, here is the > s-ramp meta-data for maven-metadata.xml in the artifactId folder: > maven.groupId: org.overlord > maven.hash.sha1: 0e48bd3e6279b419c8d111763bfa88143fff9aff > maven.artifactId: sramp > maven.type: xml > maven.hash.md5: 241a18e0cceb8dfc0ca01640dffc5db5 > maven.version: maven-facade-test-api > These properties are incorrect (artifactId, groupId, and version are all > wrong). > 3) I don't see an option to disable/enable SNAPSHOT support in the > facade. I think we need this option for this release and I think it > should default to "disabled". In other words, let's turn off SNAPSHOT > support by default. It should be controlled via a property in > sramp.properties. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 06:36:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 25 Jun 2014 06:36:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-508) Test RTGov REST services with typed args/return values In-Reply-To: References: Message-ID: Gary Brown created RTGOV-508: -------------------------------- Summary: Test RTGov REST services with typed args/return values Key: RTGOV-508 URL: https://issues.jboss.org/browse/RTGOV-508 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 When initially porting RTGov onto Karaf (RTGOV-373) we used the built in JAX-RS support provided by CXF. However the version of Karaf we needed to use, to support Fuse 6.1, had some issues with the typed signature. The solution was to untyped the methods and just pass strings, and handle json marshalling in the REST service. Now that REST API docs are being generated, this causes the problem that it does not document the true types being used. We are now using RESTEasy to provide the JAX-RS services, so we need to retest with typed signatures in Karaf/Fuse, to see whether they now work. This will allow better API documentation to be automatically produced. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 07:27:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 25 Jun 2014 07:27:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-239) Documentation insufficient In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-239: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/131 > Documentation insufficient > -------------------------- > > Key: RTGOV-239 > URL: https://issues.jboss.org/browse/RTGOV-239 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Documentation > Environment: N/A > Reporter: Cojan van Ballegooijen > Assignee: Gary Brown > Priority: Minor > Fix For: 2.0.0.Final > > > Documentation insufficient: for example the REST interface > documentation is incomplete; for example paragraph 3.2.2 in the user > guide; which formats are supported, which expressions are supported, > what is the expression format, which objects can be used and how, etc? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 07:29:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 25 Jun 2014 07:29:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-239) Documentation insufficient In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-239. ------------------------------ Resolution: Done Added auto generation of REST API documentation which is now included in the distribution along with javadocs. Currently (see RTGV-508) the REST APIs don't provide as much typed info as would like, but hopefully that can be fixed shortly. The query method is being deprecated as it exposes too much of the internal implementation being used for the activity store. > Documentation insufficient > -------------------------- > > Key: RTGOV-239 > URL: https://issues.jboss.org/browse/RTGOV-239 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Documentation > Environment: N/A > Reporter: Cojan van Ballegooijen > Assignee: Gary Brown > Priority: Minor > Fix For: 2.0.0.Final > > > Documentation insufficient: for example the REST interface > documentation is incomplete; for example paragraph 3.2.2 in the user > guide; which formats are supported, which expressions are supported, > what is the expression format, which objects can be used and how, etc? -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 08:37:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 25 Jun 2014 08:37:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-471) Maven Facade: Implement maven deploy support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann resolved SRAMP-471. --------------------------------- Resolution: Done > Maven Facade: Implement maven deploy support > -------------------------------------------- > > Key: SRAMP-471 > URL: https://issues.jboss.org/browse/SRAMP-471 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > The maven facade currently only supports maven GET related operations (e.g. pulling artifacts out of s-ramp using the standard maven http protocol support). We should enhance the facade to also support the maven PUT/POST http protocol. In other words, support whatever maven does when you do this: > {code} > mvn deploy > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 08:37:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 25 Jun 2014 08:37:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-471) Maven Facade: Implement maven deploy support In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Wittmann closed SRAMP-471. ------------------------------- > Maven Facade: Implement maven deploy support > -------------------------------------------- > > Key: SRAMP-471 > URL: https://issues.jboss.org/browse/SRAMP-471 > Project: S-RAMP > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: S-RAMP API > Reporter: Eric Wittmann > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > > The maven facade currently only supports maven GET related operations (e.g. pulling artifacts out of s-ramp using the standard maven http protocol support). We should enhance the facade to also support the maven PUT/POST http protocol. In other words, support whatever maven does when you do this: > {code} > mvn deploy > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 09:21:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 25 Jun 2014 09:21:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-507) Deprecate activity server/store query method as dependent upon store impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-507: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/132 > Deprecate activity server/store query method as dependent upon store impl > ------------------------------------------------------------------------- > > Key: RTGOV-507 > URL: https://issues.jboss.org/browse/RTGOV-507 > 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 query method provides a QuerySpec instance that defined an expression and format - which exposes the store implementation. > Deprecate the query methods on the REST service, ActivityServer API and ActivityStore API, as well as the QuerySpec class. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 09:21:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Wed, 25 Jun 2014 09:21:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-507) Deprecate activity server/store query method as dependent upon store impl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-507. ------------------------------ Resolution: Done > Deprecate activity server/store query method as dependent upon store impl > ------------------------------------------------------------------------- > > Key: RTGOV-507 > URL: https://issues.jboss.org/browse/RTGOV-507 > 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 query method provides a QuerySpec instance that defined an expression and format - which exposes the store implementation. > Deprecate the query methods on the REST service, ActivityServer API and ActivityStore API, as well as the QuerySpec class. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Wed Jun 25 11:55:25 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Wed, 25 Jun 2014 11:55:25 -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:comment-tabpanel&focusedCommentId=12979321#comment-12979321 ] Eric Wittmann commented on SRAMP-436: ------------------------------------- Note that the SPFilter currently being used has a xmlsec bug that will need to be addressed before it will successfully validate the signature. > 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.Final > > 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 Thu Jun 26 06:04:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Thu, 26 Jun 2014 06:04:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-508) Test RTGov REST services with typed args/return values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979613#comment-12979613 ] Gary Brown commented on RTGOV-508: ---------------------------------- Need to also add enunciate annotations to the JSON serializable classes for it to document them. > Test RTGov REST services with typed args/return values > ------------------------------------------------------ > > Key: RTGOV-508 > URL: https://issues.jboss.org/browse/RTGOV-508 > 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 > > > When initially porting RTGov onto Karaf (RTGOV-373) we used the built in JAX-RS support provided by CXF. However the version of Karaf we needed to use, to support Fuse 6.1, had some issues with the typed signature. > The solution was to untyped the methods and just pass strings, and handle json marshalling in the REST service. > Now that REST API docs are being generated, this causes the problem that it does not document the true types being used. > We are now using RESTEasy to provide the JAX-RS services, so we need to retest with typed signatures in Karaf/Fuse, to see whether they now work. This will allow better API documentation to be automatically produced. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 02:52:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 27 Jun 2014 02:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-483) Maven Repository Servlet breaks dtgov in fuse In-Reply-To: References: Message-ID: David virgil naranjo created SRAMP-483: ------------------------------------------ Summary: Maven Repository Servlet breaks dtgov in fuse Key: SRAMP-483 URL: https://issues.jboss.org/browse/SRAMP-483 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 Fri Jun 27 03:52:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 03:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: Gary Brown created RTGOV-509: -------------------------------- Summary: Large number of activities with the same ID in call trace gadget will not be displayed Key: RTGOV-509 URL: https://issues.jboss.org/browse/RTGOV-509 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Gary Brown Large call traces can cause exceptions. Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 03:52:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 03:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-509: ----------------------------- Fix Version/s: 2.0.0.Final > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 03:52:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 27 Jun 2014 03:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-483) Maven Repository Servlet failing in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-483: --------------------------------------- Summary: Maven Repository Servlet failing in fuse (was: Maven Repository Servlet breaks dtgov in fuse) > Maven Repository Servlet failing in fuse > ---------------------------------------- > > Key: SRAMP-483 > URL: https://issues.jboss.org/browse/SRAMP-483 > 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 Fri Jun 27 03:52:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 27 Jun 2014 03:52:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-509) Large number of activities with the same ID in call trace gadget will not be displayed In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] RH Bugzilla Integration updated RTGOV-509: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1053468 > Large number of activities with the same ID in call trace gadget will not be displayed > -------------------------------------------------------------------------------------- > > Key: RTGOV-509 > URL: https://issues.jboss.org/browse/RTGOV-509 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.Final > > > Large call traces can cause exceptions. > Issue is length of time to build the trace, if involving many queries, but also the size of the trace which then becomes impossible to display. > Need to investigate ways to cap the processing (i.e. number of subsequent queries performed to build the trace) and also ways to restrict the size of the displayed result. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 03:56:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 27 Jun 2014 03:56:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-483) Maven Repository Servlet failing in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo updated SRAMP-483: --------------------------------------- Git Pull Request: https://github.com/Governance/s-ramp/pull/447 > Maven Repository Servlet failing in fuse > ---------------------------------------- > > Key: SRAMP-483 > URL: https://issues.jboss.org/browse/SRAMP-483 > 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 Fri Jun 27 03:56:24 2014 From: issues at jboss.org (David virgil naranjo (JIRA)) Date: Fri, 27 Jun 2014 03:56:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-483) Maven Repository Servlet failing in fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David virgil naranjo resolved SRAMP-483. ---------------------------------------- Fix Version/s: 0.5.0.Final Resolution: Done > Maven Repository Servlet failing in fuse > ---------------------------------------- > > Key: SRAMP-483 > URL: https://issues.jboss.org/browse/SRAMP-483 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: David virgil naranjo > Assignee: David virgil naranjo > Fix For: 0.5.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 06:01:33 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 06:01:33 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-510) Situation state transition to Close causes resolutionState and assignedTo properties to be cleared In-Reply-To: References: Message-ID: Gary Brown created RTGOV-510: -------------------------------- Summary: Situation state transition to Close causes resolutionState and assignedTo properties to be cleared Key: RTGOV-510 URL: https://issues.jboss.org/browse/RTGOV-510 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Components: User Interface Reporter: Gary Brown Assignee: Michael Clay Fix For: 2.0.0.Final Currently when transitioning a Situation to the Closed state causes the 'resolutionState' and 'assignedTo' properties to be cleared. This is the same state as when the Situation is first created and therefore creates an ambiguity regarding whether the situation has been dealt with. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 06:35:23 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 06:35:23 -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: Gary Brown created RTGOV-511: -------------------------------- Summary: 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 Fri Jun 27 06:47:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 06:47:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-512) Situation list refresh waits indefinitely after UI not used for a while on fuse In-Reply-To: References: Message-ID: Gary Brown created RTGOV-512: -------------------------------- Summary: Situation list refresh waits indefinitely after UI not used for a while on fuse Key: RTGOV-512 URL: https://issues.jboss.org/browse/RTGOV-512 Project: RTGov (Run Time Governance) Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Gary Brown Assignee: Eric Wittmann Fix For: 2.0.0.Final When testing the RTGov UI on fuse, found that if the UI had been left running for a while, when returning to it and refreshing the Situations list, it didn't return (i.e. the spinning icon continued indefinitely). If the UI was closed and reopened, using the localhost:8181/rtgov-ui URL, it went straight into the dashboard without requesting credentials, and when selecting the 'Situations' link, it showed the list immediately. In the log, found the following exceptions when this occurred: {noformat} 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | javax.servlet.ServletException: java.io.IOException: Closed at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] Caused by: java.io.IOException: Closed at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] ... 28 more 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error java.io.IOException: Closed at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 06:59:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 06:59:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-512) Situation list refresh waits indefinitely after UI not used for a while on fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-512: ----------------------------- Steps to Reproduce: Follow the instructions at https://github.com/Governance/rtgov/wiki/UGInstallation to install RTGov into Fuse, and then install the order mgmt app and the SLA example. Follow the instructions in the SLA example section to send an appropriate message to create some situations. Start the UI at localhost:8181/rtgov-ui and sign in with the username/password of admin/admin. Navigate to the situations page and see the situations in the list. I then waited for 5 mins, and did a refresh, and it didn't respond. > Situation list refresh waits indefinitely after UI not used for a while on fuse > ------------------------------------------------------------------------------- > > Key: RTGOV-512 > URL: https://issues.jboss.org/browse/RTGOV-512 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Eric Wittmann > Fix For: 2.0.0.Final > > > When testing the RTGov UI on fuse, found that if the UI had been left running for a while, when returning to it and refreshing the Situations list, it didn't return (i.e. the spinning icon continued indefinitely). > If the UI was closed and reopened, using the localhost:8181/rtgov-ui URL, it went straight into the dashboard without requesting credentials, and when selecting the 'Situations' link, it showed the list immediately. > In the log, found the following exceptions when this occurred: > {noformat} > 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | > javax.servlet.ServletException: java.io.IOException: Closed > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > Caused by: java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > ... 28 more > 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error > java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 07:49:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 27 Jun 2014 07:49:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-512) Situation list refresh waits indefinitely after UI not used for a while on fuse In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12979906#comment-12979906 ] Eric Wittmann commented on RTGOV-512: ------------------------------------- There are two problems here. The first is the waiting for 5 minutes and the UI timing out. I have no explanation for that. The errai message bus should be active the whole time, and should be keeping the user's session active as a result (I believe). Even if that is not the case, 5 minutes is far too short a time period for the user session to timeout (default is probably something like 30 minutes). The fact that credentials were not required again on a refresh is good - that means the IDP is working properly (the user session on the IDP is set to something like 8 hours). So it's likely that the refresh resulted in the SSO redirect dance. Finally, the stack trace is a known bug in the picketlink SPFilter. It doesn't seem to cause any problems, and it happens often on every platform with the possible exception of EAP. > Situation list refresh waits indefinitely after UI not used for a while on fuse > ------------------------------------------------------------------------------- > > Key: RTGOV-512 > URL: https://issues.jboss.org/browse/RTGOV-512 > Project: RTGov (Run Time Governance) > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Gary Brown > Assignee: Eric Wittmann > Fix For: 2.0.0.Final > > > When testing the RTGov UI on fuse, found that if the UI had been left running for a while, when returning to it and refreshing the Situations list, it didn't return (i.e. the spinning icon continued indefinitely). > If the UI was closed and reopened, using the localhost:8181/rtgov-ui URL, it went straight into the dashboard without requesting credentials, and when selecting the 'Situations' link, it showed the list immediately. > In the log, found the following exceptions when this occurred: > {noformat} > 11:43:19,755 | WARN | tp2121620920-466 | ServletHandler | 92 - org.eclipse.jetty.aggregate.jetty-all-server - 8.1.14.v20131031 | > javax.servlet.ServletException: java.io.IOException: Closed > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:188)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.ui.header.OverlordHeaderResources.doFilter(OverlordHeaderResources.java:76)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:971)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1033)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > Caused by: java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.sendRequestToIDP(SPFilter.java:547)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > at org.picketlink.identity.federation.web.filters.SPFilter.doFilter(SPFilter.java:186)[399:org.overlord.rtgov.ui.overlord-rtgov-ui-war-fuse6:2.0.0.Snapshot] > ... 28 more > 11:43:19,852 | ERROR | tp2121620920-466 | common | 264 - org.jboss.logging.jboss-logging - 3.1.4.GA | Unexpected error > java.io.IOException: Closed > at org.eclipse.jetty.server.AbstractHttpConnection$Output.print(AbstractHttpConnection.java:1134)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:171)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at javax.servlet.ServletOutputStream.println(ServletOutputStream.java:183)[91:org.apache.geronimo.specs.geronimo-servlet_3.0_spec:1.0] > at org.picketlink.identity.federation.web.util.PostBindingUtil.sendPost(PostBindingUtil.java:147)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.util.IDPWebRequestUtil.send(IDPWebRequestUtil.java:232)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.processSAMLRequestMessage(IDPFilter.java:712)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.handleSAMLMessage(IDPFilter.java:262)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.picketlink.identity.federation.web.filters.IDPFilter.doFilter(IDPFilter.java:210)[302:org.picketlink.picketlink-federation:2.5.3.SP1] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.overlord.commons.auth.filters.HttpRequestThreadLocalFilter.doFilter(HttpRequestThreadLocalFilter.java:58)[300:org.overlord.overlord-commons-auth:2.0.2.Final] > at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1467)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:499)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:69)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:522)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1086)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:219)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:428)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1020)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:77)[100:org.ops4j.pax.web.pax-web-jetty:3.0.6] > at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.Server.handle(Server.java:370)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:494)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:982)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1043)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:865)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:667)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)[92:org.eclipse.jetty.aggregate.jetty-all-server:8.1.14.v20131031] > at java.lang.Thread.run(Thread.java:722)[:1.7.0_07] > {noformat} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 09:11:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 27 Jun 2014 09:11:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-484) IOException in SPFilter when authenticating In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-484: ----------------------------------- Summary: 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.Final {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 Fri Jun 27 09:19:24 2014 From: issues at jboss.org (Eric Wittmann (JIRA)) Date: Fri, 27 Jun 2014 09:19:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-485) Remove s-ramp-ui-widgets project In-Reply-To: References: Message-ID: Eric Wittmann created SRAMP-485: ----------------------------------- Summary: 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.Final 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 Fri Jun 27 12:46:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 12:46:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-508) Test RTGov REST services with typed args/return values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown updated RTGOV-508: ----------------------------- Git Pull Request: https://github.com/Governance/rtgov/pull/135 > Test RTGov REST services with typed args/return values > ------------------------------------------------------ > > Key: RTGOV-508 > URL: https://issues.jboss.org/browse/RTGOV-508 > 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 > > > When initially porting RTGov onto Karaf (RTGOV-373) we used the built in JAX-RS support provided by CXF. However the version of Karaf we needed to use, to support Fuse 6.1, had some issues with the typed signature. > The solution was to untyped the methods and just pass strings, and handle json marshalling in the REST service. > Now that REST API docs are being generated, this causes the problem that it does not document the true types being used. > We are now using RESTEasy to provide the JAX-RS services, so we need to retest with typed signatures in Karaf/Fuse, to see whether they now work. This will allow better API documentation to be automatically produced. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Fri Jun 27 12:46:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Fri, 27 Jun 2014 12:46:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (RTGOV-508) Test RTGov REST services with typed args/return values In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/RTGOV-508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Brown resolved RTGOV-508. ------------------------------ Resolution: Done > Test RTGov REST services with typed args/return values > ------------------------------------------------------ > > Key: RTGOV-508 > URL: https://issues.jboss.org/browse/RTGOV-508 > 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 > > > When initially porting RTGov onto Karaf (RTGOV-373) we used the built in JAX-RS support provided by CXF. However the version of Karaf we needed to use, to support Fuse 6.1, had some issues with the typed signature. > The solution was to untyped the methods and just pass strings, and handle json marshalling in the REST service. > Now that REST API docs are being generated, this causes the problem that it does not document the true types being used. > We are now using RESTEasy to provide the JAX-RS services, so we need to retest with typed signatures in Karaf/Fuse, to see whether they now work. This will allow better API documentation to be automatically produced. -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Sat Jun 28 00:13:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Sat, 28 Jun 2014 00:13:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer reassigned SRAMP-453: --------------------------------- Assignee: Brett Meyer (was: David virgil naranjo) > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > {code} > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 30 09:59:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 09:59:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on SRAMP-453 started by Brett Meyer. > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > {code} > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 30 10:13:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 10:13:24 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Meyer resolved SRAMP-453. ------------------------------- Resolution: Done > Exception if using Backspace on CLI password prompt > --------------------------------------------------- > > Key: SRAMP-453 > URL: https://issues.jboss.org/browse/SRAMP-453 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Brett Meyer > Assignee: Brett Meyer > Fix For: 0.5.0 > > > If you mistype a password in the CLI prompt and hit Backspace 1 too many times, boom. > {code} > S-RAMP Password: java.lang.ArrayIndexOutOfBoundsException > at java.lang.System.arraycopy(Native Method) > at java.lang.AbstractStringBuilder.insert(AbstractStringBuilder.java:1152) > at java.lang.StringBuilder.insert(StringBuilder.java:336) > at org.jboss.aesh.console.Buffer.write(Buffer.java:319) > at org.jboss.aesh.console.Console.writeChar(Console.java:837) > at org.jboss.aesh.console.Console.writeChars(Console.java:832) > at org.jboss.aesh.console.Console.parseOperation(Console.java:515) > at org.jboss.aesh.console.Console.read(Console.java:452) > at org.overlord.sramp.shell.InteractiveShellCommandReader.promptForPassword(InteractiveShellCommandReader.java:161) > at org.overlord.sramp.shell.ShellContextImpl.promptForPassword(ShellContextImpl.java:172) > at org.overlord.sramp.shell.commands.core.ConnectCommand.promptForPassword(ConnectCommand.java:107) > at org.overlord.sramp.shell.commands.core.ConnectCommand.execute(ConnectCommand.java:67) > at org.overlord.sramp.shell.SrampShell.run(SrampShell.java:102) > at org.overlord.sramp.shell.SrampShell.main(SrampShell.java:67) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:297) > at java.lang.Thread.run(Thread.java:744) > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264) From issues at jboss.org Mon Jun 30 10:23:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 10:23:24 -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:all-tabpanel ] Brett Meyer updated SRAMP-479: ------------------------------ Fix Version/s: 0.5.0 > 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 > Fix For: 0.5.0 > > > 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 Mon Jun 30 10:50:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 10:50:24 -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=12980672#comment-12980672 ] Brett Meyer commented on SRAMP-479: ----------------------------------- Most likely an ISPN configuration issue and not an S-RAMP bug. Discussing on https://bugzilla.redhat.com/show_bug.cgi?id=1029034 > 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 > Fix For: 0.5.0 > > > 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 Mon Jun 30 10:52:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 10:52: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: Brett Meyer created SRAMP-486: --------------------------------- Summary: 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 Mon Jun 30 10:54:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 30 Jun 2014 10:54: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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-486: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1057022 > 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 Mon Jun 30 11:00:28 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 11:00:28 -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=12980681#comment-12980681 ] Brett Meyer commented on SRAMP-486: ----------------------------------- Keep what we have, but also attempt "java" if $JAVA_HOME isn't set. Fail only if neither work. > 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 Mon Jun 30 11:45:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 11:45:25 -0400 (EDT) Subject: [overlord-issues] [JBoss JIRA] (SRAMP-487) Improved handling of artifact updates In-Reply-To: References: Message-ID: Brett Meyer created SRAMP-487: --------------------------------- Summary: 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 Mon Jun 30 11:45:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 11:45:25 -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 updated SRAMP-487: ------------------------------ Fix Version/s: 0.6.0 > 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 > Fix For: 0.6.0 > > > 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 Mon Jun 30 11:47:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 11:47:24 -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:comment-tabpanel&focusedCommentId=12980718#comment-12980718 ] Brett Meyer commented on SRAMP-487: ----------------------------------- >From [~eric.wittmann]: {quote} Consider: don't allow updates for non-SNAPSHOT artifacts. For SNAPSHOT artifacts add a new one (do not update). So in other words, *never* update the s-ramp artifact. Instead, either fail (non-SNAPSHOT) or create new (SNAPSHOT). The latter should never be done, but can be supported anyway (users probably shouldn't be putting snapshot artifacts in s-ramp). {quote} > 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 > Fix For: 0.6.0 > > > 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 Mon Jun 30 11:47:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 30 Jun 2014 11:47:24 -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 ] RH Bugzilla Integration updated SRAMP-487: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1060773 > 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 > Fix For: 0.6.0 > > > 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 Mon Jun 30 12:05:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:05:24 -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:all-tabpanel ] Brett Meyer closed SRAMP-479. ----------------------------- Resolution: Rejected > 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 > Fix For: 0.5.0 > > > 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 Mon Jun 30 12:07:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:07:24 -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:all-tabpanel ] Brett Meyer reopened SRAMP-479: ------------------------------- > 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 > Fix For: 0.5.0 > > > 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 Mon Jun 30 12:07:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:07:25 -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:all-tabpanel ] Brett Meyer updated SRAMP-479: ------------------------------ Fix Version/s: (was: 0.5.0) > 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 Mon Jun 30 12:07:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:07:25 -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:all-tabpanel ] Brett Meyer closed SRAMP-479. ----------------------------- Resolution: Done > 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 Mon Jun 30 12:07:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:07:25 -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:all-tabpanel ] Brett Meyer reopened SRAMP-479: ------------------------------- > 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 Mon Jun 30 12:07:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:07:25 -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:all-tabpanel ] Brett Meyer closed SRAMP-479. ----------------------------- Resolution: Rejected > 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 Mon Jun 30 12:15:26 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:15: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=12980727#comment-12980727 ] Brett Meyer commented on SRAMP-433: ----------------------------------- We should simultaneously support creating point-to-point queues and pub/sub. I'll still try to do it as an abstract API w/ a JMS impl. > 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 Jun 30 12:17:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:17: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 updated SRAMP-413: ------------------------------ Fix Version/s: 0.6.0 > 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 Mon Jun 30 12:17:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 12:17:25 -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:comment-tabpanel&focusedCommentId=12980729#comment-12980729 ] Brett Meyer commented on SRAMP-413: ----------------------------------- Hold off until 0.6. Things are finally "stable" for 0.5 and this would need tested thoroughly. > 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 Mon Jun 30 15:05:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 15:05: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 ] Work on SRAMP-433 started by Brett Meyer. > 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 Jun 30 15:07:24 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 15:07: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=12980778#comment-12980778 ] Brett Meyer commented on SRAMP-433: ----------------------------------- Really rough design ideas and an initial JMS impl: https://github.com/brmeyer/s-ramp/commit/258b3f2bfda5799b39fd642c9b700ef6a8ee569c EventProducer provides an extendable internal/external API for managing pub/sub and queues. JMSEventProducer is the first impl and demonstrates the concept. Presumably the repository will push the events and the client will be responsible for telling the module when to start and stop the individual queues. Topics and queues will need to be predefined on the platform and discovered through JNDI. I definitely need feedback on the types of events and the format (text, JSON, Serializable, etc.). > 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 Jun 30 15:23:25 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 30 Jun 2014 15:23: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=12980781#comment-12980781 ] Gary Brown commented on SRAMP-433: ---------------------------------- I don't think the client should have any control - it should just be a recipient of events. SRAMP should just be configured with the relevant destinations without caring if there is a recipient - so truly decoupled. So its the choice of the event producer (i.e. jms queue or durable topic) that dictates the quality of service (i.e. guaranteed delivery or fire and forget). I think the format of events may not always be in our control, so we probably shouldn't fix the format - however we would hope that generally it will be xml or json. Would prefer not to deal with serialized java objects, although it would not necessarily be a show stopper. Perhaps for sramp we should just use something simple - e.g. json, and define our own format for use in cases where we do control the publisher. > 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 Jun 30 15:35:25 2014 From: issues at jboss.org (Brett Meyer (JIRA)) Date: Mon, 30 Jun 2014 15:35: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=12980784#comment-12980784 ] Brett Meyer commented on SRAMP-433: ----------------------------------- {quote} I don't think the client should have any control - it should just be a recipient of events. SRAMP should just be configured with the relevant destinations without caring if there is a recipient - so truly decoupled. {quote} For pub/sub, of course. But for the queue(s), should S-RAMP be filling it if no client is popping off the messages? That was my thought process behind the client-driven portion. Of course, JMS message expiration times would take care of that... > 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 Jun 30 15:45:24 2014 From: issues at jboss.org (Gary Brown (JIRA)) Date: Mon, 30 Jun 2014 15:45: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=12980786#comment-12980786 ] Gary Brown commented on SRAMP-433: ---------------------------------- In general I think if a queue has been configured, then they don't want messages lost - even if DTGov was down for some time. However, as you say, the expiration time could be used to ensure the queue does not grow indefinitely. > 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 Jun 30 15:51:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 30 Jun 2014 15:51: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:all-tabpanel ] RH Bugzilla Integration updated SRAMP-395: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1085429, https://bugzilla.redhat.com/show_bug.cgi?id=1114732 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1085429) > 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 Mon Jun 30 15:55:24 2014 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 30 Jun 2014 15:55: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=12980788#comment-12980788 ] 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 NEW 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)