I have a problem with following tutorial:
http://www.mkyong.com/jsf2/jsf-2-internationalization-example/
In faces-context file you have to declare the place where all the language properties-files are (<base-name>HERE</base-name>). But in that example they use apparently maven2 and so they have a resource folder.
I am using eclipse and dynamic web project, that's why there is no resource folder. I tried a few possibilities like adding a new folder to the build path but I don't get it work.
Can you tell me please where to place those files to let my app find it. thank you so much
In addition I add a picture of my directory-structure:
They need to end up in the runtime classpath. The WebContent isn't part of the runtime classpath.
In your case, just drop them in the Java Resources folder. Imagine that they are placed in a package com.example.i18n, then you can specify as basename com.example.i18n.locale (although I would prefer text or messages over locale since they are actually no locale files).
Related:
How to internationalize a JSF 2.0 webapplication with UTF-8 properties files without native2ascii?
Related
I have implemented log4j in my web application project. Project is done using net beans,using tomcat 7.0.41. At first,I created log4j.property file and placed under web page->Web-INF->classes->log4j.properties in net beans and it asks me to locate the file in my project,so I manually located that file to implement log4j in my application. After that I changed the place of the log4j.properties file to myproject->build->web->WEB_INF->classes->log4j.properties in location of my project saved, now its working fine, it did not ask me to manually locate the property file, It takes automatically when my class files executed. Now my problem is that once I committed the project and again checkout the project on some day, property file does not appear and it again ask for property file. So where can I create the log4j property file in my project so that my team mates can utilize it when they checkout project in their system.
Normally you put log4j.properties to src/main/resources/ and it will be copied to the right place by the build process.
I never use net beans, but I think put log4j.properties under Classpath will work.
Not sure how Net Beans handels this, but i think that the "build" directory is where the "compiled" project is put to.
So i would not recommend to put any files there which should be versioned because mostly those directories are ignored for versioning ( see .gitignore files for example when using git).
Resources like property files should be within the sources and your IDE should copy them to the correct place when building the project.
I am using jquery i18n plugin to internationalize the messages placed in jquery/js.
i have below project structure.
I have some.js file in js folder and inside some.js file i have to refer a properties file which is located in src/main/resources folder. can i do as below?
jQuery.i18n.properties({
name:'Messages',
path:'resources/', //as i have properties file in src/main/resources am referring.
mode:'both'
});
Maybe. You need to understand that Java source paths and Web paths are unrelated unless you write some code to connect the two.
My suggestion for requirements like this is to put all resources into a certain package (which doesn't contain anything else, especially no classes in src/main/java).
Also note that src/main/resources will be gone when you deploy. After deployment, all resources will be available from the Java Classpath and relative to the classpath root. So if the source path is src/main/resources/foo/, it will be foo/ at runtime.
If you use Spring on the server side, you can use mvc:resources.
This question has a solution without Spring: Servlet for serving static content
I am wondering why some resources files are put under the META-INF directory in the JAR? I am always put the resources like test.properties under the root diretcory. Any advantage to put them in the META-INF?
Lot of Java (EE) APIs have a contract that when you put a specific configuration/metadata file in the META-INF folder of your (or a 3rd party) JAR, then the API will automatically do the API-specific job, such as scanning classes, preloading specific classes and/or executing specific code based on the meta information.
An example provided by the standard Java SE API is the ServiceLoader. Among others, the JDBC 4.0 compatible drivers implement this. This way just dropping the JDBC driver JAR file folder will automatically load the driver class during Java application's startup/initialization without the need for any manual Class.forName("com.example.Driver") line in your code.
Further there is also the Java EE 6 provided JSF 2.0 API which scans during application's startup all JAR files for a faces-config.xml file in the META-INF folder. If present, it then will then take it as a hint to scan the entire JAR file for classes implementing the JSF specific annotations like #ManagedBean so that they get auto-instantiated and auto-configured. This saves time in potentially expensive job of scanning thousands of classes in all JARs in the entire classpath. In older versions of those API's the configuration was usually done by (verbose) XML files.
All with all, the major goal is to save the developer from code and/or configuration boilerplate. The JAR's META-INF folder is used for configuration files/hints. Some API's indeed also put static files/resources in there for own use. The META-INF folder is also part of the classpath, so the loading of those files by the classloader is easy done.
In servlet 3.0, certain static resources are available through the web context, such as .css, java script, and .png files, so you no longer need to use ServletContext getResource() and getResourceAsStream(). For more information, check out web-fragment.xml (https://blogs.oracle.com/swchan/entry/servlet_3_0_web_fragment) which is one resource that covers this subject.
Personally, I prefer to structure my projects the way Maven likes them, with a src/main/resources directory which is part of the application's classpath.
It's just a convention that some (most?) third party jars use to look for files that you provide. For your own classes and files, you can choose to put them where you like.
I'm using internationalization with Spring, and the properties file needs to be on the classpath. I also have some XML files that will need to be on the classpath. Is it acceptable to just include those resources inside the "src" in a sub-directory, and then let them build to the classpath, or is it better to add a different folder to the classpath during startup? I'm using Ant, but from the looks of it this was the approach Maven took (everything under src or test). I'm looking for the most widely accepted industry standards or better alternatives. Thanks!
Is it acceptable to just include those resources inside the "src" in a sub-directory, and then let them build to the classpath
Depends on the sole purpose of the resource in question. With this approach, any minor edit in such a resource file would thus require a full rebuild, redeploy and restart.
This may not necessarily harm for one-time-read startup and applicationwide configuration files like web.xml and application.xml and consorts since that would usually affect (or be affected by) changes in Java source code which require a full rebuild/redeploy/etc anyway.
But in case of runtime files like i18n properties files and environment-specific configuration files (which would/could be managed by a non-developer like a serveradmin or a customer), it is not useful to package it inside the webapplication. This requires knowledge how to rebuild the webapp after edits. You would rather like to externalize it so that only a webapp restart is required to reflect the changes in the configuration, or maybe even not at all, like for ResourceBundle which will just reload automagically.
I myself usually put such files in a fixed path along the servletcontainer and add that path to the servletcontainer's runtime classpath. In case of for example Tomcat, it's configureable as shared.loader property in /conf/catalina.properties. E.g.
shared.loader=/var/webapp
Anything in this folder is then taken in the servletcontainer's (and webapp's) runtime classpath.
Anything you put in your WEB-INF/classes directory is automatically in the CLASSPATH.
I usually put only .java files under /src and /test directories. Any resources that I put elsewhere have to end up in WEB-INF/classes. It's either my IDE (IntelliJ) or Ant that put them there when the WAR file is created.
I would recommend following the Spring examples and put resources where they do.
For example, if you use Velocity as your templating engine, you'll see that Spring configuration allows you to put them under /WEB-INF/vm_views.
Properties are put in WEB-INF/classes.
Check the Spring docs for examples.
I have just imported a WAR file from an external site, which is basically a servlet into Eclipse IDE (the project runs on Apache-Tomcat).
When I import it it has a folder called Web App Libraries. So here are a few of my newbie questions:
I am unsure about what the exact purpose is of this folder is? What does it do, why would you choose to have it in your project?
I see that it has a folder called Improted Classes and foobar.class files inside it - why?
(These seemed to be mirrored in Web Content folder - although here you can modify the code as they are foobar.java.)
There are references to foobar.jar files too - these are also mirrored in WEB-INF/lib folder too - why?
I know these are basic type questions but I'm just getting to grips with Java and website dev, so apologies if they sound a bit dumb! - BTW if anyone knows any good online resource to understand more about project file structures like this, then let me know. I just need to get to grips with this stuff asap - as the project deadline is fairly soon.
Cheers.
Here's a screenshot just to help you visualise:
I assume this is a screenshot from the 'Project Explorer' view. It does not display exact folders and files structure, is adds a few candy constructed from project's metadata.
To see real structure of your project, try switching to the 'Navigator' view.
During a WAR file import, Eclipse basically does two things:
Creates a new web project and copies WAR's content to 'WebContent' subfolder of the new project.
Based on the WAR, it constructs project's metadata (.project and .classpath files).
The 'Web App Libraries' section displays list of jar files that the WAR contained (in WEB-INF/lib
'Imported classes' (which I also see for a first time) seem to contain classes found in the imported WAR (WEB-INF/classes), for which Eclipse was not able to find any corresponding source files. To fix this, create a new Java source folder in the project and move the classes you now have in 'firstResource' folder to it.
Web App Libraries isn't a real directory, but rather a listing of what Eclipse thinks are this project's libraries.
Generally, this consists of all the jar files in WebContent/WEB-INF/lib/
Sometimes, Eclipse no longer lists them in their real directory in Eclipse's Package Explorer... but they're still there if you look with another program.
In Eclipse, if you are using the Java Web Development view, you'll have configured:
A Tomcat Server runtime that provides the servlet libraries
A Java Runtime
Other required libraries
The Web App Libraries that are in the project duplicate the first setting, so that you don't need a local Tomcat installed on the development box.
The rest sounds messy to me.
You have your src / JavaSource folder with the raw Java files in it. They shouldn't be in Web Content - that's for your HTML, images, JSPs, etc.
So a typical project setup:
Project Name/
JavaSource/ or src/ // holds all the Java Source Files, Servlets, Struts Actions
WebContent/ // Nice root folder to hold web content files
content files and folders
WEB-INF/ // Web App Config folder
lib/ // Libraries (but not tomcat ones)
web.xml
classes/ // Where your compiled Java goes, and configs (log4j.properties)
Some people put the JSP inside WEB-INF too, as it isn't required to be accessible in the JSP file state, only in the compiled state that Tomcat does itself.
Its simple, eclipse provides multiple view to your project structure. The view you are looking at is definitely the Package Explorer view. In that view, everything that has a special icon in front is a helper item which is there to help you out by simplifying access to certain stuff like external libraries (which are provided by software on your computer or eclipse itself or other project).
In eclipse, go to menu->window->show view->navigator
The Navigator view will tell you the real folder structure of your project.