voyent
Messages posted by: deryk.sinotte  XML
Profile for deryk.sinotte -> Messages posted by deryk.sinotte [915] Go to Page: 1, 2, 3  ...  59, 60, 61 Next 
Author Message
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:

http://www.liferay.com/community/liferay-projects/liferay-faces/overview

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

http://www.liferay.com/community/liferay-projects/liferay-faces/download.

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:

http://www.liferay.com/community/liferay-projects/liferay-faces/bridge

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

http://www.liferay.com/community/wiki/-/wiki/Main/Liferay+Faces+Version+Scheme

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:

http://icefaces-showcase.icesoft.org/showcase.jsf

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

Code:
./samples/showcase/showcase-portlet


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

http://www.icesoft.org/wiki/display/ICE/Sample+Portlet+Applications.
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:

Code:
    <portlet>
         <portlet-name>chat-ice-portlet</portlet-name>
         <display-name>Chat</display-name>
         <portlet-class>org.portletfaces.bridge.GenericFacesPortlet</portlet-class>
         <init-param>
             <name>javax.portlet.faces.defaultViewId.view</name>
             <value>/chat.xhtml</value>
         </init-param>
         <supports>
             <mime-type>text/html</mime-type>
             <portlet-mode>view</portlet-mode>
         </supports>
     </portlet>
 


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:

http://www.icesoft.org/wiki/display/ICE/Portlet+Development

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:

http://www.icesoft.org/java/products/ICEfaces-EE/overview.jsf

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:

Code:
<context-param>
      <param-name>javax.faces.PROJECT_STAGE</param-name>
      <param-value>Development</param-value>
  </context-param>
 
 <context-param>
      <param-name>org.icefaces.coalesceResources</param-name>
      <param-value>false</param-value>
  </context-param>


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:

Code:
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?
If it's the same as the original problem noted in the JIRA (http://jira.icesoft.org/browse/ICE-9135) then the icefaces.jar is missing some JavaScript resources. These resources are stored in the icefaces.jar under META-INF/resources/ice.core. There will be a few of them that start with the term bridge:

  • bridge.js
  • bridge.uncompressed.js
  • bridge-support.js
  • bridge-support.uncompresssed.js

    ICEfaces will server up the uncompressed files if the project is set to development mode:

    Code:
    <context-param>
         <param-name>javax.faces.PROJECT_STAGE</param-name>
         <param-value>Development</param-value>
     </context-param>
     


    Resources (CSS and scripts) are coalesced into a single file if the following parameter is set:

    Code:
    <context-param>
         <param-name>org.icefaces.coalesceResources</param-name>
         <param-value>true</param-value>
     </context-param>
     


    So multiple resource files (bridge.js, etc.) are loaded as coalesced.js and coalesced.css files. Since "ice" is defined in bridge.js, then either bridge.js is not being loaded (coalesced=false) or coalesced.js is not being loaded (coalesced=true).
  • What version of JBoss 7 are you using and which version of JSF?

    I just deployed the same showcase.war to JBoss 7.1.1 and it worked fine. It may be a combination of JBoss and/or the JSF version involved.
    I just:

  • checked out a clean version of the current icefaces3/trunk (3.4.0-SNAPSHOT)
  • built everything from the top using "mvn clean install"
  • deployed the resulting showcase build (samples/showcase/showcase/target/showcase.war) to Tomcat 7

    and it worked fine for me. Anything different than what you are trying? I visually checked that the resources that were missing previously are making it into the jars. What JavaScript errors are you seeing specifically?
  • Just a reminder, if you are a customer with a support agreement with ICEsoft, you should direct all support-related inquiries through the official support channel.

    The problem is likely related to this case:

    http://jira.icesoft.org/browse/ICE-3277

    The workaround in there should be the answer. Basically, for IE, you need to move the CSS output components to the bottom of the view/page:

    Code:
     ...
             <ice:outputStyle href="/resources/css/ehp.css" /> 
             <ice:outputStyle href="/resources/css/jquery-ui.css" /> 
             <ice:outputStyle href="/resources/css/custom.css" /> 
         </ice:portlet>
     </f:view>
     
    Can you provide more information about the exact problem you are seeing and which SNAPSHOT version(s) has/have the issue?

    I believe the last time there was a problem, the jars assembled using Maven were missing some JavaScript resources. For example icefaces.jar was missing META-INF/resources/ice.core/bridge.js.

    However, I visually inspected at the latest SNAPSHOT (20130515) and those files are there and seem to include all the proper scripts.

    Also, the last few current 3.4.0-SNAPSHOTs have been released under 3.3.0-SNAPSHOT inadvertently. We'll get this corrected shortly.

    Deryk
     
    Profile for deryk.sinotte -> Messages posted by deryk.sinotte [915] Go to Page: 1, 2, 3  ...  59, 60, 61 Next 
    Go to:   
    Powered by JForum 2.1.7ice © JForum Team