[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
[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
[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
[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
[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