Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Rhino

- Original Message - 
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 3:44 PM
Subject: RE: Weird Problems installing servlets in Tomcat



Howdy,

>Combining your remarks with John's and now Andrews, I'm satisfied that
all
>I
>really need to do to get everything working is put
>commons-fileupload-beta-1.0.jar in the /common/lib and put the
>commons-fileupload-1.0.jar in the /shared-lib and everything should
work
>correctly again.

| That's suboptimal.  Put the beta fileupload back where it was, and put
| the one you need in WEB-INF/lib.

It now turns out that the jar that needs to be put back in /common/lib is
*not* commons-fileupload-beta-1.0.jar; it is commons-fileupload.jar. The
Linux administrator is busy digging it out of the RPM and putting it back in
the /common/lib. I'm optimistic that this will finally solve the problem.
That is the file that I remember being there originally but when Andrew
suggested the beta, I just assumed I was having a minor memory failure about
the name and went with the beta; it didn't work though.

>1. Where do I find a binary of the commons-fileupload-beta-1.0.jar? I
can

Download and reinstall tomcat 4.1.24.  Or download just fileupload from:
http://jakarta.apache.org/commons/fileupload/index.html

>find the source for it but I don't have a C compiler so I need a
binary.

| It's a java program, not C.  You have a java compiler.  See above URL.

Now I know how Homer Simpson feels when he has one of those "Doh" moments!
For some reason, I've assumed that all the Tomcat code was written in C and
I never gave it another second's thought. What a moron I am - OF COURSE the
Tomcat code is written in Java! All I can do is blame it on too many years
playing with computers; almost everything else seems to be written in C so I
just assumed Tomcat was too. Arggh.

>2. Why is the Tomcat on my Windows box working? I've deleted the beta
jar
>from /common/lib and everything still works fine there. I don't have
>another
>copy of either the beta or the 1.0 jar anywhere else in that copy of
>Tomcat.
>Shouldn't Tomcat on the Windows box be failing the same way? Mind you,
I
>don't import WAR files on the Window box; Eclipse and Sysdeo take care
of
>everything for me.

| That's a problem with modern IDEs.  They take care of everything for
| you, but when it comes time to deploy/test without the IDEs, you're
| never quite sure where the right libraries are.  (By you I mean a
| generic you, not Rhino specifically)

How right you are! And most of the time I *like* the fact that I don't have
to deal with the minutae. But today is one of those days that it just bites
you in the ass.

Tell me, does this make sense to you? Last night, when I was first trying to
deploy the new version of my servlet, I used the Tomcat Project/Export to
War file option in Eclipse to refresh my War file before attempting to
install it on the Linux server. When things started misbehaving, I had a
look at the War file and noticed that it was putting the beta 1.0 version of
commons-fileupload in the jar. I thought that was messing me up so I
searched both Eclipse and my hard drive and renamed or deleted every copy of
the beta jar, every single one. When I renamed the jar, I added a .old to
the end of the name, thus "breaking" the file association. I thought that
would surely keep any program from mistaking it for a real jar file. Yet
despite that, each time I did an export to my War file, I kept getting the
beta version of the file upload in the War file despite the fact that no
file named commons-fileupload-beta-1.0.jar was anywhere on my computer. I
was baffled about how Sysdeo conjured up a file that didn't exist and put it
in my War file. Does that many any sense to you? I just noticed that I still
have one of the renamed files in my /server/lib directory on the Windows
box; it is called commons-fileupload-1.0-beta1.jar.old: is it possible that
Sysdeo was somehow grabbing that file and ignoring the ".old" suffix in
order to put it in my War file? I wouldn't have thought that would be
possible but I'm at a loss to think of any other explanation.

I don't really want to keep flogging this dying horse but understanding this
issue might give me some useful insights in understanding Tomcat in general,
which could be handy in further problem solving

Rhino





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Shapira, Yoav

Howdy,

>Combining your remarks with John's and now Andrews, I'm satisfied that
all
>I
>really need to do to get everything working is put
>commons-fileupload-beta-1.0.jar in the /common/lib and put the
>commons-fileupload-1.0.jar in the /shared-lib and everything should
work
>correctly again.

That's suboptimal.  Put the beta fileupload back where it was, and put
the one you need in WEB-INF/lib.

>1. Where do I find a binary of the commons-fileupload-beta-1.0.jar? I
can

Download and reinstall tomcat 4.1.24.  Or download just fileupload from:
http://jakarta.apache.org/commons/fileupload/index.html

>find the source for it but I don't have a C compiler so I need a
binary.

It's a java program, not C.  You have a java compiler.  See above URL.

