October 2013 - overlord-issues - Jboss List Archives

[JBoss JIRA] (SRAMP-240) Modify installer to install into an existing JBoss EAP

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMP-240: ----------------------------------- Summary: Modify installer to install into an existing JBoss EAP Key: SRAMP-240 URL: https://issues.jboss.org/browse/SRAMP-240 Project: S-RAMP Issue Type: Task Security Level: Public (Everyone can see) Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.4.0 - API Management Currently we require a zip'd up version of EAP to be available. Instead, let's install to an existing JBoss EAP. This requires users to download *and* unzip EAP 6.1, but that seems ok. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMPUI-111) Upgrade to Errai 2.4.0.Final

by Eric Wittmann (JIRA)

Eric Wittmann created SRAMPUI-111: ------------------------------------- Summary: Upgrade to Errai 2.4.0.Final Key: SRAMPUI-111 URL: https://issues.jboss.org/browse/SRAMPUI-111 Project: S-RAMP UI Issue Type: Feature Request Reporter: Eric Wittmann Assignee: Eric Wittmann Fix For: 0.3.1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-182) Make artifact type detection less generic (atom layer)

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-182?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-182: -------------------------------- Fix Version/s: 0.4.0 - API Management (was: 0.3.1 - jBPM - bugfix 1) > 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.4.0 - API Management > > > 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 <artifact> 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-203) Ensure the not() function works with classifiers

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-203?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-203: -------------------------------- Fix Version/s: 0.4.0 - API Management (was: 0.3.1 - jBPM - bugfix 1) > 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.4.0 - API Management > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[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.4.0 - API Management (was: 0.3.1 - jBPM - bugfix 1) > 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: Eric Wittmann > Priority: Minor > Fix For: 0.4.0 - API Management > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-161) S-RAMP Client: obey endpoints found in /servicedocument

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-161?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-161: -------------------------------- Fix Version/s: 0.4.0 - API Management (was: 0.3.1 - jBPM - bugfix 1) > 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.4.0 - API Management > > > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-140) Create unit tests for shell commands

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-140?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-140: -------------------------------- Fix Version/s: 0.4.0 - API Management (was: 0.3.1 - jBPM - bugfix 1) > Create unit tests for shell commands > ------------------------------------ > > Key: SRAMP-140 > URL: https://issues.jboss.org/browse/SRAMP-140 > Project: S-RAMP > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Priority: Minor > Fix For: 0.4.0 - API Management > > > I currently have poor junit coverage in the s-ramp-shell project. I need to create some unit tests, both for executing commands as well as for ancillary functionality like tab-completion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (SRAMP-199) Wsdl and Xsd Derivers are not setting up import/include relationships

by Eric Wittmann (JIRA)

