ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

We appreciate your courage and daring ;-). The software world needs its pioneers.

I had captured that in this JIRA a couple of days ago:

http://jira.icefaces.org/browse/ICE-7718

We're code frozen for release so as soon as the repository thaws, I can add this in and you should be able to pick it up.

I opened a JIRA for the jQuery issue:

http://jira.icefaces.org/browse/ICE-7717

I did see some other minor issues when running on Liferay 5 but they were not related to the most recent PortletFaces Bridge (2.0.2). We'll create JIRAs and investigate as we narrow them down. Do you have stack traces or logging output related to the issues you are seeing?

Deryk

Sorry but I don't fully understand your question. Are you asking why the View-scoped beans aren't going out of scope? I'm not sure myself.

You might try verifying that the View-scoped bean lifecycle is being executed as intended by adding @PostConstruct and @PreDestroy annotations on a couple of methods and then logging when the beans are created and destroyed. That might provide clues. Perhaps JSF does let them go out of scope but the Liferay Messaging system retains a reference.

I might try removing the "throws Exception" from the method. Perhaps it doesn't like that signature.

You can build and run the Component Showcase example as a portlet:

cd icefaces.dir/samples/compat/component-showcase-portlets
ant clean liferay6.servlet-profile

The resulting .war file should be deployable to Liferay and has lots of different portlets showing off various components, including the command button.

We would have tested against 6.0.6 as we don't typically test against pre-release versions of platforms. Probably worthwhile to run against 6.0.6 and see if you get the same issue.

I downloaded the 6.1 Beta and a clean binary version of ICEfaces 3.0 RC 1 and was able to deploy the Accordion Panel example without hitting the issue you are seeing. I do get an exception regarding the source code resources:

Code:

18:12:30,336 INFO  [PortalImpl:4678] Current URL /comp-suite/sourcecodeStream.html?path=%2FWEB-INF%2Fclasses%2Forg%2Ficefaces%2Fsamples%2Fshowcase%2Fexample%2Face%2Faccordionpanel%2FAccordionPanelBean.java generates exception: null
 java.io.FileNotFoundException: http://localhost:8080/comp-suite/sourcecodeStream.html?path=%2FWEB-INF%2Fclasses%2Forg%2Ficefaces%2Fsamples%2Fshowcase%2Fexample%2Face%2Faccordionpanel%2FAccordionPanelBean.java

but it doesn't interfere with the operation of the portlet. We'll clean that up for final release (just need to comment out the relevant section in content-template.xhtml).

When .war files are deployed to Liferay, it dynamically adds files as well as modifies the web.xml. Perhaps you could check the deployed version of the web.xml file and see what it has in it.

The web.xml shipped with showcase-portlets should contain the following mappings:

Code:

     <servlet-mapping>
         <servlet-name>Faces Servlet</servlet-name>
         <url-pattern>*.jsf</url-pattern>
     </servlet-mapping>
     
     <servlet-mapping>
         <servlet-name>Faces Servlet</servlet-name>
         <url-pattern>/icefaces/*</url-pattern>
     </servlet-mapping>

Does yours have something different? It would be highly unusual to map all requests to the FacesServlet - especially in a portlet environment.

I don't think so but the behaviour of the portal session is up to the portal container so you might want to ask the Liferay forums. Since your portlet is special (system portlet) the session might behave differently from non-system portlets.

Views are scoped per-page and per-portlet. That is, each portlet on a page is a separate View and switching pages also creates a new View. If you want to maintain the state between different pages (ie Views) then you probably want to use session scoped beans.

Please paste the entire stack trace.

Can you post your web.xml file? In your forum message, it looks as if there is a space between the '/' and the '*.

Depending on the behaviour of your portlet application, it may be useful to you. Normally, when a portal page is loaded that contains more than one portlet, a corresponding View is created on the server for each portlet. When the portlets get rendered to the client, they are tracked by client-side code so that when the page unloads, all of the Views can be disposed on the server.

In some circumstances (testing scenarios, impatient users, etc), the page may not be allowed to fully render on the client and this can lead to Views being created on the server but not registed on the client for disposal. While the Views will get disposed when the session expires, you may want to free up the resources sooner to avoid memory issues. This is what the AssociatedPageViews is designed to help with. It attempts to associated all the portlets that are on the same page so that if one View gets disposed then all associated Views are also disposed whether they got rendered or no.

You can build and deploy the library yourself or contact our support team for more details.

The configuration looks fine but there's something wrong with the request. It shouldn't be going to the context:

Code:

http://127.0.0.1:8081/auctionMonitor/block/message

It should be going to:

Code:

http://127.0.0.1:8081/push-server/block/message

The push-server.war should not be deployed as a portlet but rather as a normal web app.

The web.xml for the location example likely hasn't been updated to run with the latest servlet container (Tomcat 7 in this case). You can start by adding the web-app attributes for Servlet 2.5:

Code:

 <web-app version="2.5"
          xmlns="http://java.sun.com/xml/ns/javaee"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">