I'm currently developing a jsf app on quarkus using myfaces (2.3-next-M7) but due to a bug that I raised here I can't use it in production and I am eagerly waiting for version 2.3-next-M8, would someone know when it is supposed to be released ?
I haven't found any information on myfaces' site or myfaces' issue tracker
Thanks for your help.
Related
I'm developing a new application using websockets and decided to use JSF 2.3 in wildfly 15. All is working fine until I try to redeploy my code using wildfly management console. Websockets stops working after this point and I can just make it work after a server restart. I made a simple application to test this behaviour with this code in the body of xhtml:
<f:websocket channel="test" />
When the application is redeployed I noticed that my page keeps trying to make requests to websocket endpoint and keeps receiving multiple 101 (Switching protocols) as response code in short intervals (about 5 requests/second).
Firefox network inspection
I used wireshark to capture traffic and discovered that just after this response wildfly send a websocket connection close [FIN].
I tried to narrow down this issue and seems to me like a wildfly bug. I used fresh installations of wildfly 15.0.1.Final and 16.0.0.Final. Does anyone have a workaround or a working solution for this?
I tested a very simple application on glassfish (with just f:websocket on xhtml - no backing bean, just to test network websocket connection) and couldn't get the same result I had on wildfly (repeated 101 responses), so I thought this wouldn't apply in glassfish (thus unrelated to Websocket PushContext not working anymore after application redeploy)
After reading Kukeltje comment I decided to make a more functional test application and noticed that websocket stopped working on glassfish after reload (but couldn't get multiple 101 responses - as in wildfly).
So this must be related to Websocket PushContext not working anymore after application redeploy
Test application source
Test application WAR
This is a bug in the source code. Omnifaces websocket implementation fixed the bug. I would recommend using that.
This has been fixed in Mojarra 2.3.15 (released May 2021).
It was initially already fixed at May 2019 for the imagined 2.3.10 version via issue 4565 wherein I have backported the fixes from <o:socket> into <f:websocket>. Unfortunately it was done during the Oracle -> Eclipse transition and in hindsight the changes appear to have completely slipped through during the chaos. So it was re-done via issue 4802 for 2.3.15.
I am trying to deploy an application on Websphere 8.5.5
I've created a shared library for Websphere that includes myfaces 2.2 jars and other dependencies like commons-collections.
I also made the class loader of my application as PARENT_LAST.
When I deploy the application, I get this exception:
An error occured while initializing MyFaces: Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no org.apache.myfaces.spi.AnnotationProvider
java.lang.IllegalArgumentException: Class com.ibm.ws.jsf.config.annotation.WASMyFacesAnnotationProvider is no org.apache.myfaces.spi.AnnotationProvider
at org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:557)
at org.apache.myfaces.shared.util.ClassUtils.buildApplicationObject(ClassUtils.java:524)
I was looking at running a newer version of MyFaces on WAS 8.5.5, and ran into a similar issue. It appears to be a conflict between the code IBM wrote to support its embedded version of MyFaces, and an application- or shared library-provided MyFaces.
IBM provides a way to circumvent this issue. When WAS 8.0 shipped, it provided a feature to allow select either "SunRI1.2" or "MyFaces" as the server-provided JSF. Setting the default to "SunRI1.2" would remove the server-provided MyFaces from the classpath and allow the developer to provide their own.
Select any application
Click JSP and JSF Options
In the JSF implementation section, change the drop-down to SunRI1.2
Click OK
Save configuration and restart server
Im trying to use CDI in a Java-web-start app but get stuck at classloading. Looks like FileSystemURLHandler treats the URLs in the web-start cache as files.
org.jboss.weld.environment.se.discovery.url.FileSystemURLHandler - could not read entries
java.io.FileNotFoundException: http:\localhost:8080\myapp.jar
Which is the same as: https://issues.jboss.org/browse/WELD-1040
My limited skills in jira and git-hub suggests that someone started working on it, but it didnt make it into a release: https://github.com/agattiker/core/blob/9eabd09f0b8e80e48e3270414e2f68ebc1016b70/environments/se/core/src/main/java/org/jboss/weld/environment/se/discovery/url/FileSystemURLHandler.java
So my question is if anyone got around this problem or if cdi+weld on jws is a dead end?
I hope it is not too late, the issue was fixed in the weld version 2.2.0.Alpha1.
After migrating to CDI/Seam 3 I'm getting these messages in my server log:
WARN: Cannot attempt extension on null.
I saw a post in the Seam 3 forum (which is not accepting new posts at present)
with some logging from org.jboss.seam.faces.environment.SeamApplicationWrapper
which looks like it will help me diagnose the underlying cause of the messages.
Can anyone tell me how to enable this logging level on a Glassfish server? I
could see nothing in the Seam 3 FAQ to help me.
Thanks.
I'm using Glassfish 3.1, JSF 2.1.3, Weld 1.1.1 & Seam 3.
I'm no expert, but have you tried adding the line
org.jboss.seam.faces.environment.SeamApplicationWrapper.level=DEBUG
to your domain's logging.properties file? It's in the config directory of your domain (e.g. [glassfish-install-directory]/glassfish/domains/domain1/config/logging.properties).
I have been developing a small project meant to run under weblogic 8.1.
Richfaces according to documentation states that it supports weblogic 8.1.
Weblogic 8.1 uses servlet specification 2.3 with jsp 1.2
This has been working on my locally installed version of weblogic 8.1 but when deploying to the sparc server, I start running into trouble. I have worked through some of the initial headaches, but then I got an error 500 and couldnt get the details. But after some effort I have come out with this...
javax.servlet.ServletException: javax/servlet/jsp/JspContext
at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:344)
at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:346)
at com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:152)
at org.ajax4jsf.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:108)
at org.ajax4jsf.application.AjaxViewHandler.renderView(AjaxViewHandler.java:216)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:107)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:245)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:137)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:214)
at weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1072)
at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:465)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:28)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:141)
at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:281)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27)
at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6987)
at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:121)
at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3892)
at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2766)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:224)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:183)
JspContext is not part of jsp 1.2 it's newer. I am thinking this exception is originally a ClassNotFoundException or something similar considering the message. There is no 'cause' attached to the exception.
Following are the jar files contained in my web-application.
antlr-2.7.6.jar
asm-1.5.3.jar
asm-attrs-1.5.3.jar
cglib-2.1_3.jar
commons-beanutils-1.6.jar
commons-collections-3.2.jar
commons-digester-1.5.jar
commons-lang-2.4.jar
commons-logging-1.0.3.jar
dom4j-1.6.1.jar
ehcache-1.2.3.jar
hibernate-3.2.4.sp1.jar
jsf-api-1.1_02.jar
jsf-impl-1.1_02.jar
jstl-1.0.jar
jta-1.1.jar
log4j-1.2.15.jar
richfaces-api-3.1.6.SR1.jar
richfaces-impl-3.1.6.SR1.jar
richfaces-ui-3.1.6.SR1.jar
xercesImpl-2.9.1.jar
xml-apis-1.3.04.jar
I'm running out of options, I'll be trying to figure out who has the dependency on the JspContext class... but if someone could give me some insight it would be greatly appreciated. Oh, I cannot make many changes to the production web-logic server. I'd prefer not to make any at all, chances are those changes will be denied
Oh this error occurs when attempting to view the page, so deployment is successful.
Ok, I have solved my problem. Not the way I wanted to but it's working (atleast to what I know right now).
After using google (again) I found a comment with someone mentioning using richfaces 3.0.1.
Now I have seen many people say use version xxx even 3.3.x. After all I did get it working with 3.1.6 but on the windows version of weblogic (which could have possibly been tainted by some other weblogic version I have installed).
So I have modified my pom for maven to depend on:
<groupId>org.richfaces</groupId>
<artifactId>richfaces</artifactId>
<version>3.0.1</version>
This is not optimal, but I geuss it works.
Some taglibrary references needed changing, and packages changed to some extent.
I could post my project configuration for this if anyone ever needs it. Getting this all to work on weblogic 8.1 was not straight forward. But the reference documentation for 3.1.6 is to my knowledge incorrect by saying it support weblogic 8.1
jsp-api-2.1.jar contains the missing class, so you could try using it (either replace it in weblogic, or try in your /lib), but I can't predict what would happen.