jsp - I feel like an ass!

[tiewknvc9]

Man this question makes me feel like an ass.

I created a servlet, "test.class"

and I would like to deploy it onto my tomcat server. I know that I
need to create a war file, and I have created war files and attempted
to deploy the servlet, however all have failed to make the website
recognize the servlet.

I have restarted tomcat numerous times, and it still does not show up
(my other html and jsp files show up, but not the servlet output).

So I suppose I have a few newb questions...

1. If I wanted to manually place the file in a location where it
should be able to be recognized, where should I put it? --
C:\Tomcat\apache-tomcat-5.5.17\webapps\ROOT\WEB-INF\classes\
???

2. Do I NEED a web.xml file? how can I create a simple on that works
(mine is problematic I think it looks like this)
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE web-app (View Source for full doctype...)>
<?xml version="1.0" encoding="ISO-8859-1" ?>
- <web-app>
- <servlet>
<servlet-name>test</servlet-name>
<servlet-class>test</servlet-class>
</servlet>
- <servlet-mapping>
<servlet-name>test</servlet-name>
<url-pattern>/test</url-pattern>
</servlet-mapping>
</web-app>

3. How do I create a war file properly, so that it can deploy into the
right locations, and register with tomcat appropriately??? jar -cvf
my.war %path%\test.class???

any advice will be appreciated (as long as Im not being badmouthed)

thanks

 

[Mark Space]

Man this question makes me feel like an ass.

I created a servlet, "test.class"

and I would like to deploy it onto my tomcat server. I know that I
need to create a war file, and I have created war files and attempted

Actually not true. Have you tried just creating a subdir manually and
copying the files to it? I'd do that first, to make sure the web app is
correct, then tackle the war file structure.

1. If I wanted to manually place the file in a location where it
should be able to be recognized, where should I put it? --
C:\Tomcat\apache-tomcat-5.5.17\webapps\ROOT\WEB-INF\classes\
???

C:\Tomcat\apache-tomcat-5.5.17\webapps\

Your webapps all deploy here.

 

[rounner]

Hi Mark,

Using a war is adding an unnecessary step and complicates things (you
might be set to not unpack).

In conf/catalina/localhost you should have an xml file that describes
your app (tells tomcat where it is located). In that folder you place
your unpacked application. Example application definition:

myapp.xml

<Context
path="/myapp"
docBase="../arootfolder_eg_webapps/myapp"
unpackWARs="true"
deployOnStartup="true"
reloadable="true"
/>


You need a web.xml to map your servlets. Anything else not in the
web.xml will be defined by the web.xml in the conf folder. To begin
with all you really need to define is the mapping:

myapp/WEB-INF/web.xml

<web-app>

<servlet>
<servlet-name>myapp.test</servlet-name>
<servlet-class>myapp.test</servlet-class>
</servlet>

<servlet-mapping>
<servlet-name>myapp.test</servlet-name>
<url-pattern>/myapp/test.jsp</url-pattern>
</servlet-mapping>

</web-app>

Make sure in myapp/WEB-INF/classes/myapp/ you put test.class.
Put non standard libraries in myapp/WEB-INF/lib

I think just those things will get you going.

 

[Mark Space]

Hi Mark,

1. I am not the OP

<url-pattern>/myapp/test.jsp</url-pattern>

2. I don't think this is correct

 

[Jeff Kish]

Man this question makes me feel like an ass.

<snip>
been there (still there)... done that (you know the drill ...)


I am just learning, and this really was extraordinarily helpful in
getting me going, and indeed answering exactly the question you are
asking. Read carefully!

http://www.coreservlets.com/Apache-Tomcat-Tutorial/


hth

 

[Chris Smith]

1. I am not the OP


2. I don't think this is correct

I'll just confirm that this is definitely not correct. url-pattern
should be a context-relative URI, which means that it begins with a
slash, but the "root" designated by the slash is the root of the current
web application. You do NOT put the path of the web application in the
context-relative URI.

There's also no need to worry about server.xml or Context elements for
the purposes of getting this web application running. That's another
thing that's probably worth thinking about after getting a simple web
application up and running.

 

[Chris Smith]

I created a servlet, "test.class"

One comment off the bat: you seem to be creating a class in the default
package. I don't know any reason this shouldn't work off-hand, but I
will warn you that using the default package when you interact with JSPs
later on will be impossible. May as well get started now with
specifying a named package for your code.

1. If I wanted to manually place the file in a location where it
should be able to be recognized, where should I put it? --
C:\Tomcat\apache-tomcat-5.5.17\webapps\ROOT\WEB-INF\classes\
???

