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!
Related
I deployed a portlet in liferay 7 and it got deployed successfully and was available for use. I want to replace the jsp file, in earlier version I could see my application in tomcat/webapps folder and replace it quickly.
Now I am unable to locate the exploded war in liferay 7. I can only see the war in osgi/war folder.
Can someone help me with that.
Thanks in advance.
While I mostly agree with what Olaf wrote, I do understand the need to be able to make changes in JSP files and try them quickly during development. I'm afraid I don't have the solution for that yet.
However, let me answer the question you asked:
where is war exploded in Liferay 7 tomcat after getting copied in osgi folder
It is NOT (at least not the way it was done by application servers)! When you deploy a WAR file in Liferay 7, it will automatically (on the fly) convert it into OSGi bundle and install it in OSGi runtime. This way now Liferay is fully in charge of deploying plugins and does not need to rely on various application servers.
PLEASE NOTE: Every bundle has it's own state folder. In Liferay those are in <LIFERAY_HOME>/osgi/state. If you know the bundle ID you can easily find it. It may be (I haven't checked) that you'll find some JSP files there. The reason I'm writing this is to warn you (in case you figured it yourself) to NEVER modify bundle's state folder manually. Doing so may brake the whole environment. In worse case scenario you may have to redeploy everything in clean environment.
You should not rely on behavior like this. In previous versions it was the task of the application server to compile changed JSPs at runtime. However, this is bad practice in production systems and totally screws up your maintainability. If you need to update some UI code frequently, I'm suggesting you change your implementation to utilize ADT (Application Display Templates), e.g. through Freemarker or Velocity. Those are meant to be updated at runtime, where the JSP updates were a side effect of Tomcat's default (development friendly, production hostile) configuration
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.
A very strange issue happening.
I have developed an application under JSF and Primefaces on tomcat 6 on my local computer. Everything works perfect.
But when I deploy the application on remote tomcat 6 (Under enterprise RedHat Linux), the primefaces stops working. The funniest part:
the response takes a lot of time, and it returns the generated html (so it seems like it calls the lifecycle). But no components are rendered (there is plain lot of html intermixed with javascript functions) - p:tabView and other components` contents are rendered as simple lines of text.
But as for the Javascript, it states - ReferenceError: PrimeFaces is not defined.
Catalina log file states nothing.
I have no idea what it can be. Is there any idea?
1) Check what dependencies your project has in eclipse build path. Verify all of them are available in your remote server . All the dependencies in build path should be copied to the lib folder in war file you are generating(unless they are runtime like tomcat,jdk etc).
2) Verify your web.xml and faces-config.xml is same in your eclipse and war deployed in remote.
If it doesn't work then you can compare the temp folder in your eclipse to the war you are deploying contains everything that is in local.
You can find your local war by searching for your project file in eclipse under your workspace
The problem was security for Tomcat. It did not allow any redirections so the js-files were listed in the links but nothing was fetched. Problem was solved by reinstalling tomcat.
When I am using flash scope in glassfish it lives longer than one request but works fine with jetty8 and even tried the latest version of glassfish but its not working. The JSF has a jira about it and they have solved it in the next version, I have even tried that version of jars for JSF but still same problem persists in Glassfish but works fine for Jetty8. Facing this problem from many days can anyone throw some light on this??
Jetty as being a barebones servletcontainer doesn't come with any JSF implementation bundled and the one supplied along with the webapp will always be used.
Glassfish as being a fullfledged Java EE applicationserver comes with a JSF implementation bundled and the one supplied along with the webapp will by default always be ignored. If you'd like to upgrade the Glassfish-bundled JSF implementation, then you should be replacing the JAR in /glassfish/modules folder. Or, if you'd like to force Glassfish to use the webapp-supplied JSF implementation, then you should add the following entries to /WEB-INF/glassfish-web.xml (or sun-web.xml, depending on GF version used):
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
I had the same issue. The problem was caused by Mojarra (even 2.1.11) not able to cope with HTTP chunking. By disabling it the flash was emptied as expected.
You can disable it in the admin console
Configurations
server-config
Network Config
Protocols
http-listener-[N]
HTTP tab
Chunking
I am familiar with the classloading trouble when using JSF 2 in Websphere 7. I'd like to know if there are similar problems on other fullstack application servers. What about JBoss 5+, WebLogi 10+, etc? Are there any known issues with JSF 2 and if so, what needs to be done to get JSF 2 running on these servers?
Thx
On WebSphere 5.x up to with the current 8.x you need to set the WAR and EAR classloader to PARENT_LAST in the WAS admin console whenever you want to bundle and use your own JSF impl in /WEB-INF/lib.
On JBoss 4.x up to with the current 6.x it's sufficient to add the following context param to /WEB-INF/web.xml to suppress JBoss' builtin JSF deployer.
<context-param>
<param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
<param-value>true</param-value>
</context-param>
On Glassfish 2.x up to with the current 3.x you need to add the following entries to the /WEB-INF/sun-web.xml (Eclipse with Glassfish plugin should autogenerate the template file if you create a web project with target runtime set to Glassfish).
<class-loader delegate="false" />
<property name="useBundledJsf" value="true" />
On Weblogic, sorry I have no idea, I have never used it.
In WebLogic there is a shared Java EE library that is included with WebLogic for JSF 2.0. It is easy to use and referenced through a deployment descriptor.
Here is a brief how-to for the library concept Jeff mentioned.
http://blog.eisele.net/2009/07/jsf-20-beta-1-on-oracle-weblogic-10gr3.html
Seeing the latest WLS 12c it still is in place but AFAIK you will end up having to revert the web-app classloader in the future in favor of this concept.