>2. Why is the Tomcat on my Windows box working? I've deleted the beta
jar
>from /common/lib and everything still works fine there. I don't have
>another
>copy of either the beta or the 1.0 jar anywhere else in that copy of
>Tomcat.
>Shouldn't Tomcat on the Windows box be failing the same way? Mind you,
I
>don't import WAR files on the Window box; Eclipse and Sysdeo take care
of
>everything for me.

That's a problem with modern IDEs.  They take care of everything for
you, but when it comes time to deploy/test without the IDEs, you're
never quite sure where the right libraries are.  (By you I mean a
generic you, not Rhino specifically)

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Rhino

- Original Message - 
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 1:18 PM
Subject: RE: Weird Problems installing servlets in Tomcat



Howdy,

>I have had no luck getting Tomcat to load War files yet; I've been
trying
>various things for hours but no joy yet

| This an issue: it means your tomcat installation is screwed up.  Resolve
| this before you proceed with more development.

Believe me, I had no plan to do more development until I'd resolved this
problem ;-) I couldn't do much of ANYTHING on the server with Tomcat the way
it was anyway ;-)

>the screen. In fact, commons-fileupload-1.0.jar was in
>$CATALINA_HOME/common/lib (and still is). I think that's where I want
it,
>right? Tomcat uses FileUpload itself doesn't it? Otherwise I would put
it
>in the /shared path, right?

| All those three "right?" questions are correct.

Okay, then at least I understood the HOWTO correctly.

>I've been reading the HOWTO that you cited and I'm getting a bit
confused;
>it seems to contradict both itself and you! According to the Quick
Start
>section, JAR files containing resource which are to be shared across
all
>web
>applications are to be placed in $CATALINA_HOME/shared/lib. Later, in
the
>detailed description of the class loaders, it says that JAR resources
which
>need to be shared across all web applications (except Tomcat itself)
should
>be put in $CATALINA_HOME/lib, not shared/lib. I suspect that the Quick

| Make sure you're reading the documentation for the appropriate tomcat
| version, i.e. 4.1 and not 4.0 or 5.0.  If confused, the classloader
| how-to trumps the Quick Start guide.

I was definitely reading the Tomcat 4.1 docs. The Quick Start I was
referring to was the brief precis at the start of the Class Loader HOWTO; in
other words, the document was inconsistent within itself.


>There's one other thing that I didn't post earlier which I'm starting
to
>suspect is fairly critical. When I first copied
commons-fileupload-1.0.jar
>into the $CATALINA_HOME/commons/lib, I noticed that there was already a
jar
>in that directory with the name commons-upload.jar. I assumed that was
an
>old version of the jar and deleted it.

| You assumed correctly, but took the wrong action.  As I've mentioned a
| couple of times now, those two jars are different APIs of the fileupload
| component.  Soemthing which compiles against one jar won't compile
| against the other.  Therein lies your, and tomcat's internal, problem.

| What you should have done is keep the older file there and put your
| fileupload in your WEB-INF/lib directory.

| You might find it easier to start with a new installation of tomcat.
| Don't touch the common/lib, server/lib, shared/lib directories.  Only
| put libraries under the WEB-INF/lib directory of your webapp.

Combining your remarks with John's and now Andrews, I'm satisfied that all I
really need to do to get everything working is put
commons-fileupload-beta-1.0.jar in the /common/lib and put the
commons-fileupload-1.0.jar in the /shared-lib and everything should work
correctly again.

Two small problems though:
1. Where do I find a binary of the commons-fileupload-beta-1.0.jar? I can
find the source for it but I don't have a C compiler so I need a binary. The
only binary seems to be the commons-fileupload-1.0.jar. Or would I be better
asking this on the commons-user mailing list?
2. Why is the Tomcat on my Windows box working? I've deleted the beta jar
from /common/lib and everything still works fine there. I don't have another
copy of either the beta or the 1.0 jar anywhere else in that copy of Tomcat.
Shouldn't Tomcat on the Windows box be failing the same way? Mind you, I
don't import WAR files on the Window box; Eclipse and Sysdeo take care of
everything for me.

I'm pretty confident now that everything will work again as soon as I put
the beta jar back in the /common/lib and put the current jar in the
/shared/lib. (I'll be doing that on both the Windows and the Linux boxes,
just to be safe, as soon as I find the binary of the beta jar.)

Even though things aren't actually working again yet, I really appreciate
all the help that you, John, and Andrew have rendered. It's much appreciated
guys!

Rhino


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread John Turner
Rhino wrote:

I've been reading the HOWTO that you cited and I'm getting a bit confused;
it seems to contradict both itself and you! According to the Quick Start
section, JAR files containing resource which are to be shared across all web
applications are to be placed in $CATALINA_HOME/shared/lib. Later, in the
detailed description of the class loaders, it says that JAR resources which
need to be shared across all web applications (except Tomcat itself) should
be put in $CATALINA_HOME/lib, not shared/lib. 
Which is exactly what the ClassLoader HOWTO says.