You should pace all this stuff in a subdirectory inside $TOMCAT/webapps,
where "$TOMCAT" is whatever location you've used to install tomcat.

2. Do I NEED a web.xml file?

To write a valid web application that has a servlet, you need a web
application. There are non-portable ways to work around it for Tomcat,
but they are a bad idea.

how can I create a simple on that works
(mine is problematic I think it looks like this)

That looks fine, though I didn't try it out. If you're having problems,
then maybe it has to do with your class "test" (which should be Test, by
the way; class names are capitalized by convention in Java) being in the
default package.

3. How do I create a war file properly, so that it can deploy into the
right locations, and register with tomcat appropriately??? jar -cvf
my.war %path%\test.class???

Actually, when I have to create them manually, I create war files by
zipping up the directory with WinZip, and then renaming the file to have
an extension of ".war". This works just fine, and is generally easier
than remembering the syntax to yet another command-line tool. You do
have to be careful, though, to include directory names, and make sure
that WEB-INF is a top-level directory in your zip file.

 

[rounner]

wow...

The OP's class should not be a root class but defined in a package eg.

package myapp;

import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;


public class test extends HttpServlet
..
..
..

It would then be class myapp.test.

myapp/myapp/test.jsp would be an appropriate mapping. If the package
was something else instead of myapp it might have been clearer eg
myapp/myclass/test.jsp. You're right I did complicate things for a
begginer, but umm, a little creepy....

 

[Chris Smith]

myapp/myapp/test.jsp would be an appropriate mapping. If the package
was something else instead of myapp it might have been clearer eg
myapp/myclass/test.jsp. You're right I did complicate things for a
begginer, but umm, a little creepy....

Please check your information. If I understand you well, you're still
saying that a URL mapping in web.xml should include the context path for
the web application. That is not true. The url-mapping element is a
context-relative URI. E.g., if the web application has a context path
of myapp, and the web.xml file says:

<servlet-mapping>
<servlet-name>Test</servlet-name>
<url-pattern>/something</url-pattern>
</servlet-mapping>

Then the servlet is mapped to a global URL of:

http://some.server.com/myapp/something

The context path of "/myapp" was added automatically because we're
working in a web application that is mapped to that path. If you map
the servlet to "/myapp/something" in web.xml, then it will end up mapped
to:

http://some.server.com/myapp/myapp/something

which is probably not what was wanted.

Incidentally, there is no reason to use a servlet mapping URL pattern
that follows the package structure of the servlet. Unless you plan to
have so many servlets in different packages that you can't keep track of
the names (now that's a scary thought!), it's probably sufficient to
just use a simple descriptive path name. The servlet class itself would
belong to a package, of course, as has been said twice now.

(I don't know what you thought was creepy... I'll just ignore it, I
suppose.)

 

[rounner]

To the OP, dont worry just use the tutorial link.

Tomcat is open development. I can map my servlets however I want to.
Mapping by package is a legitimate technique:

http://server/app/package/class

I am not an idiot, I know it is context relative, but its my fault for
calling the package myapp. In my original post the class was called
myapp.test, so you would have realised if you paused before jumping on
your chance to affirm your expertise.

I just wanted to help the OP but couldnt be bothered finding a link to
a tutorial, simple as that. I wasnt promoting my services, I wasnt
trying to show off to the world how much I know, I was just trying to
help a tomcat beginner. All this melodrama must really put off
beginners that are intimidated by tomcat. Its really very easy, if only
posters didnt try to patronise so much.

 

[Chris Smith]

I am not an idiot, I know it is context relative, but its my fault for
calling the package myapp.

I am not saying you're an idiot. Nevertheless, what you are posting
here confuses me even when I know what's going on, so I'm pretty sure it
confuses others as well. People correct confusing or false statements
posted to newsgroups. I'm glad they do, since I don't often make a
habit of verifying every sentence I write here.

To get back to the matter at hand, it really just doesn't matter what
you call the package. Even if you wanted to map the servlet to the URL
you specified:

http://server/app/package/class

You would still just specify "/package/class" as the URL pattern in the
servlet-mapping element of web.xml, assuming that /app is the context
path. You would not specify "/app/package/class" or
"app/package/class" there. Similarly, in your original example, even
with the package named the same as the application, it would be wrong to
specify "myapp/myapp/test.jsp", although I suppose something like
"myapp/test" might make sense if you're following package-based naming
conventions.

In my original post the class was called
myapp.test, so you would have realised if [...]

I did realize. I still believe the content of the post was incorrect.
If I'm wrong, please explain why. If you expect me to shut up and let
people come away confused, then your expectations are at fault here.