[JBoss JIRA] (SRAMP-453) Exception if using Backspace on CLI password prompt
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-453?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (SRAMP-451) S-ramp maven facade for fuse fabric
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-451?page=com.atlassian.jira.plugin.... ]
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)
10 years
[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 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)
10 years
[JBoss JIRA] (SRAMP-473) S-ramp logout 500 error
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-473?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (SRAMP-450) S-ramp installer && S-ramp-distro add fabric as a new target
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-450?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (SRAMP-389) Performance issue in s-ramp client when using custom properties in query results
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-389?page=com.atlassian.jira.plugin.... ]
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)
10 years
[JBoss JIRA] (SRAMP-202) The not() function doesn't quite work with relationships
by Eric Wittmann (JIRA)
[ https://issues.jboss.org/browse/SRAMP-202?page=com.atlassian.jira.plugin.... ]
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)
10 years