All webapps PLUS Tomcat itself: $CATALINA_HOME/shared/lib
All webapps BUT NOT Tomcat itself: $CATALINA_HOME/lib
I suggest you step back, rethink things, and take Yoav's advice.

John



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Bodycombe, Andrew
Tomcat 4.1.24 comes with commons-fileupload-1.0-beta-1.jar bundled in the
$CATALINA_HOME/server/lib directory. Tomcat needs this file to work, and
also this version because the interface changed between this beta and the
1.0 final release. Tomcat is relying on the interface from the beta version
(this may explain the NoSuchMethodError), so this file should be left where
it is.

If you wish your webapp to use the 1.0 release version of
commons-fileupload, you can put in the WEB-INF/lib directory inside the .war
file, or if you wish to share between several webapps, you can place the
file in $CATALINA_HOME/shared/lib

So, you may actually need 2 copies of commons-fileupload to get your
application working:

$CATALINA_HOME/server/lib/commons-fileupload-1.0-beta-1.jar
$CATALINA_HOME/shared/lib/commons-fileupload-1.0.jar

-Original Message-
From: Rhino [mailto:[EMAIL PROTECTED] 
Sent: 22 July 2003 17:59
To: Tomcat Users List
Subject: Re: Weird Problems installing servlets in Tomcat



- Original Message - 
From: "John Turner" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 10:22 AM
Subject: Re: Weird Problems installing servlets in Tomcat


> Rhino wrote:
>
> >
> > I'm still relatively new to Tomcat and Linux so I may be asking stupid
> > questions; if so, I don't mean to be. I'm just trying to understand
what's
> > going wrong. It's very possible that I've made some kind of newbie
mistake;
> > I'm just trying to understand what it is and how to fix it.
>
> Move the JAR file to where it should be, like $CATALINA_HOME/lib or
> $CATALINA_HOME/common/lib as described in the ClassLoader HOWTO.
>

I have had no luck getting Tomcat to load War files yet; I've been trying
various things for hours but no joy yet

First of all, I made a big mistake when I told you earlier that
commons-fileupload-1.0.jar was in /var/tomcat4/server/lib, AKA
$CATALINA_HOME/server/lib. I just plain looked at the wrong darned line of
the screen. In fact, commons-fileupload-1.0.jar was in
$CATALINA_HOME/common/lib (and still is). I think that's where I want it,
right? Tomcat uses FileUpload itself doesn't it? Otherwise I would put it in
the /shared path, right?

I've been reading the HOWTO that you cited and I'm getting a bit confused;
it seems to contradict both itself and you! According to the Quick Start
section, JAR files containing resource which are to be shared across all web
applications are to be placed in $CATALINA_HOME/shared/lib. Later, in the
detailed description of the class loaders, it says that JAR resources which
need to be shared across all web applications (except Tomcat itself) should
be put in $CATALINA_HOME/lib, not shared/lib. I suspect that the Quick Start
is wrong because it I don't even have a $CATALINA_HOME/shared/lib on the
server. That assumption would also agree with your remarks which say to use
$CATALINA_HOME/lib. The only problem is that I don't have a
$CATALINA_HOME/lib either! (We are using Tomcat 4.1.24 on Linux Mandrake 9.1
and running Tomcat as a service.) Anyway, this is probably all a bit off
point anyway; I should have commons-fileupload-1.0.jar in /common/lib,
right?

There's one other thing that I didn't post earlier which I'm starting to
suspect is fairly critical. When I first copied commons-fileupload-1.0.jar
into the $CATALINA_HOME/commons/lib, I noticed that there was already a jar
in that directory with the name commons-upload.jar. I assumed that was an
old version of the jar and deleted it.

The reason I think this might have been a major mistake was that nothing
worked right from that point on. I have been unable to install a single WAR
file, even one whose servlets did no FileUploads, since the point where I
copied commons-fileupload-1.0 jar into /commons/lib and deleted the
commons-fileupload.jar. Could that really be the cause of my problems? If
yes, what do I do about it? Do I need to find a copy of
commons-fileupload.jar and put it into /commons/lib? If yes, what do I do
about commons-fileupload-1.0.jar? Should it be in /common/lib as well? But
won't that cause conflicts?

I hope this note isn't too incoherent; I'm fairly confused right now and may
not be making quite as much sense as I would like

Rhino


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Shapira, Yoav

Howdy,

>I have had no luck getting Tomcat to load War files yet; I've been
trying
>various things for hours but no joy yet

This an issue: it means your tomcat installation is screwed up.  Resolve
this before you proceed with more development.

>the screen. In fact, commons-fileupload-1.0.jar was in
>$CATALINA_HOME/common/lib (and still is). I think that's where I want
it,
>right? Tomcat uses FileUpload itself doesn't it? Otherwise I would put
it
>in the /shared path, right?

All those three "right?" questions are correct.

>I've been reading the HOWTO that you cited and I'm getting a bit
confused;
>it seems to contradict both itself and you! According to the Quick
Start
>section, JAR files containing resource which are to be shared across
all
>web
>applications are to be placed in $CATALINA_HOME/shared/lib. Later, in
the
>detailed description of the class loaders, it says that JAR resources
which
>need to be shared across all web applications (except Tomcat itself)
should
>be put in $CATALINA_HOME/lib, not shared/lib. I suspect that the Quick

Make sure you're reading the documentation for the appropriate tomcat
version, i.e. 4.1 and not 4.0 or 5.0.  If confused, the classloader
how-to trumps the Quick Start guide.


>There's one other thing that I didn't post earlier which I'm starting
to
>suspect is fairly critical. When I first copied
commons-fileupload-1.0.jar
>into the $CATALINA_HOME/commons/lib, I noticed that there was already a
jar
>in that directory with the name commons-upload.jar. I assumed that was
an
>old version of the jar and deleted it.

You assumed correctly, but took the wrong action.  As I've mentioned a
couple of times now, those two jars are different APIs of the fileupload
component.  Soemthing which compiles against one jar won't compile
against the other.  Therein lies your, and tomcat's internal, problem.

What you should have done is keep the older file there and put your
fileupload in your WEB-INF/lib directory.

You might find it easier to start with a new installation of tomcat.
Don't touch the common/lib, server/lib, shared/lib directories.  Only
put libraries under the WEB-INF/lib directory of your webapp.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Rhino

- Original Message - 
From: "John Turner" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 10:22 AM
Subject: Re: Weird Problems installing servlets in Tomcat


> Rhino wrote:
>
> >
> > I'm still relatively new to Tomcat and Linux so I may be asking stupid
> > questions; if so, I don't mean to be. I'm just trying to understand
what's
> > going wrong. It's very possible that I've made some kind of newbie
mistake;
> > I'm just trying to understand what it is and how to fix it.
>
> Move the JAR file to where it should be, like $CATALINA_HOME/lib or
> $CATALINA_HOME/common/lib as described in the ClassLoader HOWTO.
>

I have had no luck getting Tomcat to load War files yet; I've been trying
various things for hours but no joy yet

First of all, I made a big mistake when I told you earlier that
commons-fileupload-1.0.jar was in /var/tomcat4/server/lib, AKA
$CATALINA_HOME/server/lib. I just plain looked at the wrong darned line of
the screen. In fact, commons-fileupload-1.0.jar was in
$CATALINA_HOME/common/lib (and still is). I think that's where I want it,
right? Tomcat uses FileUpload itself doesn't it? Otherwise I would put it in
the /shared path, right?

I've been reading the HOWTO that you cited and I'm getting a bit confused;
it seems to contradict both itself and you! According to the Quick Start
section, JAR files containing resource which are to be shared across all web
applications are to be placed in $CATALINA_HOME/shared/lib. Later, in the
detailed description of the class loaders, it says that JAR resources which
need to be shared across all web applications (except Tomcat itself) should
be put in $CATALINA_HOME/lib, not shared/lib. I suspect that the Quick Start
is wrong because it I don't even have a $CATALINA_HOME/shared/lib on the
server. That assumption would also agree with your remarks which say to use
$CATALINA_HOME/lib. The only problem is that I don't have a
$CATALINA_HOME/lib either! (We are using Tomcat 4.1.24 on Linux Mandrake 9.1
and running Tomcat as a service.) Anyway, this is probably all a bit off
point anyway; I should have commons-fileupload-1.0.jar in /common/lib,
right?

There's one other thing that I didn't post earlier which I'm starting to
suspect is fairly critical. When I first copied commons-fileupload-1.0.jar
into the $CATALINA_HOME/commons/lib, I noticed that there was already a jar
in that directory with the name commons-upload.jar. I assumed that was an
old version of the jar and deleted it.

The reason I think this might have been a major mistake was that nothing
worked right from that point on. I have been unable to install a single WAR
file, even one whose servlets did no FileUploads, since the point where I
copied commons-fileupload-1.0 jar into /commons/lib and deleted the
commons-fileupload.jar. Could that really be the cause of my problems? If
yes, what do I do about it? Do I need to find a copy of
commons-fileupload.jar and put it into /commons/lib? If yes, what do I do
about commons-fileupload-1.0.jar? Should it be in /common/lib as well? But
won't that cause conflicts?

I hope this note isn't too incoherent; I'm fairly confused right now and may
not be making quite as much sense as I would like

Rhino


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Shapira, Yoav

Howdy,

>Obviously I can't tell which methods are there via this technique. I'm
just
>trying to show the dates on the different classes to show that they are
>from
>the late-June version of the commons fileupload jar, as opposed to one
of
>the betas or RC* releases which had earlier dates. I'm taking it on
faith
>that the method I want is in there. Frankly, I'm not really sure how to
>tell what methods are in a given class in a jar file.

Using the dates is not conclusive.

One way to tell what methods are (or more importantly for this case,
aren't) in the fileupload jar is to compile your classes against it.
Not compile them someplace else and then deploy, assuming it's the same
jar file.

>I'm not sure I understand your advice. I did the compile in Eclipse on
my
>Windows machine. All I'm doing on the Linux box is importing a WAR file
>that contains the already compiled class files from Windows.

Either include the fileupload jar against which you compiled in the WAR
file, or compile against the fileupload jar that's on your linux
machine.

>| Tomcat 4.1.26, which is looking like the next stable release at the
>moment, have the fileupload 1.0 | final.  Feel free to download and use
it.
>
>Do I really need to do this? Tomcat 4.1.24 and
commons-fileupload-1.0.jar
>seem to work fine on my Windows machine. Shouldn't they also work fine
on
>the Linux box?

They should work fine, but they aren't because somewhere along the way
from your windows setup to your linux setup is a different fileupload
jar.  The reason I mentioned it is that tomcat 4.1.24 and 4.1.26 use
different versions of fileupload, that are inconsistent as far as the
API goes.

>I'm still relatively new to Tomcat and Linux so I may be asking stupid
>questions; if so, I don't mean to be. I'm just trying to understand
what's
>going wrong. It's very possible that I've made some kind of newbie
mistake;
>I'm just trying to understand what it is and how to fix it.

This is more of a general issue: make sure you're compiling against the
same libraries that you will deploy to.  No question is stupid, but this
is a common error.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread John Turner
Rhino wrote:

I'm still relatively new to Tomcat and Linux so I may be asking stupid
questions; if so, I don't mean to be. I'm just trying to understand what's
going wrong. It's very possible that I've made some kind of newbie mistake;
I'm just trying to understand what it is and how to fix it.
Move the JAR file to where it should be, like $CATALINA_HOME/lib or 
$CATALINA_HOME/common/lib as described in the ClassLoader HOWTO.

John



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Rhino

- Original Message - 
From: "Shapira, Yoav" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 9:31 AM
Subject: RE: Weird Problems installing servlets in Tomcat



Howdy,

>I took a peek inside the commons-fileupload-1.0.jar and got this, which
>looks just fine to me:
>jar tvf commons-fileupload-1.0.jar | more
> 0 Wed Jun 25 23:12:04 EDT 2003 META-INF/
> 420 Wed Jun 25 23:12:04 EDT 2003 META-INF/MANIFEST.MF
> 0 Wed Jun 25 23:11:58 EDT 2003 org/


| I'm curious how you can tell which methods are in these classes (and which
aren't, thereby causing | the NoMethod error), from the jar listing? ;)

Obviously I can't tell which methods are there via this technique. I'm just
trying to show the dates on the different classes to show that they are from
the late-June version of the commons fileupload jar, as opposed to one of
the betas or RC* releases which had earlier dates. I'm taking it on faith
that the method I want is in there. Frankly, I'm not really sure how to tell
what methods are in a given class in a jar file.

>I can't think of anything else to try at this point.
>
>Any ideas anyone?

| Yeah.  Compile with the components on your deployment classpath in the
compile classpath.  That's | a standard practice to ensure consistency and
avoid the errors you're seeing.

I'm not sure I understand your advice. I did the compile in Eclipse on my
Windows machine. All I'm doing on the Linux box is importing a WAR file that
contains the already compiled class files from Windows.

| FileUploaded went through a couple of 1.0 RCs before the final 1.0 release
that did not work with
| tomcat.  If you're really interested in the details, search the
commons-dev list archive.

Haven't I already established that I'm using the final 1.0 release rather
than one of the RCs or betas?

| Tomcat 4.1.26, which is looking like the next stable release at the
moment, have the fileupload 1.0 | final.  Feel free to download and use it.

Do I really need to do this? Tomcat 4.1.24 and commons-fileupload-1.0.jar
seem to work fine on my Windows machine. Shouldn't they also work fine on
the Linux box?

I'm still relatively new to Tomcat and Linux so I may be asking stupid
questions; if so, I don't mean to be. I'm just trying to understand what's
going wrong. It's very possible that I've made some kind of newbie mistake;
I'm just trying to understand what it is and how to fix it.

Rhino



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread John Turner
That's probably the worst place to put it, according to the ClassLoader 
HOWTO:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/class-loader-howto.html

I would try $CATALINA_HOME/common/lib or better yet $CATALINA_HOME/lib.

The former if ALL web applications PLUS Tomcat internals need access, 
the latter if just web applications need access.

John

Rhino wrote:
commons-fileupload-1.0.jar is in /var/tomcat4/server/lib.

I'm not sure if that's the *best* place for it but I thought that was one of
the two places where you can put jars and have them visible to all the
servlets that might need them.
Rhino

- Original Message - 
From: "John Turner" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 9:21 AM
Subject: Re: Weird Problems installing servlets in Tomcat



Where is commons-fileupload-1.0.jar located?  Is it in the correct
location for the ClassLoader to find it?
John

Rhino wrote:


Tomcat has suddenly started behaving rather strangely on our Linux
server. I was hoping someone here could give me some insight into the
reasons and some suggestions for resolving the problem. We are running
Tomcat 4.1.24 on a Linux Mandrake 9.1 box.
I wrote a servlet on the weekend which worked on my Windows XP machine
but misbehaved slightly on the Linux server when installed there.
Yesterday, I figured out what the problem was and revised the servlet.
The revised version worked in Windows so I tried to install it in Linux.
That's when the weirdness started: I can't install the WAR file in
Tomcat. It always fails on the same error:
java.lang.NoSuchMethodError:
org.apache.commons.fileupload.FileUpload.setSizeMax(I)V
I checked the Javadocs and found that the setSizeMax() method is part of
the class FileUploadBase, not FileUpload, so I immediately suspected
that the Linux box had an older version of the commons fileupload jar,
which only went to version 1.0 at the end of June. I searched the Linux
box and found commons-fileupload.jar, which is NOT the current version,
and also found commons-fileupload-1.0.jar which IS the current version.
I deleted the old one and now the only version of the jar on the server
is commons-fileupload-1.0.jar.
I tried installing the WAR file again but get the same error. I even
tried installing a newer version of a different WAR file that doesn't do
file uploads and IT failed on the same error. What is going on here?
I took a peek inside the commons-fileupload-1.0.jar and got this, which
looks just fine to me:
jar tvf commons-fileupload-1.0.jar | more
0 Wed Jun 25 23:12:04 EDT 2003 META-INF/
  420 Wed Jun 25 23:12:04 EDT 2003 META-INF/MANIFEST.MF
0 Wed Jun 25 23:11:58 EDT 2003 org/
0 Wed Jun 25 23:11:58 EDT 2003 org/apache/
0 Wed Jun 25 23:11:58 EDT 2003 org/apache/commons/
0 Wed Jun 25 23:11:58 EDT 2003 org/apache/commons/fileupload/
 6020 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/DefaultFileItem.class
 1541 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/DefaultFileItemFactory.class
 1547 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/DeferredFileOutputStream.class
 2159 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/DiskFileUpload.class
  792 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/FileItem.class
  262 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/FileItemFactory.class
  811 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/FileUpload.class
  672 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/FileUploadBase$InvalidContentTypeException.cla
ss
  669 Wed Jun 25 23:11:58 EDT 2003

org/apache/commons/fileupload/FileUploadBase$SizeLimitExceededException.clas
s
  651 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/FileUploadBase$UnknownSizeException.class
 7449 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/FileUploadBase.class
  486 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/FileUploadException.class
  894 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/MultipartStream$IllegalBoundaryException.class

  894 Wed Jun 25 23:11:58 EDT 2003

org/apache/commons/fileupload/MultipartStream$MalformedStreamException.class

 6245 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/MultipartStream.class
 1789 Wed Jun 25 23:11:58 EDT 2003
org/apache/commons/fileupload/ThresholdingOutputStream.class
 2873 Mon Feb 10 22:05:50 EST 2003 META-INF/LICENSE.txt
  121 Wed Jun 25 23:12:04 EDT 2003 META-INF/INDEX.LIST
I can't think of anything else to try at this point.
Any ideas anyone?

Rhino
---
rhino1 AT sympatico DOT ca
"If you want the best seat in the house, you'll have to move the cat."


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-

RE: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Shapira, Yoav

Howdy,

>commons-fileupload-1.0.jar is in /var/tomcat4/server/lib.
>
>I'm not sure if that's the *best* place for it but I thought that was
one
>of
>the two places where you can put jars and have them visible to all the
>servlets that might need them.

Umm, no.  From the classloader how-to, regarding the server/lib and
server/classes: "These classes and resources are TOTALLY invisible to
web applications"

Move it to common/lib or keep a copy in server/lib and another in the
WEB-INF/lib directory of your webapp.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Rhino
commons-fileupload-1.0.jar is in /var/tomcat4/server/lib.

I'm not sure if that's the *best* place for it but I thought that was one of
the two places where you can put jars and have them visible to all the
servlets that might need them.

Rhino

- Original Message - 
From: "John Turner" <[EMAIL PROTECTED]>
To: "Tomcat Users List" <[EMAIL PROTECTED]>
Sent: Tuesday, July 22, 2003 9:21 AM
Subject: Re: Weird Problems installing servlets in Tomcat


>
> Where is commons-fileupload-1.0.jar located?  Is it in the correct
> location for the ClassLoader to find it?
>
> John
>
> Rhino wrote:
>
> > Tomcat has suddenly started behaving rather strangely on our Linux
> > server. I was hoping someone here could give me some insight into the
> > reasons and some suggestions for resolving the problem. We are running
> > Tomcat 4.1.24 on a Linux Mandrake 9.1 box.
> >
> > I wrote a servlet on the weekend which worked on my Windows XP machine
> > but misbehaved slightly on the Linux server when installed there.
> > Yesterday, I figured out what the problem was and revised the servlet.
> > The revised version worked in Windows so I tried to install it in Linux.
> > That's when the weirdness started: I can't install the WAR file in
> > Tomcat. It always fails on the same error:
> >
> > java.lang.NoSuchMethodError:
> > org.apache.commons.fileupload.FileUpload.setSizeMax(I)V
> > I checked the Javadocs and found that the setSizeMax() method is part of
> > the class FileUploadBase, not FileUpload, so I immediately suspected
> > that the Linux box had an older version of the commons fileupload jar,
> > which only went to version 1.0 at the end of June. I searched the Linux
> > box and found commons-fileupload.jar, which is NOT the current version,
> > and also found commons-fileupload-1.0.jar which IS the current version.
> > I deleted the old one and now the only version of the jar on the server
> > is commons-fileupload-1.0.jar.
> >
> > I tried installing the WAR file again but get the same error. I even
> > tried installing a newer version of a different WAR file that doesn't do
> > file uploads and IT failed on the same error. What is going on here?
> >
> > I took a peek inside the commons-fileupload-1.0.jar and got this, which
> > looks just fine to me:
> > jar tvf commons-fileupload-1.0.jar | more
> >  0 Wed Jun 25 23:12:04 EDT 2003 META-INF/
> >420 Wed Jun 25 23:12:04 EDT 2003 META-INF/MANIFEST.MF
> >  0 Wed Jun 25 23:11:58 EDT 2003 org/
> >  0 Wed Jun 25 23:11:58 EDT 2003 org/apache/
> >  0 Wed Jun 25 23:11:58 EDT 2003 org/apache/commons/
> >  0 Wed Jun 25 23:11:58 EDT 2003 org/apache/commons/fileupload/
> >   6020 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/DefaultFileItem.class
> >   1541 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/DefaultFileItemFactory.class
> >   1547 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/DeferredFileOutputStream.class
> >   2159 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/DiskFileUpload.class
> >792 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/FileItem.class
> >262 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/FileItemFactory.class
> >811 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/FileUpload.class
> >672 Wed Jun 25 23:11:58 EDT 2003
> >
org/apache/commons/fileupload/FileUploadBase$InvalidContentTypeException.cla
ss
> >669 Wed Jun 25 23:11:58 EDT 2003
> >
org/apache/commons/fileupload/FileUploadBase$SizeLimitExceededException.clas
s
> >651 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/FileUploadBase$UnknownSizeException.class
> >   7449 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/FileUploadBase.class
> >486 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/FileUploadException.class
> >894 Wed Jun 25 23:11:58 EDT 2003
> >
org/apache/commons/fileupload/MultipartStream$IllegalBoundaryException.class
> >894 Wed Jun 25 23:11:58 EDT 2003
> >
org/apache/commons/fileupload/MultipartStream$MalformedStreamException.class
> >   6245 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/MultipartStream.class
> >   1789 Wed Jun 25 23:11:58 EDT 2003
> > org/apache/commons/fileupload/ThresholdingOutputStream.class
> >   2873 Mon Feb 10 22:05:50 EST 2003 META-INF/LICENSE.txt
> >121 Wed Jun 25 23:12:04 EDT 2003 META-INF/INDEX.LIST
> > I can't think of 

RE: Weird Problems installing servlets in Tomcat

2003-07-22 Thread Shapira, Yoav

Howdy,

>I took a peek inside the commons-fileupload-1.0.jar and got this, which >looks just 
>fine to me:
>jar tvf commons-fileupload-1.0.jar | more
> 0 Wed Jun 25 23:12:04 EDT 2003 META-INF/
>   420 Wed Jun 25 23:12:04 EDT 2003 META-INF/MANIFEST.MF
> 0 Wed Jun 25 23:11:58 EDT 2003 org/


I'm curious how you can tell which methods are in these classes (and which aren't, 
thereby causing the NoMethod error), from the jar listing? ;)

