[JBoss JIRA] (WFLY-3623) Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3623?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3623:
-----------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1119531|https://bugzilla.redhat.com/show_bug.cgi?id=1119531] from ASSIGNED to POST
> Spurious ":" in @Resource annotation 'name' value results in invalid binding but no deployment error
> ----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3623
> URL: https://issues.jboss.org/browse/WFLY-3623
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EE
> Affects Versions: JBoss AS7 7.2.0.Final, 8.0.0.Final, 8.1.0.Final
> Reporter: Brian Stansberry
> Assignee: Bartosz Baranowski
> Attachments: 01134324.jar, dumpServices.txt
>
>
> See attached jar for a reproducer. Just deploy it. The jar includes it's own source.
> An @Resource annotation with a spurious ":" in the name attribute value results in an incorrect binding but no deployment failure:
> {code}
> @Resources({
> @Resource(
> // name="java:jboss/ResourceTestEJB", // ==> this works fine
> name="java:jboss:/ResourceTestEJB", // ==> this will not bind the JNDI correctly, and there is no error on deploying EJB
>
> type=com.test.ResourceEJB.class,
> lookup="java:global/01134324/ResourceEJBImpl")
> })
> {code}
> There is no error reported in the log.
> Using jndi-view op in the CLI, I see:
> {code}
> [standalone@localhost:9990 subsystem=naming] :jndi-view
> {
> "outcome" => "success",
> "result" => {
> "java: contexts" => {
> .....
> "java:jboss" => {
> ....
> "java:jboss:" => {"class-name" => "javax.naming.Context"},
> }
> }
> ....
> }
> {code}
> Any time the jndi-view op is run, the following is logged in the server.log:
> {code}
> 10:52:02,985 ERROR [org.jboss.as.naming] (management-handler-thread - 5) WFLYNAM0013: Failed to obtain jndi view value for entry java:jboss:.: javax.naming.NameNotFoundException: jboss: -- service jboss.naming.context.java.jboss.jboss:
> at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:106) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:132) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:47) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:72) [wildfly-naming-9.0.0.Alpha1-SNAPSHOT.jar:9.0.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:603) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:481) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:282) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:277) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1060) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:296) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:165) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:204) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:133) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:154) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_45]
> at javax.security.auth.Subject.doAs(Subject.java:415) [rt.jar:1.7.0_45]
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:150) [wildfly-controller-1.0.0.Alpha2.jar:1.0.0.Alpha2]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:297)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:536)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.1.Final.jar:2.1.1.Final]
> {code}
> If a proper binding can't be done per the annotation value, there should be an exception thrown triggering deployment rollback.
> I'll attach an MSC service dump in case it's useful.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3630) NonPersistentIntervalTimerManagementTestCase fails sometimes
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-3630?page=com.atlassian.jira.plugin.... ]
Frank Langelage commented on WFLY-3630:
---------------------------------------
More information:
I added some log statements to the testcase, in method testSuspendAndTrigger and in Timeout method of the bean.
Usually I see something like this:
07:38:53,024 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) createTimer
07:38:53,040 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) triggerTimer
07:38:53,054 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.IntervalTimerBean] (management-handler-thread - 4) booom: [id=6397e6f9-e7f7-4a84-aa58-d3f9d02d8b43 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.IntervalTimerBean auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@1734190 initialExpiration=Fri Aug 08 07:38:56 CEST 2014 intervalDuration(in milli sec)=3000 nextExpiration=Fri Aug 08 07:38:59 CEST 2014 timerState=IN_TIMEOUT info=NonPersistentIntervalTimerCLITestCase
07:38:53,063 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) suspendTimer
07:38:53,070 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) waitOverTimer
07:38:57,080 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) activateTimer
07:38:57,089 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) waitOnTimeout
07:38:59,038 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.IntervalTimerBean] (EJB default - 7) booom: [id=6397e6f9-e7f7-4a84-aa58-d3f9d02d8b43 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.IntervalTimerBean auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@1734190 initialExpiration=Fri Aug 08 07:38:56 CEST 2014 intervalDuration(in milli sec)=3000 nextExpiration=Fri Aug 08 07:39:02 CEST 2014 timerState=IN_TIMEOUT info=NonPersistentIntervalTimerCLITestCase
But for a failed test I see:
01:08:11,368 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) createTimer
01:08:11,368 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) triggerTimer
01:08:11,368 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.IntervalTimerBean] (management-handler-thread - 3) booom: [id=467f7f53-a6c7-4abe-9d28-63da530eeda6 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.IntervalTimerBean auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@5931ef88 initialExpiration=Fri Aug 08 01:08:14 CEST 2014 intervalDuration(in milli sec)=3000 nextExpiration=Fri Aug 08 01:08:14 CEST 2014 timerState=IN_TIMEOUT info=NonPersistentIntervalTimerCLITestCase
01:08:11,368 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) suspendTimer
01:08:11,368 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) waitOverTimer
01:08:15,410 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) activateTimer
01:08:15,410 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.IntervalTimerBean] (EJB default - 3) booom: [id=467f7f53-a6c7-4abe-9d28-63da530eeda6 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.IntervalTimerBean auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@5931ef88 initialExpiration=Fri Aug 08 01:08:14 CEST 2014 intervalDuration(in milli sec)=3000 nextExpiration=Fri Aug 08 01:08:17 CEST 2014 timerState=IN_TIMEOUT info=NonPersistentIntervalTimerCLITestCase
8:15,410 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase] (main) waitOnTimeout
01:08:18,446 INFO [org.jboss.as.test.integration.ejb.timerservice.mgmt.IntervalTimerBean] (EJB default - 8) booom: [id=467f7f53-a6c7-4abe-9d28-63da530eeda6 timedObjectId=ejb-mgmt-timers.ejb-mgmt-timers.IntervalTimerBean auto-timer?:false persistent?:false timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@5931ef88 initialExpiration=Fri Aug 08 01:08:14 CEST 2014 intervalDuration(in milli sec)=3000 nextExpiration=Fri Aug 08 01:08:20 CEST 2014 timerState=IN_TIMEOUT info=NonPersistentIntervalTimerCLITestCase
Note the initialExpiration and the nextExpiration. When in Timeout, the nextExpiration is already incremented by intervalDuration. But in failing case it's not. Then, when activate happens nextExpiration is in the past and timer fires directly, which makes the testcase fail.
> NonPersistentIntervalTimerManagementTestCase fails sometimes
> ------------------------------------------------------------
>
> Key: WFLY-3630
> URL: https://issues.jboss.org/browse/WFLY-3630
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 9.0.0.Beta1
> Environment: Windows 7 SP1, Oracle JDK 1.7.0_60
> Reporter: Frank Langelage
> Assignee: Jason Greene
>
> Testcase org.jboss.as.test.integration.ejb.timerservice.mgmt.NonPersistentIntervalTimerManagementTestCase fails sometimes for me when running build with all tests on Windows machine. I never saw this failure on my Solaris box using the same JDK version. And somehow the appearance of the failure seem to be related to the execution time.
> Executing the testsuite during the day does not show me this error. Only in the very late evening / early morning hours the error appeared. (All related to Central European Summer time in my case.)
> I added some debug output an saw, that, in case of failure, after "activateTimer" the timer fires immediately so that there is one timeout too much then. The initial timeout time of the timer is passed, when it's suspended. When activated it seems to make good for the missed timeout sometimes.
> The persistent version of this testcase located in the same package with exactly same logic never fails for me.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp
by Dmitry Lisovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ]
Dmitry Lisovsky commented on WFLY-3385:
---------------------------------------
The current issue is not fixed in 1.1.0.Beta3.
Reported UNDERTOW-295.
> when using jsp:include the jsp:param being encoded at the included jsp
> ----------------------------------------------------------------------
>
> Key: WFLY-3385
> URL: https://issues.jboss.org/browse/WFLY-3385
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> I have JSP A that includes JSP B like this:
> <jsp:include page="../anotherFolder/B.jsp">
> <jsp:param name="pathToRootContext" value='../' />
> </jsp:include>
> In JSP B i have the following:
> String pathToRootContext = request.getParameter("pathToRootContext");
> The value i get in the pathToRootContext is "..%2f"
> I tried the following but it didn't help:
> <servlet-container name="default" default-encoding="UTF-8">
> <jsp-config development="true" java-encoding="UTF-8"/>
> </servlet-container>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFCORE-40) Deadlock while logging
by Stefan Schueffler (JIRA)
[ https://issues.jboss.org/browse/WFCORE-40?page=com.atlassian.jira.plugin.... ]
Stefan Schueffler commented on WFCORE-40:
-----------------------------------------
Every time this happens to us, one thread is blocked in {code}Throwable.fillInStackTrace(){code}.
I'll try to get a reproducable deployment / configuration, and i'll try whether this only happens in our jdk 1.7.0_45 or also in never releases of jdk.
> Deadlock while logging
> ----------------------
>
> Key: WFCORE-40
> URL: https://issues.jboss.org/browse/WFCORE-40
> Project: WildFly Core
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Logging
> Environment: CentOS 6.5 64bit, java7u45 64bit (and 32 bit, the same behavior)
> Reporter: Stefan Schueffler
> Assignee: James Perkins
> Priority: Critical
>
> We hit really often a deadlock? in org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> Even if the "StdioContext" belongs to Jboss-Logging, the problem occurs in our production wildfly installation twice to 4 times a day - all threads are deadlocking while trying to log.debug, log.error, or (sometimes) System.out.println from our application code, and wildfly does not respond anymore...
> The partial stacktrace always is similar to this one:
> {code}
> "default task-64" prio=10 tid=0x4c539c00 nid=0x5ef9 waiting for monitor entry [0x495e0000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at java.io.PrintStream.println(PrintStream.java:806)
> - waiting to lock <0x5ee0adf8> (a java.io.PrintStream)
> at org.jboss.stdio.StdioContext$DelegatingPrintStream.println(StdioContext.java:474)
> at jsp.communications.statuschange.selectStatus_jsp._jspService(selectStatus_jsp.java:413)
> at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:69)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:82)
> {code}
> While investigating the StdioContext - class, i really wondered whether the used "locking/checking by using a threadlocal" could have worked in a multi-threaded environment (it should have the very same problems as every "double checking" algorithm without proper synchronization).
> If all threads are hanging in this particular lock, only a full wildfly-restart recovers in our case.
> My preferred solution would be a rework of the used org.jboss.stdio. classes, as the used idioms of ThreadLocals for reentrant-checks are at least highly unusual?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp
by Gael Marziou (JIRA)
[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ]
Gael Marziou edited comment on WFLY-3385 at 8/8/14 2:35 AM:
------------------------------------------------------------
I'm concerned that this bug may not be reviewed anymore by team because it is marked as resolved so maybe opening a new one against undertow may help to raise visibility too.
This NPE happens on a line that was changed in June.
According to SessionListenerBridge.java's history, this NPE should not occur in 1.1.0.Beta3
was (Author: gmarziou):
I'm concerned that this bug may not be reviewed anymore by team because it is marked as resolved so maybe opening a new one against undertow may help to raise visibility too.
This NPE happens on a line that was changed in June.
According to this SessionListenerBridge.java history, this NPE should not occur in 1.1.0.Beta3
> when using jsp:include the jsp:param being encoded at the included jsp
> ----------------------------------------------------------------------
>
> Key: WFLY-3385
> URL: https://issues.jboss.org/browse/WFLY-3385
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> I have JSP A that includes JSP B like this:
> <jsp:include page="../anotherFolder/B.jsp">
> <jsp:param name="pathToRootContext" value='../' />
> </jsp:include>
> In JSP B i have the following:
> String pathToRootContext = request.getParameter("pathToRootContext");
> The value i get in the pathToRootContext is "..%2f"
> I tried the following but it didn't help:
> <servlet-container name="default" default-encoding="UTF-8">
> <jsp-config development="true" java-encoding="UTF-8"/>
> </servlet-container>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp
by Gael Marziou (JIRA)
[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ]
Gael Marziou commented on WFLY-3385:
------------------------------------
I'm concerned that this bug may not be reviewed anymore by team because it is marked as resolved so maybe opening a new one against undertow may help to raise visibility too.
This NPE happens on a line that was changed in June.
According to this SessionListenerBridge.java history, this NPE should not occur in 1.1.0.Beta3
> when using jsp:include the jsp:param being encoded at the included jsp
> ----------------------------------------------------------------------
>
> Key: WFLY-3385
> URL: https://issues.jboss.org/browse/WFLY-3385
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> I have JSP A that includes JSP B like this:
> <jsp:include page="../anotherFolder/B.jsp">
> <jsp:param name="pathToRootContext" value='../' />
> </jsp:include>
> In JSP B i have the following:
> String pathToRootContext = request.getParameter("pathToRootContext");
> The value i get in the pathToRootContext is "..%2f"
> I tried the following but it didn't help:
> <servlet-container name="default" default-encoding="UTF-8">
> <jsp-config development="true" java-encoding="UTF-8"/>
> </servlet-container>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3722) IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/WFLY-3722?page=com.atlassian.jira.plugin.... ]
Brian Leathem edited comment on WFLY-3722 at 8/8/14 2:07 AM:
-------------------------------------------------------------
Thanks [~stuartdouglas]. Is there anything that can be done to suppress the exception in the mean time? It gets quite verbose after a few page navigations.
was (Author: bleathem):
Thanks [~stuartdouglas]. Is there anything that can be done to suppress the exception in the mean time? It gets quite vebose after a few page navigations.
> IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
> --------------------------------------------------------------------------
>
> Key: WFLY-3722
> URL: https://issues.jboss.org/browse/WFLY-3722
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Brian Leathem
> Assignee: Stuart Douglas
>
> While working on RF-13753 I upgraded the RichFaces Atmosphere dependency from 1.0.x to 2.2.0. All is functional after the upgrade except an IOException is thrown when I navigate away from a page using Atmosphere (via the RichFaces push component).
> The stacktrace looks like:
> {code}
> 16:35:27,083 ERROR [stderr] (default task-39) Exception in thread "default task-39" java.lang.RuntimeException: java.io.IOException: Broken pipe
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:517)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.lang.Thread.run(Thread.java:745)
> 16:35:27,084 ERROR [stderr] (default task-39) Caused by: java.io.IOException: Broken pipe
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:531)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:256)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:625)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
> 16:35:27,086 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
> 16:35:27,086 ERROR [stderr] (default task-39) ... 6 more
> {code}
> There are no richfaces not atmosphere classes in the stacktrace, so I'm not sure how to narrow the problem down.
> A reproducer can be found by building RichFaces from the branch:
> https://github.com/richfaces/richfaces/tree/RF-13753-upgrade-atmosphere
> and deploying the showcase. The push component sample triggers the error when you navigate away from the page:
> http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=push&s...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3722) IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/WFLY-3722?page=com.atlassian.jira.plugin.... ]
Brian Leathem commented on WFLY-3722:
-------------------------------------
Thanks [~stuartdouglas]. Is there anything that can be done to suppress the exception in the mean time? It gets quite vebose after a few page navigations.
> IOException: Broken pipe thrown when using RichFaces with Atmosphere 2.2.0
> --------------------------------------------------------------------------
>
> Key: WFLY-3722
> URL: https://issues.jboss.org/browse/WFLY-3722
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Reporter: Brian Leathem
> Assignee: Stuart Douglas
>
> While working on RF-13753 I upgraded the RichFaces Atmosphere dependency from 1.0.x to 2.2.0. All is functional after the upgrade except an IOException is thrown when I navigate away from a page using Atmosphere (via the RichFaces push component).
> The stacktrace looks like:
> {code}
> 16:35:27,083 ERROR [stderr] (default task-39) Exception in thread "default task-39" java.lang.RuntimeException: java.io.IOException: Broken pipe
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:527)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$3.run(AsyncContextImpl.java:294)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$6.run(AsyncContextImpl.java:432)
> 16:35:27,083 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.AsyncContextImpl$TaskDispatchRunnable.run(AsyncContextImpl.java:517)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 16:35:27,084 ERROR [stderr] (default task-39) at java.lang.Thread.run(Thread.java:745)
> 16:35:27,084 ERROR [stderr] (default task-39) Caused by: java.io.IOException: Broken pipe
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.FileDispatcherImpl.write0(Native Method)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47)
> 16:35:27,084 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.IOUtil.write(IOUtil.java:65)
> 16:35:27,085 ERROR [stderr] (default task-39) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:487)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.nio.NioSocketConduit.write(NioSocketConduit.java:150)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:531)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.conduits.ChunkedStreamSinkConduit.flush(ChunkedStreamSinkConduit.java:256)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.conduits.ConduitStreamSinkChannel.flush(ConduitStreamSinkChannel.java:162)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.channels.DetachableStreamSinkChannel.flush(DetachableStreamSinkChannel.java:100)
> 16:35:27,085 ERROR [stderr] (default task-39) at org.xnio.channels.Channels.flushBlocking(Channels.java:63)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.ServletOutputStreamImpl.close(ServletOutputStreamImpl.java:625)
> 16:35:27,085 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.closeStreamAndWriter(HttpServletResponseImpl.java:451)
> 16:35:27,086 ERROR [stderr] (default task-39) at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:525)
> 16:35:27,086 ERROR [stderr] (default task-39) ... 6 more
> {code}
> There are no richfaces not atmosphere classes in the stacktrace, so I'm not sure how to narrow the problem down.
> A reproducer can be found by building RichFaces from the branch:
> https://github.com/richfaces/richfaces/tree/RF-13753-upgrade-atmosphere
> and deploying the showcase. The push component sample triggers the error when you navigate away from the page:
> http://localhost:8080/showcase/richfaces/component-sample.jsf?demo=push&s...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3385) when using jsp:include the jsp:param being encoded at the included jsp
by Dmitry Lisovsky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3385?page=com.atlassian.jira.plugin.... ]
Dmitry Lisovsky commented on WFLY-3385:
---------------------------------------
We tried to replace undertow-core, undertow-servlet and undertow-websockets-jsr with 1.1.0.Beta5 and 1.1.0.Beta6. The result is the same - NPE in undertow class: http://pastebin.com/mp6rT2we
In the 1.0.15.Final, which is included in 8.1.0.Final it does not happens.
Should we report this to the undertow project?
> when using jsp:include the jsp:param being encoded at the included jsp
> ----------------------------------------------------------------------
>
> Key: WFLY-3385
> URL: https://issues.jboss.org/browse/WFLY-3385
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.CR2
> Reporter: roy mizrachi
> Assignee: Stuart Douglas
> Fix For: 9.0.0.Beta1
>
>
> I have JSP A that includes JSP B like this:
> <jsp:include page="../anotherFolder/B.jsp">
> <jsp:param name="pathToRootContext" value='../' />
> </jsp:include>
> In JSP B i have the following:
> String pathToRootContext = request.getParameter("pathToRootContext");
> The value i get in the pathToRootContext is "..%2f"
> I tried the following but it didn't help:
> <servlet-container name="default" default-encoding="UTF-8">
> <jsp-config development="true" java-encoding="UTF-8"/>
> </servlet-container>
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months