Ron McLeod wrote:You need to import the class, not the package.
Since your package is named FileSystem (package names should use all lowercase) and your class is named FileSystem, you should importing FileSystem.FileSystem .
Also, class names should begin with a capital, so your servlet class should be named Files, not files.
Paul Clapham wrote:There's a class named java.io.FileSystem in the standard API, and you're importing that because you import "java.io.*". So there's confusion between that class and your class.
You could solve that by only importing the classes you actually need from the java.io package instead of importing all of them. Like the way you did it in your FileSystem class.
D:\Apache Software Foundation\Tomcat 7.0\webapps\ROOT\WEB-INF\classes\evo\test>javac files.java
Michael Portman wrote:1. Renamed FileSysem to evoFileSystem.
3. Compiled it at J:\source\ javac evoFileSystem.java.
5. Made a manifest called manifest.mf with the following contents:
6. JAR'd it up at J:\source\ jar cfm evoEngine.jar manifest.mf evoFileSystem.class
8. Now I have evoEngine.jar with evoFileSystem.class contained in it.
9. Created a test servlet called files2 [...]
10. Tried to compile it where I normally compile my test servlets at (D:\Apache Software Foundation\Tomcat 7.0\webapps\ROOT\WEB-INF\classes\evo\test) javac files2.java
The evoEngine.jar is in my D:\Apache Software Foundation\Tomcat 7.0\webapps\ROOT\WEB-INF\lib folder as well.
Often the most important part of the news is what they didn't tell.
Tim Holloway wrote:Short synopsis:
1. All classes belong to a package. If you don't put a "package" statement at the top of your class source code file, the class will be assigned to the default package which has no package name. A LOT of tools don't like the default package, so you should always define an explicit package.
2. A package name is a tree construct like a file directory. For example, "java.lang.utils". The package name component separators are "." characters. Each package name component MUST adhere to certain lexical standards as defined in the Java Language Specification. Briefly, only letters, digits, and underscores. There are other options, but these are all you should use unless you know better.
3. Java is a case-sensitive language. The package name components should not start with a capital letter. In fact, caps are best not used in package name components.
4. In actual practice, the source class files should be arranged in a subdirectory tree that matches the package component tree. That is, put the com.coderanch.utils class files in the source directory com/coderanch/utils. NOTE that while some OS's ignore letter case in filenames, Java does not, so naming the directories Com/Coderanch/Utils is a big no-no, even if the OS would prefer to do it that way.
The actual rule in Java is that class names are capitalized, but resource names (instances and members, for example) are not. So If I want a file I/O class, I'd name it something like FileIO. The file itself would be com/coderanch/utils/FileIO.java and the compiler would produce a file names com/coderanch/utils/FileIO.class.
When you take all the classes and build a JAR, the pathnames of the class resources in the JAR are relative to the package root. So if the actual filesystem location was C:/users/chad/project1/classes/com/coderanch/utils/FileIO.class, a jar directory listing would show "com/coderanch/utile/FileIO.class".
AND FINALLY.
To use the JAR in your webapp, all that's needed is to include the JAR under the webapp's WEB-INF/lib directory. You don't need a Main-Class in the manifest, since webapps are not executable programs and this is a library, not a program anyhow.
When the server deploys the webapp, it will look under WEB-INF, add the WEB-INF/classes directory to the webapp's classpath, and scan each JAR in WEB-INF/lib, adding the classes it finds in the JARs (this is different than how stand-alone application classpaths work). A custom classloader is created for each webapp deployed in a server, and each of those webapp classloaders sees only the classes/jars that are part of that webapp. So if I deploy 2 webapps - app1 and app2 and app1 has a WEB-INF/lib/myfileio.jar, the classes in that JAR will not be found by code in app2. You'd have to include a separate copy of myfileo.jar in the WEB-INF/lib of app2 for app2's classes to see them.
Dave Tolls wrote:You need to include any dependencies in the classpath of the javac command.
In your case something like:
javac -cp <path to the jar file>:. files2.java
Also, you are still writing your java code inside your webapps directory.
You really need to move this out of there. It's a bad habit to get into.
Are you learning Java by doing Servlets, by the way?
I'm not sure that's going to be very productive. There's a lot of parts to a web app, and an IDE really helps when building one. Even a fairly basic one.
Dave Tolls wrote:You're still trying to work in the webapps directory.
In addition, your jar file is intended for your webapp, not Tomcat as a whole, so shouldn't be in the Tomcat lib directory.
Your jar file looks like it has an issue.
Or possibly your class file itself?
But first off I would move your stuff out into a proper project structure, away from Tomcat.
Often the most important part of the news is what they didn't tell.
Look ma! I'm selling my stuff!
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|