>I can't think of anything else to try at this point.
>
>Any ideas anyone?

Yeah.  Compile with the components on your deployment classpath in the compile 
classpath.  That's a standard practice to ensure consistency and avoid the errors 
you're seeing.

FileUploaded went through a couple of 1.0 RCs before the final 1.0 release that did 
not work with tomcat.  If you're really interested in the details, search the 
commons-dev list archive.

Tomcat 4.1.26, which is looking like the next stable release at the moment, have the 
fileupload 1.0 final.  Feel free to download and use it.

Yoav Shapira



This e-mail, including any attachments, is a confidential business communication, and 
may contain information that is confidential, proprietary and/or privileged.  This 
e-mail is intended only for the individual(s) to whom it is addressed, and may not be 
saved, copied, printed, disclosed or used by anyone else.  If you are not the(an) 
intended recipient, please immediately delete this e-mail from your computer system 
and notify the sender.  Thank you.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Weird Problems installing servlets in Tomcat

2003-07-22 Thread John Turner
Where is commons-fileupload-1.0.jar located?  Is it in the correct 
location for the ClassLoader to find it?

John

Rhino wrote:

Tomcat has suddenly started behaving rather strangely on our Linux 
server. I was hoping someone here could give me some insight into the 
reasons and some suggestions for resolving the problem. We are running 
Tomcat 4.1.24 on a Linux Mandrake 9.1 box.
 
