I've encountered exactly the same problem in the past, and I know how to get
around it.
The problem is I forgot that the shtml mapping is in both local.properties
_and_ global.properties. Sorry.
If you coment out the line below in both files, restart JRun and Apache, you
shouldn't see JRun trying to handle shtml anymore, and Apache should work as
before with respect to shtml.
webapp.servlet-mapping.*.shtml={default}
If you have Apache and JRun configured this way and it still doesn't work
(and you are sure JRun and Apache have been restarted), then this is a bug
and we should fix it.
Scott S.
-----Original Message-----
From: Ben Groeneveld
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: 8/24/2001 1:16 PM
Subject: Re: JRun 3.1 connector disables SSI
Scott, the goal is to have apache work the way it used to before jrun
was connected. jrun interferes with the ssi handling as far as I can
tell. If I turn off jrun's .shtml handling then .shtml in the apache
server root still doesn't work unless I rm the mod_jrun.
I have found a workaround. Using the apache 'xbithack on' directive I
can cause std .html files to be parsed for ssi if their file mode is +x.
I also rename my files from .shtml to .html for this to work.
I don't have evidence of anyone else seeing this issue, but would like
to. it's easy to reproduce. The default redhat config for apache is to
recognize ssi. I'm running jrun 3.1 on redhat 6.2 with apache 1.3.14.
Thanks, BenG.
Scott Stirling wrote:
I don't understand. Do you want JRun to handle your SSI or do you want
Apache to? I thought you wanted Apache to, so I sent instructions for
disabling JRun's SSI support. JRun's SSI is weak, and only works with a
few
directives, so I would recommend disabling it, and let SSI fall through
to
Apache. You shouldn't have to rearrange the order of modules in Apache
to
achieve this -- just comment out the line below in JRun's
global.properties
and restart JRun and Apache.
Scott
-----Original Message-----
From: Ben Groeneveld
To: JRun-Talk
Sent: 8/24/01 12:07 AM
Subject: Re: JRun 3.1 connector disables SSI
Scott, thanks. I would like to have it on in my apache html tree. But
the mod_jrun seems to disable it. BenG.
Scott Stirling wrote:
A sure way to disable JRun's handling of SSI, assuming you are using
.shtml
as the file extension for these, is remove or comment out the line in
global.properties that makes JRun handle those files:
###################
## rules
###################
webapp.servlet-mapping./servlet=invoker
webapp.servlet-mapping.*.jrun=invoker
#webapp.servlet-mapping.*.shtml=ssifilter <-- comment this line out
webapp.servlet-mapping.*.jsp=jsp
webapp.servlet-mapping.*.thtml=template
Scott Stirling
-----Original Message-----
From: Ben Groeneveld
To: JRun-Talk
Sent: 8/23/01 8:16 PM
Subject: Re: JRun 3.1 connector disables SSI
Victory cry too soon!
Just when shtml is working the mod_jrun stops, if I get mod_jrun to run
by placing it before includes_module then shtml stops...
Any help appreciated. Thanks, BenG.
Ben Groeneveld wrote:
John, SSI becomes disabled for all files in the apache <Directory>'s.
By default JRun loads their module after all others when
auto-installed
by the JRun admin console. So this is interesting: I just tried
loading
the JRun module first. *This works*. I put it back at the end of the
httpd.conf and SSI stops working. Order matters. Thanks!!!!
As an aside, I would also like to be able to control access to the
paths
mapped by jrun using .htaccess or AuthUserFile, but it seems that they
get intercepted first by the mod_jrun. Do you know of a way around
this?
BenG.
Mullee John - ZGI wrote:
Subject: JRun 3.1 connector disables SSI
Hooking up my JRun 3.1 to Apache 1.3.14 on RedHat 6.2 disables
server
side includes (.shtml). It is easily reproducible. Has anyone else
seen this - is it a known problem with a workaround? Thanks, BenG.
Does it disable SSI for all files or only files which are also JSPs?
Or only for files under the directory below which paths are mapped to
mod_jrun ?
Have you tried putting mod_jrun after all other modules loaded in the
https.conf?
john
.
--
Ben Groeneveld
Information Concepts, Inc., 115 N.W. Oregon, Suite 30, Bend, OR 97701
Mailto:[EMAIL PROTECTED] <Mailto:[EMAIL PROTECTED]> ,
phone:541.388.3611, cell:208.520.6488
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
