[JBoss JIRA] (FORGE-2733) bug in either forge REST API or in obsidian front end
by James Strachan (JIRA)
James Strachan created FORGE-2733:
-------------------------------------
Summary: bug in either forge REST API or in obsidian front end
Key: FORGE-2733
URL: https://issues.jboss.org/browse/FORGE-2733
Project: Forge
Issue Type: Bug
Reporter: James Strachan
I managed to get this exception just now:
{code}
2017-02-28 10:01:27,355 ERROR [io.undertow.request] (default task-20) UT005023: Exception handling request to /forge/commands/obsidian-new-quickstart/validate: org.jboss.resteasy.spi.UnhandledException: java.lang.IndexOutOfBoundsException: Index: 4, Size: 4
at org.jboss.resteasy.core.ExceptionHandler.handleApplicationException(ExceptionHandler.java:77)
at org.jboss.resteasy.core.ExceptionHandler.handleException(ExceptionHandler.java:220)
at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:175)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:418)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209)
at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.swarm.generated.FaviconErrorHandler.handleRequest(FaviconErrorHandler.java:62)
at io.undertow.server.handlers.PathHandler.handleRequest(PathHandler.java:94)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IndexOutOfBoundsException: Index: 4, Size: 4
at java.util.ArrayList.rangeCheck(ArrayList.java:653)
at java.util.ArrayList.get(ArrayList.java:429)
at org.jboss.forge.addon.ui.impl.controller.WizardCommandControllerImpl.getCurrentEntry(WizardCommandControllerImpl.java:493)
at org.jboss.forge.addon.ui.impl.controller.WizardCommandControllerImpl.getCurrentController(WizardCommandControllerImpl.java:504)
at org.jboss.forge.addon.ui.impl.controller.WizardCommandControllerImpl.isInitialized(WizardCommandControllerImpl.java:127)
at org.jboss.forge.addon.ui.impl.controller.AbstractCommandController.assertInitialized(AbstractCommandController.java:55)
at org.jboss.forge.addon.ui.impl.controller.WizardCommandControllerImpl.canMoveToNextStep(WizardCommandControllerImpl.java:298)
at org.jboss.forge.addon.ui.impl.controller.NoUIWizardControllerDecorator.canMoveToNextStep(NoUIWizardControllerDecorator.java:52)
at sun.reflect.GeneratedMethodAccessor280.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback$2.call(ClassLoaderAdapterCallback.java:124)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)
at org.jboss.forge.furnace.proxy.ClassLoaderAdapterCallback.invoke(ClassLoaderAdapterCallback.java:97)
at org.jboss.forge.addon.ui.controller.CommandController_$$_javassist_6eedec42-b625-4979-a432-d20d894e7b45.canMoveToNextStep(CommandController_$$_javassist_6eedec42-b625-4979-a432-d20d894e7b45.java)
at org.jboss.forge.service.util.UICommandHelper.describeCurrentState(UICommandHelper.java:83)
at org.obsidiantoaster.generator.rest.ObsidianResource.validateCommand(ObsidianResource.java:192)
at org.obsidiantoaster.generator.rest.ObsidianResource$Proxy$_$$_WeldClientProxy.validateCommand(Unknown Source)
at sun.reflect.GeneratedMethodAccessor546.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139)
at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402)
{code}
as I clicked on the last page of a 4 page wizard. Not sure if its a front end bug or not. The last posted form data was:
{code}
stepIndex:3
type:Creates a new Spring Boot Tomcat - Rest & Config Map
named:demo26
topLevelPackage:com.example
version:1.0.0-SNAPSHOT
pipeline:CanaryRelease
gitOrganisation:jstrachan
gitRepository:demo26
gitRepoDescription:undefined
kubernetesSpace:team
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (FORGE-2074) easy way to auto-reload addons being developed
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2074?page=com.atlassian.jira.plugin... ]
George Gastaldi closed FORGE-2074.
----------------------------------
Resolution: Done
Introduced {{addon-watch-start}} and {{addon-watch-stop}}
> easy way to auto-reload addons being developed
> ----------------------------------------------
>
> Key: FORGE-2074
> URL: https://issues.jboss.org/browse/FORGE-2074
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Reporter: James Strachan
> Assignee: George Gastaldi
> Fix For: 3.5.2.Final
>
>
> So Apache Karaf has a nice command "dev:watch *"
> http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html
> which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them.
> It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell.
> Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool.
> e.g. a new command, something like...
> {code}
> addon-watch *
> {code}
> which uses the currently loaded jars and applies the wildcard to filter the SNAPSHOT builds to watch in ~/.m2/repository to detect if a build is done; then it'd invoke the addon-install command with the updated jar
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 1 month
[JBoss JIRA] (FORGE-2074) easy way to auto-reload addons being developed
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2074?page=com.atlassian.jira.plugin... ]
Work on FORGE-2074 started by George Gastaldi.
----------------------------------------------
> easy way to auto-reload addons being developed
> ----------------------------------------------
>
> Key: FORGE-2074
> URL: https://issues.jboss.org/browse/FORGE-2074
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Reporter: James Strachan
> Assignee: George Gastaldi
> Fix For: 3.5.2.Final
>
>
> So Apache Karaf has a nice command "dev:watch *"
> http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html
> which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them.
> It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell.
> Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool.
> e.g. a new command, something like...
> {code}
> addon-watch *
> {code}
> which uses the currently loaded jars and applies the wildcard to filter the SNAPSHOT builds to watch in ~/.m2/repository to detect if a build is done; then it'd invoke the addon-install command with the updated jar
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (FORGE-2074) easy way to auto-reload addons being developed
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2074?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-2074:
-----------------------------------
Fix Version/s: 3.5.2.Final
(was: 3.x Future)
> easy way to auto-reload addons being developed
> ----------------------------------------------
>
> Key: FORGE-2074
> URL: https://issues.jboss.org/browse/FORGE-2074
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Reporter: James Strachan
> Fix For: 3.5.2.Final
>
>
> So Apache Karaf has a nice command "dev:watch *"
> http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html
> which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them.
> It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell.
> Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool.
> e.g. a new command, something like...
> {code}
> addon-watch *
> {code}
> which uses the currently loaded jars and applies the wildcard to filter the SNAPSHOT builds to watch in ~/.m2/repository to detect if a build is done; then it'd invoke the addon-install command with the updated jar
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (FORGE-2074) easy way to auto-reload addons being developed
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2074?page=com.atlassian.jira.plugin... ]
George Gastaldi reassigned FORGE-2074:
--------------------------------------
Assignee: George Gastaldi
> easy way to auto-reload addons being developed
> ----------------------------------------------
>
> Key: FORGE-2074
> URL: https://issues.jboss.org/browse/FORGE-2074
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Reporter: James Strachan
> Assignee: George Gastaldi
> Fix For: 3.5.2.Final
>
>
> So Apache Karaf has a nice command "dev:watch *"
> http://karaf.apache.org/manual/latest-2.x/commands/dev-watch.html
> which looks at all the currently installed bundles; figures out the mvn coords and where they are in the ~/.m2/repository; then any which are SNAPSHOT versions it watches them; if they get rebuilt it auto-reloads them.
> It'd be great to have the same kinda thing in Forge for when you're working on an addon; then every time you do a mvn build, forge would reload it on the fly so you could try it out for real in a forge shell.
> Right now it seems pretty slow to install newly built addons; anything to make the development a bit more RAD would be really cool.
> e.g. a new command, something like...
> {code}
> addon-watch *
> {code}
> which uses the currently loaded jars and applies the wildcard to filter the SNAPSHOT builds to watch in ~/.m2/repository to detect if a build is done; then it'd invoke the addon-install command with the updated jar
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (FORGE-2665) addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2665?page=com.atlassian.jira.plugin... ]
George Gastaldi closed FORGE-2665.
----------------------------------
Fix Version/s: (was: 3.5.2.Final)
Resolution: Duplicate Issue
Duplicate of FORGE-2074
> addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2665
> URL: https://issues.jboss.org/browse/FORGE-2665
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Affects Versions: 3.2.2.Final
> Reporter: James Strachan
> Assignee: George Gastaldi
>
> its kinda clumsy and slow when working on a Forge addon; you try some code, rebuild it, then in your Forge app you run the remove / install commands to get the new code into your CLI install of Forge (or your web app running Forge, or your IDE etc...)
> What would be cooler is if we had an 'addon-watch wildcard' command. That lets you start/stop watching addons that have SNAPSHOT versions. Even ignore the wildcard and just watch all SNAPSHOT addons.
> When watching, every installed addon of version SNAPSHOT, we'd watch ~/.m2/repository for the builds of the addons. If you then rebuild an addon, it'd reload the addon automatically (remove it first, then re-install it)!
> This would make it much quicker and simpler to try things out! Its especially painful when testing out changes to Forge commands in a web app (e.g. hawtio-forge) as you typically need to build the addons then rebuild the addon repo then rebuild/restart the web app etc!
> So this simple approach would help folks get more rapid feedback on building any addon - however you run them (CLI, web, IDE)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (FORGE-2665) addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2665?page=com.atlassian.jira.plugin... ]
George Gastaldi commented on FORGE-2665:
----------------------------------------
It would be nice to bring this command to the {{addon-manager}} addon.
> addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2665
> URL: https://issues.jboss.org/browse/FORGE-2665
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Affects Versions: 3.2.2.Final
> Reporter: James Strachan
> Assignee: George Gastaldi
> Fix For: 3.5.2.Final
>
>
> its kinda clumsy and slow when working on a Forge addon; you try some code, rebuild it, then in your Forge app you run the remove / install commands to get the new code into your CLI install of Forge (or your web app running Forge, or your IDE etc...)
> What would be cooler is if we had an 'addon-watch wildcard' command. That lets you start/stop watching addons that have SNAPSHOT versions. Even ignore the wildcard and just watch all SNAPSHOT addons.
> When watching, every installed addon of version SNAPSHOT, we'd watch ~/.m2/repository for the builds of the addons. If you then rebuild an addon, it'd reload the addon automatically (remove it first, then re-install it)!
> This would make it much quicker and simpler to try things out! Its especially painful when testing out changes to Forge commands in a web app (e.g. hawtio-forge) as you typically need to build the addons then rebuild the addon repo then rebuild/restart the web app etc!
> So this simple approach would help folks get more rapid feedback on building any addon - however you run them (CLI, web, IDE)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (FORGE-2665) addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2665?page=com.atlassian.jira.plugin... ]
George Gastaldi reopened FORGE-2665:
------------------------------------
> addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2665
> URL: https://issues.jboss.org/browse/FORGE-2665
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Affects Versions: 3.2.2.Final
> Reporter: James Strachan
> Assignee: George Gastaldi
> Fix For: 3.5.2.Final
>
>
> its kinda clumsy and slow when working on a Forge addon; you try some code, rebuild it, then in your Forge app you run the remove / install commands to get the new code into your CLI install of Forge (or your web app running Forge, or your IDE etc...)
> What would be cooler is if we had an 'addon-watch wildcard' command. That lets you start/stop watching addons that have SNAPSHOT versions. Even ignore the wildcard and just watch all SNAPSHOT addons.
> When watching, every installed addon of version SNAPSHOT, we'd watch ~/.m2/repository for the builds of the addons. If you then rebuild an addon, it'd reload the addon automatically (remove it first, then re-install it)!
> This would make it much quicker and simpler to try things out! Its especially painful when testing out changes to Forge commands in a web app (e.g. hawtio-forge) as you typically need to build the addons then rebuild the addon repo then rebuild/restart the web app etc!
> So this simple approach would help folks get more rapid feedback on building any addon - however you run them (CLI, web, IDE)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months
[JBoss JIRA] (FORGE-2665) addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
by George Gastaldi (JIRA)
[ https://issues.jboss.org/browse/FORGE-2665?page=com.atlassian.jira.plugin... ]
George Gastaldi updated FORGE-2665:
-----------------------------------
Fix Version/s: 3.5.2.Final
(was: 3.x Future)
> addon-watch command for developer mode where we can make the forge container watch for rebuilds of addons and auto-reload them
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: FORGE-2665
> URL: https://issues.jboss.org/browse/FORGE-2665
> Project: Forge
> Issue Type: Feature Request
> Components: Addon Development
> Affects Versions: 3.2.2.Final
> Reporter: James Strachan
> Assignee: George Gastaldi
> Fix For: 3.5.2.Final
>
>
> its kinda clumsy and slow when working on a Forge addon; you try some code, rebuild it, then in your Forge app you run the remove / install commands to get the new code into your CLI install of Forge (or your web app running Forge, or your IDE etc...)
> What would be cooler is if we had an 'addon-watch wildcard' command. That lets you start/stop watching addons that have SNAPSHOT versions. Even ignore the wildcard and just watch all SNAPSHOT addons.
> When watching, every installed addon of version SNAPSHOT, we'd watch ~/.m2/repository for the builds of the addons. If you then rebuild an addon, it'd reload the addon automatically (remove it first, then re-install it)!
> This would make it much quicker and simpler to try things out! Its especially painful when testing out changes to Forge commands in a web app (e.g. hawtio-forge) as you typically need to build the addons then rebuild the addon repo then rebuild/restart the web app etc!
> So this simple approach would help folks get more rapid feedback on building any addon - however you run them (CLI, web, IDE)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 2 months