I wrote a servlet on the weekend which worked on my Windows XP machine 
but misbehaved slightly on the Linux server when installed there. 
Yesterday, I figured out what the problem was and revised the servlet. 
The revised version worked in Windows so I tried to install it in Linux. 
That's when the weirdness started: I can't install the WAR file in 
Tomcat. It always fails on the same error:
 
java.lang.NoSuchMethodError: 
org.apache.commons.fileupload.FileUpload.setSizeMax(I)V
I checked the Javadocs and found that the setSizeMax() method is part of 
the class FileUploadBase, not FileUpload, so I immediately suspected 
that the Linux box had an older version of the commons fileupload jar, 
which only went to version 1.0 at the end of June. I searched the Linux 
box and found commons-fileupload.jar, which is NOT the current version, 
and also found commons-fileupload-1.0.jar which IS the current version. 
I deleted the old one and now the only version of the jar on the server 
is commons-fileupload-1.0.jar.
 
I tried installing the WAR file again but get the same error. I even 
tried installing a newer version of a different WAR file that doesn't do 
file uploads and IT failed on the same error. What is going on here?
 
I took a peek inside the commons-fileupload-1.0.jar and got this, which 
looks just fine to me:
jar tvf commons-fileupload-1.0.jar | more
 0 Wed Jun 25 23:12:04 EDT 2003 META-INF/
   420 Wed Jun 25 23:12:04 EDT 2003 META-INF/MANIFEST.MF
 0 Wed Jun 25 23:11:58 EDT 2003 org/
 0 Wed Jun 25 23:11:58 EDT 2003 org/apache/
 0 Wed Jun 25 23:11:58 EDT 2003 org/apache/commons/
 0 Wed Jun 25 23:11:58 EDT 2003 org/apache/commons/fileupload/
  6020 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/DefaultFileItem.class
  1541 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/DefaultFileItemFactory.class
  1547 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/DeferredFileOutputStream.class
  2159 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/DiskFileUpload.class
   792 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileItem.class
   262 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileItemFactory.class
   811 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileUpload.class
   672 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileUploadBase$InvalidContentTypeException.class
   669 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileUploadBase$SizeLimitExceededException.class
   651 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileUploadBase$UnknownSizeException.class
  7449 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileUploadBase.class
   486 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/FileUploadException.class
   894 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/MultipartStream$IllegalBoundaryException.class
   894 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/MultipartStream$MalformedStreamException.class
  6245 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/MultipartStream.class
  1789 Wed Jun 25 23:11:58 EDT 2003 
org/apache/commons/fileupload/ThresholdingOutputStream.class
  2873 Mon Feb 10 22:05:50 EST 2003 META-INF/LICENSE.txt
   121 Wed Jun 25 23:12:04 EDT 2003 META-INF/INDEX.LIST
I can't think of anything else to try at this point.
 
Any ideas anyone?
 
Rhino
---
rhino1 AT sympatico DOT ca
"If you want the best seat in the house, you'll have to move the cat."


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]