[ https://issues.jboss.org/browse/SRAMP-199?page=com.atlassian.jira.plugin.... ] Eric Wittmann updated SRAMP-199: -------------------------------- Fix Version/s: 0.4.0 - API Management (was: 0.3.1 - jBPM - bugfix 1) > Wsdl and Xsd Derivers are not setting up import/include relationships > --------------------------------------------------------------------- > > Key: SRAMP-199 > URL: https://issues.jboss.org/browse/SRAMP-199 > Project: S-RAMP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 0.2.0 - Security & S-RAMP-1.0 > Reporter: Eric Wittmann > Assignee: Eric Wittmann > Fix For: 0.4.0 - API Management > > > The XSD deriver and WSDL derivers need to set up relationships to other xsd/wsdl documents when they are imported or included. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (RTGOV-283) Fix integration bom import

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/RTGOV-283?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on RTGOV-283: ----------------------------------------------- Gary Brown <gbrown(a)redhat.com> changed the Status of [bug 1013509|https://bugzilla.redhat.com/show_bug.cgi?id=1013509] from NEW to MODIFIED > Fix integration bom import > -------------------------- > > Key: RTGOV-283 > URL: https://issues.jboss.org/browse/RTGOV-283 > Project: RTGov (Run Time Governance) > Issue Type: Enhancement > Reporter: Gary Brown > Assignee: Gary Brown > Fix For: 2.0.0.M1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (GADGETS-71) Occasion ConcurrentModificationException when starting up gadget web UI

by Gary Brown (JIRA)

Gary Brown created GADGETS-71: --------------------------------- Summary: Occasion ConcurrentModificationException when starting up gadget web UI Key: GADGETS-71 URL: https://issues.jboss.org/browse/GADGETS-71 Project: Gadget Server and Gadgets Issue Type: Bug Reporter: Gary Brown Assignee: Eric Wittmann This exception occurs periodically when starting up the gadget server and adding the gadgets to a page. It appears to be related to the service overview gadget, as that does not display any content when this exception occurs. {noformat} 10:23:09,459 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/gadget-web].[js]] (http-/127.0.0.1:8080-4) JBWEB000236: Servlet.service() for servlet js threw exception: java.util.ConcurrentModificationException at java.util.TreeMap$NavigableSubMap$SubMapIterator.prevEntry(TreeMap.java:1605) [rt.jar:1.7.0_07] at java.util.TreeMap$NavigableSubMap$DescendingSubMapKeyIterator.next(TreeMap.java:1682) [rt.jar:1.7.0_07] at com.google.javascript.jscomp.ComposeWarningsGuard.addGuards(ComposeWarningsGuard.java:99) [closure-compiler-r1741.jar:] at com.google.javascript.jscomp.ComposeWarningsGuard.addGuard(ComposeWarningsGuard.java:89) [closure-compiler-r1741.jar:] at com.google.javascript.jscomp.ComposeWarningsGuard.addGuards(ComposeWarningsGuard.java:100) [closure-compiler-r1741.jar:] at com.google.javascript.jscomp.ComposeWarningsGuard.<init>(ComposeWarningsGuard.java:79) [closure-compiler-r1741.jar:] at com.google.javascript.jscomp.Compiler.initOptions(Compiler.java:277) [closure-compiler-r1741.jar:] at com.google.javascript.jscomp.Compiler.initModules(Compiler.java:332) [closure-compiler-r1741.jar:] at com.google.javascript.jscomp.Compiler.init(Compiler.java:312) [closure-compiler-r1741.jar:] at com.google.javascript.jscomp.Compiler.compile(Compiler.java:511) [closure-compiler-r1741.jar:] at org.apache.shindig.gadgets.rewrite.js.ClosureJsCompiler.doCompile(ClosureJsCompiler.java:205) [shindig-gadgets-3.0.0-beta4.jar:3.0.0-beta4] at org.apache.shindig.gadgets.rewrite.js.ClosureJsCompiler.compile(ClosureJsCompiler.java:172) [shindig-gadgets-3.0.0-beta4.jar:3.0.0-beta4] at org.apache.shindig.gadgets.js.CompilationProcessor.process(CompilationProcessor.java:48) [shindig-gadgets-3.0.0-beta4.jar:3.0.0-beta4] at org.apache.shindig.gadgets.js.DefaultJsProcessorRegistry.process(DefaultJsProcessorRegistry.java:53) [shindig-gadgets-3.0.0-beta4.jar:3.0.0-beta4] at org.apache.shindig.gadgets.js.DefaultJsServingPipeline.execute(DefaultJsServingPipeline.java:41) [shindig-gadgets-3.0.0-beta4.jar:3.0.0-beta4] at org.apache.shindig.gadgets.servlet.JsServlet.doGet(JsServlet.java:93) [shindig-gadgets-3.0.0-beta4.jar:3.0.0-beta4] at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.shindig.gadgets.servlet.ETagFilter.doFilter(ETagFilter.java:55) [shindig-gadgets-3.0.0-beta4.jar:3.0.0-beta4] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.shindig.common.servlet.HostFilter.doFilter(HostFilter.java:39) [shindig-common-3.0.0-beta4.jar:3.0.0-beta4] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:481) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.0.Final-redhat-1.jar:7.2.0.Final-redhat-1] {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

overlord-issues October 2013