Messages posted by: deryk.sinotte  XML
Profile for deryk.sinotte -> Messages posted by deryk.sinotte [1008] Go to Page: 1, 2, 3  ...  66, 67, 68 Next 
Author Message
Servlet 3.0 shouldn't really be an issue. ICEpush does try to take advantage of the async features in Servlet 3.0 if they are available but that should be done transparently for you.

A push group is basically just a logical "tag" that organizes who should get a notification. You can use it to indicate that you want to push to a single user or many users. I usually think of them as "chat rooms". When sessions are added to a push group it simply indicates to the ICEpush engine which users should receive notifications when a render is called. In your case it appears that every new client would be added to "MyGroup" and when the render is called, everyone in that group would receive a notification that the model had changed in some meaningful way. This would trigger each client to make a JSF request to update their UI based on the differences in the app state. Other than calling render, the rest is done automatically for you.

In your case, I don't see where the current user is added to the push group:


only when render is called:


This step is outlined in the tutorial but perhaps you missed it or didn't copy in that part of your code:


If that's not the issue and your app is small enough would it be possible to post it to the thread? I don't see anything obvious up front but if I could actually run it, it might help make things clearer. You can leave out the ICEfaces libs to keep the upload smaller.
To my knowledge, there's no official way to capture a "push" directly in the client. There are documented callbacks you can register for that might be useful:


For example you might be able to make use of ice.onAfterUpdate(callback) or ice.onElementUpdate(elementID, callback) to determine whether the data that is being updated is relevant and trigger your animation. However, you might not be able to distinguish between an update originating from a Push vs an update originated from a standard user request. Or perhaps it makes no difference to your application.

A different approach would be to handle it on the server. A Push triggers a normal JSF lifecycle to occur so you could potentially change some state that could be detected on the client and then call your animation code.

More of longshot but perhaps you could even make use of the JavaScriptRunner utility:


It allows you to send JavaScript as part of the update and get evaluated on the client.
Glad you got it working. Yes, the PushContext is stored in the ServletContext so, unless your Web Service can get or provide access to it, there's no real way to trigger the push that way.

Just to clarify, you are trying to determine when a push triggers an update in a client so that you can do some other work? In this case animate something in the UI?
Thanks for all the detailed info.

First of all, there seems to be an error even starting up your application:

Grave: Exception sending context initialized event to listener instance of class org.apache.myfaces.webapp.StartupServletContextListener java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.application.ApplicationFactory. Attempting to find backup. at javax.faces.FactoryFinder$FactoryManager.getFactory(FactoryFinder.java:800)

It might be worthwhile tackling that issue as it indicates that JSF is not initializing properly for some reason.

As for the PortableRenderer, the creation in the User constructor should be fine providing that the User bean is constructed during a servlet or JSF request as it will need access to the ServletContext. The ServletContext is necessary as that's where the PushContext is stored.

However, the WebService class will generally not be on a thread that originates as a JSF or servlet request and so will likely fail. As you've noted, since there is no access to the ServletContext, it can't propertly create a PortableRenderer.

Rather than have the WebService create and hold a reference to the PortableRenderer, would it be possible to change the design so that the WebService can call back into an application that does have a valid reference to the PortableRenderer? This could be your existing application or could be a separate application who's main responsibility is to handle notifications from the WebService in order to trigger push calls.

In short, instead of:

app login -> notifies web service -> calls PortableRenderer

the chain would add a layer and look more like:

app login -> notififies web service -> notifies some JSF app -> calls PortableRenderer
Perhaps a bit more information about your environment and what you are trying to do:

What version of ICEfaces are you running?

Can you post the stack trace for the NullPointerException?

You are correct that if you are trying to do a Push from outside a JSF request, you'll need to get a reference to a PortableRenderer and use that. You should get the initial PortableRenderer reference during a request that does have access to either the FacesContext or an HttpSession so that the PortableRenderer can get the internal references that it needs and save the PushContext properly.

Can you post the snippets of code in your application where you are creating the PortableRenderer and the area of your application where the web service is calling back into your application to use the PortableRenderer?
So the combination of Tomcat 6 and Liferay is good.

Which version of Liferay are you using?

Also, you stated before that you were using the portlet-bridge-api-3.0.0-alpha.jar which appears to be part of the MyFaces Portlet Bridge. To run ICEfaces you need the Liferay Faces Portlet Bridge which is part of this project:


The library can be downloaded via Maven or directly from their site:


However the version of the bridge depends on which version of Liferay you are using.
It's difficult to help unless you answer some of the other questions I've posed.

What app server are you using?
What portlet bridge (we only support Liferay)?

As I also noted, the approach to building portlets with ICEfaces 1.x and 3.x are quite different. If you examine the showcase-portlet and chat-portlet examples that come with the ICEfaces 3.3 distribution, you'll see that you don't really write your own portlets. You simply configure the portlet bridge to point at your JSF views. This means that developing a portlet application is much the same as developing a regular servlet application.

The work being done in your servlet to serve files and images can be done more easily with existing ICEfaces components. I again recommend you review the showcase components and see what they have to offer as I think you could potentially save yourself a lot of time and effort by adjusting how your application is built.
Which portal server are you running on?

It looks like you are trying to use the MyFaces Apache portal bridge. The bridge we officially support is from Liferay:


The version of the bridge that you need depends on which version of Liferay you are using:


