Multiple JSF Implementations?

[7年前 に Andrew Jardine によって更新されました。]

Hi Everyone,

I'm just going to start by saying my JSF knowledge with respect to Liferay is pretty much academic. I know that JSF is a standard and that there are several implementations + bridges that you can use, including one Liferay's very own (Liferay Faces). I'm troubleshooting and issue right now that is masquerading itself as a Network Issue. We have an F5 that is terminating (resource requests) -- in particular the one that grabs the primefaces.js. Now this portlet that is being deployed in it latest version is referencing both primefaces (how it has always functioned) and not Liferay Faces (because we wanted the runtime tag functionality). If i deploy the last version of the portlet (when it was just primefaces) there is no error. When I deploy the new version (PF + LF) then I get the net::ERR_CONNECTION_RESET error.

My question may be elementary but -- can you reference more than one JSF implementation within the same portlet? I can't think of any reason why not but I'm not sure what else it could be at this point.

[7年前 に Neil Griffin によって更新されました。]

Moved to Liferay Faces - English

[7年前 に Neil Griffin によって更新されました。]

Andrew Jardine:

My question may be elementary but -- can you reference more than one JSF implementation within the same portlet? I can't think of any reason why not but I'm not sure what else it could be at this point.

Yes, you can utilize PrimeFaces and Liferay Faces Alloy components in the same XHTML view. We designed Liferay Faces Alloy to be compatible with PrimeFaces. For example, the applicant.xhtml Facelet composition in our primefaces-applicant-portlet demo contains both alloy: component tags and p: component tags.

However, it is not advisable to do this with PrimeFaces+ICEfaces, or PrimeFaces+RichFaces since they don't necessarily work well together in the same view.

Regarding the network error you are experiencing, I have not seen that before. What Liferay Faces component tags are you using along with the PrimeFaces ones?

[7年前 に Andrew Jardine によって更新されました。]

Hey Neil --

