I have a Java solution that needs to include servlet-api.jar in my classpath.
It works if I copy the servlet-api.jar from my tomcat folder to the project folder. But when I upgrade to Java7, the servlet-api.jar is a new version and will need to be replaced.
Is there anyway I can get around this issue? I don't think I can point it directly to my tomcat folder on my local development machine...
The problem is not the choice of Java 7 vs. another version of the JDK. The problem is: which version of the servlet API specification do you want to use in your webapp. This choice of course also has an impact on the servlet container you'll be able to use. For example, if you choose servlet 3.0, you will have to use Tomcat 7, and not Tomcat 6.
So, first choose which version of the API (and thus container) you want to use, then add the corresponding jar to your project, and build with this jar in your classpath. Just make sure NOT to add this jar file in the WEB-INF/lib folder of your deployed webapp. The jar should only be used for compiling. At runtime, the container already has this jar in its own classpath.
I do not like having servlet api jar to satisfy ant build.
Say, we move from Tomcat 6.0.42 to 6.0.43 or 7.x.x. Or to Glassfish.
Someone has to make sure to get the latest jar from the tomcat installation and replace it in the project.
Renaming servlet-api.jar to servlet-api-tomcat-6.0.42.jar may be one solution. It also might indicate to the developer that it must be replaced when we change the Web Container.
Is there a cleaner solution?
Related
I created a client using proxy in Oracle JDeveloper to call web service. JDeveloper deployed automatically and the code works well under windows environment. But now I'm required to migrate the code to unix server. I deployed the project to a .war file and copy it to unix which cannot be executed correctly using "jar" command.
Could anybody give me a whole picture or a high-level step-by-step instruction about what I need to set up to execute war on unix? I'm new to this area, and for now I got some suggestions like installing a Tomcat first.
What I have now:
1. a war file including .class, .java, WEB-INF, META-INF, MANIFEST.MF deployed from JDeveloper
2. JDK 1.6.0_25 installed on unix usr/java/
3. Tomcat installed on unix, but not under bin or local or usr directory(is it ok?)
Some specific questions:
1. what else do I need?
2. where to drop the .war?
3. do I need to unzip or re-compile the war?
4. how can I run the main class in the war?
Errors poped-up now:
1. cannot find main class
2. I tried to un-zip war and compile the class including main, and get "cannot find symbol" for the webservice specified classes' name.
Thanks to whoever attempt to help!
Even though this question probably should've been asked on ServerFault instead of here, sounds like you got all you need. Try dropping the .war on tomcat's webapps directory.
You should be able to just drop the .war file in $CATALINA_BASE/webapps and tomcat should pick it up when you start it.
$CATALINA_BASE is where you installed tomcat, unless you've configured tomcat for multiple bases.
You only need a war file if you are developing web application. From what you describe, you need to create a zip file which contains all the libraries and classes you need and copy it to Unix. Then you unpack it and execute it using java command.
Alternatively you can create a jar file with all dependencies included using Maven Shade Plugin and execute your code using jar command.
I'm doing some project maintenance on the source code for an MVC JS website running on JBoss. The project contains both Java and Javascript and I'm trying to figure out all of the frameworks that were used on this project, seeing that the Javascript code is somewhat lacking in project documentation.
In WEB_INF/lib/, I see these files:
avalon-framework-4.2.0.jar
batik-all-1.7.jar
commons-io-1.3.1.jar
commons-lang-2.4.jar
commons-logging-1.0.4.jar
dwr.jar
fop.jar
mail.jar
servlet-api.jar
sqljdbc4.jar
xmlgraphics-commons-1.3.1.jar
From my preliminary research, I think this project uses:
Avalon Framework
Batik SVG Toolkit
Apache Commons
DWR
Apache FOP
JavaMail
MS SQL Server JDBC driver
Apache XML Graphics commons
However, I'm a little confused about serlvet-api.jar. Other than a Google search, what is the best way to determine where this package comes from and its purpose? In particular, I'm getting this message in the console when I start this project in JBoss through Eclipse:
INFO [WebappClassLoader] validateJarFile(C:\jboss-4.2.2.GA\server\default\.\tmp\deploy\tmp6553188861131946313Ag4-exp.war\WEB-INF\lib\servlet-api.jar) - jar not loaded. See Servlet Spec 2.3, section 9.7.2. Offending class: javax/servlet/Servlet.class
Any suggestions as to what I should do to track down the source of this jar file, and its corresponding error message, to ensure that my source code maintenance doesn't harm the project?
I don't know why you wouldn't want to use google to find the answer. But, the specific problem is probably due to the fact that Tomcat now has it's own Servlet class. So try removing the servlet-api.jar file from the lib directory. Or make sure the version of Tomcat you are using with Eclipse matches the server you are going to deploy on (although it's probably easier to upgrade the Tomcat version on the server than trying to setup eclipse with an older version).
You can list the directory of the jar on the command line with
jar tvf servlet-api.jar
(jar is in the bin directory of your jdk).
Odds are that this is the standard servlet api specification jar. The jar itself likely contains no implementation, rather jboss is relied on for that, but the project needed eclipse to have a copy to be able to compile the project.
You should not include the servlet-api inside your war file, as any servlet container will provide it.
You can use Provenance to figure out where random jar files come from, and easily get some XML to help you convert to a Maven (or Ivy) project structure.
Disclaimer: this is my project.
I am a brand new Java developer (I have been working in asp.net) and I inherited a project I am trying to get running correctly. I am on Windows 7 and have Tomcat installed and I am using Eclipse
I'm trying to figure out how the heck Jar's work in java and I am really confused at the moment. I have been playing around with it and looking up stuff on the web for about a day now and this is where I am:
I have a dynamic web project which I inherited and it has what I am going to assume is a fairly standard project layout. There is a lib folder in the project root which contains some jar's.
If I don't do anything and go to a particular page in the site I get this error: "The import net.sf cannot be resolved, XLSTransformer cannot be resolved to a type"
So I added jxls-core-0.9.8.jar to my build path in Eclipse and that error went away but now I am getting this error "java.lang.ClassNotFoundException: net.sf.jxls.transformer.XLSTransformer"
I copied that jar from its current location to the tomcat/lib directory and that error went away. Now I am getting essentially the same issue with another file.
Mainly I just need to know how should jar's work? Do they need to be in the class path, in web/WEB-INF/lib, in tomcat/lib, in all of them, none of them I just can't figure it out.
Also when I was looking around I saw some stuff that indicated the order of my classpath entries matters as well. If that is the case how do you insure you have them in the correct order.
Where your jars need to go actually depends - there are entire best practices and major headaches involved. The term Jar Hell exists for a reason.
All classes used by your application must be on the classpath. How they get there will vary depending on the classloader.
For a fuller understanding, you'll want to do reading on the Java classloader. Ideally you'll want to look into Tomcat's classloader, or at least a Servlet Container's classloader, as the classloader for Tomcat will differ from that for a Java SE (desktop) app, will differ from that for an applet. On top of that, classloaders can really bite you if you don't understand them. If you want the gory details of how a servlet container ought to work, you can check out the latest and greatest Servlet specification.
The information on Tomcat's classloader provides a best practice list for you. Note that I've linked a 5.5 version. If you are using a later or earlier version, check around for the same file for your version.
Here's a suggestion that might help in troubleshooting the problem.
WAR files (Web Archives) will put all of your application's dependency JARs in the directory WEB-INF/lib. If you get a report of a missing class, try unzipping your WAR file, or looking in the exploded webapp directory of your app server, and see if the necessary jar is there.
The difference between this location and tomcat/lib is that JARs in tomcat/lib are made available in Tomcat's parent classloader for all loaded apps. (Indeed this can cause a problem if an app has its own version of a particular JAR in WEB-INF/lib.) The JARs in WEB-INF/lib are loaded in the application's classloader and are only available to that app.
If your JAR is missing from WEB-INF/lib, check your build scripts or the Build Path of your project in Eclipse. Good luck!
In Eclipse, I export as "Runnable JAR file", and in the dialog after, under "Library handling", I choose "Extract required libraries into generated Jar".
Basically, what this means is that if I can run it in Eclipse without error, it will run stand alone too since everything that I've told Eclipse is required will be included in the JAR.
I recently switched to J2EE from .NET, and am confused about where to put JAR files. I know that the CLASSPATH, WEB-INF, and Eclipse's Java Web Path are all places where JARs can be stored, but I'm confused about which folder to use, when, and why.
First off, we have the CLASSPATH. I usually set this by going into "Environment Variables" inside "My Computer." I know that this is the default place where the Java compiler looks for JAR files. When I add a folder or a JAR to my CLASSPATH environment variable, why is it ignored by Eclipse, the Java compiler, and the web server?
Also, I know that WEB-INF\LIB is a place where you can put JAR files that your web app is going to use. However, I've put JARs in WEB-INF\LIB only to have them be ignored. In what situations should I put JARs into WEB-INF\LIB folder? How do I get Eclipse or the web server to notice them?
So far, the only thing that works for me is to actually change the Java Build Path for an Eclipse project. I'll select the JARs I need and hit "Add External JARs." Most of the time when I do this, Eclipse will recognize my JARs and read the classes therein. However, I've run into a bunch of weird random errors while doing this (mostly having to do with dependencies, I think). For some reason, I just get the feeling that this isn't the right way to do things, and that I'm missing some vital piece of information. When should I be manually Adding External JARs inside Eclipse, and when should I be doing things differently? How come Eclipse's Java Build Path doesn't seem to know about the folders in my CLASSPATH environment variable?
Really, I would just like to gain a better understanding of the CLASSPATH, Eclipse's Java Build Path, and the WEB-INF/LIB folder -- the purposes they serve, the relationships between them, and where I should be putting my JARs in various situations. I would appreciate any advice you could give me, or any articles that you could recommend.
Thank you.
The CLASSPATH you set in your environment affects only standalone Java applications, i.e. ones you run from a command prompt or an icon. As you've noticed, Eclipse ignores this. It sets up its own per-project classpaths.
javac and java, if called from the command prompt, should/may honor this path, but it's no longer considered great practice to do this. It's turned out that every app needs its own set of stuff, so a global CLASSPATH isn't really doing any of them any good. Modern practice is to simply specify the classpath with the -cp option on the command line for javac or java.
A standalone Web Application server will also set up its own classpath. From the command line or GUI, WebAppServers are usually started by a script (.BAT or .sh) that sets up a classpath using -cp. Tomcat has a directory called common or common/lib where it expects to see libraries that should be available the the server and all programs running under it. But you will generally not need/want to mess with this, as it's customaries for applications to provide their own library collectons in WEB-INF/lib.
So for a Web app, you'd put your varous jars into the lib directory, under WEB-INF, assuming Eclipse pre-builds such a directory structure for you.
All the libs you need also need to be made known to Eclipse. In the Project Explorer, I select the whole slew of them at once, right-click and select Build Path | add to build path. That's easier than messing with Eclipse's project build path manually.
Java has a long history and experience has shown that some ideas were good and some were bad.
The CLASSPATH environment variable was the initial way to tell the Java machine where to locate classes from your program, and works reasonably well for command line programs. It was rapidly found that this should not be a global thing (as that tend to mess things up in the long run) but a per-program thing. This could be done by creating a wrapper script/BAT-file which sets the variable and runs the Java machine.
All was well, then people wanted to write web server stuff in Java. The Servlet API was created where a web application is a stand-alone unit - this resulted in that the CLASSPATH for each web application is the unpacked files under WEB-INF/classes plus the jar-files under WEB-INF/lib. And only that. This means the global CLASSPATH variable is ignored. This has been found to be a VERY good thing, so the concept has migrated elsewhere.
For instance a "executable jar" (which Eclipse calls a "runnable jar") which is invoked with "java -jar foobar.jar" contains the complete classpath INSIDE the Jar in a special manifest file. Java Web Start which is used to start java programs from a web server explicily lists the full classpath in the configuration file on the server.
But, to get you started. If you want to write a Java web application:
Get the Eclipse Java EE version.
Create a new Dynamic Web Project e.g. named foobar.
Drag and drop (or copy/paste) the jar files you need in foobar/WebContent/WEB-INF/lib
Create a new file named foobar/WebContent/index.jsp. In the blank file type <h1>Hello World <%= new java.util.Date() %></h1>
Right click in editor for index.jsp, choose Run -> Run on Server, and choose the Basic -> J2EE preview at localhost server, and Finish.
A browser window will now open, either in a browser or inside Eclipse which will render your JSP-page. You can change the JSP-page, save it with Ctrl-S and reload the browser window to see the changes.
Also, I know that WEB-INF\LIB is a place where you can put JAR files that your web app is going to use. However, I've put JARs in WEB-INF\LIB only to have them be ignored. In what situations should I put JARs into WEB-INF\LIB folder? How do I get Eclipse or the web server to notice them?
The real problem you have here is likely that you didn't got Eclipse for Java EE developers and/or that you just created a generic Java Project instead of a Dynamic Web Project and built up the necessary folder structure yourself.
If you create a Dynamic Web Project in Eclipse for Java EE developers, then Eclipse will automagically add any libraries in WEB-INF/lib to the build path. The build path is roughly said just the classpath which is been used in both compiletime and runtime. With other words: just drop the 3rd party JAR's in there, really nothing more needs to be done.
Note that Java is case sensitive, thus it should be really called WEB-INF/lib, not WEB-INF/LIB. But anyway, if you create a Dynamic Web Project, then Eclipse will just automagically generate the correct folder/file structure for you.
As said by others, ignore the %CLASSPATH% environment variable. It is only used by javac.exe/java.exe and even then only when you do not specify any of the -cp, -classpath or -jar arguments. In real world this environment variable is seldom used, it is just some convenience for starters (and unfortunately also the most confusing one, they should never have invented it).
If you're dealing with web applications, /WEB-INF/lib is the portable place to put JARs. This is where web servers servlet containers expect to find an application's jar files.
Eclipse requires you to specify the path to your libraries, jar files (on Properties -> Java Build Path -> Libraries tab). This can be found on the .classpath project file.
Usually you have the JRE libs on its path (which would be on your classpath too), so adding the libs to the classpath and updating eclipse build path would work.
The WEB-INF directory should be the place that contains necessary information for your web application.
I'm not an Eclipse expert, but I think that your problem can be answered like this:
1) CLASSPATH is an environment variable that is read in when you launch java programs and is used by classloader to figure out where the classes are placed.
I would modify the CLASSPATH variable only in the case when you are launching an java program from a script, as this allows you to conveniently launch a program and make sure that the classes are found. This would not be the case for you, as you are developing the web application.
2) WEB-INF/lib is the directory under which the web application container's classloader (like tomcat or glassfish) looks into if your web application needs to resolve a class. So you put there the classes that are used in your web application.
Some IDE's do include the libraries/.jar files that you are using in a project automatically to the package.
3) Eclipse library/classpath resolving during the development time. I would assume, but apologies for assuming, as one really shouldn't do this ;), that you can define a library (add external .jar files to projects) and autocomplete/all the other interesting features should start working with this, as you basically make those classes visible for the IDE with that activity. I also would assume that you can then mark those libraries to be automatically added to the web projects etc., by the IDE.
In general a good reading about how classes are found during execution is here (it's a sun's official documentation). Also a good place to read about this is the ClassLoader class documentation.
Taken together the comments helped me as well. I had added all the jena .jars to the build path from eclipse but that wasn't sufficient. Following suggestion to "add to WEB-INF/lib" it seemed intuitive to drag from libraries folder to WEB-INF (from within eclipse), but that didn't work. Nor did copying the .jars to WEB-INF. I eventually drag-and-dropped from the windows desktop to the WEB-INF lib folder in Eclipse, and that fixed the problem. It would be nice if any .jars added to the build path were automatically copied to WEB-INF lib by Eclipse. In case it matters, this was eclipse EE IDE, Indigo release, on windows 7.
Summary
Is that possible for webapps deployed on linux + tomcat5.5 to use/see all /usr/share/java/ jars automatically?
Details
I'm packaging my java webapp for Ubuntu (yet the question is related to any linux-based distro) and going to make it depend on tomcat.
I'm going to put context descriptor (an xml file) to /usr/share/tomcat5.5/conf/Catalina/localhost/ to make my app deployed.
Having my web dir here: /usr/share/<appname>/web, how can I enable my app to use java jar libs installed in the system (/usr/share/java)?
I can't just symlink /usr/share/java -> <webdir>/WEB-INF/lib, since I have my custom jars need to be placed in lib dir.
Bad Solution
The solution I've found so far is to symlink each required jar to <webdir>/WEB-INF/lib/.
This is not so good, because I have to symlink a lot of jars and even worse to symlink all jars my direct dependency lib (jar) requires (and so on). In case my direct dependency lib changes its list of required jars I'll have to maintain that symlinks.
According to the Tomcat classloading documentation, you need to put any shared libs that should be available to all Tomcat apps in the $CATALINA_BASE/shared/lib library -- so one way to do what you're looking to do is to move your libraries from /usr/share/java to $CATALINA_BASE/shared/lib.
BUt if I'm not misunderstanding that same documentation, Tomcat also makes the system-wide CLASSPATH variable's contents available to the classloader at launch, so if your directory -- /usr/share/java -- were included in the system-wide CLASSPATH variable, then that should work too. I've never done this, though; Tomcat's method of making the contents of $CATALINA_BASE/shared/lib available Tomcat-wide has always served me perfectly.
entzik's answer lead me to the following solution.
I'm going to use modified "bad solution" (see question).
Modifications are following:
Depend on specific package version for all dependencies (affects "control" file while packaging for deb)example: libcommons-io-java ( = 1.3.1) instead of just libcommons-io-java
Symlink to actual jar files in `/usr/share/java` and not "generalized" onesexample: webdir/WEB-INF/lib/commons-io.jar -> /usr/share/java/commons-io-1.3.1.jarand notwebdir/WEB-INF/lib/commons-io.jar -> /usr/share/java/commons-io.jar
This modifications ensure webapp is not broken if administrator installed new version of a library (commons-io for example).
The downside is this approach clearly inflates system with used-by-only-one-app versions of libraries and may lead to problem some other application/library can't install due to version conflict. I guess both potential problems are minor if we are speaking about libraries.
You have two options, one is to let the classloader provide the libraries to all java programs and the other is to let the classloader provide the libraries to all tomcat contexts.
Add your symlinks to /usr/lib/jvm/java-1.5.0-sun-1.5.0.11/jre/lib (note you may need to specify a different version in this path) to allow all java programs access to these libraries or add them to Tomcat's shared libraries at var/lib/tomcat5.5/shared/libs (again, the version number may be different) for access by all Tomcat contexts.
I should also note that these directory locations were taken from Ubuntu "Feisty".
You should not do that. Java EE applications are the supposed to be self sufficient and not depend on any resources outside the deployment package other than those provided by the container. So you should take the libs you need from that directory and add it to your war or ear package.
This guarantees that your application will behave the same wherever you deploy it and you will not be subject to unexpected changes in the versions of the libs in /usr/share/java....