[JBoss JIRA] (RTGOV-359) "Value too long" error when storing resubmit failure result
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-359?page=com.atlassian.jira.plugin.... ]
Gary Brown commented on RTGOV-359:
----------------------------------
Aim is to currently allow the UI to be deployed on the current version of the product, which has this column length limitation. Also not sure having a complete stack trace is ideal - the field should just be providing an indication of the problem.
The problem with the 'successful' status is that it is not being reported in the UI - the result field only appears to be used for reporting the failure result.
It might be nice if the basic message just reports success or failure (with the by and date/time fields), but provide a hoverover/popup with the failure details when relevant?
> "Value too long" error when storing resubmit failure result
> -----------------------------------------------------------
>
> Key: RTGOV-359
> URL: https://issues.jboss.org/browse/RTGOV-359
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Components: User Interface
> Reporter: Gary Brown
> Assignee: Michael Clay
>
> Related to RTGOV-332.
> When a failure occurs resubmitting the message, the result is stored in a property associated with the situation. However there is a length restriction of VARCHAR(255) on this field:
> 10:08:01,249 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-/127.0.0.1:8080-3) Value too long for column "VALUE VARCHAR(255)": "STRINGDECODE('org.overlord.rtgov.ui.client.model.UiException: org.switchyard.HandlerException: SWITCHYARD014000: Validator ''org... (12795)"; SQL statement:
> insert into RTGOV_SITUATION_PROPERTIES (id, name, value) values (?, ?, ?) [22001-168]
> The original intention of the result field was to report whether the message had been resubmitted successfully or not. Therefore we have a few options:
> 1) Just report 'successful' or 'failed' in this field - however this doesn't give an indication of why the resubmit failed. Although the failure is reported at the time when the resubmit is performed, so just depends whether we actually want the resubmission error to be persisted?
> 2) Truncate the error message - probably 250 characters would be enough anyway? However we should prefix the result with "Failed: ".
> Probably option 2 is best, although need to also ensure that a 'Successful' result is also recorded.
--
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
10 years, 10 months
[JBoss JIRA] (RTGOV-359) "Value too long" error when storing resubmit failure result
by Michael Clay (JIRA)
[ https://issues.jboss.org/browse/RTGOV-359?page=com.atlassian.jira.plugin.... ]
Michael Clay commented on RTGOV-359:
------------------------------------
i think option 2 is the way to go but why not also increase the column length because 250 chars are not much for a stacktrace? pls note that there are already 2 result properties to differentiate between successful (resubmitResult = OK )and 'erroneous' resubmit (resubmitFailure = stacktrace)
> "Value too long" error when storing resubmit failure result
> -----------------------------------------------------------
>
> Key: RTGOV-359
> URL: https://issues.jboss.org/browse/RTGOV-359
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Components: User Interface
> Reporter: Gary Brown
> Assignee: Michael Clay
>
> Related to RTGOV-332.
> When a failure occurs resubmitting the message, the result is stored in a property associated with the situation. However there is a length restriction of VARCHAR(255) on this field:
> 10:08:01,249 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-/127.0.0.1:8080-3) Value too long for column "VALUE VARCHAR(255)": "STRINGDECODE('org.overlord.rtgov.ui.client.model.UiException: org.switchyard.HandlerException: SWITCHYARD014000: Validator ''org... (12795)"; SQL statement:
> insert into RTGOV_SITUATION_PROPERTIES (id, name, value) values (?, ?, ?) [22001-168]
> The original intention of the result field was to report whether the message had been resubmitted successfully or not. Therefore we have a few options:
> 1) Just report 'successful' or 'failed' in this field - however this doesn't give an indication of why the resubmit failed. Although the failure is reported at the time when the resubmit is performed, so just depends whether we actually want the resubmission error to be persisted?
> 2) Truncate the error message - probably 250 characters would be enough anyway? However we should prefix the result with "Failed: ".
> Probably option 2 is best, although need to also ensure that a 'Successful' result is also recorded.
--
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
10 years, 10 months
[JBoss JIRA] (RTGOV-360) Move the 'resubmit' fields closer to the resubmit button
by Gary Brown (JIRA)
Gary Brown created RTGOV-360:
--------------------------------
Summary: Move the 'resubmit' fields closer to the resubmit button
Key: RTGOV-360
URL: https://issues.jboss.org/browse/RTGOV-360
Project: RTGov (Run Time Governance)
Issue Type: Enhancement
Components: User Interface
Reporter: Gary Brown
Assignee: Michael Clay
Currently the resubmit by, at and result fields are displayed above the message content. I think it would be better if this information was displayed along side the 'resubmit' button, and only information once a resubmission has been performed.
The text should then be of the form:
Resubmitted by 'xyz' at 'date and time': Successful
--
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
10 years, 10 months
[JBoss JIRA] (RTGOV-359) "Value too long" error when storing resubmit failure result
by Gary Brown (JIRA)
Gary Brown created RTGOV-359:
--------------------------------
Summary: "Value too long" error when storing resubmit failure result
Key: RTGOV-359
URL: https://issues.jboss.org/browse/RTGOV-359
Project: RTGov (Run Time Governance)
Issue Type: Bug
Components: User Interface
Reporter: Gary Brown
Assignee: Michael Clay
Related to RTGOV-332.
When a failure occurs resubmitting the message, the result is stored in a property associated with the situation. However there is a length restriction of VARCHAR(255) on this field:
10:08:01,249 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-/127.0.0.1:8080-3) Value too long for column "VALUE VARCHAR(255)": "STRINGDECODE('org.overlord.rtgov.ui.client.model.UiException: org.switchyard.HandlerException: SWITCHYARD014000: Validator ''org... (12795)"; SQL statement:
insert into RTGOV_SITUATION_PROPERTIES (id, name, value) values (?, ?, ?) [22001-168]
The original intention of the result field was to report whether the message had been resubmitted successfully or not. Therefore we have a few options:
1) Just report 'successful' or 'failed' in this field - however this doesn't give an indication of why the resubmit failed. Although the failure is reported at the time when the resubmit is performed, so just depends whether we actually want the resubmission error to be persisted?
2) Truncate the error message - probably 250 characters would be enough anyway? However we should prefix the result with "Failed: ".
Probably option 2 is best, although need to also ensure that a 'Successful' result is also recorded.
--
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
10 years, 10 months
[JBoss JIRA] (RTGOV-358) Dynamic inclusion of extensions in the Overlord UI
by Gary Brown (JIRA)
[ https://issues.jboss.org/browse/RTGOV-358?page=com.atlassian.jira.plugin.... ]
Gary Brown closed RTGOV-358.
----------------------------
Resolution: Done
After discussion with Eric, this can already be done by include a war for the extension pages with an additional properties file in the config/overlord-apps folder.
> Dynamic inclusion of extensions in the Overlord UI
> --------------------------------------------------
>
> Key: RTGOV-358
> URL: https://issues.jboss.org/browse/RTGOV-358
> Project: RTGov (Run Time Governance)
> Issue Type: Bug
> Reporter: Gary Brown
> Assignee: Eric Wittmann
>
> Consider how it would be possible to have hot deployable (if possible), but atleast dynamic (without compilation) inclusion of additional screens within the Overlord UI.
> They should appear as top level tabs (or atleast as sub-tabs within an 'extension' area), and participate in the Overlord UI SSO session.
--
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
10 years, 10 months
[JBoss JIRA] (RTGOV-332) Record message resubmission details against situation
by Michael Clay (JIRA)
[ https://issues.jboss.org/browse/RTGOV-332?page=com.atlassian.jira.plugin.... ]
Michael Clay reassigned RTGOV-332:
----------------------------------
Assignee: Michael Clay (was: Gary Brown)
> Record message resubmission details against situation
> -----------------------------------------------------
>
> Key: RTGOV-332
> URL: https://issues.jboss.org/browse/RTGOV-332
> Project: RTGov (Run Time Governance)
> Issue Type: Feature Request
> Components: User Interface
> Reporter: Gary Brown
> Assignee: Michael Clay
>
> When message is resubmitted, record the date/time, who resubmitted it, and the status of the resubmission (success/fail) in the properties of the situation, and saved back to the db.
> If these properties exist on a situation - when the situation details are displayed, they should be displayed on the Message tab, so that user avoids resubmitting again if previously successful.
--
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
10 years, 10 months
[JBoss JIRA] (RTGOV-358) Dynamic inclusion of extensions in the Overlord UI
by Gary Brown (JIRA)
Gary Brown created RTGOV-358:
--------------------------------
Summary: Dynamic inclusion of extensions in the Overlord UI
Key: RTGOV-358
URL: https://issues.jboss.org/browse/RTGOV-358
Project: RTGov (Run Time Governance)
Issue Type: Bug
Reporter: Gary Brown
Assignee: Eric Wittmann
Consider how it would be possible to have hot deployable (if possible), but atleast dynamic (without compilation) inclusion of additional screens within the Overlord UI.
They should appear as top level tabs (or atleast as sub-tabs within an 'extension' area), and participate in the Overlord UI SSO session.
--
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
10 years, 10 months
[JBoss JIRA] (RTGOV-355) UI integration tests fail when run as part of full build
by Gary Brown (JIRA)
Gary Brown created RTGOV-355:
--------------------------------
Summary: UI integration tests fail when run as part of full build
Key: RTGOV-355
URL: https://issues.jboss.org/browse/RTGOV-355
Project: RTGov (Run Time Governance)
Issue Type: Bug
Reporter: Gary Brown
Assignee: Gary Brown
Fix For: 2.0.0.M1
When the switchyard integration tests are performed as part of a full build of the rtgov-ui, they fail with the following issue:
{noformat}
org.overlord.rtgov.ui.tests.services.switchyard.SwitchYardServicesProviderTest Time elapsed: 31011 sec <<< ERROR!
java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.WebArchive org.overlord.rtgov.ui.tests.services.switchyard.SwitchYardServicesProviderTest.createDeployment1()
at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:160)
at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generateDeployment(AnnotationDeploymentScenarioGenerator.java:94)
at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.generate(AnnotationDeploymentScenarioGenerator.java:57)
at org.jboss.arquillian.container.test.impl.client.deployment.DeploymentGenerator.generateDeployment(DeploymentGenerator.java:79)
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:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:100)
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:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
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:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
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:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:80)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:182)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
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:601)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.reflect.InvocationTargetException
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:601)
at org.jboss.arquillian.container.test.impl.client.deployment.AnnotationDeploymentScenarioGenerator.invoke(AnnotationDeploymentScenarioGenerator.java:156)
... 56 more
Caused by: java.lang.RuntimeException: Could not parse pom.xml: /home/gbrown/repositories/overlord/objectiser/rtgov-ui/rtgov-ui-core/pom.xml
at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.createFoundArtifact(ClasspathWorkspaceReader.java:307)
at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.getFoundArtifact(ClasspathWorkspaceReader.java:272)
at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.findArtifact(ClasspathWorkspaceReader.java:194)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:296)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:193)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:281)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:186)
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:412)
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:544)
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:240)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveDependencies(DefaultRepositorySystem.java:333)
at org.jboss.shrinkwrap.resolver.impl.maven.bootstrap.MavenRepositorySystem.resolveDependencies(MavenRepositorySystem.java:114)
at org.jboss.shrinkwrap.resolver.impl.maven.MavenWorkingSessionImpl.resolveDependencies(MavenWorkingSessionImpl.java:256)
at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.using(MavenStrategyStageBaseImpl.java:67)
at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:49)
at org.jboss.shrinkwrap.resolver.impl.maven.MavenStrategyStageBaseImpl.withTransitivity(MavenStrategyStageBaseImpl.java:38)
at org.overlord.rtgov.ui.tests.services.switchyard.SwitchYardServicesProviderTest.createDeployment1(SwitchYardServicesProviderTest.java:65)
... 61 more
Caused by: org.xml.sax.SAXParseException; systemId: file:/home/gbrown/repositories/overlord/objectiser/rtgov-ui/rtgov-ui-core/pom.xml; lineNumber: 56; columnNumber: 3; The markup in the document following the root element must be well-formed.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:251)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:300)
at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:205)
at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.loadPom(ClasspathWorkspaceReader.java:313)
at org.jboss.shrinkwrap.resolver.impl.maven.aether.ClasspathWorkspaceReader.createFoundArtifact(ClasspathWorkspaceReader.java:286)
... 78 more
{noformat}
However when just the tests are performed on their own, they work.
--
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
10 years, 10 months