voyent
Messages posted by: dsinotte  XML
Profile for dsinotte -> Messages posted by dsinotte [28] Go to Page: Previous  1, 2
Author Message
The redirect feature of icecore was added as of 3.1:

http://www.icesoft.org/wiki/display/ICE/redirect

so it won't be available in ICEfaces 3.0 EE. It will be available in 3.2 EE but I don't have a timeline for that release yet. Likely in the next month or so.

Following the steps you've posted:

1) The client performs an action. This starts a request thread with a valid FacesContext. It fires a message. What kind of message is this? If it doesn't create a new thread then this message is sent on the current request thread.

2) Object B receives the message. What is Object B? Is it an instance of something in Portlet A? Is it part of a different portlet and is that portlet in the same .war file or different .war file as Portlet A? Again, if a new thread has not been used, this is still on the original request thread.

3) If conditions are met, Portlet A receives a message back. Again, if there are no new threads, this is still the request thread. It sets something in the session. Does it set in portlet scope or application scope?

4) Using Ajax Push at this point will trigger the server to send the client (browser) a response telling it to issue a new request. If the thread *is* the original request thread, then you might be able to use the ExternalContext.redirect() API rather than do an Ajax Push.

5) The new request triggers the JSF lifecycle and invokes your phase listener logic.
Without knowing more about how your code, it's tough to comment on how the initial request thread is behaving. Is it blocked in some way when you spawn off your own new thread?

I'd forgotten about the ice:core href setting but that's definitely worth a try as well using the PortableRender approach.
This looks fairly complex. If I had to guess, I'd say the "Network" popup is occurring because the original request that started the whole thing has not actually returned before another process/thread ends up triggering the redirect. ICEfaces likely detects this as a "severed" connection and puts up the warning.

A quick thing to try would be to set this context parameter:

http://www.icesoft.org/wiki/display/ICE/disableDefaultErrorPopups

It's definitely not a fix but would likely prevent the popup for the time being.

It would be better to try and get the original request thread to return the redirect. The API for that is on the ExternalContext:

Code:
        FacesContext.getCurrentInstance().getExternalContext().redirect(yourURL);
 


That call must be done from the request thread though as the FacesContext is a thread local and is only available on that thread.
A couple of questions:

What scope is your backing bean? Does changing the scope of the bean change the behaviour?

If you take the same page and bean and run them in a non-portlet environment (just a regular web app), does the same thing happen? Just trying to gauge whether or not it's a portlet-specific issue.
Glad you got it going.
I'm at a bit of a loss as to what to try next as it doesn't appear to be a problem related to ICEfaces.

It works in the bundled Glassfish + Liferay version and it appears from the server side that the URLs for the resources are being successfully constructed (i.e. they work when used manually from the browser). They just aren't making it out to the markup.

This would seem to indicate a mis-communication between the Liferay Faces Bridge and the portal container as it's the bridge that's talking to the portal container's API to add these resources to the head. Because we're dealing with portlets, adding stuff to the head is not as straightforward as a non-portlet app so the bridge may use some container specific methods to do it. Perhaps you could pose some of the findings we've made here to the Liferay Faces Bridge forums.
So in the logging, we can see the resources being processed and added to Liferay's head section:

Code:
INFO: 13:21:14,835 DEBUG [BridgeContextImpl:284] encodeResourceURL fromURL=[http://localhost:8080/web/guest/home;jsessionid=dc880d9de157b8fa2f7013eeae7c?p_p_id=pushButton_WAR_showcaseportlet&p_p_lifecycle=2&p_p_state=normal&p_p_mode=view&p_p_cacheability=cacheLevelPage&p_p_col_id=column-1&p_p_col_count=2&p_p_col_pos=1&_pushButton_WAR_showcaseportlet_javax.faces.resource=jsf.js&_pushButton_WAR_showcaseportlet_ln=javax.faces]
 
 INFO: 13:21:14,835 DEBUG [HeadResponseWriterLiferayImpl:81] Added resource to Liferays <head>...</head> section, element=[{0}]


One thing to try after the page is loaded, is to copy the "fromURL" and paste it manually into the browser's address bar and see if it can get resolved.
Not sure what the "311 logging options" refers to.

The logging is a bit complicated by the fact that ICEfaces uses java.util logging while the Liferay Faces Bridge uses Log4j by default if it's available. However, you can include 2 logging config files in WEB-INF/classes:

logging.properties:

handlers = java.util.logging.ConsoleHandler, java.util.logging.FileHandler
org.icefaces.level = FINEST
java.util.logging.ConsoleHandler.level = FINEST
java.util.logging.FileHandler.level = INFO
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter


log4.properties:

log4j.rootLogger=INFO, CONSOLE
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=%d{ABSOLUTE} %-5p [%c{1}:%L] %m%n
log4j.logger.com.liferay.faces.bridge=DEBUG


This is very blunt and dumps out a lot of info but until we know where things might be going wrong, better too much than too little.
You're right. My bad, there is no web-profile for Liferay 6. However, I ran my test using liferay6.servet-profile so I know it does work.

I realize your environment can't use the stock Liferay on Glassfish bundle but you could:

1) Verify that it does work for you on that configuration just to ensure that there isn't something else in your environment causing a problem. If the stock bundle works, then it's very likely something to do with the way Liferay and Glassfish are being combined. Perhaps just a missing or misconfigured setting. Is Liferay being deployed to the root context ("/") or some other context?

2) Crank up the logging. Liferay does occasionally have a habit of "eating" important logging statements. If you can turn on debug/finest level logging, it may show something important that isn't being propagated to the console.

I'm not sure what could be going wrong. I went through the following exercise:

- Downloaded the latest Liferay on Glassfish bundle (liferay-portal-6.1.1-ce-ga2).
- Unzipped and started the server.
- Built and deployed our showcase-portlet application on to the platform.
- Created a new portal page.
- Added an Accordion sample portlet to the page.

And everything worked fine for me. Firebug shows that the bridge was downloaded without issue (uncompressed in this case as I was in JSF Development mode):

http://localhost:8080/web/guest/test?_accordionPanel_WAR_showcaseportlet_javax.faces.resource=bridge.uncompressed.js&p_p_col_count=1&p_p_col_id=column-1&p_p_id=accordionPanel_WAR_showcaseportlet&p_p_lifecycle=2
The .iface mapping was something we typically recommended as part of ICEfaces 1.x:

<servlet-mapping>
<servlet-name>Persistent Faces Servlet</servlet-name>
<url-pattern>*.iface</url-pattern>
</servlet-mapping>

But we don't have our own servlets anymore - we just rely on the FacesServlet.

Are you migrating an older application to a newer version of ICEfaces? We have a page that summarizes some of the more important points of doing this:

http://www.icesoft.org/wiki/display/ICE/ICEfaces+1.x+Compatibility
Is there any server console logging showing warnings, exceptions, etc?

Since you are running on Glassfish, it probably ships with it's own version of JSF. Is that version being logged? Does it match the version you've included in the .war file?

You can build a version of the showcase that doesn't include javax.faces.jar by using the web-profile target:

ant clean -Dliferayfaces="true" liferay6.web-profile

However, we generally recommend using the version we ship (Mojarra 2.1.6 is the latest one we include) as there are bugs with more recent versions of Mojarra that can cause problems. Not loading jsf.js and bridge.js are not typically an issue, though.
There should always be a request for jsf.js (as part of JSF) and a request for bridge.js (as part of ICEfaces) - both are fundamental pieces that are required for proper operation on the client side. The bridge.js resource should be load automatically.

Can you provide a list of the .jar files that are included in the deploy .war file?

What JSF or ICEfaces resources are being successfully loaded in the client?
 
Profile for dsinotte -> Messages posted by dsinotte [28] Go to Page: Previous  1, 2
Go to:   
Powered by JForum 2.1.7ice © JForum Team