Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / June 2006

Tip: Looking for answers? Try searching our database.

jsp - I feel like an a.s!

Thread view: 
tiewknvc9 - 15 Jun 2006 19:42 GMT
Man this question makes me feel like an a.s.

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 - 15 Jun 2006 21:06 GMT
> Man this question makes me feel like an a.s.
>
> 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@yahoo.com - 16 Jun 2006 00:03 GMT
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 - 16 Jun 2006 00:20 GMT
> Hi Mark,

1. I am not the OP

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

2. I don't think this is correct
Chris Smith - 18 Jun 2006 08:25 GMT
> > Hi Mark,
>
[quoted text clipped - 3 lines]
>
> 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.

Signature

Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

rounner@yahoo.com - 19 Jun 2006 04:11 GMT
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 - 19 Jun 2006 04:56 GMT
> 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.)

Signature

Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

rounner@yahoo.com - 19 Jun 2006 05:51 GMT
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 - 19 Jun 2006 06:05 GMT
> 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.

Signature

Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation

Jeff Kish - 16 Jun 2006 02:31 GMT
>Man this question makes me feel like an a.s.

<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 - 18 Jun 2006 08:31 GMT
> 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.

Signature

Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation



Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.