You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by de...@wexwarez.com on 2002/07/18 00:46:36 UTC
Apache Tomcat combo-please help
I am having a problem getting apache tomcat running using mod_webapp.so
I am using:
linux redhat 7.3
jdk1.4
apache 1.3.26
tomcat 4.0.4
I got apache 1.3.26 compiled and installed with enable-module=so option it
starts and stops fine
I got tomcat 4.0.4, installed it and it starts and stops fine, the
examples work etc etc
I got jakarta-tomcat-connectors using CVS, and followed the instructions
to compile mod_webapp.so. It compiled and I placed it in
$APACHE_HOME/libexec/
I added the following lines to httpd.conf:
LoadModule webapp_module libexec/mod_webapp.so
AddModule mod_webapp.c
WebAppConnection warpConnection warp localhost:8080
WebAppDeploy examples conn /examples
I started tomcat no problem. When I start apache i get:
yntax error on line 984 of /usr/local/apache/conf/httpd.conf:
Invalid virtual host name
/usr/local/apache/bin/apachectl start: httpd could not be started
line 984 refers to this line:
WebAppDeploy examples conn /examples
I am stumped some help please?
thanks,
ryan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: io path information in servlets
Posted by Jacob Kjome <ho...@visi.com>.
With Tomcat, normally when you deploy a .war file, it gets expanded and the
context is run out of the directory created upon expansion, not the .war
file itself. For intance if you put a "myapp.war" file in
TOMCAT_HOME/webapps (and haven't defined the context in server.xml because,
if defined, it doesn't expand for some reason...known bug...) Tomcat
automatically extracts the contents of the .war file to a directory called
"myapp". Then the context is run from that directory.
However, you can specify your appbase as the myapp.war file itself. Tomcat
can serve your entire application out of the archive. Given this,
myapp/WEB-INF is not on the file system. It exists ony iside the archive
where no file IO is possible. So, a call to getRealPath"/") will return
null because there is no real system file path to be found.
You can avoid this issue by always making sure to use your .war archive to
distribute the app and make sure that the system is set up to expand the
archive so the app is run out of a directory on the file system.
Hope that helps.
Jake
At 07:20 PM 7/17/2002 -0500, you wrote:
>I have a webapp that stores some data in an xml file. (I am using jdom to
>read and write the xml files.)
>
>Right now I am using a construct like:
>
>String prefix = sc.getRealPath("/") + "/WEB-INF/dirName/";
>
>to get the path. I then concatonate that with the file name and it works
>fine.
>
>However, in the javadocs for javax.servlet I read:
>
>"This method returns null if the servlet container cannot translate the
>virtual path to a real path for any reason (such as when the content is
>being made available from a .war archive)."
>
>I am not exactly sure what this means. If I deploy this application as a
>.war, does the sc.getRealPath stop working?
>
>Thanks
>Paul Phillips
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: io path information in servlets
Posted by Paul Phillips <pa...@partitura.com>.
I appreciate the thoughts of Will and Craig on this subject. I want to
store and manipulate data in XML files that accompany a webapp I want to
deploy as a war. I was using:
String prefix = sc.getRealPath("/") + "/WEB-INF/dirName/";
to get the path.
I think it was Will who wrote:
>Also, if you're writing stuff to the "exploded webapp directory", then
>remember that it can "go away" if the container, for whatever reason,
>decided to redeploy your WAR.
Ouch - that is scary.
OK, so my question - if I want to do this, where in the file system should
I stick the xml file so it doesn't get overwritten if the war is
redeployed? A user's home directory? That will force the user to mess
with the configuration.
I'm a out of my league on this, so I'd appreciate any advice. Of of
course, I could give up on file storage and go with jdbc, but that seems
like overkill for this little app I am writing.
Thanks...
Paul Phillips
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: io path information in servlets
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Thu, 18 Jul 2002, Will Hartung wrote:
>
> This all came out of the fact that it seems essentially impossible to create
> a webapp according to the 2.3 spec that uses file based storage and have it
> be usable "out of the box" with zero basic configuration to start up. For
> example, I don't think that there is a (portable) way for a servlet to
> change its own "parameters". Say the webapp comes with some "reasonable
> default" for File pathnames, but a user wishes to change them. They cannot
> do that using the servlet itself (through some HTML Form/GUI mechanism), in
> a portable way.
>
The approach I would use for this is to pass the default pathname as an
<env-entry> in the web.xml file, and access it via JNDI calls in the
servlet. Containers that support JNDI resources for webapps (which means
Tomcat 4 plus every J2EE server in the world) provide mechanisms for the
administrator to change the value of environment entries, either in a
configuration file (like server.xml for Tomcat) or as part of the process
of deploying the application, with zero changes to the WAR itself.
The mechanism to do the configuration customizaton is not "portable" in
the sense of being identical on every server, but it is available.
> Even with a databased app, there's no way for a servlet to change its
> "default" JDBC URL and persist that change, it has to be done through the
> configuration files or in the webapp itself.
>
That's actually a good thing (changing it via configuration).
Consider an environment with three servers (development, test, and
production). Naturally, each is connected to a different database. The
last thing you want to do is have to change JDBC strings in your webapp
depending on which server you are deploying to.
Using a <resource-ref> to declare a reference to a connection pool that is
configured for you by the server administrator is much less tedious and
error prone -- and you don't have to do anything at all to your
application itself.
JNDI resources are your friend.
> That would be a nice bit to concentrate on in the future I think.
>
> Best Regards,
>
> Will Hartung
> (willh@msoft.com)
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: io path information in servlets
Posted by Will Hartung <wi...@msoft.com>.
From: "Craig R. McClanahan" <cr...@apache.org>
Sent: Wednesday, July 17, 2002 11:19 PM
Subject: Re: io path information in servlets
> On Wed, 17 Jul 2002, Will Hartung wrote:
>
> > It has CONVENTIONALLY been done this way, as it's a fairly obvious
> > optimization to handle a web app (who wants to constantly grind through
a
> > jar file for crying out loud). However, what is convention, and what is
> > specification are two completely different things.
>
> Be sure you run some benchmarks before complaining too loudly about
> "constantly grind through a jar file". You will find, for example, that
> Tomcat will never do that more than once to load a class or JAR file, and
> for most static resources in the WAR it will also unpack them once and
> only once.
>
> In the very large majority of cases, whether a webapp is unpacked or not
> will have zero impact on performance for typical installations of Tomcat.
Yes, this was a premature statement, and I didn't actually expect a
container to literally continually access the files from the jar files.
> > So, specifically, if you are relying upon the fact that getRealPath will
> > give you a location that you can actually perform read/write file I/O
upon,
> > then you are relying on a Container specific behavior that MAY not be
> > portable to other containers.
> >
> > A simple contrived example is that if you were deploying your WAR to,
say,
> > an Oracle Application Server, then Oracle can easily "deploy" the WAR
into
> > DBMS Tables and not use a file system at all, and this behavior is
perfectly
> > legal within the specification. (Mind you, I don't know what Oracle
does.
> > Like I said, a contrived example).
>
> As a matter of fact, Oracle has web containers that do exactly this --
> funny thing, they run *faster* than the filesystem in many cases, because
> they take advantage of the DBMS's optimized I/O and caching capabilities
> :-).
Yeah, it makes you wonder about things like Oracle's Internet File System.
> > Another example is that your WAR may be deployed into a container where
the
> > webapp is exploded in an area where you may only have READ permission,
and
> > not WRITE. Also legal.
> >
> > It's actually a bit of a nit of mine that by specification, there is no
> > guaranteed, portable way for a Servlet to get access to some writeable
area
> > for file I/O. It can be a parameter, say in the WAR, but the container
> > itself is not guaranteed to have to deliver this kind of functionality
to a
> > Servlet.
> >
>
> Not true.
>
> File workdir = (File)
> getServletContext().getAttribute("javax.servlet.context.tempdir");
>
> You don't get any assurances about the persistence of any files you store
> here, but this returns a perfectly useful directory for temporary files
> that you might need to create during execution of your business logic.
> (See section 3.7.1).
Ah good! This is really necessary I think. I also like how they required
that it contain File objects, thus you're able to get Streams and Writers as
necessary. Pity about persistence, however.
This all came out of the fact that it seems essentially impossible to create
a webapp according to the 2.3 spec that uses file based storage and have it
be usable "out of the box" with zero basic configuration to start up. For
example, I don't think that there is a (portable) way for a servlet to
change its own "parameters". Say the webapp comes with some "reasonable
default" for File pathnames, but a user wishes to change them. They cannot
do that using the servlet itself (through some HTML Form/GUI mechanism), in
a portable way.
Even with a databased app, there's no way for a servlet to change its
"default" JDBC URL and persist that change, it has to be done through the
configuration files or in the webapp itself.
That would be a nice bit to concentrate on in the future I think.
Best Regards,
Will Hartung
(willh@msoft.com)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: io path information in servlets
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 17 Jul 2002, Will Hartung wrote:
> It has CONVENTIONALLY been done this way, as it's a fairly obvious
> optimization to handle a web app (who wants to constantly grind through a
> jar file for crying out loud). However, what is convention, and what is
> specification are two completely different things.
>
Be sure you run some benchmarks before complaining too loudly about
"constantly grind through a jar file". You will find, for example, that
Tomcat will never do that more than once to load a class or JAR file, and
for most static resources in the WAR it will also unpack them once and
only once.
In the very large majority of cases, whether a webapp is unpacked or not
will have zero impact on performance for typical installations of Tomcat.
> So, specifically, if you are relying upon the fact that getRealPath will
> give you a location that you can actually perform read/write file I/O upon,
> then you are relying on a Container specific behavior that MAY not be
> portable to other containers.
>
> A simple contrived example is that if you were deploying your WAR to, say,
> an Oracle Application Server, then Oracle can easily "deploy" the WAR into
> DBMS Tables and not use a file system at all, and this behavior is perfectly
> legal within the specification. (Mind you, I don't know what Oracle does.
> Like I said, a contrived example).
>
As a matter of fact, Oracle has web containers that do exactly this --
funny thing, they run *faster* than the filesystem in many cases, because
they take advantage of the DBMS's optimized I/O and caching capabilities
:-).
> Another example is that your WAR may be deployed into a container where the
> webapp is exploded in an area where you may only have READ permission, and
> not WRITE. Also legal.
>
> It's actually a bit of a nit of mine that by specification, there is no
> guaranteed, portable way for a Servlet to get access to some writeable area
> for file I/O. It can be a parameter, say in the WAR, but the container
> itself is not guaranteed to have to deliver this kind of functionality to a
> Servlet.
>
Not true.
File workdir = (File)
getServletContext().getAttribute("javax.servlet.context.tempdir");
You don't get any assurances about the persistence of any files you store
here, but this returns a perfectly useful directory for temporary files
that you might need to create during execution of your business logic.
(See section 3.7.1).
> I think that for PORTABILITY, you should make the path that you save your
> XML file to be a ENV-ENTRY in the WAR, that, at least in TC 4, can be
> overridden by the Context that deploys the WAR. This gives the person
> deploying your application the control over where your webapp can write to
> its disk.
>
That's one reasonable way to do it. All J2EE containers, by the way, need
to provide mechanisms for defining the values corresponding <env-entry>
resources.
> For those containers that do not have the ability to override the ENV-ENTRY
> in the Context, they're stuck unpacking the WAR and fixing it there (so much
> for validating the integrity of your WAR buy signing it, though to be honest
> I don't know if the specification mentions anything about signed WARs).
> Which is another nit. Something like the ENV-ENTRY override needs to be
> standardized.
>
It is ... across every J2EE container.
> Also, if you're writing stuff to the "exploded webapp directory", then
> remember that it can "go away" if the container, for whatever reason,
> decided to redeploy your WAR.
>
> Basically, what you're doing with TC is probably fine, even semi-long term,
> but it's not portable behavior as documented in the specification.
>
Well, there's always databases ... last I heard they are pretty good at
long term storage :-).
> These limitations are not there specifically to screw up your code, they're
> in the spec to let the container developers have a lot more flexibility in
> how they build their containers.
>
> Best Regards,
>
> Will Hartung
> (willh@msoft.com)
>
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: io path information in servlets
Posted by Will Hartung <wi...@msoft.com>.
From: "Paul Phillips" <pa...@partitura.com>
Sent: Wednesday, July 17, 2002 5:20 PM
Subject: io path information in servlets
> I have a webapp that stores some data in an xml file. (I am using jdom to
> read and write the xml files.)
>
> Right now I am using a construct like:
>
> String prefix = sc.getRealPath("/") + "/WEB-INF/dirName/";
>
> to get the path. I then concatonate that with the file name and it works
> fine.
>
> However, in the javadocs for javax.servlet I read:
>
> "This method returns null if the servlet container cannot translate the
> virtual path to a real path for any reason (such as when the content is
> being made available from a .war archive)."
>
> I am not exactly sure what this means. If I deploy this application as a
> .war, does the sc.getRealPath stop working?
What it is refering to is the fact that there is nothing in the
specification that says when a WAR is deployed into a server, that the WAR
is actually exploded into something resembling a filesystem, much less
something that you may actually have write access too (or, heck, even READ
access for that matter).
It has CONVENTIONALLY been done this way, as it's a fairly obvious
optimization to handle a web app (who wants to constantly grind through a
jar file for crying out loud). However, what is convention, and what is
specification are two completely different things.
So, specifically, if you are relying upon the fact that getRealPath will
give you a location that you can actually perform read/write file I/O upon,
then you are relying on a Container specific behavior that MAY not be
portable to other containers.
A simple contrived example is that if you were deploying your WAR to, say,
an Oracle Application Server, then Oracle can easily "deploy" the WAR into
DBMS Tables and not use a file system at all, and this behavior is perfectly
legal within the specification. (Mind you, I don't know what Oracle does.
Like I said, a contrived example).
Another example is that your WAR may be deployed into a container where the
webapp is exploded in an area where you may only have READ permission, and
not WRITE. Also legal.
It's actually a bit of a nit of mine that by specification, there is no
guaranteed, portable way for a Servlet to get access to some writeable area
for file I/O. It can be a parameter, say in the WAR, but the container
itself is not guaranteed to have to deliver this kind of functionality to a
Servlet.
I think that for PORTABILITY, you should make the path that you save your
XML file to be a ENV-ENTRY in the WAR, that, at least in TC 4, can be
overridden by the Context that deploys the WAR. This gives the person
deploying your application the control over where your webapp can write to
its disk.
For those containers that do not have the ability to override the ENV-ENTRY
in the Context, they're stuck unpacking the WAR and fixing it there (so much
for validating the integrity of your WAR buy signing it, though to be honest
I don't know if the specification mentions anything about signed WARs).
Which is another nit. Something like the ENV-ENTRY override needs to be
standardized.
Also, if you're writing stuff to the "exploded webapp directory", then
remember that it can "go away" if the container, for whatever reason,
decided to redeploy your WAR.
Basically, what you're doing with TC is probably fine, even semi-long term,
but it's not portable behavior as documented in the specification.
These limitations are not there specifically to screw up your code, they're
in the spec to let the container developers have a lot more flexibility in
how they build their containers.
Best Regards,
Will Hartung
(willh@msoft.com)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: io path information in servlets
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Wed, 17 Jul 2002, Paul Phillips wrote:
> Date: Wed, 17 Jul 2002 19:20:00 -0500
> From: Paul Phillips <pa...@partitura.com>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: io path information in servlets
>
> I have a webapp that stores some data in an xml file. (I am using jdom to
> read and write the xml files.)
>
> Right now I am using a construct like:
>
> String prefix = sc.getRealPath("/") + "/WEB-INF/dirName/";
>
> to get the path. I then concatonate that with the file name and it works
> fine.
>
> However, in the javadocs for javax.servlet I read:
>
> "This method returns null if the servlet container cannot translate the
> virtual path to a real path for any reason (such as when the content is
> being made available from a .war archive)."
>
> I am not exactly sure what this means. If I deploy this application as a
> .war, does the sc.getRealPath stop working?
>
Yes; assuming that Tomcat doesn't unpack the WAR into a directory, this
definitely stops working. In that case, getRealPath() will return null
because there is no such thing as a "real path" to this resource path.
Note that the ability to run an application from an unpacked directory at
all is *not* a feature that the servlet spec requires -- the only
requirement is to accept a WAR.
If you want to do this kind of thing in a manner guaranteed to be
portable, you should make your servlet accept an initialization parameter
of some sort that identifies the directory in which output files should be
stored.
> Thanks
> Paul Phillips
>
Craig
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
io path information in servlets
Posted by Paul Phillips <pa...@partitura.com>.
I have a webapp that stores some data in an xml file. (I am using jdom to
read and write the xml files.)
Right now I am using a construct like:
String prefix = sc.getRealPath("/") + "/WEB-INF/dirName/";
to get the path. I then concatonate that with the file name and it works
fine.
However, in the javadocs for javax.servlet I read:
"This method returns null if the servlet container cannot translate the
virtual path to a real path for any reason (such as when the content is
being made available from a .war archive)."
I am not exactly sure what this means. If I deploy this application as a
.war, does the sc.getRealPath stop working?
Thanks
Paul Phillips
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Apache Tomcat integration-please help
Posted by de...@wexwarez.com.
The lack of a ServerName tag and the warpConnection instead of conn
seemed to be my problem i am up and running thanks for your help!
ryan
On Thu, 18 Jul 2002, Milt Epstein wrote:
> On Thu, 18 Jul 2002 developer@wexwarez.com wrote:
>
> > UNfortunately I have tried that at it did not help. Anymore
> > suggestions would be wonderful, cause I am stumped. Maybe does it
> > have something to do with my apache install?
>
> Well, that *was* a problem, but maybe it wasn't the only one. Try
> commenting out those lines, and see what effect that has. Are those
> the last lines in your conf file? Maybe you've got a different
> problem somewhere else in your conf file, and it's just reporting it
> there because it's the last line. The error message (are you still
> getting the same one?) indicates it's something related to virtual
> hosts, so that would be a place to focus. Of course, then you're
> talking about an apache problem, not a tomcat problem.
>
>
> > On Thu, 18 Jul 2002, Milt Epstein wrote:
> >
> > > On Thu, 18 Jul 2002 developer@wexwarez.com wrote:
> > >
> > > > I am having a problem getting apache tomcat running using mod_webapp.so
> > > > I am using:
> > > > linux redhat 7.3
> > > > jdk1.4
> > > > apache 1.3.26
> > > > tomcat 4.0.4
> > > > I got apache 1.3.26 compiled and installed with enable-module=so option it
> > > > starts and stops fine
> > > > I got tomcat 4.0.4, installed it and it starts and stops fine, the
> > > > examples work etc etc
> > > > I got jakarta-tomcat-connectors using CVS, and followed the instructions
> > > > to compile mod_webapp.so. It compiled and I placed it in
> > > > $APACHE_HOME/libexec/
> > > > I added the following lines to httpd.conf:
> > > > LoadModule webapp_module libexec/mod_webapp.so
> > > > AddModule mod_webapp.c
> > > > WebAppConnection warpConnection warp localhost:8080
> > > > WebAppDeploy examples conn /examples
> > > >
> > > > I started tomcat no problem. When I start apache i get:
> > > > yntax error on line 984 of /usr/local/apache/conf/httpd.conf:
> > > > Invalid virtual host name
> > > > /usr/local/apache/bin/apachectl start: httpd could not be started
> > > > line 984 refers to this line:
> > > > WebAppDeploy examples conn /examples
> > > >
> > > > I am stumped some help please?
> > >
> > > This is my understanding of WebAppConnection and WebAppDeploy
> > > (corrections welcome :-):
> > >
> > > The second argument to the WebAppDeploy directive (here conn) must be
> > > a defined connection per a WebAppConnection directive (the first
> > > argument of WebAppConnection specifies the connection). That is,
> > >
> > > WebAppConnection connection protocol host:port
> > >
> > > defines a connection -- named connection, using protocol (warp is the
> > > only possibility currently, I believe), available at host:port -- and
> > >
> > > WebAppDeploy context connection url-prefix
> > >
> > > indicates that URLs that begin with url-prefix belong to context and
> > > should be passed to connection.
> > >
> > > Anyway, although you should understand at least the basics of the
> > > above, the gist of it is you should change "conn" to "warpConnection".
> > >
> > > Milt Epstein
> > > Research Programmer
> > > Systems and Technology Services (STS)
> > > Campus Information Technologies and Educational Services (CITES)
> > > University of Illinois at Urbana-Champaign (UIUC)
> > > mepstein@uiuc.edu
> > >
> > >
> > > --
> > > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
> Milt Epstein
> Research Programmer
> Systems and Technology Services (STS)
> Campus Information Technologies and Educational Services (CITES)
> University of Illinois at Urbana-Champaign (UIUC)
> mepstein@uiuc.edu
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Apache Tomcat integration-please help
Posted by Milt Epstein <me...@uiuc.edu>.
On Thu, 18 Jul 2002 developer@wexwarez.com wrote:
> UNfortunately I have tried that at it did not help. Anymore
> suggestions would be wonderful, cause I am stumped. Maybe does it
> have something to do with my apache install?
Well, that *was* a problem, but maybe it wasn't the only one. Try
commenting out those lines, and see what effect that has. Are those
the last lines in your conf file? Maybe you've got a different
problem somewhere else in your conf file, and it's just reporting it
there because it's the last line. The error message (are you still
getting the same one?) indicates it's something related to virtual
hosts, so that would be a place to focus. Of course, then you're
talking about an apache problem, not a tomcat problem.
> On Thu, 18 Jul 2002, Milt Epstein wrote:
>
> > On Thu, 18 Jul 2002 developer@wexwarez.com wrote:
> >
> > > I am having a problem getting apache tomcat running using mod_webapp.so
> > > I am using:
> > > linux redhat 7.3
> > > jdk1.4
> > > apache 1.3.26
> > > tomcat 4.0.4
> > > I got apache 1.3.26 compiled and installed with enable-module=so option it
> > > starts and stops fine
> > > I got tomcat 4.0.4, installed it and it starts and stops fine, the
> > > examples work etc etc
> > > I got jakarta-tomcat-connectors using CVS, and followed the instructions
> > > to compile mod_webapp.so. It compiled and I placed it in
> > > $APACHE_HOME/libexec/
> > > I added the following lines to httpd.conf:
> > > LoadModule webapp_module libexec/mod_webapp.so
> > > AddModule mod_webapp.c
> > > WebAppConnection warpConnection warp localhost:8080
> > > WebAppDeploy examples conn /examples
> > >
> > > I started tomcat no problem. When I start apache i get:
> > > yntax error on line 984 of /usr/local/apache/conf/httpd.conf:
> > > Invalid virtual host name
> > > /usr/local/apache/bin/apachectl start: httpd could not be started
> > > line 984 refers to this line:
> > > WebAppDeploy examples conn /examples
> > >
> > > I am stumped some help please?
> >
> > This is my understanding of WebAppConnection and WebAppDeploy
> > (corrections welcome :-):
> >
> > The second argument to the WebAppDeploy directive (here conn) must be
> > a defined connection per a WebAppConnection directive (the first
> > argument of WebAppConnection specifies the connection). That is,
> >
> > WebAppConnection connection protocol host:port
> >
> > defines a connection -- named connection, using protocol (warp is the
> > only possibility currently, I believe), available at host:port -- and
> >
> > WebAppDeploy context connection url-prefix
> >
> > indicates that URLs that begin with url-prefix belong to context and
> > should be passed to connection.
> >
> > Anyway, although you should understand at least the basics of the
> > above, the gist of it is you should change "conn" to "warpConnection".
> >
> > Milt Epstein
> > Research Programmer
> > Systems and Technology Services (STS)
> > Campus Information Technologies and Educational Services (CITES)
> > University of Illinois at Urbana-Champaign (UIUC)
> > mepstein@uiuc.edu
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Milt Epstein
Research Programmer
Systems and Technology Services (STS)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Apache Tomcat integration-please help
Posted by de...@wexwarez.com.
UNfortunately I have tried that at it did not help. Anymore suggestions
would be wonderful, cause I am stumped. Maybe does it have something to
do with my apache install?
thanks
ryan
On Thu, 18 Jul 2002, Milt Epstein wrote:
> On Thu, 18 Jul 2002 developer@wexwarez.com wrote:
>
> > I am having a problem getting apache tomcat running using mod_webapp.so
> > I am using:
> > linux redhat 7.3
> > jdk1.4
> > apache 1.3.26
> > tomcat 4.0.4
> > I got apache 1.3.26 compiled and installed with enable-module=so option it
> > starts and stops fine
> > I got tomcat 4.0.4, installed it and it starts and stops fine, the
> > examples work etc etc
> > I got jakarta-tomcat-connectors using CVS, and followed the instructions
> > to compile mod_webapp.so. It compiled and I placed it in
> > $APACHE_HOME/libexec/
> > I added the following lines to httpd.conf:
> > LoadModule webapp_module libexec/mod_webapp.so
> > AddModule mod_webapp.c
> > WebAppConnection warpConnection warp localhost:8080
> > WebAppDeploy examples conn /examples
> >
> > I started tomcat no problem. When I start apache i get:
> > yntax error on line 984 of /usr/local/apache/conf/httpd.conf:
> > Invalid virtual host name
> > /usr/local/apache/bin/apachectl start: httpd could not be started
> > line 984 refers to this line:
> > WebAppDeploy examples conn /examples
> >
> > I am stumped some help please?
>
> This is my understanding of WebAppConnection and WebAppDeploy
> (corrections welcome :-):
>
> The second argument to the WebAppDeploy directive (here conn) must be
> a defined connection per a WebAppConnection directive (the first
> argument of WebAppConnection specifies the connection). That is,
>
> WebAppConnection connection protocol host:port
>
> defines a connection -- named connection, using protocol (warp is the
> only possibility currently, I believe), available at host:port -- and
>
> WebAppDeploy context connection url-prefix
>
> indicates that URLs that begin with url-prefix belong to context and
> should be passed to connection.
>
> Anyway, although you should understand at least the basics of the
> above, the gist of it is you should change "conn" to "warpConnection".
>
> Milt Epstein
> Research Programmer
> Systems and Technology Services (STS)
> Campus Information Technologies and Educational Services (CITES)
> University of Illinois at Urbana-Champaign (UIUC)
> mepstein@uiuc.edu
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Apache Tomcat integration-please help
Posted by Milt Epstein <me...@uiuc.edu>.
On Thu, 18 Jul 2002 developer@wexwarez.com wrote:
> I am having a problem getting apache tomcat running using mod_webapp.so
> I am using:
> linux redhat 7.3
> jdk1.4
> apache 1.3.26
> tomcat 4.0.4
> I got apache 1.3.26 compiled and installed with enable-module=so option it
> starts and stops fine
> I got tomcat 4.0.4, installed it and it starts and stops fine, the
> examples work etc etc
> I got jakarta-tomcat-connectors using CVS, and followed the instructions
> to compile mod_webapp.so. It compiled and I placed it in
> $APACHE_HOME/libexec/
> I added the following lines to httpd.conf:
> LoadModule webapp_module libexec/mod_webapp.so
> AddModule mod_webapp.c
> WebAppConnection warpConnection warp localhost:8080
> WebAppDeploy examples conn /examples
>
> I started tomcat no problem. When I start apache i get:
> yntax error on line 984 of /usr/local/apache/conf/httpd.conf:
> Invalid virtual host name
> /usr/local/apache/bin/apachectl start: httpd could not be started
> line 984 refers to this line:
> WebAppDeploy examples conn /examples
>
> I am stumped some help please?
This is my understanding of WebAppConnection and WebAppDeploy
(corrections welcome :-):
The second argument to the WebAppDeploy directive (here conn) must be
a defined connection per a WebAppConnection directive (the first
argument of WebAppConnection specifies the connection). That is,
WebAppConnection connection protocol host:port
defines a connection -- named connection, using protocol (warp is the
only possibility currently, I believe), available at host:port -- and
WebAppDeploy context connection url-prefix
indicates that URLs that begin with url-prefix belong to context and
should be passed to connection.
Anyway, although you should understand at least the basics of the
above, the gist of it is you should change "conn" to "warpConnection".
Milt Epstein
Research Programmer
Systems and Technology Services (STS)
Campus Information Technologies and Educational Services (CITES)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Apache Tomcat integration-please help
Posted by de...@wexwarez.com.
I am having a problem getting apache tomcat running using mod_webapp.so
I am using:
linux redhat 7.3
jdk1.4
apache 1.3.26
tomcat 4.0.4
I got apache 1.3.26 compiled and installed with enable-module=so option it
starts and stops fine
I got tomcat 4.0.4, installed it and it starts and stops fine, the
examples work etc etc
I got jakarta-tomcat-connectors using CVS, and followed the instructions
to compile mod_webapp.so. It compiled and I placed it in
$APACHE_HOME/libexec/
I added the following lines to httpd.conf:
LoadModule webapp_module libexec/mod_webapp.so
AddModule mod_webapp.c
WebAppConnection warpConnection warp localhost:8080
WebAppDeploy examples conn /examples
I started tomcat no problem. When I start apache i get:
yntax error on line 984 of /usr/local/apache/conf/httpd.conf:
Invalid virtual host name
/usr/local/apache/bin/apachectl start: httpd could not be started
line 984 refers to this line:
WebAppDeploy examples conn /examples
I am stumped some help please?
thanks,
ryan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>