Question
Confused about jrun-web.xml
G'day there
I'm hoping someone can clarify the *actual* purpose of the
[cf]/WEB-INF/jrun-web.xml file, and how CF uses it.
My understanding of it was that it was the JRun-internal-webserver's
equivalent of Apache's httpd.conf, or IIS's... err... whereever IIS stores
its config. Basically a web server configuration file. So if one wasn't
actually USING the JRun webserver for a given web site, then that file is
just ignored.
However that understanding is incorrect, it seems.
I have this sort of set-up on my dev machine's file system:
C:\webroots
\webapp1root
\lib
\subapp
\myCfc.cfc
\webapp2root
\lib
\subapp
\myCfc.cfc
And my IIS default website (I'm just running XP Pro, so only one website @
a time) is set up to have either webapp1root or webapp2root as its webroot,
depending on which I am working on, at a given moment in time. And the
website also has a virtual directory to "subapp", called... "subapp".
Currently I'm working on webapp1, so was bemused that when I did this:
createObject("component", "subapp.myCfc")
I was getting an instance of C:\webroots\webapp2root\lib\subapp\myCfc.cfc
created, instead of the webapp1 version.
I spent rather too long ballocksing around checking virtual directories, CF
mappings and all that sort of palarver, only to eventualy find that I had a
residual mapping in my jrun-web.xml file pointing to webapp2root's subapp
directory.
Once I removed that: all good.
Now to me, jrun-web.xml should be completely irrelevant to that mix, as I'm
not using the JRun web server.
So obviously it's NOT just a web server config file. WTF *is* it?
I have read various docs on the Adobe website, but they all seem to be
written for an audience who would already know what the author is on about
(hence making the doc a bit of a waste of time, in my view), and it's all
completely impenetrable for me, as I'm just a CF developer and haven't got
a clue about the inner workings of JRun (and, to be frank: I'd like to keep
it that way if poss... JRun knowledge is not exactly a marketable skill
;-).
What am I missing here?
--
Adam
I'm hoping someone can clarify the *actual* purpose of the
[cf]/WEB-INF/jrun-web.xml file, and how CF uses it.
My understanding of it was that it was the JRun-internal-webserver's
equivalent of Apache's httpd.conf, or IIS's... err... whereever IIS stores
its config. Basically a web server configuration file. So if one wasn't
actually USING the JRun webserver for a given web site, then that file is
just ignored.
However that understanding is incorrect, it seems.
I have this sort of set-up on my dev machine's file system:
C:\webroots
\webapp1root
\lib
\subapp
\myCfc.cfc
\webapp2root
\lib
\subapp
\myCfc.cfc
And my IIS default website (I'm just running XP Pro, so only one website @
a time) is set up to have either webapp1root or webapp2root as its webroot,
depending on which I am working on, at a given moment in time. And the
website also has a virtual directory to "subapp", called... "subapp".
Currently I'm working on webapp1, so was bemused that when I did this:
createObject("component", "subapp.myCfc")
I was getting an instance of C:\webroots\webapp2root\lib\subapp\myCfc.cfc
created, instead of the webapp1 version.
I spent rather too long ballocksing around checking virtual directories, CF
mappings and all that sort of palarver, only to eventualy find that I had a
residual mapping in my jrun-web.xml file pointing to webapp2root's subapp
directory.
Once I removed that: all good.
Now to me, jrun-web.xml should be completely irrelevant to that mix, as I'm
not using the JRun web server.
So obviously it's NOT just a web server config file. WTF *is* it?
I have read various docs on the Adobe website, but they all seem to be
written for an audience who would already know what the author is on about
(hence making the doc a bit of a waste of time, in my view), and it's all
completely impenetrable for me, as I'm just a CF developer and haven't got
a clue about the inner workings of JRun (and, to be frank: I'd like to keep
it that way if poss... JRun knowledge is not exactly a marketable skill
;-).
What am I missing here?
--
Adam