[JBoss JIRA] (AS7-4913) Server sends "big integer <val>" for config entries when a reload is needed
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4913?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4913:
----------------------------------
Summary: Server sends "big integer <val>" for config entries when a reload is needed (was: Server sends "big interger <val>" for config entries when a reload is needed)
> Server sends "big integer <val>" for config entries when a reload is needed
> ---------------------------------------------------------------------------
>
> Key: AS7-4913
> URL: https://issues.jboss.org/browse/AS7-4913
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JCA
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Heiko Rupp
> Assignee: David Lloyd
> Priority: Minor
> Labels: rhq
> Fix For: 7.2.0.Alpha1
>
>
> RHQ sends JSON like this to change e.g. the max-pool-size setting of a data source:
> {"operation":"composite","steps":[{"operation":"write-attribute","address":[{"subsystem":"datasources"},{"data-source":"ExampleDS"}],"name":"max-pool-size","value":75},{"operation":"write-attribute","address":[{"subsystem":"datasources"},{"data-source":"ExampleDS"}],"name":"use-fast-fail","value":false}],"address":[]}
> Server returns success.
> When I directly go to the cli afterwards I see:
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size)
> {
> "outcome" => "success",
> "result" => big integer 75,
> "response-headers" => {"process-state" => "restart-required"}
> }
> Note the "big integer"
> [standalone@localhost:9999 /] /:reload
> {"outcome" => "success"}
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size)
> {
> "outcome" => "success",
> "result" => 75
> }
> [standalone@localhost:9999 /]
> Now the server acts as always.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6237) Upgrade DMR to 1.1.4
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6237:
-------------------------------------
Summary: Upgrade DMR to 1.1.4
Key: AS7-6237
URL: https://issues.jboss.org/browse/AS7-6237
Project: Application Server 7
Issue Type: Component Upgrade
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Critical
Fix For: 7.2.0.Alpha1
Pick up fix for AS7-4913.
Only critical so it doesn't get mass-pushed to 7.3.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6236) CLONE - Server sends "big interger <val>" for config entries when a reload is needed
by Brian Stansberry (JIRA)
Brian Stansberry created AS7-6236:
-------------------------------------
Summary: CLONE - Server sends "big interger <val>" for config entries when a reload is needed
Key: AS7-6236
URL: https://issues.jboss.org/browse/AS7-6236
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, JCA
Affects Versions: 7.1.2.Final (EAP)
Reporter: Heiko Rupp
Assignee: David Lloyd
Priority: Minor
Fix For: 7.2.0.Alpha1
RHQ sends JSON like this to change e.g. the max-pool-size setting of a data source:
{"operation":"composite","steps":[{"operation":"write-attribute","address":[{"subsystem":"datasources"},{"data-source":"ExampleDS"}],"name":"max-pool-size","value":75},{"operation":"write-attribute","address":[{"subsystem":"datasources"},{"data-source":"ExampleDS"}],"name":"use-fast-fail","value":false}],"address":[]}
Server returns success.
When I directly go to the cli afterwards I see:
[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size)
{
"outcome" => "success",
"result" => big integer 75,
"response-headers" => {"process-state" => "restart-required"}
}
Note the "big integer"
[standalone@localhost:9999 /] /:reload
{"outcome" => "success"}
[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:read-attribute(name=max-pool-size)
{
"outcome" => "success",
"result" => 75
}
[standalone@localhost:9999 /]
Now the server acts as always.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6225) MessagingSubsystemParser swallows exceptions
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/AS7-6225?page=com.atlassian.jira.plugin.s... ]
Jeff Mesnil resolved AS7-6225.
------------------------------
Resolution: Done
PR merged in master and 7.1 branches
> MessagingSubsystemParser swallows exceptions
> --------------------------------------------
>
> Key: AS7-6225
> URL: https://issues.jboss.org/browse/AS7-6225
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, JMS
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Brian Stansberry
> Assignee: Jeff Mesnil
> Fix For: 7.2.0.Alpha1
>
> Attachments: AS7-6225.patch
>
>
> In numerous places, MessagingSubsystemParser calls ParseUtils.missingRequired but does not throw the returned exception.
> I'll attach a patch showing all the places where Intellij reported this. I'd just send a pull request, but when I run with this patch, the messaging module testsuite has failures and I don't have time today to investigate.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6231) Context initialization exceptions are swallowed on deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6231?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6231:
---------------------------------------
See comment from Kyle Lape on https://issues.jboss.org/browse/JBWEB-232 -- "if you add -Dorg.jboss.as.logging.per-deployment=false it will show the desired exception".
Note I haven't checked that what he says is correct.
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: AS7-6231
> URL: https://issues.jboss.org/browse/AS7-6231
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6231) Context initialization exceptions are swallowed on deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6231?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry commented on AS7-6231:
---------------------------------------
There is some logging system property setting that if set results in these message re-appearing -- disabling per-deployment logging or something. I remember seeing it recently in a comment on another issue.
I'm not saying that makes this not a bug; it's just a clue to the problem and a possible workaround.
> Context initialization exceptions are swallowed on deployment
> -------------------------------------------------------------
>
> Key: AS7-6231
> URL: https://issues.jboss.org/browse/AS7-6231
> Project: Application Server 7
> Issue Type: Bug
> Components: EE
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: David Lloyd
> Attachments: jboss-7.1.1.-stacktrace-beans.txt, jboss-7.1.1.-stacktrace-namespace.txt, jboss-7.2.0.-stacktrace-namespace.txt, spring-app-1.0.0-BUILD-SNAPSHOT-startupexception.war
>
>
> On 7.2.0.Alpha1, trying to deploy a simple spring app with problems in context initialization, all exceptions are swallowed, and only a meaningless error
> org.jboss.msc.service.StartException in anonymous service: JBAS018040: Failed to start context at org.jboss.as.web.deployment.WebDeploymentService.doStart(WebDeploymentService.java:161)
> is shown, making it impossible to find out the root cause.
> On 7.1.1., meaningful exception is shown, like
> Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://www.osgi.org/xmlns/blueprint/v1.0.0]
> Offending resource: ServletContext resource [/WEB-INF/spring/root-context.xml]
> or
> org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
> Caused by: org.xml.sax.SAXParseException; lineNumber: 6; columnNumber: 108; cvc-elt.1: Cannot find the declaration of element 'beans'.
> which allows the developer to fix the problem.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6234) WAB deployment showing as successful, but not responding
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6234?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler reopened AS7-6234:
---------------------------------
Yes, this is a bug. The webcontext gets registered but root access gives 404
> WAB deployment showing as successful, but not responding
> --------------------------------------------------------
>
> Key: AS7-6234
> URL: https://issues.jboss.org/browse/AS7-6234
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Attachments: jboss-7.2.0-server-output-deployment-showing-as-successful.txt, server.springapp.log, spring-app-1.0.0-BUILD-SNAPSHOT-looks-to-start-normally-but-doesnt.war, spring-app-1.0.0-BUILD-SNAPSHOT-no-manifest-works.war, spring-app-source-codes.zip
>
>
> Simple Spring WAB file, that I think should work, doesn't seem to. Deployment goes seemingly without issues - no errors are reported - but servlet does not respond to requests. Both OSGi panel and deployment management panel in admin console show the deployment as successful.
> Attached server output and .war file, that should respond to /spring-app request.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6234) WAB deployment showing as successful, but not responding
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6234?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori commented on AS7-6234:
----------------------------------------
I attached the very same .war without the manifest creation (just the default manifest), and that works without issues. Having a proper OSGi manifest should not cause the app to not work - it should either work or complain about something. As far as I know and what I have tested with other apps, in 7.2, that is expected to work.
> WAB deployment showing as successful, but not responding
> --------------------------------------------------------
>
> Key: AS7-6234
> URL: https://issues.jboss.org/browse/AS7-6234
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Attachments: jboss-7.2.0-server-output-deployment-showing-as-successful.txt, server.springapp.log, spring-app-1.0.0-BUILD-SNAPSHOT-looks-to-start-normally-but-doesnt.war, spring-app-1.0.0-BUILD-SNAPSHOT-no-manifest-works.war, spring-app-source-codes.zip
>
>
> Simple Spring WAB file, that I think should work, doesn't seem to. Deployment goes seemingly without issues - no errors are reported - but servlet does not respond to requests. Both OSGi panel and deployment management panel in admin console show the deployment as successful.
> Attached server output and .war file, that should respond to /spring-app request.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6234) WAB deployment showing as successful, but not responding
by jarkko rantavuori (JIRA)
[ https://issues.jboss.org/browse/AS7-6234?page=com.atlassian.jira.plugin.s... ]
jarkko rantavuori updated AS7-6234:
-----------------------------------
Attachment: spring-app-1.0.0-BUILD-SNAPSHOT-no-manifest-works.war
> WAB deployment showing as successful, but not responding
> --------------------------------------------------------
>
> Key: AS7-6234
> URL: https://issues.jboss.org/browse/AS7-6234
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Attachments: jboss-7.2.0-server-output-deployment-showing-as-successful.txt, server.springapp.log, spring-app-1.0.0-BUILD-SNAPSHOT-looks-to-start-normally-but-doesnt.war, spring-app-1.0.0-BUILD-SNAPSHOT-no-manifest-works.war, spring-app-source-codes.zip
>
>
> Simple Spring WAB file, that I think should work, doesn't seem to. Deployment goes seemingly without issues - no errors are reported - but servlet does not respond to requests. Both OSGi panel and deployment management panel in admin console show the deployment as successful.
> Attached server output and .war file, that should respond to /spring-app request.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6233) System properties referencing each other in domain mode do not work
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/AS7-6233?page=com.atlassian.jira.plugin.s... ]
Kabir Khan updated AS7-6233:
----------------------------
Description:
The following set up:
{code}
<system-properties>
<property name="one" value="one1"/>
<property name="two" value="${one}"/>
</system-properties>
{code}
works in standalone, so
{code}
[standalone@localhost:9999 /] :resolve-expression(expression="${two}")
{
"outcome" => "success",
"result" => "one1"
}
{code}
However, in domain mode the properties get passed in in the wrong order so
{code}
[domain@localhost:9999 /] /host=master/server=server-one:resolve-expression(expression="${two}")
{
"outcome" => "success",
"result" => "${one}"
}
{code}
ManagedServerOperationsFactory.getAllSystemProperties() should use a LinkedHashMap to preserve the order of the system properties, since at the moment in the server 'two' gets added before 'one'
was:
The following set up:
{code}
<system-properties>
<property name="one" value="one1"/>
<property name="two" value="${one}"/>
</system-properties>
{code}
works in standalone, so
{code}
[standalone@localhost:9999 /] :resolve-expression(expression="${two}")
{
"outcome" => "success",
"result" => "one1"
}
{code}
However, in domain mode the properties get passed in in the wrong order so
{code}
[domain@localhost:9999 /] /host=master/server=server-one:resolve-expression(expression="${two}")
{
"outcome" => "success",
"result" => "${one}"
}
{code}
> System properties referencing each other in domain mode do not work
> -------------------------------------------------------------------
>
> Key: AS7-6233
> URL: https://issues.jboss.org/browse/AS7-6233
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Affects Versions: 7.1.2.Final (EAP), 7.1.3.Final (EAP)
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> The following set up:
> {code}
> <system-properties>
> <property name="one" value="one1"/>
> <property name="two" value="${one}"/>
> </system-properties>
> {code}
> works in standalone, so
> {code}
> [standalone@localhost:9999 /] :resolve-expression(expression="${two}")
> {
> "outcome" => "success",
> "result" => "one1"
> }
> {code}
> However, in domain mode the properties get passed in in the wrong order so
> {code}
> [domain@localhost:9999 /] /host=master/server=server-one:resolve-expression(expression="${two}")
> {
> "outcome" => "success",
> "result" => "${one}"
> }
> {code}
> ManagedServerOperationsFactory.getAllSystemProperties() should use a LinkedHashMap to preserve the order of the system properties, since at the moment in the server 'two' gets added before 'one'
--
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
13 years, 4 months