[JBoss JIRA] (WFLY-1414) Undertow suppresses JAX-RS error message
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1414?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1414.
----------------------------------
Fix Version/s: 8.0.0.Alpha2
Resolution: Done
> Undertow suppresses JAX-RS error message
> ----------------------------------------
>
> Key: WFLY-1414
> URL: https://issues.jboss.org/browse/WFLY-1414
> Project: WildFly
> Issue Type: Bug
> Components: REST, Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I'm using a snapshot of WildFly 8.0.0.Alpha2 containing Undertow 1.0.0.Alpha17.
> My RESTful Web Service in a war is using an ExceptionMapper (see below) which converts an exception into a 404 error code and also an error message. Now I try to submit a GET request resulting in an exception to be mapped.
> I get the 404 error code, but NOT the error message. Instead I'm getting the contents of the error page which is declared in web.xml for a 404 error. In EAP 6.1.Beta I'm getting the error message produced by the exception mapper.
> The exception mapper class:
> @Provider
> @ApplicationScoped
> public class NotFoundExceptionMapper implements ExceptionMapper<NotFoundException> {
> @Override
> public Response toResponse(NotFoundException e) {
> final String msg = e.getMessage();
> final Response response = Response.status(NOT_FOUND)
> .type(TEXT_PLAIN)
> .entity(msg)
> .build();
> return response;
> }
> }
--
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, 7 months
[JBoss JIRA] (WFLY-1411) UT005013 at the end of an Arquillian test
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-1411?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-1411.
----------------------------------
Fix Version/s: 8.0.0.Alpha2
Resolution: Done
This should be fixed now, feel free to re-open if you still see it.
> UT005013 at the end of an Arquillian test
> -----------------------------------------
>
> Key: WFLY-1411
> URL: https://issues.jboss.org/browse/WFLY-1411
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Alpha2
> Reporter: Juergen Zimmermann
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> I'm using an Alpha 2 snapshot of WildFly. When an Arquillian test ends I'm getting the following stacktrace:
> ...
> 20:07:12,101 INFO [org.jboss.as.server] JBAS018558: Undeployed "shop2.war" (runtime-name: "shop2.war")
> 20:07:12,131 ERROR [io.undertow.request.io] UT005013: An IOException occurred: java.io.IOException: Eine vorhandene Verbindung wurde vom Remotehost geschlossen
> at sun.nio.ch.SocketDispatcher.read0(Native Method) [rt.jar:1.7.0_21]
> at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:43) [rt.jar:1.7.0_21]
> at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:225) [rt.jar:1.7.0_21]
> at sun.nio.ch.IOUtil.read(IOUtil.java:193) [rt.jar:1.7.0_21]
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:359) [rt.jar:1.7.0_21]
> at org.xnio.nio.NioSocketConduit.read(NioSocketConduit.java:262) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:127) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> at io.undertow.server.HttpReadListener.handleEvent(HttpReadListener.java:83)
> at io.undertow.server.HttpReadListener.handleEvent(HttpReadListener.java:43)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:91) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:61) [xnio-api-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:85) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528) [xnio-nio-3.1.0.CR3.jar:3.1.0.CR3]
--
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, 7 months
[JBoss JIRA] (WFLY-1437) Cannot remove JGroups subsystem from managed domain via CLI
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1437?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-1437:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=968815
> Cannot remove JGroups subsystem from managed domain via CLI
> -----------------------------------------------------------
>
> Key: WFLY-1437
> URL: https://issues.jboss.org/browse/WFLY-1437
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Affects Versions: 8.0.0.Alpha1
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 8.0.0.Alpha2
>
>
> Osamu Nagano reports:
> "Description of problem:
> In EAP 6.1 domain mode, try to create a new profile from scratch in CLI. You can add jgroups subsystem but you cannot remove it with an error message.
> In standalone mode and both modes of EAP 6.0.1, you can successfully remove it.
> Steps to Reproduce:
> 1. Start EAP 6.1 in domain mode. The default domain.xml is sufficient.
> 2. Connect to the DC by CLI.
> 3. Execute the following commands in CLI.
> --
> [domain@localhost:9999 /] /profile=test:add()
> [domain@localhost:9999 /] /profile=test/subsystem=jgroups:add(default-stack=udp)
> [domain@localhost:9999 /] /profile=test/subsystem=jgroups:remove()
> --
> Actual results:
> {
> "outcome" => "failed",
> "failure-description" => {"domain-failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"jgroups\")]' not found"},
> "rolled-back" => true
> }
> Expected results:
> {
> "outcome" => "success",
> "result" => undefined,
> "server-groups" => undefined
> }
> "
> I see that the problem exists in WildFly as well.
> The problem is in JGroupsSubsystemRemove:
> ModelNode removeSubsystem = Util.createOperation(REMOVE, PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH));
> context.addStep(removeSubsystem, new OriginalSubsystemRemoveHandler(), OperationContext.Stage.MODEL, true);
> That PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH) is incorrect in a managed domain, as it doesn't include the profile element. It's correct in a standalone server.
> Easy fix.
--
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, 7 months
[JBoss JIRA] (WFLY-1437) Cannot remove JGroups subsystem from managed domain via CLI
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-1437:
--------------------------------------
Summary: Cannot remove JGroups subsystem from managed domain via CLI
Key: WFLY-1437
URL: https://issues.jboss.org/browse/WFLY-1437
Project: WildFly
Issue Type: Bug
Components: Clustering, Domain Management
Affects Versions: 8.0.0.Alpha1
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 8.0.0.Alpha2
Osamu Nagano reports:
"Description of problem:
In EAP 6.1 domain mode, try to create a new profile from scratch in CLI. You can add jgroups subsystem but you cannot remove it with an error message.
In standalone mode and both modes of EAP 6.0.1, you can successfully remove it.
Steps to Reproduce:
1. Start EAP 6.1 in domain mode. The default domain.xml is sufficient.
2. Connect to the DC by CLI.
3. Execute the following commands in CLI.
--
[domain@localhost:9999 /] /profile=test:add()
[domain@localhost:9999 /] /profile=test/subsystem=jgroups:add(default-stack=udp)
[domain@localhost:9999 /] /profile=test/subsystem=jgroups:remove()
--
Actual results:
{
"outcome" => "failed",
"failure-description" => {"domain-failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"jgroups\")]' not found"},
"rolled-back" => true
}
Expected results:
{
"outcome" => "success",
"result" => undefined,
"server-groups" => undefined
}
"
I see that the problem exists in WildFly as well.
The problem is in JGroupsSubsystemRemove:
ModelNode removeSubsystem = Util.createOperation(REMOVE, PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH));
context.addStep(removeSubsystem, new OriginalSubsystemRemoveHandler(), OperationContext.Stage.MODEL, true);
That PathAddress.pathAddress(JGroupsExtension.SUBSYSTEM_PATH) is incorrect in a managed domain, as it doesn't include the profile element. It's correct in a standalone server.
Easy fix.
--
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, 7 months
[JBoss JIRA] (WFLY-1048) Allow hooking into logging subsystem through Management API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1048?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka updated WFLY-1048:
-------------------------------
Assignee: James Perkins (was: Ondrej Zizka)
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFLY-1048
> URL: https://issues.jboss.org/browse/WFLY-1048
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: James Perkins
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
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, 7 months
[JBoss JIRA] (WFLY-1048) Allow hooking into logging subsystem through Management API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1048?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka commented on WFLY-1048:
------------------------------------
This is the latter - appender that pushes.
Log viewer is WFLY-280.
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFLY-1048
> URL: https://issues.jboss.org/browse/WFLY-1048
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
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, 7 months
[JBoss JIRA] (WFLY-1048) Allow hooking into logging subsystem through Management API
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/WFLY-1048?page=com.atlassian.jira.plugin.... ]
Ondrej Zizka reassigned WFLY-1048:
----------------------------------
Assignee: Ondrej Zizka (was: James Perkins)
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFLY-1048
> URL: https://issues.jboss.org/browse/WFLY-1048
> Project: WildFly
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: Ondrej Zizka
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
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, 7 months
[JBoss JIRA] (DROOLS-156) Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-156?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-156:
---------------------------------------
The internal memories for the Eval nodes are created "too lazily".
In fact, if the eval node is not used, the memory will not be created at all,
causing the exception when that memory has to be cleared during the rule
removal process.
It's a RETE construction bug, it will be fixed in 5.6+
> Deletion of EvalConditionNode raises IndexOutOfBoundsException in some combinations
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-156
> URL: https://issues.jboss.org/browse/DROOLS-156
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Philipp Herzig
> Assignee: Mark Proctor
> Attachments: EvalNodeDeletion.zip
>
>
> This bug is a little bit strange to explain. In some combinations the deletion of EvalConditionNodes gives an IndexOutOfBoundsException (see exception below). As consequence the rule is not correctly removed from the internal RETE representation leading to an inconsistent KnowledgeBase.
> I cannot dig it to the exact cause, but from my observation the exception comes from two factors: Number of eval nodes + an arbitrary number of other alpha and beta nodes.
> I attached a dummy mvn project with senseless dummy rules that simulates the exception. The according JUnit is TestClass.java. With the class you can do the following tests:
> 1. Run it as is --> Exception at the primary removal point
> 2. Comment out the addition of "normalRule1" at line 111 --> Exception at the secondary removal point, i.e., one deletion works but adding and deleting again, raises exception
> 3. Comment out the addition of "normalRule2" --> No Exception.
> java.lang.IndexOutOfBoundsException: index 34
> at java.util.concurrent.atomic.AtomicReferenceArray.rawIndex(AtomicReferenceArray.java:31)
> at java.util.concurrent.atomic.AtomicReferenceArray.set(AtomicReferenceArray.java:94)
> at org.drools.common.ConcurrentNodeMemories.clearNodeMemory(ConcurrentNodeMemories.java:44)
> at org.drools.common.AbstractWorkingMemory.clearNodeMemory(AbstractWorkingMemory.java:1038)
> at org.drools.reteoo.EvalConditionNode.doRemove(EvalConditionNode.java:295)
> at org.drools.common.BaseNode.remove(BaseNode.java:115)
> at org.drools.reteoo.RuleTerminalNode.doRemove(RuleTerminalNode.java:360)
> at org.drools.common.BaseNode.remove(BaseNode.java:115)
> at org.drools.reteoo.ReteooBuilder.removeRule(ReteooBuilder.java:253)
> at org.drools.reteoo.ReteooRuleBase.removeRule(ReteooRuleBase.java:459)
> at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1099)
> at org.drools.common.AbstractRuleBase.removeRule(AbstractRuleBase.java:1077)
> at org.drools.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:207)
> at code.RuleEngine.deleteRule(RuleEngine.java:272)
> at test.TestClass.test(TestClass.java:122)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
--
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, 7 months