Lucky me! The master himself . The Liferay Faces was added to the dependencies (we're using maven) solely to use the portal:runtime tag. So basically the changes equated to --

1. Adding a new dependency to the pom
2. Creating a new view
3. Using the tags to embed a couple of other portlets we have (that are regular MVCPortlets)

We're on Liferay EE SP11 and specifed the GA5 version of the Faces library. We checked the logs on the F5 and confirmed that the request is getting killed at that point. If we disable the Http Profile in the F5 (default profile it ships with) essentially making the F5 nothing more than a passthrough proxy, then there is no issue. We're using this as confirmation that there is something in that resource request that the F5 does not like (we're going to do a wireshark next week).

As I said though, we only get this issue with the mixed lib version. If we roll back to the version without the new page, dependency and embedded portlets, everything is hunky dorey.

[7年前 に Neil Griffin によって更新されました。]

Hi Andrew,

If you can, please upgrade to the 4.2.5-ga6 (for JSF 2.2) or 3.2.5-ga6 (for JSF 2.1) versions of all Liferay Faces dependencies.

Andrew Jardine:

Liferay Faces was added to the dependencies (we're using maven) solely to use the portal:runtime tag. So basically the changes equated to --
1. Adding a new dependency to the pom

I am assuming you mean the liferay-faces-portal dependency? That's the one that features the portal:runtime component tag.

Andrew Jardine:

We checked the logs on the F5 and confirmed that the request is getting killed at that point. If we disable the Http Profile in the F5 (default profile it ships with) essentially making the F5 nothing more than a passthrough proxy, then there is no issue. We're using this as confirmation that there is something in that resource request that the F5 does not like (we're going to do a wireshark next week). As I said though, we only get this issue with the mixed lib version. If we roll back to the version without the new page, dependency and embedded portlets, everything is hunky dorey.

I could be wrong, but on the surface it doesn't seem like this is an issue related to JSF ResourceURLs. In order to confirm that, I would recommend that you try to reproduce the problem without using JSF:
1. Create a new plain MVCPortlet project.
2. Inside view.jsp, specify the liferay-portlet:runtime tag (that's the plain JSP equivalent of the portal:runtime component tag).
3. Also inside view.jsp, make sure there is a <script> or <link> element that specifies a portlet:resourceURL to a JS or CSS resource.

If you still see the problem with the F5, then you might want to examine the {scheme:}{//authority}{path} part of the ResourceURLs that are getting stopped by the F5 to see if there is anything different from the ResourceURLs with the embedded portlets.

Kind Regards,

Neil

[7年前 に Andrew Jardine によって更新されました。]

Hey Neil.

I would agree that it doesn't make sense -- I mean, I am assuming that under the covers, the resource URLs are built from the same segment of the Liferay API whether its an MVCPortlet or a JSF Portlet. It just seems weird that the version before works without issue, but this version fails -- and we know that the only changes are the additions that I mentioned.

I'm going to try to do a wireshark today to see if we can get more details though -- once thing that I did notice last week when I was looking at the (basic) information from the resource requests what that some of them appeared to be missing Content-Length headers. I am wondering if perhaps this is part of the issue and that the F5 IRules are preventing requests missing said headers.

I'll report back on what we find.

[7年前 に Andrew Jardine によって更新されました。]

Hey Neil,

I have some updates to share -- sadly the mystery is not solved, in fact it's only getting stranger.

1. I was mistaken earlier when I shared the versions -- we are in fact using the 3.2.5 GA6 when we see this error. If we downgrade to an earlier version then we don't see the error. So there is suspicion around GA6.

2. I think I mentioned that if we disable the Http Profile on the f5 it works. This is not a solution though as it turns the proxy into a dumb router (essentially). We did discover though that the ERR_CONNECTION_RESET that is happening is in fact from the proxy BUT! it doesn't occur on the way in, it occurs on the way OUT. So there is something in the Response that it is not happy with. This is important as I had initially thought that there was something wrong with the request headers (making it a browser issue perhaps) but in fact it's something that comes from LR that is upsetting it.

Here is the WEIRDEST part of all --

3. If it definitely related to cache in requests in some way. If we set the browser.cache.enabled=false, and clear our browser cache, then there is no issue.

4. To confirm the cache issue we did this. Allowed cache to work. Took one of the broken urls, and added a new parameter to it, or changed an existing parameter -- and then the value loaded. Oddly enough though you would expect that reloading the same (changed) url would cause the error to occur, but it doesn't. Only the original url causes the error to manifest itself.

Original (broken) URL:

?p_p_id=compassportlet_WAR_compassportlet&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=1&_compassportlet_WAR_compassportlet_javax.faces.resource=watermark%2Fwatermark.css&_compassportlet_WAR_compassportlet_ln=primefaces&v=4.0

Changed URL (see last param):

?p_p_id=compassportlet_WAR_compassportlet&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=1&_compassportlet_WAR_compassportlet_javax.faces.resource=watermark%2Fwatermark.css&_compassportlet_WAR_compassportlet_ln=primefaces&v=4.0&andrew=test

5. We never get the error if we disable SSL so that all requests are HTTP only.

[7年前 に Neil Griffin によって更新されました。]

Hi Andrew,

Thanks for the update. When you get an opportunity, please try our newest SNAPSHOT artifacts.

Keeping in mind that we have a new OSGi file naming convention for our artifacts, along with a new version scheme, here are the dependencies that should work in your environment:

<repositories>
  <repository>
    <id>liferay-faces-snapshots</id>
    <url>
     https://oss.sonatype.org/content/repositories/snapshots
    </url>
  <releases>
    <enabled>false</enabled>
  </releases>
  <snapshots>
    <enabled>true</enabled>
  </snapshots>
  </repository>
</repositories>
<dependencies>
  <dependency>
    <groupid>com.liferay.faces</groupid>
    <artifactid>com.liferay.faces.alloy</artifactid>
    <version>2.0.0-SNAPSHOT</version>
  </dependency>
  <dependency>
    <groupid>com.liferay.faces</groupid>
    <artifactid>com.liferay.faces.bridge.impl</artifactid>
    <version>3.0.0-SNAPSHOT</version>
  </dependency>
  <dependency>
    <groupid>com.liferay.faces</groupid>
    <artifactid>com.liferay.faces.bridge.ext</artifactid>
    <version>2.0.0-SNAPSHOT</version>
  </dependency>
  <dependency>
    <groupid>com.liferay.faces</groupid>
    <artifactid>com.liferay.faces.portal</artifactid>
    <version>2.0.0-SNAPSHOT</version>
  </dependency>
  <dependency>
    <groupid>com.sun.faces</groupid>
    <artifactid>jsf-impl</artifactid>
    <version>2.1.29-05</version>
  </dependency>
</dependencies>

Kind Regards,

Neil

[7年前 に Andrew Jardine によって更新されました。]

Hi Neil,

We'll give it a shot -- but just wanted to validate something with you. Right now we have (for exmaple)

<dependency>
  <groupid>com.liferay.faces</groupid>
  <artifactid>com.liferay.faces.alloy</artifactid>
  <version>3.2.5-ga6</version>
</dependency>

and you have asked us to try the snapshot --

<dependency>
  <groupid>com.liferay.faces</groupid>
  <artifactid>com.liferay.faces.alloy</artifactid>
  <version>2.0.0-SNAPSHOT</version>
</dependency>

does this mean that 2.0.0-SNAPSHOT is a snapshot for the next release? I just want to make sure that it is newer than what we are using

[7年前 に Neil Griffin によって更新されました。]

Hi Andrew,

I know it might seem like a downgrade to go from liferay-faces-alloy-3.2.5-ga6.jar to com.liferay.faces.alloy-2.0.0-SNAPSHOT.jar but it is correct according to our new version scheme for releases after GA6.

Basically, each JAR is now on its own release schedule and has its own major.minor.rev in the version scheme. For more information see the blog titled New Git Repositories for Liferay Faces.

Kind Regards,

Neil