I am currently working on an EAR application which has a WEB project and EJB project in it.
To work on eclipse with local set up i do so many build path setups and all.
All these buildpaths show up in .classpath of the project.
Now when i export the EAR and deploy on Server everything works on server.
My doubt is how does server know about my local system paths which are present in .classpath of my project.
Does it mean .classpath has no significance at runtime?
Please explain.
.classpath file is eclipse specific, it will not be bundled with the EAR. Eclipse uses it to set the classpath for the project.
An EAR has a well defined structure and Servlet container understands that structure, using it's knowledge it prods around in the EAR file and extracts classes to load in the runtime.
Obviously server doesn't have any knowledge of your local environment. An EAR (or WAR or JAR) file is a simple archive file (with some specification or the file order and all). You can unzip it using any utility (something like 7zip). Check the structure of the packed EAR, that will give you a better understanding of what goes to your server.
Related
I have a project which in the meantime runs locally on Tomcat but I'm planning to deploy to some server in the future.
I have a few questions:
I'm using tomcat-jdbc.jar. How should I include that jar in the project? copy it to WEB-INF/lib or add a library reference to tomcat? is the latter portable? Can I use this jar even if the server I'm deploying to is using jetty?
When I added the JRE, eclipse asked me to point it to the JRE path. The line that was added in the classpath was
classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"
How does eclipse figure out from this line where the JRE is at?
When the project is deployed to the server, how would the project hierarchy look like?
My guess is:
<project name>
----<build> (.class files)
----<WebContent>
--------<META-INF>
------------MANIFEST.MF
--------<WEB-INF>
------------<lib>
----------------external_jar.jar
------------web.xml
---------index.html
Is this correct? if so, how will the runtime know where to find the JRE? or the tomcat-jdbc.jar which is in the Tomcat installation folder?
Your application needs the following three types of "resources"
System Resources: JRE classes, some extensions/libraries provided by the server you deploy on.
Your dependencies: Any libraries you use, say common-utils, poi etc. These JAR files go in your web-inf/lib folder
Your classes. These are deployed with the WAR file at web-inf/classes
So, to answer your questions:
If you are deploying to Tomcat, the tomcat-jdbc.jar will be provided. Take care of the version though. If your prod server will be tomcat but dev is say Jetty, then you need to provide this jar in your local IDE, but not export it in the WAR file. But if you are developing on tomcat and say deploying on some other server, then this jar has to be bundled with your war file (web-inf/lib folder). Dev and Prod servers need not be same, but take care of the JRE version and dependency on Prod server provided libraries.
JRE is a configurable setting for your server and also your IDE (Eclipse)
Project hierarchy is correct, but you will most probably deploy as WAR file, so your build folder is exported in web-inf/classes. You can verify by opening the WAR file with any zip editor.
Regarding the portability of tomcat-jdbc.jar
Unfortunately this depends on the tomcat library and version. There might be more dependencies of this jar file which might cause problems later on. I would recommend not relying on this jar unless you plan to deploy on tomcat.
you should test your application with the same server you're going to use in production.
to see and set the jre properties eclipse->preferences->java->Installed JREs.
If you export a war file, all files in WebContent will be in the war and the .class files from src folder will be in WEB-INF/classes.
When you uses a server like tomcat, it uses the configuration you setted on it.
If you want the application to always reference your jar, put it in the web-inf lib.
As Daniel has mentioned below,eclipse gets the JREs from the installed JREs under the preferences tab. You can have multiple JREs installed and configured in your eclipse and then select individually for a project and also select default.
3.Your project hierarchy is correct. The runtime will get the JRE from the JAVA_HOME environment variable set on the server.
1) Pool connections, it's a service provided by Application Server (Tomcat in this case). IMHO you have to avoid bind your application with specific implementation, in that case use generic javax.sql.DataSource for expample, and then "inject" or lookup the implmementation from the server. Then if you use Jetty, configure what you want as connection pool implementation https://wiki.eclipse.org/Jetty/Howto/Configure_JNDI_Datasource
So dont´t include in your web-inf/lib tomcat-jdbc.jar.
2) The "org.eclipse.jdt.launching.JRE_CONTAINER" it's a internal variable of eclipse and the value is what you configure on eclipse properties. It's used for eclipse to compile and run your app.
3) in your project structure ".class" files, must go in "WEB-INF/classes". That it's defined by servlet specification. Eclipse automatically generate the correct structure if you select yor project and with right click run "Export" --> "War file". Or you can use maven.
I just created my first Web Application Project using the Google-Eclipse plugin. Amongst other artifacts, it autogenerated a war/ directory with several subdirectories and many files, including:
war/
WEB-INF/
lib/
<Lots of JARs here>
web.xml
appengine-web.xml
etc.
Several times now I've cleared out certain parts of this war/ directory (messing around with buildscripts and other Google-Eclipse plugin features - this is just a test/temp project for getting used to the plugin), and they magically reappear at some point in the future.
I'm wondering if, because I set this up as a Web Application Project (and it is thus managed by the Google-Eclipse plugin), is the plugin trying to preserve the structure of the war/, and as such, continuing to auto-generate any missing files?
If so, why? Exactly (which files/directories) what is it trying to preserve? Can I disable it?
And if not, then I obviously have something else going on here. In which case, has anybody else ever experienced this with the Google-Eclipse plugin, or just Eclipse in general? Thanks in advance.
This plugin only updates war/lib directory by adding dependencies. Actually it just copies jar files when you switch to a another version of Google App Engine SDK.
This should not be a problem.
War folder is the exploded package that later on you need to deploy to Google App Engine.
When you build or deploy file to GAE, this folder will be re-created/updated, and it contains the newly compiled jar and the necessary libs.
Read this.
War folder contains the generated javascript files which are deployed to the app engine.
I have a web application which consist of JSP pages, Servlet and Consumes Web Services.
It also references apache axis and excel libraries.
Now I want to deploy my application directly in Weblogic server
How do i do that.Whcih archive shud i make WAR or JAR??
ALso how to ensures that it covers all the referenced libraries.
I have made my application in Jdeveloper, but I dont want to deploy it using Jdevelper..
I would package my solution as a .war file, containing all dependent .jar files.
That way your solution is self-contained. You can deploy to an app server containing other apps with their own versions of your libraries (dependent or developed). If you put the dependent jars directly into the app server (as you can do), then you're forcing those versions on all applications deployed, and that could well cause you grief.
The downside is that your developed .war file can become sizable. It's not normally a major problem, and I wouldn't worry about it until it's identified as an issue.
A JAR-file cannot contain a JAR-file, so that option is out. Since you mention JSPs and servlets a WAR would seem the appropriate option, although an EAR with a WAR and several JARs could also be a way forward...
Cheers,
Consider a WAR with your JAR files in WEB-INF/lib. Or, create an EAR with APP-INF/lib folder.
Are .classpath and .project files as created by Eclipse, only used by Eclipse internally? Are these files being used by JDK? How do Java EE application servers find classes and path?
In between, when I create the ear, war using ant, I will use ant options to look out for the libraries for the project compilation.
Then does the application server use .classpath for compilation?
Java EE application servers don't need the classpath which we set in Eclipse for the war (web project) to run because while packaging the war, we stuff all the required jar's in the lib folder of the war file. When the application server starts , it loads all the jars from the lib folder without the need for any classpath declaration.
Also, in case any external dependencies are needed, most Java EE servers provide facility to define external jar dependencies.
And yes, .project, .settings folder etc. are all needed by Eclipse to handle the classpath and other settings of your workspace.
if we put it simply
.classpath and .project are eclipse metadata files and are used by eclipse only. They are meaning less for other applications.
Forgive me for a novice question, but what is the difference between the dist and deploy folders? It seems like the same thing - both contains the .jar of the files. However, when you clean and build the project, it looks like only the dist folder is updated. How does the deploy folder get updated?
Thanks.
I will assume that you are using a directory layout similar to what Netbeans IDE creates by default.
dist is the folder where your generated archives are stored (so it gets updated through clean and build).
build folder contains compiled classes and resources, but not the compressed archives.
Maven, by default, places the content of both into a target folder.
A deploy folder is the place where you put your generated artifacts (either archives or directory trees with the same layout as archives, a.k.a. exploded archives) so that you Application Server can serve it.
In development environments it is not unusual to configure the server to scan the dist folders for generated artifacts and redeploy them. So, in that sense, deploy and dist folders can be the same.
You can even have "in place" deployment scenarios. This works by compiling your classes direct to WEB-INF/classes folder inside webapp (with something like Maven war:inplace goal). If you set your server to scan changes in this folder, you can edit resources such as jps in place and have it immediately reflected into your running application (a.k.a. exploded artifact hot deployment).
Of course that you can accomplish something similar by instructing your IDE to copy resources and compiled classes to a exploded archive structure and configuring your server to scan it. Netbeans tends to use build/web for that purpose.
Also sometimes incremental redeployment is not possible and frequently full redeploys are not desirable (some applications may take several minutes to redeploy). That is why you can use separate folders / deploy your artifacts as jars / wars / ears, etc.
Compiling, packaging and deploying are very different phases / concepts of a Build lifecycle, which may or may not happen together.
I hope this is enough info to get you going.
Cheers,
Typically a project is responsible for creating one artifact, when that artifact gets built it is put in a directory called target or dist. When your project is responsible for creating a web application, you need a place to layout the files in your project to run under your servlet container or app server, and that place is the deploy folder. So the dist directory would typically have a single artifact like a war, ear or jar, while the deploy folder would have the contents exploded in a directory structure where the app server can use them. How the deploy folder contents get updated depends on your build process or IDE integration.