Although JRebel can reload Java class changes in my project, it can not reload JSF changes. When I change a JSF file I can not see any logs etc.
Here is my rebel.xml:
<classpath>
<dir name="${projectDir}/classes">
</dir>
</classpath>
<web>
<link target="/WEB-INF">
<dir name="${projectDir}/war/conf">
</dir>
</link>
</web>
All JSF files are in ${projectDir}/war/. I use JBoss and IntelliJ IDEA. In the project, Ant creates an ear file and deploys it to JBoss.
How can I use JRebel to reload JSF files? Should web tag in rebel.xml point JSF files or compiled XHTML?
I have had a similar problem, and for me it was the parameter javax.faces.FACELETS_REFRESH_PERIOD which needs to be set to 0. The parameter is set in the web.xml.
<context-param>
<param-name>javax.faces.FACELETS_REFRESH_PERIOD</param-name>
<param-value>0</param-value>
</context-param>
There is a good blog entry here describing the different available configuration parameters:
Time in seconds that facelets should be checked for changes since last request. When a page is requested, what interval in seconds should the compiler check for changes. If you don't want the compiler to check for changes once the page is compiled, then use a value of -1. Setting a low refresh period helps during development to be able to edit pages in a running application.
So in short, setting the value to 0 during development should enable immediate reloading of the files.
Related
I'm having a lot of issues getting Netbeans 12 to hot deploy a JavaEE project (using Ant) to Wildfly. Surprisingly, any changes to my Java code hot deploys as usual upon save, but any changes to my web markup (.xhtml) will only show up after a fresh deployment.
Here's a list of what I've done and my current settings:
Settings:
Copy Static Resources on Save
Compile on Save
In my web.xml:
<context-param>
<param-name>javax.faces.PROJECT_STAGE</param-name>
<param-value>Development</param-value>
</context-param>
What I've tried:
Reviewed the following questions and applied changes where applicable (most was not applicable given my version of Wildfly)
How do I enable on-the-fly compilation of JSPs in Wildfly 9?
https://developer.jboss.org/thread/237954
Netbeans 8.2 + wildfly 11 hot deploy not working [I've had this issue in NetBeans 8.2 instances too! No resolution]
Wildfly system Property:
<system-properties>
<property name="java.net.preferIPv4Stack" value="true"/>
<property name="org.jboss.as.web.deployment.DELETE_WORK_DIR_ONCONTEXTDESTROY" value="true"/>
</system-properties>
Wildfly Deployment Scanner:
<subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
<deployment-scanner path="deployments" relative-to="jboss.server.base.dir"
scan-interval="100"
auto-deploy-exploded="true"
untime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/>
</subsystem>
In addition to the above, I've also modified the Ant script to copy the required files over to the appropriate directories. This DOES work, but each time I do this, I lose any session state with the app that I had prior to the save.
What I'm hoping to achieve is to be able to modify either my backing Java code or my front-end markup and upon saving the file (or clicking the hot deploy button, doesn't really matter to me) have the changes reflected on my application server.
I've worked on other projects that used WebLogic as the application server with no issues. Netbeans (8) simply "works" when you attach the debugger and modify a file (using WebLogic). The changes are immediately reflected in the browser upon a refresh without loss of state. I'm hoping that I'm missing something really small and it's easy to do with Netbeans 12 + Wildfly as well.
Thank you!! Hopefully I'm just missing something small!
I'm reviewing a current JSF project where the web.xml configuration contains:
the FacesServlet (configured on *.xhtml)
the com.sun.faces.config.ConfigureListener
I'm using JSF 2.2 and Mojarra implementation.
I'm confused about the ConfigureListener. Is this class needed in the configuration? What is the goal of this class? I couldn't find any information and the class has almost no javadoc.
If I remove this configuration, everything seem to work the same way. Thus I guess that the ConfigureListener could or should be removed but I am not sure.
The ConfigureListener is normally automatically registered via /META-INF/jsf_core.tld file of Mojarra implementation JAR file. Additionally, the ConfigureListener is explicitly registered via a Servlet 3.0 ServletContainerInitializer in order to workaround an old GlassFish v3 bug (note: v3, not 3.0.x, thus really that one first GF3 version ever).
There exist situations wherein the auto-registration via .tld file is insufficient. The well known one is when the webapp is deployed to Jetty. This is explained in detail in this Q&A: could not find Factory: javax.faces.context.FacesContextFactory.
Also, as mentioned before and in that detailed answer, GlassFish v3 has a bug wherein the TLD file is scanned too late and thus JSF couldn't do its necessary initialization thing at the right moment. You'd then need to explicitly register the ConfigureListener in webapp's web.xml.
But if it works for you when it's not explicitly registered in web.xml, then just keep it out. Less noise in web.xml is better. But if you happen to possibly deploy to a container sensitive to the mentioned problem (so when your webapp is actually a publicly distributed one and you have no control over choice of target container), then you'd better keep it in "for the case that".
Update: It appears that Tomcat 8.x shows buggy behavior when this entry is enabled in web.xml: this listener will actually be executed twice instead of only once. The consequence is disastrous: among others, all JSF event listeners will be registered twice and component libraries will be loaded twice. This leads only to conflicts during runtime. In other words, when deploying to Tomcat, make sure that this entry is removed from web.xml.
I added OmniFaces to use the CombinedResourceHandler.
But now the PrimeFaces Extensions <pe:ckEditor> doesn´t work anymore.
Is there any workaround for this issue?
Unfortunately, this is a known issue caused by the way how PrimeFaces Extensions loads and manages its JS resources. This was already ever reported as an issue on old Google Code host and is mentioned in the current OmniFaces known issues wiki as follows:
PrimeFaces Extensions <=0.7.1-4.0.0 (and probably future versions)
PrimeFaces Extensions JS resource primefaces-extensions.js is incompatible with CombinedResourceHandler. During load, it attempts to figure the version from its own <script> element in order to dynamically load additional CSS/JS resources. This is however absent and the attempt fails with a JS error which in turn causes the dynamic loading of additional CSS/JS resources for e.g. CKEditor to fail.
Your best bet is to exclude primefaces-extensions.js from combining by adding the following entry to web.xml telling the CombinedResourceHandler to not combine the PrimeFaces Extensions main script file:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:primefaces-extensions.js</param-value>
</context-param>
If you're using OmniFaces 2.2 or newer, then you can use a wildcard * as name:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:*</param-value>
</context-param>
If you're using PrimeFaces Extensions before version 3.0.0, then you also need to make sure that the PrimeFaces Extensions own resource handler is explicitly declared after CombinedResourceHandler in faces-config.xml:
<application>
<resource-handler>org.omnifaces.resourcehandler.CombinedResourceHandler</resource-handler>
<resource-handler>org.primefaces.extensions.application.PrimeFacesExtensionsResourceHandler</resource-handler>
</application>
This issue is fixed in PrimeFaces Extensions 6.2.8 or higher.
https://github.com/primefaces-extensions/primefaces-extensions.github.com/issues/601
I added OmniFaces to use the CombinedResourceHandler.
But now the PrimeFaces Extensions <pe:ckEditor> doesn´t work anymore.
Is there any workaround for this issue?
Unfortunately, this is a known issue caused by the way how PrimeFaces Extensions loads and manages its JS resources. This was already ever reported as an issue on old Google Code host and is mentioned in the current OmniFaces known issues wiki as follows:
PrimeFaces Extensions <=0.7.1-4.0.0 (and probably future versions)
PrimeFaces Extensions JS resource primefaces-extensions.js is incompatible with CombinedResourceHandler. During load, it attempts to figure the version from its own <script> element in order to dynamically load additional CSS/JS resources. This is however absent and the attempt fails with a JS error which in turn causes the dynamic loading of additional CSS/JS resources for e.g. CKEditor to fail.
Your best bet is to exclude primefaces-extensions.js from combining by adding the following entry to web.xml telling the CombinedResourceHandler to not combine the PrimeFaces Extensions main script file:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:primefaces-extensions.js</param-value>
</context-param>
If you're using OmniFaces 2.2 or newer, then you can use a wildcard * as name:
<context-param>
<param-name>org.omnifaces.COMBINED_RESOURCE_HANDLER_EXCLUDED_RESOURCES</param-name>
<param-value>primefaces-extensions:*</param-value>
</context-param>
If you're using PrimeFaces Extensions before version 3.0.0, then you also need to make sure that the PrimeFaces Extensions own resource handler is explicitly declared after CombinedResourceHandler in faces-config.xml:
<application>
<resource-handler>org.omnifaces.resourcehandler.CombinedResourceHandler</resource-handler>
<resource-handler>org.primefaces.extensions.application.PrimeFacesExtensionsResourceHandler</resource-handler>
</application>
This issue is fixed in PrimeFaces Extensions 6.2.8 or higher.
https://github.com/primefaces-extensions/primefaces-extensions.github.com/issues/601
I have problems running JSF in an OSGi environment. I am using jetty web container and equinox to provide the OSGi functionality. The structure of my application is as follows:
The first bundle has all the JSF libs, web.xml and a config.xml. It looks as the following:
bundle1
----src/main/java
-------de/package
----------Activator.java
----------JSFResolver.java
----src/main/resource
------ WebContent
----------META-INF
-------------face-config.xml
-------------web.xhtml
----------start.xhtml
-----------include.xhtml
----libs (containing all JSF required Jars)
The structure of the second bundle is as follows:
bundle2
---src/main/java
------de/package
----------Bean.java
---src/main/resource
------META-INF
---------face-config.xml
------WebContent
---------index.xhtml
When running the application of equinox, the bundle1 is the main bundle where all the browser requests are sent to. In the second bundle, the index.xhtml file can be retrieved the by first bundle upon request. The index.xhtml in bundle 2 gets its values and properties from the 'Bean.java' in bundle 2. The problem comes when i request the 'index.xhtml', the Bean.java class is not found. I think this is because the class loader of bundle1 cannot find it, it has no knowledge of it. So i would like to ask if anyone knows how to solve this problem. If so please do assist me, i have tried all the possibilities i had..
Is it in fact possible to have JSF run on multiple bundles using the same FaceletsContex? Can i be able to have seperate faces-config.xml files in each bundle, which can all be connected other faces-config.xml in other bundles? Can anyone please provide me a solution. Sample code would help.
If any one is interested in the answer, in this case, the faces-config.xml is of no use. So i had to use the plug-in.xml file to register all my beans across all plug-in projects. I created an extension point in the main plug-in, which other plug-ins could register their Beans as extension. I had to override the managedBean class of JSF for it to be able to read the bean properties from extension point rather than from the faces-config.xml.
So during runtime, the application reads all extensions registered in the managedBeans extension point, and then creates all the required bean instances from all plug-ins. Therefore the error will no longer be there. If anyone wants to implement JSF in such a structure, you should know that almost all the functionality in the faces-config.xml will have to be moved to the plug-in.xml of the plug-ins, this includes the navigation rules aswell. One has to do alot of customizations but at the end, you get a nice modular JSF application running on equinox, without having to embed it in a .WAR file.. which seems to be very advantageoous.