MyFaces ExtScripting - groovy

I'm a satisfied (and historical ...) myfaces user and I'm looking for a JSF 2.2 rapid prototyping environment.
I've already used Groovy in other projects so the natural choice should be Apache MyFaces Extension Scripting.
These are problems:
1) Home page don't works (... is the project yet maintained ? ...)
2) Trying to follow example config I've noticed that the web.xml settings are wrong so:
<param-name>org.apache.myfaces.FACES_INIT_PLUGINS</param-name>
<param-value>org.apache.myfaces.extensions.scripting.servlet.StartupServletContextPluginChainLoader</param-value>
must be updated to:
...
<param-value>org.apache.myfaces.extensions.scripting.jsf.startup.StartupServletContextPluginChainLoader</param-value>
...
3) The example war (deployed in a clean tomcat 7.0 instance) don't works (no errors, no results ...)
Have anyone suggestions for me ?
Thanks in advance.

Related

Multiple JSF related files in Weblogic modules folder

I have recently installed the WebLogic 12.1.3 on my local windows 10 desktop. Created a very small webapp and it ran fine until I added the beans.xml.
Adding the beans.xml and starting the server, I get the error : weblogic.management.DeploymentException: java.lang.NoSuchMethodError: com.sun.faces.util.Util.isCdiOneOneOrGreater()Z
I could sort of understand it is something related to a mismatch in JSF versions. Then, I started searching and stumbled upon this beautiful answer from BalusC.
How to find out the current version of Mojarra which my WebLogic is using?
The above answer says "Another way would be to explore the JSF module in /wlserver/modules folder of WebLogic installation. In my 12c installation, the filename says glassfish.jsf_1.0.0.0_2-1-20.jar, which in turn identifies Mojarra 2.1.20".
So I checked to see what is there in my modules folder and I got more than 1 jsf jar. My question (preferably to BalusC :-) but also to anyone who can help) is
- if it is fine or not to have multiple JSF related jars in the modules folder.
- if this multiple JSF jars is the reason for the error ?
- if I can clean up (manually delete) files in this "modules" folder to have one version of JSF related files ?
Note : All these stuff came out of the box with the 12.1.3 installation.
JSF related files found in my "\wlserver\modules" folder
glassfish.jsf_1.2.0.0_1-2-15.jar
glassfish.jsf_2.0.0.0_2-1-20.jar
javax.jsf_1.4.0.0_1-2.jar
weblogic.server.modules.jsf_12.1.3.0.jar
weblogic.server.modules.jsf2.0_12.1.3.0.jar
weblogic.server.merge.modules_12.1.3.0.xml
weblogic.server.modules.extra_12.1.3.0.xml
weblogic.server.modules.jsf_12.1.3.0.xml
weblogic.server.modules.jsf2.0_12.1.3.0.xml
Thanks a lot in advance.
Using JSF and JSTL With Web Applications:
https://docs.oracle.com/middleware/1213/wls/WBAPP/configurejsfandjtsl.htm#WBAPP197
it will depend if you are embedding the JSF jar's.
I think you need to upgrade JSF, embedding the jars and using Filtering Classloading.
<prefer-application-packages>
<package-name>javax.faces.*</package-name>
<package-name>com.sun.faces.*</package-name>
<package-name>com.bea.faces.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>javax.faces.*</resource-name>
<resource-name>com.sun.faces.*</resource-name>
<resource-name>com.bea.faces.*</resource-name>
<resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
<resource-name>META-INF/services/com.sun.faces.*</resource-name>
</prefer-application-resources>
It looks similar (jboss) to: java.lang.NoSuchMethodError: com.sun.faces.util.Util.isCdiOneOneOrGreater()Z

Can a jetty 5 custom classloader exclude specific jar files in a war?

I've got a large code base that currently runs on JSF 1.1 on embedded Jetty 5.1.14 server (Servlet 2.4). I've managed to get a JSF 2.0.9 app running on this version of Jetty even though I'd expected to require servlet 2.5, and I add EL 2.1.2 & the JSF jar to WEB-INF/lib. This works on a jetty config that excludes JSF 1.1.
The production environment consists of a large number of war and jar files on a single server instance.
JSF 1.1 is currently in the server ext/lib folder, and in a single war file I'd like to include the JSF 2 jar in the WEB-INF/lib. This is not possible as the server JSF version will load first and cause classpath pollution.
However would it be possible to eliminate the JSF 1.1 jar loading in just the one war file with a custom classloader? The documentation seems to cater for the case of adding paths to the classpath rather than excluding things. I wasn't clear whether it's loaded in the context of the server as a whole or just the war.
A little more information: Another potential solution is to simply upgrade to Jetty 8 and JSF 2.1+. Apart from convincing management that this is a good idea, we use an old WebMethods7 version, this has a graphical layout tool that produces some XML that is translated by a Component Application Framework, which uses the JSF APIs to generate content (so only a very few JSPs). This would simply be a case of seeing if it works, and if not having a total rethink because of the need to keep supporting this WebMethods "code".
The main goal here is to ultimately run up to date software although not necessarily in one step.
Jetty5 is incredibly old at this point and I would recommend working on the update to jetty8, or waiting a couple of months and making the jump to jetty9 which we are currently releasing milestones for. Changes in the newer jvm's since then alone are enough reason to update your jetty container.
I don't know if this approach was supported in jetty5 or not, but in jetty6 we have ability on the webapp context to modify the classes that are exposed to the context via system and server classes. If those hooks exists then you should be able to tweak that specific context to not expose the classes in the jar in ext/lib.

