[JBoss JIRA] (AS7-2936) Canot remove security login moddule
by Heiko Braun (Created) (JIRA)
Canot remove security login moddule
-----------------------------------
Key: AS7-2936
URL: https://issues.jboss.org/browse/AS7-2936
Project: Application Server 7
Issue Type: Bug
Components: Domain Management, Security
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 7.1.0.CR1
Due to some weird DMR constraints I cannot clear the list of security domain modules:
{noformat}
[INFO] save:{
[INFO] "operation" => "write-attribute",
[INFO] "address" => [
[INFO] ("subsystem" => "security"),
[INFO] ("security-domain" => "other"),
[INFO] ("authentication" => "classic")
[INFO] ],
[INFO] "name" => "login-modules",
[INFO] "value" => []
[INFO] }
[ERROR] 2011-12-07 09:21:57,097 [ERROR] On Wed Dec 07 09:21:57 CET 2011, MessageCenter received Failed to: write-attribute login-modules: other
[ERROR] 2011-12-07 09:21:57,101 [ERROR] Message{conciseMessage='Failed to: write-attribute login-modules: other', detailedMessage='JBAS014706: [0] is an invalid size for parameter value. A minimum length of [1] is required', fired=Wed Dec 07 09:21:57 CET 2011, severity=Error, options=[]}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4134) Jacorb name service may not be started before Transaction Manager attempts to bind itself
by Tom Jenkinson (JIRA)
Tom Jenkinson created AS7-4134:
----------------------------------
Summary: Jacorb name service may not be started before Transaction Manager attempts to bind itself
Key: AS7-4134
URL: https://issues.jboss.org/browse/AS7-4134
Project: Application Server 7
Issue Type: Bug
Components: IIOP, Transactions
Affects Versions: 7.1.1.Final
Reporter: Tom Jenkinson
Assignee: Stefan Guilhen
When I configure the Transaction manager to use the Jacorb name service for publishing its endpoint, occasionally I get an error such as:
11:42:19,781 INFO [org.hornetq.core.server.impl.FileLockNodeManager] (MSC service thread 1-1) Live Server Obtained live lock
11:42:20,437 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.txn.ArjunaTransactionManager: org.jboss.msc.service.StartException in service jboss.txn.ArjunaTransactionManager: JBAS010104: Start failed
at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_18]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_18]
at java.lang.Thread.run(Thread.java:619) [rt.jar:1.6.0_18]
Caused by: java.lang.Exception: ARJUNA032027: Problem encountered while trying to register transaction manager with ORB!
at com.arjuna.ats.jbossatx.jts.TransactionManagerService.start(TransactionManagerService.java:85)
at org.jboss.as.txn.service.ArjunaTransactionManagerService.start(ArjunaTransactionManagerService.java:152)
... 5 more
Caused by: org.omg.CORBA.OBJECT_NOT_EXIST
at org.jacorb.orb.Delegate.servant_preinvoke(Delegate.java:1859)
at org.jacorb.orb.Delegate.is_a(Delegate.java:1324)
at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:49) [rt.jar:1.6.0_18]
at org.omg.CosNaming.NamingContextHelper.narrow(NamingContextHelper.java:47) [rt.jar:1.6.0_18]
at com.arjuna.orbportability.Services.registerService(Services.java:344)
at com.arjuna.ats.jts.TransactionServer.registerTransactionManager(TransactionServer.java:57)
at com.arjuna.ats.jbossatx.jts.TransactionManagerService.start(TransactionManagerService.java:81)
... 6 more
11:42:20,484 INFO [org.jboss.as.jacorb] (MSC service thread 1-2) JBAS016328: CORBA Naming Service started
C:\hudson\workspace\blacktie-windows2003\
As you can see, the transaction manager is trying to register itself in Jacorb before the Name service is resolvable even though the transactions module.xml has a dependency on org.omg.api.
Perhaps it should have a different dependency?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (JBMESSAGING-1917) Networking Failure Locks Post Office
by Doug Grove (JIRA)
Doug Grove created JBMESSAGING-1917:
---------------------------------------
Summary: Networking Failure Locks Post Office
Key: JBMESSAGING-1917
URL: https://issues.jboss.org/browse/JBMESSAGING-1917
Project: JBoss Messaging
Issue Type: Bug
Components: Messaging Core
Affects Versions: 1.4.8.SP5
Environment: JBoss EAP .1.2
Reporter: Doug Grove
Several network failure modes can cause the messaging post office to lock. For example, loss of connectivity to a client can cause Messaging to stop accepting new clients and stop delivering messages. Message can, however, still be delivered from the clients.
220 threads waiting to acquire MessagingPostOffice's ReaderLock. Likely owned by:
"WorkManager(2)-7" daemon prio=10 tid=0x25108800 nid=0x1af7 in Object.wait() [0x1a675000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
- waiting on <0x3e6031f8> (a java.util.HashSet)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:538)
- locked <0x3e6031f8> (a java.util.HashSet)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1165)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:816)
at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:470)
at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:169)
at org.jboss.remoting.Client.invoke(Client.java:2070)
at org.jboss.remoting.Client.invoke(Client.java:879)
at org.jboss.remoting.Client.invokeOneway(Client.java:928)
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallback(ServerInvokerCallbackHandler.java:835)
at org.jboss.remoting.callback.ServerInvokerCallbackHandler.handleCallbackOneway(ServerInvokerCallbackHandler.java:708)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.performDelivery(ServerSessionEndpoint.java:1610)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.handleDelivery(ServerSessionEndpoint.java:1522)
- locked <0x3fd4bc18> (a org.jboss.jms.server.endpoint.ServerSessionEndpoint)
at org.jboss.jms.server.endpoint.ServerConsumerEndpoint.handle(ServerConsumerEndpoint.java:353)
- locked <0x3e5960b8> (a java.lang.Object)
at org.jboss.messaging.core.impl.RoundRobinDistributor.handle(RoundRobinDistributor.java:119)
at org.jboss.messaging.core.impl.MessagingQueue$DistributorWrapper.handle(MessagingQueue.java:617)
at org.jboss.messaging.core.impl.ClusterRoundRobinDistributor.handle(ClusterRoundRobinDistributor.java:79)
at org.jboss.messaging.core.impl.ChannelSupport.deliverInternal(ChannelSupport.java:677)
at org.jboss.messaging.core.impl.MessagingQueue.deliverInternal(MessagingQueue.java:540)
at org.jboss.messaging.core.impl.ChannelSupport.handle(ChannelSupport.java:251)
- locked <0x3e595e28> (a java.lang.Object)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.routeInternal(MessagingPostOffice.java:3163)
at org.jboss.messaging.core.impl.postoffice.MessagingPostOffice.route(MessagingPostOffice.java:980)
Thread looks to be in this while loop until the timeout passes:
while ((isConnected()) && ((!this.pingFailed.flag) || (pingFailedTimeRemaining > 0L)) && ((timeout == 0) || (timeRemaining > 0L)))
{
synchronized (sockets)
{
try
{
sockets.wait(1000L); //538
}
catch (InterruptedException e)
{
log.debug(this + " unexpected interrupt");
}
if (!sockets.isEmpty())
{
Iterator it = sockets.iterator();
Socket socket = (Socket)it.next();
it.remove();
configureSocket(socket);
log.debug(this + " found socket (" + this.listenerId + "): " + socket);
return socket;
}
}
if (savedControlOutputStream != this.controlOutputStream)
{
savedControlOutputStream = this.controlOutputStream;
log.debug(this + " rewriting Bisocket.CREATE_ORDINARY_SOCKET on " + this.controlOutputStream);
try
{
this.controlOutputStream.write(4);
log.debug(this + " rewrote Bisocket.CREATE_ORDINARY_SOCKET");
}
catch (IOException e)
{
log.debug(this + " unable to rewrite Bisocket.CREATE_ORDINARY_SOCKET" + e.getMessage());
}
}
long elapsed = System.currentTimeMillis() - start;
if (timeout > 0)
timeRemaining = timeout - elapsed;
pingFailedTimeRemaining = pingFailedWindow - elapsed;
}
so he pulls a client NIC and the thread on JBoss hangs on it per his timeout, but hangs while holding the MessagingPostOffice lock to back everything else up. I don't see a way around that without a messaging code overhaul. Just set a timely timeout and hope for no NIC failures :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4139) Resource adapters subsystem doesn't unregister JNDI names of undeployed resources
by Vladimir Rastseluev (JIRA)
Vladimir Rastseluev created AS7-4139:
----------------------------------------
Summary: Resource adapters subsystem doesn't unregister JNDI names of undeployed resources
Key: AS7-4139
URL: https://issues.jboss.org/browse/AS7-4139
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.1.1.Final
Reporter: Vladimir Rastseluev
Assignee: Stefano Maestri
Fix For: 7.1.2.Final
2nd run for all tests from package org.jboss.as.test.smoke.deployment.rar.examples on standalone instance fails.
Seems, that after deployment of .rar with the same name like previous archive, server tries to register JNDI names from both archives, even in case, that first archive is undeployed and resources are unbound.
ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.ra.deployment."basic.rar_2": org.jboss.msc.service.StartException in service jboss.ra.deployment."basic.rar_2": org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [basic]
at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:126)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_23]
at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_23]
Caused by: org.jboss.msc.service.StartException in anonymous service: JBAS010446: Failed to start RA deployment [basic]
at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:110)
... 5 more
Caused by: org.jboss.jca.deployers.common.DeployException: IJ020056: Deployment failed: file:/home/vrastsel/jboss-as/build/target/jboss-as-7.1.1.Final-SNAPSHOT/standalone/tmp/vfs/temp4026624ced5f302d/content-603f46fde5d58cd/contents/
at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:2174)
at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService$AS7RaXmlDeployer.doDeploy(ResourceAdapterXmlDeploymentService.java:173)
at org.jboss.as.connector.metadata.deployment.ResourceAdapterXmlDeploymentService.start(ResourceAdapterXmlDeploymentService.java:104)
... 5 more
Caused by: org.jboss.msc.service.DuplicateServiceException: Service jboss.connector.connection-factory.java:jboss/name1 is already registered
at org.jboss.msc.service.ServiceRegistrationImpl.setInstance(ServiceRegistrationImpl.java:154) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl.startInstallation(ServiceControllerImpl.java:227) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:560) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:201) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2228) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:307) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.as.connector.metadata.deployment.AbstractResourceAdapterDeploymentService$AbstractAS7RaDeployer.bindConnectionFactory(AbstractResourceAdapterDeploymentService.java:261)
at org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.createObjectsAndInjectValue(AbstractResourceAdapterDeployer.java:1946)
... 7 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3881) HornetQ configurations for broadcast and discovery groups do not use socket bindings
by Shelly McGowan (JIRA)
Shelly McGowan created AS7-3881:
-----------------------------------
Summary: HornetQ configurations for broadcast and discovery groups do not use socket bindings
Key: AS7-3881
URL: https://issues.jboss.org/browse/AS7-3881
Project: Application Server 7
Issue Type: Bug
Reporter: Shelly McGowan
Assignee: Brian Stansberry
Fix For: 7.1.1.Final
HornetQ configurations for broadcast and discovery groups do not use socket bindings. Every configurations values related to ports or addresses should use socket bindings. For example see configurations for JGrpups, ...
standalone/configuration/standalone-full-ha.xml
HornetQ
{code}
<broadcast-groups>
<broadcast-group name="bg-group1">
<group-address>231.7.7.7</group-address>
<group-port>9876</group-port>
<broadcast-period>5000</broadcast-period>
<connector-ref>netty</connector-ref>
</broadcast-group>
</broadcast-groups>
<discovery-groups>
<discovery-group name="dg-group1">
<group-address>231.7.7.7</group-address>
<group-port>9876</group-port>
<refresh-timeout>10000</refresh-timeout>
</discovery-group>
</discovery-groups>
....
{code}
{code}
<socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
...
<socket-binding name="jgroups-diagnostics" port="0" multicast-address="224.0.75.75" multicast-port="7500"/>
<socket-binding name="jgroups-mping" port="0" multicast-address="${jboss.default.multicast.address:230.0.0.4}" multicast-port="45700"/>
...
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4136) Enhance Error Reporting
by Juergen Hoffmann (JIRA)
Juergen Hoffmann created AS7-4136:
-------------------------------------
Summary: Enhance Error Reporting
Key: AS7-4136
URL: https://issues.jboss.org/browse/AS7-4136
Project: Application Server 7
Issue Type: Enhancement
Reporter: Juergen Hoffmann
Priority: Minor
If you do not have a port offset configured in our host.xml servers socket binding definition, you will receive a Null Pointer Exception:
<servers>
<server name="MY-AS-PROD" group="MY-AS-PROD" auto-start="true">
<jvm name="default">
<jvm-options>
<option value="-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"/>
</jvm-options>
</jvm>
<socket-bindings socket-binding-group="standard-sockets"/>
</server>
</servers>
after adding port-offset="0" the NPE vanished
15:18:16,740 ERROR [org.jboss.as.controller] (Controller Boot Thread) JBAS014601: Error booting the container: java.lang.RuntimeException: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:161) [jboss-as-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at java.lang.Thread.run(Unknown Source) [rt.jar:1.6.0_30]
Caused by: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:125) [jboss-as-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.HostControllerConfigurationPersister.load(HostControllerConfigurationPersister.java:155) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.DomainModelControllerService.boot(DomainModelControllerService.java:311) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:155) [jboss-as-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
... 1 more
Caused by: java.lang.NullPointerException
at org.jboss.as.host.controller.parsing.HostXml.parseServerSocketBindings(HostXml.java:1156) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.parsing.HostXml.parseServerContent1_1(HostXml.java:1044) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.parsing.HostXml.parseServer(HostXml.java:958) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.parsing.HostXml.parseServers(HostXml.java:935) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.parsing.HostXml.readHostElement_1_1(HostXml.java:398) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:123) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.as.host.controller.parsing.HostXml.readElement(HostXml.java:101) [jboss-as-host-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) [staxmapper-1.1.0.Final-redhat-1.jar:1.1.0.Final-redhat-1]
at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) [staxmapper-1.1.0.Final-redhat-1.jar:1.1.0.Final-redhat-1]
at org.jboss.as.controller.persistence.XmlConfigurationPersister.load(XmlConfigurationPersister.java:117) [jboss-as-controller-7.1.0.Final-redhat-1.jar:7.1.0.Final-redhat-1]
... 4 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-3801) Deleting content in "data/content" breaks JBoss startup
by Wolfgang Knauf (JIRA)
Wolfgang Knauf created AS7-3801:
-----------------------------------
Summary: Deleting content in "data/content" breaks JBoss startup
Key: AS7-3801
URL: https://issues.jboss.org/browse/AS7-3801
Project: Application Server 7
Issue Type: Bug
Components: Server
Affects Versions: 7.1.0.CR1b
Environment: Happens at least with the snapshot of 2012-02-07
Reporter: Wolfgang Knauf
Assignee: Jason Greene
Priority: Minor
Attachments: boot.log
I deployed an app by JSR88 (full sample + deployer attached to AS7-3474 ).
Then I started some vandalism and deleted the directory "standalone\data\content\91\107bf1efaf37237132c7e7ec9b02ec178f4bfe", where the deployed app was found.
This prevented JBoss from starting. Attached is the boot.log. Though it tells that the server was started, it seems to have skipped all modules.
This error message was found:
21:14:48,203 ERROR [org.jboss.as.controller.management-operation] Operation ("add") failed - address: ([("deployment" => "file:/C:/DOCUME~1/Knuffi/LOCALS~1/Temp/___Stateless.ear")]) - failure description: "JBAS015812: No deployment content with hash 91107bf1efaf37237132c7e7ec9b02ec178f4bfe is available in the deployment content repository."
I would expect that it skips the missing deployment, but continues with the rest of the startup process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
[JBoss JIRA] (AS7-4116) removal of unrequested json snippet '"server-groups" => undefined' postpended to operation responses via cli
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4116?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4116:
----------------------------------
Assignee: Brian Stansberry (was: Fernando Nasser)
Fix Version/s: 7.1.2.Final
Component/s: Domain Management
> removal of unrequested json snippet '"server-groups" => undefined' postpended to operation responses via cli
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-4116
> URL: https://issues.jboss.org/browse/AS7-4116
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Simeon Pinder
> Assignee: Brian Stansberry
> Priority: Minor
> Labels: rhq
> Fix For: 7.1.2.Final
>
>
> When submitting operations to as7 via CLI sometimes and extra ["server-groups" => undefined] string is post-pended to the response. The result is still valid JSON it appears, but the results are potentially confusing to external json integrators.
> To reproduce:
> - run AS7 via domain.sh to run HostController.
> - login
> - submit the following operation:
> /host=master/core-service=platform-mbean/type=threading/:read-resource(recursive=true,proxies=false,include-runtime=true,include-defaults=true)
> - Look at the result returned:
> {
> "outcome" => "success",
> "result" => {
> "all-thread-ids" => [
> 2173L,
> 2172L,
> 2171L,
> 51L,
> 50L,
> 49L,
> 48L,
> 45L,
> 44L,
> 43L,
> 42L,
> 41L,
> 40L,
> 39L,
> 38L,
> 37L,
> 36L,
> 35L,
> 34L,
> 33L,
> 32L,
> 31L,
> 30L,
> 29L,
> 28L,
> 27L,
> 26L,
> 25L,
> 24L,
> 23L,
> 22L,
> 21L,
> 19L,
> 18L,
> 17L,
> 16L,
> 15L,
> 14L,
> 13L,
> 12L,
> 11L,
> 8L,
> 4L,
> 3L,
> 2L,
> 1L
> ],
> "thread-contention-monitoring-supported" => true,
> "thread-cpu-time-supported" => true,
> "current-thread-cpu-time-supported" => true,
> "object-monitor-usage-supported" => true,
> "synchronizer-usage-supported" => true,
> "thread-contention-monitoring-enabled" => false,
> "thread-cpu-time-enabled" => true,
> "thread-count" => 46,
> "peak-thread-count" => 49,
> "total-started-thread-count" => 2168L,
> "daemon-thread-count" => 6,
> "current-thread-cpu-time" => 0L,
> "current-thread-user-time" => 0L
> },
> "server-groups" => undefined
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month