[JBoss JIRA] (RF-13674) a4j:push broken on WebLogic 12c
by Val Blant (JIRA)
[ https://issues.jboss.org/browse/RF-13674?page=com.atlassian.jira.plugin.s... ]
Val Blant updated RF-13674:
---------------------------
Attachment: RichFacesPushFixFilter.java
In the mean time, this filter can be used as a workaround.
Note that it does not fix the problem entirely! It makes _<a4j:push />_ *kind of* work
on WebLogic. Sometimes when long-polling connection times out, the client does not issue the next request, so push stops working until the page is refreshed.
Could be another problem with the ancient Atmosphere version used by RichFaces.
To register the filter:
{code:xml|title=web.xml}
<filter>
<filter-name>RichFacesPushFixFilter</filter-name>
<filter-class>ca.gc.agr.pushtest.RichFacesPushFixFilter</filter-class>
<async-supported>true</async-supported>
</filter>
<filter-mapping>
<filter-name>RichFacesPushFixFilter</filter-name>
<url-pattern>/__richfaces_push</url-pattern>
</filter-mapping>
{code}
> a4j:push broken on WebLogic 12c
> -------------------------------
>
> 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.
> {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
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 8 months
[JBoss JIRA] (RF-13674) a4j:push broken on WebLogic 12c
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.
{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
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.
> a4j:push broken on WebLogic 12c
> -------------------------------
>
> 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
>
>
> <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
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 8 months
[JBoss JIRA] (RF-13674) a4j:push broken on WebLogic 12c
by Val Blant (JIRA)
[ https://issues.jboss.org/browse/RF-13674?page=com.atlassian.jira.plugin.s... ]
Val Blant updated RF-13674:
---------------------------
Attachment: atmosphere-weblogic12c-bug-0.8.4.war
atmosphere-weblogic12c-bug-0.8.4-sources.jar
Attaching a demo app that clearly demonstrates the problem.
> a4j:push broken on WebLogic 12c
> -------------------------------
>
> 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
>
>
> <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.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 8 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 commented on RF-13640:
------------------------------------
@QE: I've committed a fix for this to the 4.5.x branch. Please verify the issue their before we backport the fix to 4.3.8. (Would it be easier to track the 4.3.8 backport with a separate jira issue?)
I checked that my fix works in both Chrome and IE 11. Please verify other supported browsers as well. Also, please check that the use case in the triggering issue remains resolved (RF-13531). Lastly, please verify all showcase samples (the regression introduced with RF-13531 was evident in a showcase sample).
cc: [~jhuska]
> 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-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, 8 months
[JBoss JIRA] (RF-13674) a4j:push broken on WebLogic 12c
by Val Blant (JIRA)
Val Blant created RF-13674:
------------------------------
Summary: a4j:push broken on WebLogic 12c
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
<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.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 8 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 updated RF-13640:
-------------------------------
Labels: needs-qe regression (was: regression)
> 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-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, 8 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 updated RF-13640:
-------------------------------
Fix Version/s: 4.5.0.Alpha3
> 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: 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, 8 months
[JBoss JIRA] (RF-13663) Warp on Chrome
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13663?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13663:
------------------------------------
+1 - using {{Warp...filter}} would make the test more clear
> Warp on Chrome
> --------------
>
> Key: RF-13663
> URL: https://issues.jboss.org/browse/RF-13663
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.5.0.Alpha2
> Environment: Chrome
> Wildfly 8.0
> Reporter: Matej Novotny
> Assignee: Matej Novotny
>
> This issue originates from RF-13651.
> RF 4.5 integration tests (I tried it with a4j tests) fail when there is a @Warp test using @BeforePhase JSF hooks.
> The problem is that the Phase does not get executed. However this only happens with Chrome, FF and PhantomJS work corectly.
> This is the exception:
> {code}
> testExecuteForm(org.richfaces.component.region.ITExecuteRichAjax) Time elapsed: 11.187 sec <<< ERROR!
> org.jboss.arquillian.warp.impl.client.verification.InspectionMethodWasNotInvokedException: Lifecycle test declared on public void org.richfaces.component.region.VerifyExecutedIds.validaExecutedIds(javax.faces.context.FacesContext) with qualifiers [@org.jboss.arquillian.warp.jsf.BeforePhase(value=RENDER_RESPONSE)] was not executed
> at org.jboss.arquillian.warp.impl.client.verification.ResponsePayloadVerifier.verifyAllLifecycleTestsExecuted(ResponsePayloadVerifier.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultResponseDeenrichmentService.deenrichResponse(DefaultResponseDeenrichmentService.java:87)
> at org.jboss.arquillian.warp.impl.client.execution.EnrichmentObserver.deenrichResponse(EnrichmentObserver.java:101)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.warp.impl.client.execution.EnrichmentObserver.tryDeenrichResponse(EnrichmentObserver.java:92)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.warp.impl.client.execution.DefaultHttpFiltersSource$1.responsePost(DefaultHttpFiltersSource.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.warp.impl.client.context.operation.Contextualizer$2.invoke(Contextualizer.java:68)
> at com.sun.proxy.$Proxy27.responsePost(Unknown Source)
> at org.littleshoot.proxy.impl.ClientToProxyConnection.respond(ClientToProxyConnection.java:316)
> at org.littleshoot.proxy.impl.ProxyToServerConnection.respondWith(ProxyToServerConnection.java:440)
> at org.littleshoot.proxy.impl.ProxyToServerConnection.readHTTPInitial(ProxyToServerConnection.java:182)
> at org.littleshoot.proxy.impl.ProxyToServerConnection.readHTTPInitial(ProxyToServerConnection.java:66)
> at org.littleshoot.proxy.impl.ProxyConnection.readHTTP(ProxyConnection.java:143)
> at org.littleshoot.proxy.impl.ProxyConnection.read(ProxyConnection.java:130)
> at org.littleshoot.proxy.impl.ProxyToServerConnection.read(ProxyToServerConnection.java:173)
> at org.littleshoot.proxy.impl.ProxyConnection.channelRead0(ProxyConnection.java:563)
> at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:103)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.handler.timeout.IdleStateHandler.channelRead(IdleStateHandler.java:253)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at org.littleshoot.proxy.impl.ProxyConnection$ResponseReadMonitor.channelRead(ProxyConnection.java:714)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:153)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
> at org.littleshoot.proxy.impl.ProxyConnection$BytesReadMonitor.channelRead(ProxyConnection.java:668)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:126)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:485)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:452)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:346)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
> at java.lang.Thread.run(Thread.java:724)
> {code}
> What I tried:
> * I downloaded Arq. warp repo and tried integration tests there (there is a test for JSF lifecycle hooks)
> ** This test works, so I suppose warp works correctly
> * I tried to change dependencies to other version to see whether it would work
> ** No luck, fails all the time
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 8 months
[JBoss JIRA] (RF-13662) <rich:orderingList> doesn't provide selection
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13662?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13662:
------------------------------------
I'd like to see us resolve this issue by providing any required client-side javascript hooks, rather than complicate the component usage and API by targeting too many use cases.
[~matinh] are the "selectItem" and "unselectItem" events not sufficient?
> <rich:orderingList> doesn't provide selection
> ---------------------------------------------
>
> Key: RF-13662
> URL: https://issues.jboss.org/browse/RF-13662
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-selects
> Affects Versions: 4.3.7
> Reporter: Martin Höller
> Labels: waiting_on_user
>
> In RichFaces 3.x the <rich:orderingList> component had a selection-Attribute. In RichFaces 4.x this is currently not supported and thus there is not way to obtain the selected entries. Please bring back this useful feature!
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 8 months