[JBoss JIRA] (RF-13674) a4j:push broken on WebLogic 12c in Chrome
by Val Blant (JIRA)
[ https://issues.jboss.org/browse/RF-13674?page=com.atlassian.jira.plugin.s... ]
Val Blant updated RF-13674:
---------------------------
Description:
<a4j:push /> works properly on Tomcat 7, but fails on WebLogic 12c in Chrome (Firefox works fine).
{code:title=Page.xhtml|borderStyle=solid}
<a4j:push address="systemLinks" >
<a4j:ajax event="dataavailable" render="systemLinksPanel" />
</a4j:push>
<a4j:outputPanel id="systemLinksPanel">
stuff here
</a4j:outputPanel>
{code}
{code:title=Java Code}
TopicKey topicKey = new TopicKey("systemLinks");
TopicsContext topicsContext = TopicsContext.lookup();
topicsContext.publish(topicKey, "fly, you fools!");
{code}
On Tomcat 7 this work perfectly, and always refreshes '_systemLinksPanel_' when data is published.
On Weblogic 12c the data is not flushed correctly. If you use Wireshark, you'd see the following response coming back from the server:
{panel:title=Tomcat 7}
3b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
0
{panel}
{panel:title=Weblogic 12c}
003b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
{panel}
*Note the missing zero terminator line in the WebLogic response!*
I narrowed down the problem to the following:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
MessageDataScriptString serializedMessages = (MessageDataScriptString) event.getMessage();
getSession().clearBroadcastedMessages(serializedMessages.getLastSequenceNumber());
hasActiveBroadcaster = false;
if (isPolling()) {
event.getResource().resume(); // <= THIS LINE
} else {
postMessages();
}
}
{code}
There is nothing wrong with this in principle, but it does not work due to a bug in Atmosphere 0.8.4. Calling _AtmosphereResource.resume()_ at this point seems reasonable, since it is supposed to properly finish/commit the _HttpServletResponse_. However, this does not work on WebLogic 12c and leads to incorrectly flushed data demonstrated above.
The underlying problem seems to be the fact that _AtmosphereResource.resume()_ method interrupts the thread which flushed the socket Writer before a call to _asyncContext.complete()_ is made:
{code}
public AtmosphereResource resume() {
....
if (!b.isDestroyed()) {
b.removeAtmosphereResource(event.getResource());
}
....
asyncSupport.action(this); // <= This is where asyncContext.complete() is called
}
{code}
I have verified that calling _asyncContext.complete()_ before we clean up Atmosphere resources fixes the problem.
Here's the fix, which needs to go into _RequestImpl.onBroadcast_:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
..............
if (isPolling()) {
// This is the workaround. Completing AsyncContext before cleaning up Atmosphere resources
// seems to make this work everywhere.
//
AsyncContext asyncContext = (AsyncContext)
event
.getResource()
.getRequest()
.getAttribute("org.atmosphere.container.asyncContext");
if ( asyncContext != null ) {
asyncContext.complete();
}
event.getResource().resume();
} else {
postMessages();
}
}
..............
{code}
I am attaching a very simple WAR file that demonstrates the problem clearly. The demo app does not use Richfaces, b/c I wanted to remove all unnecessary complexity. Instead I created a couple of simple classes that mimic the behavior of _org.richfaces.webapp.PushHandlerFilter_ and _org.richfaces.application.push.impl.RequestImpl_. In the demo app, _MeteorRequest = RequestImpl_, which is where the fix needs to go.
Please note that this issue is fixed in Atmosphere 2.1. I ran the demo jar with v2.1.5, and it works correctly, so the easiest fix on the RichFaces side could be to simply upgrade the underlying Atmosphere framework. The API differences, at least as far as the PushHandlerFilter is concerned are minimal.
Now, the reason why only Chrome is effected has to do with processing of chunked responses by the XMLHttpRequest. Unlike other browsers, Chrome is not capable of handling improperly terminated chunked responses. So:
{noformat}
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Date: Wed, 18 Jun 2014 05:37:55 GMT
Pragma: no-cache
Transfer-Encoding: chunked <<--- THIS IS IMPORTANT
Content-Type: text/plain
Expires: -1
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
X-Powered-By: Servlet/3.0 JSP/2.2
0841
<!-- ---------------------------------------------------------------- http://github.com/Atmosphere ------------------------------------------------------------------------ -->
<!-- Welcome to the Atmosphere Framework. To work with all the browsers when suspending connection, Atmosphere must output some data to makes WebKit based browser working.-->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------001c
Wed Jun 18 13:37:57 CST 201
<<--- MISSING 0 TERMINATOR
{noformat}
This can be fixed by explicitly setting Content-Length in the response, as per these discussions:
http://stackoverflow.com/questions/22219565/iis-chrome-failed-to-load-res...
http://www.rahulsingla.com/blog/2010/06/asp-net-sets-the-transfer-encodin...
However, that does not seem to be feasible here, since we must reply with a header of known length, followed by the data of unknown length.
was:
<a4j:push /> works properly on Tomcat 7, but fails on WebLogic 12c in Chrome (Firefox works fine).
{code:title=Page.xhtml|borderStyle=solid}
<a4j:push address="systemLinks" >
<a4j:ajax event="dataavailable" render="systemLinksPanel" />
</a4j:push>
<a4j:outputPanel id="systemLinksPanel">
stuff here
</a4j:outputPanel>
{code}
{code:title=Java Code}
TopicKey topicKey = new TopicKey("systemLinks");
TopicsContext topicsContext = TopicsContext.lookup();
topicsContext.publish(topicKey, "fly, you fools!");
{code}
On Tomcat 7 this work perfectly, and always refreshes '_systemLinksPanel_' when data is published.
On Weblogic 12c the data is not flushed correctly. If you use Wireshark, you'd see the following response coming back from the server:
{panel:title=Tomcat 7}
3b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
0
{panel}
{panel:title=Weblogic 12c}
003b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
{panel}
*Note the missing zero terminator line in the WebLogic response!*
I narrowed down the problem to the following:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
MessageDataScriptString serializedMessages = (MessageDataScriptString) event.getMessage();
getSession().clearBroadcastedMessages(serializedMessages.getLastSequenceNumber());
hasActiveBroadcaster = false;
if (isPolling()) {
event.getResource().resume(); // <= THIS LINE
} else {
postMessages();
}
}
{code}
There is nothing wrong with this in principle, but it does not work due to a bug in Atmosphere 0.8.4. Calling _AtmosphereResource.resume()_ at this point seems reasonable, since it is supposed to properly finish/commit the _HttpServletResponse_. However, this does not work on WebLogic 12c and leads to incorrectly flushed data demonstrated above.
The underlying problem seems to be the fact that _AtmosphereResource.resume()_ method interrupts the thread which flushed the socket Writer before a call to _asyncContext.complete()_ is made:
{code}
public AtmosphereResource resume() {
....
if (!b.isDestroyed()) {
b.removeAtmosphereResource(event.getResource());
}
....
asyncSupport.action(this); // <= This is where asyncContext.complete() is called
}
{code}
I have verified that calling _asyncContext.complete()_ before we clean up Atmosphere resources fixes the problem.
Here's the fix, which needs to go into _RequestImpl.onBroadcast_:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
..............
if (isPolling()) {
// This is the workaround. Completing AsyncContext before cleaning up Atmosphere resources
// seems to make this work everywhere.
//
AsyncContext asyncContext = (AsyncContext)
event
.getResource()
.getRequest()
.getAttribute("org.atmosphere.container.asyncContext");
if ( asyncContext != null ) {
asyncContext.complete();
}
event.getResource().resume();
} else {
postMessages();
}
}
..............
{code}
I am attaching a very simple WAR file that demonstrates the problem clearly. The demo app does not use Richfaces, b/c I wanted to remove all unnecessary complexity. Instead I created a couple of simple classes that mimic the behavior of _org.richfaces.webapp.PushHandlerFilter_ and _org.richfaces.application.push.impl.RequestImpl_. In the demo app, _MeteorRequest = RequestImpl_, which is where the fix needs to go.
Please note that according to the Atmosphere author, this problem is fixed in 2.1 branch. Here's the discussion: https://groups.google.com/forum/#!topic/atmosphere-framework/KCKlSmbMrRo
Now, the reason why only Chrome is effected has to do with processing of chunked responses by the XMLHttpRequest. Unlike other browsers, Chrome is not capable of handling improperly terminated chunked responses. So:
{noformat}
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Date: Wed, 18 Jun 2014 05:37:55 GMT
Pragma: no-cache
Transfer-Encoding: chunked <<--- THIS IS IMPORTANT
Content-Type: text/plain
Expires: -1
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
X-Powered-By: Servlet/3.0 JSP/2.2
0841
<!-- ---------------------------------------------------------------- http://github.com/Atmosphere ------------------------------------------------------------------------ -->
<!-- Welcome to the Atmosphere Framework. To work with all the browsers when suspending connection, Atmosphere must output some data to makes WebKit based browser working.-->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------001c
Wed Jun 18 13:37:57 CST 201
<<--- MISSING 0 TERMINATOR
{noformat}
This can be fixed by explicitly setting Content-Length in the response, as per these discussions:
http://stackoverflow.com/questions/22219565/iis-chrome-failed-to-load-res...
http://www.rahulsingla.com/blog/2010/06/asp-net-sets-the-transfer-encodin...
However, that does not seem to be feasible here, since we must reply with a header of known length, followed by the data of unknown length.
> a4j:push broken on WebLogic 12c in Chrome
> -----------------------------------------
>
> Key: RF-13674
> URL: https://issues.jboss.org/browse/RF-13674
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 4.2.0.Final
> Environment: WebLogic 12c
> Reporter: Val Blant
> Attachments: atmosphere-weblogic12c-bug-0.8.4-sources.jar, atmosphere-weblogic12c-bug-0.8.4.war, RichFacesPushFixFilter.java
>
>
> <a4j:push /> works properly on Tomcat 7, but fails on WebLogic 12c in Chrome (Firefox works fine).
> {code:title=Page.xhtml|borderStyle=solid}
> <a4j:push address="systemLinks" >
> <a4j:ajax event="dataavailable" render="systemLinksPanel" />
> </a4j:push>
>
> <a4j:outputPanel id="systemLinksPanel">
> stuff here
> </a4j:outputPanel>
> {code}
> {code:title=Java Code}
> TopicKey topicKey = new TopicKey("systemLinks");
> TopicsContext topicsContext = TopicsContext.lookup();
> topicsContext.publish(topicKey, "fly, you fools!");
> {code}
> On Tomcat 7 this work perfectly, and always refreshes '_systemLinksPanel_' when data is published.
> On Weblogic 12c the data is not flushed correctly. If you use Wireshark, you'd see the following response coming back from the server:
> {panel:title=Tomcat 7}
> 3b
> <"topic":"systemLinks","data":"fly, you fools!","number":0>
> 0
> {panel}
> {panel:title=Weblogic 12c}
> 003b
> <"topic":"systemLinks","data":"fly, you fools!","number":0>
> {panel}
> *Note the missing zero terminator line in the WebLogic response!*
> I narrowed down the problem to the following:
> {code:title=org.richfaces.application.push.impl.RequestImpl}
> public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
> MessageDataScriptString serializedMessages = (MessageDataScriptString) event.getMessage();
> getSession().clearBroadcastedMessages(serializedMessages.getLastSequenceNumber());
> hasActiveBroadcaster = false;
> if (isPolling()) {
> event.getResource().resume(); // <= THIS LINE
> } else {
> postMessages();
> }
> }
> {code}
> There is nothing wrong with this in principle, but it does not work due to a bug in Atmosphere 0.8.4. Calling _AtmosphereResource.resume()_ at this point seems reasonable, since it is supposed to properly finish/commit the _HttpServletResponse_. However, this does not work on WebLogic 12c and leads to incorrectly flushed data demonstrated above.
> The underlying problem seems to be the fact that _AtmosphereResource.resume()_ method interrupts the thread which flushed the socket Writer before a call to _asyncContext.complete()_ is made:
> {code}
> public AtmosphereResource resume() {
> ....
> if (!b.isDestroyed()) {
> b.removeAtmosphereResource(event.getResource());
> }
> ....
> asyncSupport.action(this); // <= This is where asyncContext.complete() is called
> }
> {code}
> I have verified that calling _asyncContext.complete()_ before we clean up Atmosphere resources fixes the problem.
> Here's the fix, which needs to go into _RequestImpl.onBroadcast_:
> {code:title=org.richfaces.application.push.impl.RequestImpl}
> public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
> ..............
> if (isPolling()) {
> // This is the workaround. Completing AsyncContext before cleaning up Atmosphere resources
> // seems to make this work everywhere.
> //
> AsyncContext asyncContext = (AsyncContext)
> event
> .getResource()
> .getRequest()
> .getAttribute("org.atmosphere.container.asyncContext");
> if ( asyncContext != null ) {
> asyncContext.complete();
> }
> event.getResource().resume();
> } else {
> postMessages();
> }
> }
> ..............
> {code}
> I am attaching a very simple WAR file that demonstrates the problem clearly. The demo app does not use Richfaces, b/c I wanted to remove all unnecessary complexity. Instead I created a couple of simple classes that mimic the behavior of _org.richfaces.webapp.PushHandlerFilter_ and _org.richfaces.application.push.impl.RequestImpl_. In the demo app, _MeteorRequest = RequestImpl_, which is where the fix needs to go.
> Please note that this issue is fixed in Atmosphere 2.1. I ran the demo jar with v2.1.5, and it works correctly, so the easiest fix on the RichFaces side could be to simply upgrade the underlying Atmosphere framework. The API differences, at least as far as the PushHandlerFilter is concerned are minimal.
> Now, the reason why only Chrome is effected has to do with processing of chunked responses by the XMLHttpRequest. Unlike other browsers, Chrome is not capable of handling improperly terminated chunked responses. So:
> {noformat}
> HTTP/1.1 200 OK
> Cache-Control: no-store, no-cache, must-revalidate
> Date: Wed, 18 Jun 2014 05:37:55 GMT
> Pragma: no-cache
> Transfer-Encoding: chunked <<--- THIS IS IMPORTANT
> Content-Type: text/plain
> Expires: -1
> Access-Control-Allow-Credentials: true
> Access-Control-Allow-Origin: *
> X-Powered-By: Servlet/3.0 JSP/2.2
> 0841
> <!-- ---------------------------------------------------------------- http://github.com/Atmosphere ------------------------------------------------------------------------ -->
> <!-- Welcome to the Atmosphere Framework. To work with all the browsers when suspending connection, Atmosphere must output some data to makes WebKit based browser working.-->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------001c
> Wed Jun 18 13:37:57 CST 201
> <<--- MISSING 0 TERMINATOR
> {noformat}
> This can be fixed by explicitly setting Content-Length in the response, as per these discussions:
> http://stackoverflow.com/questions/22219565/iis-chrome-failed-to-load-res...
> http://www.rahulsingla.com/blog/2010/06/asp-net-sets-the-transfer-encodin...
> However, that does not seem to be feasible here, since we must reply with a header of known length, followed by the data of unknown length.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13660:
------------------------------------
The SystemEventListener is called twice, because it is present in two jars in the test deployment:
{code}
{lib/
├── ...
├── richfaces-core-4.5.0-SNAPSHOT.jar
├── richfaces.jar
├── ...
{code}
I believe one of these jars is the jar created dynamically in the FrameworkDeployment class, and the other is pulled in transitively from an explicitly stated dependency.
> RichFaces 4.5 integration tests - error after test execution
> ------------------------------------------------------------
>
> Key: RF-13660
> URL: https://issues.jboss.org/browse/RF-13660
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 4.5.0.Alpha2
> Environment: AS: Wildfly
> Browser: PhantomJS
> Reporter: Matej Novotny
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
>
> This issue originated from RF-13591.
> There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/...].
> The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines.
> Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/...].
> The exception in server console is:
> {code}
> 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException
> at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:]
> at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:]
> at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final]
> at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (RF-13674) a4j:push broken on WebLogic 12c in Chrome
by Val Blant (JIRA)
[ https://issues.jboss.org/browse/RF-13674?page=com.atlassian.jira.plugin.s... ]
Val Blant updated RF-13674:
---------------------------
Summary: a4j:push broken on WebLogic 12c in Chrome (was: a4j:push broken on WebLogic 12c)
Description:
<a4j:push /> works properly on Tomcat 7, but fails on WebLogic 12c in Chrome (Firefox works fine).
{code:title=Page.xhtml|borderStyle=solid}
<a4j:push address="systemLinks" >
<a4j:ajax event="dataavailable" render="systemLinksPanel" />
</a4j:push>
<a4j:outputPanel id="systemLinksPanel">
stuff here
</a4j:outputPanel>
{code}
{code:title=Java Code}
TopicKey topicKey = new TopicKey("systemLinks");
TopicsContext topicsContext = TopicsContext.lookup();
topicsContext.publish(topicKey, "fly, you fools!");
{code}
On Tomcat 7 this work perfectly, and always refreshes '_systemLinksPanel_' when data is published.
On Weblogic 12c the data is not flushed correctly. If you use Wireshark, you'd see the following response coming back from the server:
{panel:title=Tomcat 7}
3b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
0
{panel}
{panel:title=Weblogic 12c}
003b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
{panel}
*Note the missing zero terminator line in the WebLogic response!*
I narrowed down the problem to the following:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
MessageDataScriptString serializedMessages = (MessageDataScriptString) event.getMessage();
getSession().clearBroadcastedMessages(serializedMessages.getLastSequenceNumber());
hasActiveBroadcaster = false;
if (isPolling()) {
event.getResource().resume(); // <= THIS LINE
} else {
postMessages();
}
}
{code}
There is nothing wrong with this in principle, but it does not work due to a bug in Atmosphere 0.8.4. Calling _AtmosphereResource.resume()_ at this point seems reasonable, since it is supposed to properly finish/commit the _HttpServletResponse_. However, this does not work on WebLogic 12c and leads to incorrectly flushed data demonstrated above.
The underlying problem seems to be the fact that _AtmosphereResource.resume()_ method interrupts the thread which flushed the socket Writer before a call to _asyncContext.complete()_ is made:
{code}
public AtmosphereResource resume() {
....
if (!b.isDestroyed()) {
b.removeAtmosphereResource(event.getResource());
}
....
asyncSupport.action(this); // <= This is where asyncContext.complete() is called
}
{code}
I have verified that calling _asyncContext.complete()_ before we clean up Atmosphere resources fixes the problem.
Here's the fix, which needs to go into _RequestImpl.onBroadcast_:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
..............
if (isPolling()) {
// This is the workaround. Completing AsyncContext before cleaning up Atmosphere resources
// seems to make this work everywhere.
//
AsyncContext asyncContext = (AsyncContext)
event
.getResource()
.getRequest()
.getAttribute("org.atmosphere.container.asyncContext");
if ( asyncContext != null ) {
asyncContext.complete();
}
event.getResource().resume();
} else {
postMessages();
}
}
..............
{code}
I am attaching a very simple WAR file that demonstrates the problem clearly. The demo app does not use Richfaces, b/c I wanted to remove all unnecessary complexity. Instead I created a couple of simple classes that mimic the behavior of _org.richfaces.webapp.PushHandlerFilter_ and _org.richfaces.application.push.impl.RequestImpl_. In the demo app, _MeteorRequest = RequestImpl_, which is where the fix needs to go.
Please note that according to the Atmosphere author, this problem is fixed in 2.1 branch. Here's the discussion: https://groups.google.com/forum/#!topic/atmosphere-framework/KCKlSmbMrRo
Now, the reason why only Chrome is effected has to do with processing of chunked responses by the XMLHttpRequest. Unlike other browsers, Chrome is not capable of handling improperly terminated chunked responses. So:
{noformat}
HTTP/1.1 200 OK
Cache-Control: no-store, no-cache, must-revalidate
Date: Wed, 18 Jun 2014 05:37:55 GMT
Pragma: no-cache
Transfer-Encoding: chunked <<--- THIS IS IMPORTANT
Content-Type: text/plain
Expires: -1
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
X-Powered-By: Servlet/3.0 JSP/2.2
0841
<!-- ---------------------------------------------------------------- http://github.com/Atmosphere ------------------------------------------------------------------------ -->
<!-- Welcome to the Atmosphere Framework. To work with all the browsers when suspending connection, Atmosphere must output some data to makes WebKit based browser working.-->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
<!-- --------------------001c
Wed Jun 18 13:37:57 CST 201
<<--- MISSING 0 TERMINATOR
{noformat}
This can be fixed by explicitly setting Content-Length in the response, as per these discussions:
http://stackoverflow.com/questions/22219565/iis-chrome-failed-to-load-res...
http://www.rahulsingla.com/blog/2010/06/asp-net-sets-the-transfer-encodin...
However, that does not seem to be feasible here, since we must reply with a header of known length, followed by the data of unknown length.
was:
<a4j:push /> works properly on Tomcat 7, but fails on WebLogic 12c.
{code:title=Page.xhtml|borderStyle=solid}
<a4j:push address="systemLinks" >
<a4j:ajax event="dataavailable" render="systemLinksPanel" />
</a4j:push>
<a4j:outputPanel id="systemLinksPanel">
stuff here
</a4j:outputPanel>
{code}
{code:title=Java Code}
TopicKey topicKey = new TopicKey("systemLinks");
TopicsContext topicsContext = TopicsContext.lookup();
topicsContext.publish(topicKey, "fly, you fools!");
{code}
On Tomcat 7 this work perfectly, and always refreshes '_systemLinksPanel_' when data is published.
On Weblogic 12c the data is not flushed correctly. If you use Wireshark, you'd see the following response coming back from the server:
{panel:title=Tomcat 7}
3b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
0
{panel}
{panel:title=Weblogic 12c}
003b
<"topic":"systemLinks","data":"fly, you fools!","number":0>
{panel}
*Note the missing zero terminator line in the WebLogic response!*
I narrowed down the problem to the following:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
MessageDataScriptString serializedMessages = (MessageDataScriptString) event.getMessage();
getSession().clearBroadcastedMessages(serializedMessages.getLastSequenceNumber());
hasActiveBroadcaster = false;
if (isPolling()) {
event.getResource().resume(); // <= THIS LINE
} else {
postMessages();
}
}
{code}
There is nothing wrong with this in principle, but it does not work due to a bug in Atmosphere 0.8.4. Calling _AtmosphereResource.resume()_ at this point seems reasonable, since it is supposed to properly finish/commit the _HttpServletResponse_. However, this does not work on WebLogic 12c and leads to incorrectly flushed data demonstrated above.
The underlying problem seems to be the fact that _AtmosphereResource.resume()_ method interrupts the thread which flushed the socket Writer before a call to _asyncContext.complete()_ is made:
{code}
public AtmosphereResource resume() {
....
if (!b.isDestroyed()) {
b.removeAtmosphereResource(event.getResource());
}
....
asyncSupport.action(this); // <= This is where asyncContext.complete() is called
}
{code}
I have verified that calling _asyncContext.complete()_ before we clean up Atmosphere resources fixes the problem.
Here's the fix, which needs to go into _RequestImpl.onBroadcast_:
{code:title=org.richfaces.application.push.impl.RequestImpl}
public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
..............
if (isPolling()) {
// This is the workaround. Completing AsyncContext before cleaning up Atmosphere resources
// seems to make this work everywhere.
//
AsyncContext asyncContext = (AsyncContext)
event
.getResource()
.getRequest()
.getAttribute("org.atmosphere.container.asyncContext");
if ( asyncContext != null ) {
asyncContext.complete();
}
event.getResource().resume();
} else {
postMessages();
}
}
..............
{code}
I am attaching a very simple WAR file that demonstrates the problem clearly. The demo app does not use Richfaces, b/c I wanted to remove all unnecessary complexity. Instead I created a couple of simple classes that mimic the behavior of _org.richfaces.webapp.PushHandlerFilter_ and _org.richfaces.application.push.impl.RequestImpl_. In the demo app, _MeteorRequest = RequestImpl_, which is where the fix needs to go.
Please note that according to the Atmosphere author, this problem is fixed in 2.1 branch. Here's the discussion: https://groups.google.com/forum/#!topic/atmosphere-framework/KCKlSmbMrRo
> a4j:push broken on WebLogic 12c in Chrome
> -----------------------------------------
>
> Key: RF-13674
> URL: https://issues.jboss.org/browse/RF-13674
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-push/poll
> Affects Versions: 4.2.0.Final
> Environment: WebLogic 12c
> Reporter: Val Blant
> Attachments: atmosphere-weblogic12c-bug-0.8.4-sources.jar, atmosphere-weblogic12c-bug-0.8.4.war, RichFacesPushFixFilter.java
>
>
> <a4j:push /> works properly on Tomcat 7, but fails on WebLogic 12c in Chrome (Firefox works fine).
> {code:title=Page.xhtml|borderStyle=solid}
> <a4j:push address="systemLinks" >
> <a4j:ajax event="dataavailable" render="systemLinksPanel" />
> </a4j:push>
>
> <a4j:outputPanel id="systemLinksPanel">
> stuff here
> </a4j:outputPanel>
> {code}
> {code:title=Java Code}
> TopicKey topicKey = new TopicKey("systemLinks");
> TopicsContext topicsContext = TopicsContext.lookup();
> topicsContext.publish(topicKey, "fly, you fools!");
> {code}
> On Tomcat 7 this work perfectly, and always refreshes '_systemLinksPanel_' when data is published.
> On Weblogic 12c the data is not flushed correctly. If you use Wireshark, you'd see the following response coming back from the server:
> {panel:title=Tomcat 7}
> 3b
> <"topic":"systemLinks","data":"fly, you fools!","number":0>
> 0
> {panel}
> {panel:title=Weblogic 12c}
> 003b
> <"topic":"systemLinks","data":"fly, you fools!","number":0>
> {panel}
> *Note the missing zero terminator line in the WebLogic response!*
> I narrowed down the problem to the following:
> {code:title=org.richfaces.application.push.impl.RequestImpl}
> public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
> MessageDataScriptString serializedMessages = (MessageDataScriptString) event.getMessage();
> getSession().clearBroadcastedMessages(serializedMessages.getLastSequenceNumber());
> hasActiveBroadcaster = false;
> if (isPolling()) {
> event.getResource().resume(); // <= THIS LINE
> } else {
> postMessages();
> }
> }
> {code}
> There is nothing wrong with this in principle, but it does not work due to a bug in Atmosphere 0.8.4. Calling _AtmosphereResource.resume()_ at this point seems reasonable, since it is supposed to properly finish/commit the _HttpServletResponse_. However, this does not work on WebLogic 12c and leads to incorrectly flushed data demonstrated above.
> The underlying problem seems to be the fact that _AtmosphereResource.resume()_ method interrupts the thread which flushed the socket Writer before a call to _asyncContext.complete()_ is made:
> {code}
> public AtmosphereResource resume() {
> ....
> if (!b.isDestroyed()) {
> b.removeAtmosphereResource(event.getResource());
> }
> ....
> asyncSupport.action(this); // <= This is where asyncContext.complete() is called
> }
> {code}
> I have verified that calling _asyncContext.complete()_ before we clean up Atmosphere resources fixes the problem.
> Here's the fix, which needs to go into _RequestImpl.onBroadcast_:
> {code:title=org.richfaces.application.push.impl.RequestImpl}
> public synchronized void onBroadcast(AtmosphereResourceEvent<HttpServletRequest, HttpServletResponse> event) {
> ..............
> if (isPolling()) {
> // This is the workaround. Completing AsyncContext before cleaning up Atmosphere resources
> // seems to make this work everywhere.
> //
> AsyncContext asyncContext = (AsyncContext)
> event
> .getResource()
> .getRequest()
> .getAttribute("org.atmosphere.container.asyncContext");
> if ( asyncContext != null ) {
> asyncContext.complete();
> }
> event.getResource().resume();
> } else {
> postMessages();
> }
> }
> ..............
> {code}
> I am attaching a very simple WAR file that demonstrates the problem clearly. The demo app does not use Richfaces, b/c I wanted to remove all unnecessary complexity. Instead I created a couple of simple classes that mimic the behavior of _org.richfaces.webapp.PushHandlerFilter_ and _org.richfaces.application.push.impl.RequestImpl_. In the demo app, _MeteorRequest = RequestImpl_, which is where the fix needs to go.
> Please note that according to the Atmosphere author, this problem is fixed in 2.1 branch. Here's the discussion: https://groups.google.com/forum/#!topic/atmosphere-framework/KCKlSmbMrRo
> Now, the reason why only Chrome is effected has to do with processing of chunked responses by the XMLHttpRequest. Unlike other browsers, Chrome is not capable of handling improperly terminated chunked responses. So:
> {noformat}
> HTTP/1.1 200 OK
> Cache-Control: no-store, no-cache, must-revalidate
> Date: Wed, 18 Jun 2014 05:37:55 GMT
> Pragma: no-cache
> Transfer-Encoding: chunked <<--- THIS IS IMPORTANT
> Content-Type: text/plain
> Expires: -1
> Access-Control-Allow-Credentials: true
> Access-Control-Allow-Origin: *
> X-Powered-By: Servlet/3.0 JSP/2.2
> 0841
> <!-- ---------------------------------------------------------------- http://github.com/Atmosphere ------------------------------------------------------------------------ -->
> <!-- Welcome to the Atmosphere Framework. To work with all the browsers when suspending connection, Atmosphere must output some data to makes WebKit based browser working.-->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------------------------------------------------------------------------------------------------------------------------------------------------------- -->
> <!-- --------------------001c
> Wed Jun 18 13:37:57 CST 201
> <<--- MISSING 0 TERMINATOR
> {noformat}
> This can be fixed by explicitly setting Content-Length in the response, as per these discussions:
> http://stackoverflow.com/questions/22219565/iis-chrome-failed-to-load-res...
> http://www.rahulsingla.com/blog/2010/06/asp-net-sets-the-transfer-encodin...
> However, that does not seem to be feasible here, since we must reply with a header of known length, followed by the data of unknown length.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (RF-13660) RichFaces 4.5 integration tests - error after test execution
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13660?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13660:
------------------------------------
It seems the {{InitializationListener#onStop}} method is called twice.
> RichFaces 4.5 integration tests - error after test execution
> ------------------------------------------------------------
>
> Key: RF-13660
> URL: https://issues.jboss.org/browse/RF-13660
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: build/distribution
> Affects Versions: 4.5.0.Alpha2
> Environment: AS: Wildfly
> Browser: PhantomJS
> Reporter: Matej Novotny
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
>
> This issue originated from RF-13591.
> There is an error in server log after execution of [ITResourceMapping|https://github.com/richfaces/richfaces/blob/4.5.x/core/...].
> The test itself passes (use PhantomJS) and afterwards there is an error in server console. This does not affect the build as everything gets completed however it results in Jenkins job failure on some machines.
> Currently the Jenkins job passes (machine running the tests was changed) but before it was failing after execution of this particular test. See the [Jenkins job resulsts|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/RichFaces/...].
> The exception in server console is:
> {code}
> 12:36:37,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config] (MSC service thread 1-1) Unexpected exception when attempting to tear down the Mojarra runtime: java.lang.NullPointerException
> at org.richfaces.application.ServiceTracker.release(ServiceTracker.java:135) [richfaces.jar:]
> at org.richfaces.application.InitializationListener.onStop(InitializationListener.java:93) [richfaces.jar:]
> at org.richfaces.application.InitializationListener.processEvent(InitializationListener.java:165) [richfaces.jar:]
> at javax.faces.event.SystemEvent.processListener(SystemEvent.java:108) [jboss-jsf-api_2.2_spec-2.2.5.jar:2.2.5]
> at com.sun.faces.application.ApplicationImpl.processListeners(ApplicationImpl.java:2187) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at com.sun.faces.application.ApplicationImpl.invokeListenersFor(ApplicationImpl.java:2163) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at com.sun.faces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:303) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at org.jboss.as.jsf.injection.weld.ForwardingApplication.publishEvent(ForwardingApplication.java:294) [wildfly-jsf-injection-8.0.0.Final.jar:8.0.0.Final]
> at com.sun.faces.config.ConfigureListener.contextDestroyed(ConfigureListener.java:314) [jsf-impl-2.2.5-jbossorg-3.jar:]
> at io.undertow.servlet.core.ApplicationListeners.contextDestroyed(ApplicationListeners.java:185) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.core.DeploymentImpl.destroy(DeploymentImpl.java:216) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.core.DeploymentManagerImpl.undeploy(DeploymentManagerImpl.java:557) [undertow-servlet-1.0.0.Final.jar:1.0.0.Final]
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:117)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stop(UndertowDeploymentService.java:100)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:2056)
> at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:2017)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (RF-13640) Autocomplete with custom layout: cant select item by mouse
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13640?page=com.atlassian.jira.plugin.s... ]
Brian Leathem resolved RF-13640.
--------------------------------
Resolution: Done
Thanks guys, I had tested with {{<span>}} child elements, not tables/rows. Turns out the mouseenter event is fired on the {{<td>}} element, rather than the {{<tr>}} element. I've updated the mouseenter listener to lookup the parent item element and tested the showcase sample on Chrome. Please continue with QA for this issue.
> Autocomplete with custom layout: cant select item by mouse
> ----------------------------------------------------------
>
> Key: RF-13640
> URL: https://issues.jboss.org/browse/RF-13640
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.3.6, 4.5.0.Alpha3
> Environment: Firefox 29.0.1
> Chrome 35.0.1916.114
> Reporter: liumin hu
> Assignee: Brian Leathem
> Labels: needs-backport, needs-qe, regression
> Fix For: 4.3.8, 4.5.0.Alpha3
>
>
> When the autocomplete component is used with a custom layout, n item in the suggestion list can not be selected by mouse, always the first one selected.
> This bug was not observable before 4.3.6.Final.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (RF-13661) De-couple the RichFaces.BaseComponent implementation from its JSF backend
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13661?page=com.atlassian.jira.plugin.s... ]
Brian Leathem edited comment on RF-13661 at 6/18/14 12:44 PM:
--------------------------------------------------------------
I created a branch [RF-13661-standalone-js|https://github.com/richfaces/richfaces/tree/RF-136...] where I added a examples/standalone-js example that can be use to create standalone html pages for various RF components. The jsf pages are stored in the {{jsf}} webapp folder, and the corresponding standalone html page is stored in the {{html}} folder.
Note: the standalone html page is created by deploying the webapp, and viewing a component page in a browser. The html source of the component page is saved as an html file. Path changes are made to the html file to use the js resources of the components directly from the source tree.
----
Merging of this branch is pending discussion at the upcoming f2f meeting.
was (Author: bleathem):
I created a branch [RF-13661-independent-js|https://github.com/richfaces/richfaces/tree/RF-13...] where I added a examples/standalone-js example that can be use to create standalone html pages for various RF components. The jsf pages are stored in the {{jsf}} webapp folder, and the corresponding standalone html page is stored in the {{html}} folder.
Note: the standalone html page is created by deploying the webapp, and viewing a component page in a browser. The html source of the component page is saved as an html file. Path changes are made to the html file to use the js resources of the components directly from the source tree.
----
Merging of this branch is pending discussion at the upcoming f2f meeting.
> De-couple the RichFaces.BaseComponent implementation from its JSF backend
> -------------------------------------------------------------------------
>
> Key: RF-13661
> URL: https://issues.jboss.org/browse/RF-13661
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 4.5-Tracking
>
>
> Investigate whether we can de-couple a {{RichFaces.BaseComponent}} based component from the JSF back-end. The ExtendedDataTable implementation would be a good candidate for this PoC.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (RF-13673) Backport the plain skin fix from RF 5
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13673?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13673:
------------------------------------
Backporting the issue involves cherry-picking the following commits:
{code}
commit 46b03d226ae420bcbc8abd7f79ed5790f2bb6dc4
Author: Brian Leathem <bleathem(a)gmail.com>
Date: Thu Sep 12 16:40:55 2013 -0700
RF-11103: Converted all background-image CSS properties in .ecss files to use the skin.imageUrl method
commit 21a41993bd30d64688c2cf11b667af1edc42c3fe
Author: Brian Leathem <bleathem(a)gmail.com>
Date: Thu Sep 12 16:34:39 2013 -0700
RF-11103: Implemented a skin method to return the image URL, and none for the plain skin
commit 3d58e36885890d3e0a1b51fe6d2e6af13bbd5028
Author: Brian Leathem <bleathem(a)gmail.com>
Date: Tue Sep 10 19:28:37 2013 -0700
RF-11103: Implemented an integration test for richfaces skinning
{code}
However, the cherry-pick is not quite straightforward, as some of the paths have changed, and so some of the changes will have to be applied manually.
> Backport the plain skin fix from RF 5
> -------------------------------------
>
> Key: RF-13673
> URL: https://issues.jboss.org/browse/RF-13673
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: skinning
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: 4.5.0.Alpha3
>
>
> Backport RF-11103.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months