I have a web application I'd like to edit while it's already deployed.
The part I'd like to edit is inside ...applications/myapplication/WEB-INF/classes/META-INF/*.xhtml.
I have a tool that I use to generate these XHTML files and insert them into the aforementioned directory. In a production environment actually these XHTML files are part of a jar project included as a dependency in the main web application.
But what I need is to make hot deploy during development.
I can do it by removing the jar dependency and adding the XHTML in the directory mentioned above. But updating it later doesn't do the job.
Any idea?
If you're using IntellijIDEA, just go to the configuration of glassfish server and select "Update Resources" on "Frame Deactivation".
Related
Here is the start of my JSF file:
<?xml version='1.0' encoding='UTF-8' ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:ace="http://www.icefaces.org/icefaces/components"
xmlns:c="http://java.sun.com/jsp/jstl/core"
xmlns:f="http://java.sun.com/jsf/core">
<h:head>
</h:head>
<h:body>
However, http://www.icefaces.org/icefaces/components and http://java.sun.com/jsp/jstl/core are highlighted in red with error URI is not registered. This causes many other subsequent tags to appear in red with errors element 'x' is not allowed here. Here is an image showing what I mean:
Attempted solutions:
When searching for a solution, it appeared some others with the same problem solved it by doing "Fetch External Resource". However, this didn't work for me. For the icefaces xmlns xmlns:ace="http://www.icefaces.org/icefaces/components" I get the error: Error while fetching http://www.icefaces.org/icefaces/components. And for the jstl xmlns xmlns:c="http://java.sun.com/jsp/jstl/core" I get the error: No XML at the location: http://java.sun.com/jsp/jstl/core.
I also found some people solved it by deleting the IntelliJ IDEA metadata file workspace.xml in the .idea directory. This does seem to work temporarily... but then it seems the problem comes back after a while. I also have to reconfigure several project settings which I would like to avoid.
Any help would be appreciated.. I'm not really familiar with the xmlns stuff and still a beginner to web app development. Thank you!
Update:
As per Mark Vedder's answer, I manually added external resources to my project and the problem has not resurfaced thus far.
With unregistered resources, the first solution is to use the "Fetch External Resource" quickfix. If that fails, as it has for you in this case, (usually because the "location" is in name only) you need to manually configure it.
To Manually Configure
If the resource (i.e. the .xsd, .dtd, etc.) exists in one of your library jars, skip to step 2. Otherwise, download a copy of the resource. Put it somewhere convenient on your system.
In IDEA, with your cursor on the error, open the Quick Fix / Intentions menu by typing Alt+Enter and select "Manually Setup External Resource". (If you do not have this option (based on IntelliJ IDEA version) go to the next section for instructions.)
If the resource is in a jar, select the Schemas tab and select the resource from the appropriate jar. If you downloaded it, select the Explorer tab (may be named Finder in Mac) and navigate to and select the file you downloaded.
Click OK and let IDEA index the resource.
To Edit or Set via IDE Settings
Open the settings Dialog via Ctrl+Alt+Enter or File > Settings.
To configure for all future new projects so this schema is avaiable, open the similar dialog via File > Other Settings > Default Settings
In the Project Settings section, find the Schemas and DTDs node.
Configure the desired schema. There are add, edit and delete icons in the upper right. Like above, you can select a file within a library via the Schemas tab, or your file system via the Explorer tab.
UPDATE
The various JSF Taglib definitions (for JSF 2.x and above) can be found in the com/sun/faces/metadata/taglib directory of the com.sun.faces:jsf-impl jar. The jsf-impl JAR file can be downloaded from maven central among other places.
A probable issue could be that the "Java EE: Java Server Faces" plugin is disabled. You can enable it by browsing to
Settings > Plugins and on the Installed tab search for Java Server Faces.
I tried every thing suggested here to get intellij to recognize the correct version of my jsf. At the end I discovered that I didn't have a direct reference in my web project maven dependencies to jsf-api. In other words, adding
<dependency>
<groupId>com.sun.faces</groupId>
<artifactId>jsf-api</artifactId>
<version>2.1.29-08</version>
<scope>provided</scope>
</dependency>
to my pom, fixed it. The confusing thing is that intellij was able to resolve a subset of the jsf symbols, which makes you think that the jar was being seen by it, albeit a wrong version of the jar.
In IntellijIDEA 2022 we need to add Plugin Jakarta EE: ServerFaces(JSF)
If you are using "IntelliJ Idea", please open the "Project Structure" dialog by clicking Ctrl+Alt+Shift+S, look for the JSF not found in the artifact (some thing like that) error notification, please click the fix it option and change the JSF scope to provided. It fixed my problem.
This error happens when you do not attach the library of JSF Mojarro. Download and add that library in the project.
File> Project Structure> Library
add JSF the library.
I was having same issue with icefaces resources.
One way to fix this is to give the project (again, if you already did not) the IceFaces framework support (right click on project name).
In my case I was using 3.3.0, then I set download in the Add Framework Support form.
Intellij downloaded 3.1.0 and the IDE recognizes the resource immediately after. Later I set again the 3.3.0 version.
So, I think is enough to re download the framework again, and the resources will be downloaded in META-INF folder.
Regards.-
you could also add "urn:import:<url>"
example:
xmlns:d="urn:import:com.mypackage.mylovelycode"
I had the same issue... but in my case, the problem was that by mistake I saved file with extension ".xml". Changing it into ".xhtml" solved the problem
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.
I'm developing a Liferay application, consisting on 2 different portlets, an both have to make certain operations in common, so I decided to put that operations in static methods in an external Utils class.
I have to externalize that class to avoid duplicating the same code in both portlets, and I want to have the portlets in different WAR files.
I know I can package the Utils class in a JAR file, but we are still developing and we don't want to regenerate the JAR and restart the Tomcat for every change.
Which is the best option and how can I perform it?
If you're using the Liferay SDK, you can use the clients (recently changed to shared) directory to put your common code.
A good example is how deploy-listener-shared is used in conjunction with deploy-listener-hook.
From what it looks like, all the configuration you need to do is to modify your build.xml files that will use the client\shared classes. If you look at build file of deploy-listener-hook you can see all you need to add is the.
For the new SDK:
<property name="import.shared" value="my-utils-shared" />
For the older SDK:
<property name="dependent.clients" value="my-utils-client" />
Hope this helps!
There is another method that involves building a JAR file but it doesn't require a server restart (on Tomcat at least).
Write a build script for your JAR file so it compiles, builds the JAR and finally copies it to the following location:
{tomcat}/webapps/ROOT/WEB-INF/lib
Then in your portlet open the "liferay-plugin-package.properties" (in Liferay Developer Studio / Liferay IDE this should open with a nice GUI).
Then add the name of your JAR to the "portal-dependency-jars" list in this file so in the source it would like (Or just hit the "Add" button in the GUI and select the JARs you want):
portal-dependency-jars=my-custom-lib.jar,my-other-custom-lib.jar
Save the file, and redeploy the portlet, and the JAR will be copied across when the portlet is deployed.
I've used this method for custom JARs, and 3rd party JARs that I've needed to use in my portlets.
For the development phase just package the jar file with both applications.
Unless one application depends on the other somehow it is completely ok.
Another solution is to use JRebel tool. It will allow you to redeploy jar in tomcat without restarting.
Also you may have several portlets in one .war. You may just define them both in portlet.xml.
when using jrebel, How can I make it automaticly republish static resource such as HTML javascript and jsp?
you should use rebel.xml configuration file to map your resources like jsps to the deployed app.
Check out the example: http://www.zeroturnaround.com/reference-manual/app.html#app-3.1
We are upgrading from Liferay 4.2 to Liferay 5.2.2. We are using the EXT environment. Previously, in 4.2 there was a directory called /ext/portlets. According for 4.2 doc,
"Portlets placed in this directory will be automatically deployed to the application server when running the ant deploy target from the /ext directory"
Is there an equivalent for 5.2?
At first I though that /ext/modules would do the trick, but it looks like the build file inside of /modules just unwars my portlet war file. This is not sufficient to deploy the portlets, since Liferay needs to augment the web.xml in my portlets' WEB-INF to insert servlet mapping tags.
Just for comparison, 4.2's build file in /ext/portlets directory, would call com.liferay.portal.tools.PortletDeployer and pass my war file as an argument.
I looked around, the PortletDeployer still exists in the 5. 2 code base. It is now located in com.liferay.portal.tools.deploy, but it is not called anywhere from the build files. . I wonder if this means that there is no longer a way to predeploy portlets in 5.2 Liferay. Does Liferay have to be up and running to deploy in 5.2?
If your portlets are bundled as war, and are not required to run in the same webapp as Liferay, just put your wars in the liferay deploy dir. This directory is defined in your portal-ext.properties file, and overrides the bundled portal.properties file definition of
auto.deploy.deploy.dir=${liferay.home}/deploy
At startup, Liferay scans this directory and installs any found "plugin" (portlet, theme, layout, hook...).
You may be interested in the plugins SDK for the portlet and theme creation as it could help you separate portlet developpement and core portal extension.
You should also be careful regarding your theme, it may require migration to comply to the 4.3 onward themes.