The whole purpose of the bridge is to facilitate communication between the Portal lifecycle and the JSF lifecycle. In most cases, you can write your applications without actually creating any portlet code.

(Note that non-Liferay server support may require a support agreement.)

As for your ObsGenericFacesPortlet, it seems like a lot of the work done in there could be done more easily using ICEfaces' existing components. For an overview, you can see them all here:


In the ICEfaces 3.3 bundle, you'll find a portlet version of this showcase under:


Information for building, deploying, and running that example yourself can be found here:

My recommendation is that your existing approach (trying to port the ObsGenericFacesPortlet) will probably not work well in the long run. If you view the showcase-portlet example, you'll see that we only use JSF components and beans and there is very little (if any) portlet-specific code required. It's all handled by ICEfaces and the LiferayFaces Bridge.
Technically, you don't have to extend any portlets to display a JSF view. If you look at our sample portlets (e.g. samples/core/chat-portlet) or the LiferayFaces sample portlets you can see that they simply provide a JSF page as a parameter:


I assume that com.p7s1.obs.portlet.ObsGenericFacesPortlet is your portlet. Can you post the source of that portlet along with your portlet.xml file?
The migration guide is a good first step but you should also take a look at the Portlet Development section:


There are some things in there that are likely to help. I highly recommend going over the first 3 pages in that section to get familiar with the changes to portlet development. It talks abou the new portlet bridge library that we use. It also points to the sample portlets we ship with the product that show proper configuration and such. You can use them to help adjust your own portlet descriptors.

Shashikadiwal wrote:

1) MainPortlet class (com.icesoft.faces.webapp.http.portlet.MainPortlet) was in icefaces-1.8.jar file. but not in new version. Please let me know how to work with the class which extends this MainPortlet, i tried extending with GenericPortlet, it didn't worked 

In regards to your first question, in ICEfaces 1.8, we do have our own custom portlet bridging code which was enabled via the com.icesoft.faces.webapp.http.portlet.MainPortlet class. As of ICEfaces 3.x, we now use the LiferayFaces Bridge. You should be able to download the version of LiferayFaces Bridge that you need from here (as we are not allowed to ship it due to licensing restrictions). Then your portlets should identify the <portlet-class> as javax.portlet.faces.GenericFacesPortlet which is provided by the LiferayFaces Bridge library.

Shashikadiwal wrote:

2) LifecycleExecutor (public abstract class com.icesoft.faces.webapp.http.core.LifecycleExecutor { }) was in again icefaces-1.8.jar

3) public class com.icesoft.faces.webapp.http.portlet.InterceptingPortletSession extends com.icesoft.faces.webapp.http.portlet.ProxyPortletSession {}) is not in icefaces 3.3.0 version 

ICEfaces 3.x has quite a different architecture when compared to ICEfaces 1.8 and runs on a completely different version of JSF. The two classes you point to are, indeed, no longer in the ICEfaces library. However, they were never really designed to expose public APIs (see the JavaDocs for ICEfaces 1.8 here http://res.icesoft.org/docs/v1_8_2/javadocs/icefaces/api/index.html). Perhaps if you described what you need to do with those classes, we could come up with an alternative strategy using safer, public APIs.
I'm not familiar with the combination of Open Text and WebLogic and it's not in our matrix of supported platforms - even for our paid EE subscribers.

One thing you could try is LiferayFaces Bridge ( https://www.liferay.com/community/liferay-projects/liferay-faces/download). The PortletFaces Bridge is the pre-cursor to the LiferayFaces Bridge but is older, deprecated, and really only intended for legacy versions of Liferay (i.e. Liferay 5.1).

I can't guarantee the newer bridge will work either since, as I noted, Open Text + WebLogic is not a supported platform but it is more up to date and actively worked on.

If you are interested in more formal support for your environment, you can contact our sales department to see what level of work might be involved in helping to get your environment running. If you are an existing customer, I'd contact our support team directly.
For it to work, do both context parameters need to be set or is it just one of them that is "fixing" it?

Just trying to narrow down if it's the coalescing or the compression that is causing the problem.

If I set coalescing to false, I don't see any requests for coalesced.js or coalesced.css files - just the individual scripts and stylesheets required for the app.

If I also turn on Development mode, most of the script files are delivered in uncompressed form (e.g. .../javax.faces.resource/bridge.uncompressed.js.jsf?ln=ice.core&v=3_4_0_130801)
Support for ICEfaces 3 running on WAS portal is only provided for our paid EE customers. For more information see:


There is information about various EE subscription options as well as various contact information depending on where you are based.
Well, that looks like the coalesced.js file had some sort of issue and that failure cascaded down.

Can you run with one or both of the following context parameters set:


If you set Development, you should get an uncompressed version of coalesced.js and that would help us pinpoint the area of the code that is causing the problem.

If you also set coalesceResources to false, the .js files will be downloaded individually which could also help isolate the issue.
That is odd. And the error being reported in the browser is still "Uncaught ReferenceError: ice is not defined"? Does using a different browser or clearing the browser cache have any effect? The coalesced.js file should contain a definition for the ice namespace:

if (!window.ice) {
     window.ice = new Object;

How about running in something other than JBoss (e.g. just plain Tomcat) to see if it's something JBoss-specific?
Profile for deryk.sinotte -> Messages posted by deryk.sinotte [1008] Go to Page: 1, 2, 3  ...  66, 67, 68 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team