June 2014 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-479) Enable SRAMP (modeshape) to use remote data cache provided by JDG

by Gary Brown (JIRA)

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)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-479) Enable SRAMP (modeshape) to use remote data cache provided by JDG

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-479?page=com.atlassian.jira.plugin.... ] 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)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-248) Maven mutliproject upload should recognize archive type

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SRAMP-248?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on SRAMP-248: ----------------------------------------------- Gary Brown <gbrown(a)redhat.com> 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)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-500) Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId@....'

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-500?page=com.atlassian.jira.plugin.... ] Gary Brown resolved RTGOV-500. ------------------------------ Resolution: Done > Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId@....' > -------------------------------------------------------------------------------------------------- > > 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@......'. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (RTGOV-500) Failed to get message for activity type id 'org.overlord.rtgov.activity.model.ActivityTypeId@....'

by Gary Brown (JIRA)

[ https://issues.jboss.org/browse/RTGOV-500?page=com.atlassian.jira.plugin.... ] 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@....' > -------------------------------------------------------------------------------------------------- > > 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@......'. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-478) Restructure S-RAMP integration projects

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-478?page=com.atlassian.jira.plugin.... ] 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)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-477) Restructure S-RAMP server projects

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-477?page=com.atlassian.jira.plugin.... ] 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)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-445) SSO not working on Tomcat

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-445?page=com.atlassian.jira.plugin.... ] 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)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-476) Lazy-load of JCR repository incompatible with maven repo facade auth

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-476?page=com.atlassian.jira.plugin.... ] 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)

10 years

1
0
0 / 0

[JBoss JIRA] (SRAMP-476) Lazy-load of JCR repository incompatible with maven repo facade auth

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-476?page=com.atlassian.jira.plugin.... ] 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)

10 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues June 2014