Apache TomEE: want to user Mojarra JSF in my project instead of built-in Apache MyFaces

I have a related question. I am migrating my project from Jboss to TomEE. I was using Mojarra JSF, and have been having problems trying to get everything working using MyFaces (view Encryption problems, UI problems, ajax problems, etc). I just want to include Mojarra jars in my project, but looks like they are clashing with the built-in MyFaces jars that comes bundled with TomEE. I keep getting UnSupported exceptions.
Is there a way to specify that the Mojarra JSF should override myfaces? Is there a web.xml parameter or something? By the way, I am not using Maven (I've seen many examples with pom.xml dependency tags that cannot help me).
I tried that for 3 days, after making many tweaks(error stack-> google ->change some exotic xml parameter-> new error stack->google->change some exotic xml parameter etc....), I could make it work, except that EJB injection was not working anymore (getting null). So I surrendered and use myfaces instead of mojarra.

Seam application RichFaces not loading components

I have a Seam application running on:
Linux CentOS
Tomcat 6.0.32
Java 6
JBoss Seam 2.2.1
RichFaces 3.3.3
When I run my application locally, everything works fine (Windows 7 here). But when I put the exactly same files on my server (VPS), the Tomcat starts with no errors, but the application do not load RichFaces components.
I've searching the solution for this problem for a few days, but didn't found nothing that can help me. I thought could be a permission problem (application's folder permission), so I've tried to change it too many ways, but RF components keep not loading.
Anyone can imagine what is happening?
Thanks in advance!
Fabricio Braga
I have solved the problem. The point is that in my case I have an Apache HTTP Server before Tomcat, and RichFaces add some JS files from JAR files. So, we need to map, editing apache config files to redirect also this JS files to Tomcat.
Then, I just edited this Apache mappings to point RichFaces JS files to Tomcat, for example:
"/my-domain-name/a4j/g/3_3_3.Final/org/ajax4jsf/framework.pack.js" mapped there: "/my-domain-name/a4j/*" for the Tomcat. And the same for the others files.
After that, the problem was over.
Regards,
Fabricio Braga

Websphere 7 and JSF 1.2 - Application was not properly initialized at startup, could not find Factory

JSF 1.1 and websphere 6.1 was working properly in my case. Once I deployed that to a websphere 7 server, I received the following error -
Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactoryat javax.faces.FactoryFinder.getFactory(FactoryFinder.java:270)
at javax.faces.webapp.FacesServlet.init(FacesServlet.java:164)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:358)
at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:168)
Not sure what it means, I have enabled JSF1.2 as project facet in the RAD but still keep getting the above error message and none of my jsf files are working.
EDIT
After following BalusC's comment, I see the following directories are lookup by the code (this is the o/p of url.getPath())
/C:/IBM/SDP/runtimes/base_v7/profiles/AppSrv01/properties/
/C:/IBM/SDP/runtimes/base_v7/properties/
/
/C:/IBM/SDP/runtimes/base_v7/java/lib/
/C:/IBM/SDP/runtimes/base_v7/lib/
/C:/IBM/SDP/runtimes/base_v7/deploytool/itp/plugins/com.ibm.etools.ejbdeploy/runtime/
/C:/IBM/SDP/runtimes/base_v7/installedConnectors/sib.api.jmsra.rar/
/C:/IBM/SDP/runtimes/base_v7/installedConnectors/wmq.jmsra.rar/
/C:/DETSphere10/DET_FALL9.0/DETEJB/classes/
/C:/DETSphere10/DET_FALL9.0/.metadata/.plugins/org.eclipse.wst.server.core/tmp0/DETWEB/
There is no jsf impl in among these directories. Now I am more confused as the original lib should be present under c:\IBM\SDP\runtimes\base_v7\plugins !!
This is a typical error when there are multiple different versioned JSF libraries in the classpath. Websphere ships with builtin JSF libraries. If you'd like to use the webapp-supplied JSF libraries, then you need to set the classloading policy to module after deploying. This usually defaults to application which means that the webapp libraries are loaded by the main classloader. The main classloader may happen to have loaded the JSF API library. When its version is different from the JSF IMPL library in the webapp, then you may receive this kind of errors.
Update to help with nailing down the root cause better here are 2 suggestions:
You can reveal all used classpath roots on the local disk file system as follows:
for (URL url : Collections.list(Thread.currentThread().getContextClassLoader().getResources(""))) {
System.out.println(url.getPath());
}
Execute this in ServletContextListener#contextInitialized() or so.
(eventually after finding that out), install WinRAR, associate it with JAR file type and use its file-search facility to search for a JSF specific file like FacesContext.class and FacesContextImpl.class so that you can find all JAR's which contains the JSF API/impl. You can find out the exact JSF version by extracting the JAR and reading the MANIFEST file.
You need to keep the JSF JAR's (icu4j.jar and jsf-ibm.jar if you are using IBM's component library) in your /WEB-INF/lib folder.

Resources