Understanding imported WAR in Eclipse and its folder structure - java

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.

Related

Serve Modules without publishing not working in Helios

I have recently moved a webapp I have been developing to a new machine running 64bit Eclipse Helios (Service Release 2) and I am using Maven plugin M2Eclipse.
I have deployed on a local tomcat install through Eclipse and everything is ok (more or less), but I want to select the option "Serve Modules without publishing", but when I select this option I get errors:
log4j:ERROR Could not read configuration file from URL [file:/C:/butterfly/svn/trunk/micro/src/main/webapp/WEB-INF/classes/log4j.properties].
java.io.FileNotFoundException: C:\butterfly\svn\trunk\micro\src\main\webapp\WEB-INF\classes\log4j.properties (The system cannot find the file specified)
The log4j.properties file is not there, as in my source directories in lives in src/main/resources - at build it then gets copied over to target/WEB-INF/classes/..
Eclipse seems to be mixing the expected target directory with the src directory so not finding it.
Im not sure if this is happening for just the properties file or if the same problem will occur looking for all built resources.
I have seen these issues:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=318449
http://www.eclipse.org/forums/index.php?t=msg&goto=661045&S=25bafd85b11e042c169ecf1752bfa479
but they seem to be slightly different or already fixed (My Helios is a new download from last weekend)
Anyone experience this or know how to resolve?
From here: "The Serve modules without publishing option does what it says. Web content will be served directly from the "WebContent" folder of the Dynamic Web Project. A customized context is used to make the project's dependencies available in the Web application's classloader". I would expect eclipse to emulate serving every class / resource file (including log4j.properties) from WEB-INF/classes after you build the project. As a workaround, what about creating a "classes" folder inside WebContent, copy log4j.properties file here and see if the classloader gets happy?

placing XML files in non-resources of jar with Maven

This is more of a pattern question. I am using maven to create a three module project.
Domain, Services, Site
The services module depends on the domain module. Now in the services module I am using an ORM (MyIbatis) and I need to have lots of XML files in my services module. I could place the XML files in the package that contains the .java files, or I can place the XML files under the resources directory.
My question is, what is the best pattern for when you have resources that are mapped to a single .java in the same module. Would you place that resource in the package that contains the .java or in the "resources" directory that maven uses? What are the pros and cons?
I know at the end of the day the resources and java directories get merged into the artifact (.jar), but on principal I would like to know what others do.
Update -- The reason I would like to place the XMLs in the java src directory is because I dont want to recreate the package structure under the resources directory -- to help with the maintainability of package structure changes, etc.
I would put them alongside my Java files personally. You're going to be bouncing back and forth between the object and the XML a lot, in all likelihood. It's annoying to be constantly switching between the two folders.
I put the stuff I don't go to as much while coding, such as property files or log4j.xml, in the resources folder.
But that's just me.

Java EE Directory Structure

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?

how to filter files from the root "classes" and "test-classes" folders in Eclipse?

I am using ClearCase in my application which generates a whole load of ".copyarea.db" files (one in every folder).
These cause conflicts when publishing to Tomcat as Eclipse will bundle the "classes" and "test-classes" folders into one JAR (not sure why it does this - as there is no need to have test classes available on the application server).
Any folders with the same names will have a separate .copyarea.db in the classes and test-classes branches.
I managed to get around this problem in general by adding ".copyarea.db" to the Filtered resources on the Java->Compiler->Building->Output Folder preference page. This stops the file appearing in source output (package/class folders), the vast majority of cases.
However there remains the problem of the root folder, i.e. "target/classes/.copyarea.db" and "target/test-classes/.copyarea.db".
These files are not filtered as they are not part of the compile task.
Just deleting the files manually doesn't help either, as Eclipse expects to find them and doesn't.
How can I exclude these ".copyarea.db" files from the root "classes" and "test-classes" folders?
This file .copyarea.db is created in each directory of a web view (through CCRC, the remote client of ClearCase).
The simplest solution would be to not put under source control the directories classes and test-classes.
Then, as illustrated by this technote:
Otherwise, the directory should not be controlled.
If the directory is not controlled, then the .copyarea.db file within it should never be created.
If the directory was accidentally added to source control, this could be prevented in the future by adding classes to the ignore list. This would avoid the directory being passed to ClearCase during the Share.
Since you don't usually version the binaries produced under classes and test-classes, removing those folder, and adding them again manually (keeping them private to your view) is an acceptable solution.
If those folders are not under version control, then those copyarea.db come from versioned folders which contain them, and have been copied to the destination folder.
In that case, you can simply remove the copyarea.db files.
But since you said that Eclipse "expects to find them and doesn't", I assume those "classes" and "test-classes" folders are not private folder.
concerning
These cause conflicts when publishing to Tomcat as Eclipse will bundle the "classes" and "test-classes" folders into one JAR (not sure why it does this - as there is no need to have test classes available on the application server)
you can configure this in project properties, build path, order and export, or use maven and m2eclipse!

Installing Solr onto a hosted tomcat server

I have installed and configured tomcat+solr on my personal linux machine and windows as well. I was able to get them working fine. I'm very new to Java and how the file structure works. (i.e. knowing where to put war files and what WEB-INF is) So now that I am ready to install solr and configure it on my clients shared hosting plan, the directions are different from what I did before. I dont want to mess this up and apparently the webserver reboots daily and I dont think I can do it manually which means I have one shot at this every day.
Here is the directions for installing a tomcat servlet on his hosting provider:
http://www.apluskb.com/scripts/Where_do_I_put_my_answer1186.html
As you can see I need to install solr under the html/WEB-INF directory, but read what it says.. its very confusing:
"All Servlets should be uploaded in the /html/WEB-INF/classes directory. Any unpacked custom classes and resources should be uploaded in the /html/WEB-INF/classes directory, while classes and resources packed in Jar files should be uploaded to /html/WEB-INF/lib."
uhh... so which is it? /classes? or /lib? I dont think they explain that very well and I'm a little confused by this statement. Also what exactly do I install? With a normal solr install, solr is put somewhere else, the war file is copied into tomcat and the rest of solr is referenced using some kind of XML configuration file.
Also, since I'm a little new to Java and servlets, can someone explain the tomcat file structure to me (in great detail will definitely get you a +1 from me) and where things should go and why?
Thanks in advance!
Web application structure is defined by J2EE spec, it's not limited (or specific) to Tomcat per se. Here is a detailed tutorial covering its layout. Briefly, however, it's as follows:
There a base (root, home, whatever you want to call it) folder which serves as root of web application, everything else goes under it.
All public stuff (html, images, CSS, javascript, JSP, what have you) goes under that folder (directly or via subfolders).
There's one special folder, also located directly under root, called WEB-INF. It contains non-public stuff, like application descriptor (web.xml), classes (which go into WEB-INF/classes folder), libraries (WEB-INF/lib) and possibly configuration files.
Application can be deployed either using expanded structure above or as WAR (web archive) which is basically an archive containing everything above starting at root folder level (but not including root).
The distinction between classes and lib folders is simple: all packaged libraries (JAR files) need to go into lib; all unpackaged classes (and resource files that need to be in classpath) have to go into classes preserving their directory structure (e.g. com.mypackage.Blah class should go into classes/com/mypackage/)
In your case, it looks like you can only have one web application deployed and it has to be deployed to /html folder. If you're deploying a war file, you need to extract it to that directory (e.g. from within that /html folder run jar xvf solr.war or whatever it's called).

Categories

Resources