Confused about jrun-web.xml

Report · Jul 06, 2007

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

Report · Jul 06, 2007

Sod it: that filesystem ock-up lost it's indent. Try this:

C:\webroots
----\webapp1root
--------\lib
------------\subapp
-----------------\myCfc.cfc
----\webapp2root
--------\lib
------------\subapp
-----------------\myCfc.cfc

--
Adam

Report · Jul 06, 2007

jrun-web.xml is the JRun-specific J2EE Web App Deployment Descriptor. The J2EE spec defines a standard deployment descriptor that all J2EE App Servers must use, called web.xml. If the app server wants to add anything additional above and beyond the spec, they must do so in separate files. In this instance, JRun named their file jrun-web.xml.

ColdFusion, installed Standalone or Multiserver, runs on JRun. All CF is now is a J2EE Web Application. When you are using IIS, you are using an ISAPI filter that connects to JRun, which itself deployed the ColdFusion Web App.

Therefore, even though you're not using the built-in web server, jrun-web.xml is very much involved. Without jrun-web.xml, the ColdFusion web app (which is actually JRun that you're trying to start up) wouldn't start.

Report · Jul 06, 2007

Sorry, I guess you got stuck on the first 14 words of my posting, missing
all the rest of it.

Maybe I worded it poorly.

Now. Why does CF pay any heed to web-server mappings from a config file
for a web server I'm not using. Irrespective of the requiredness and
complete scope and possible application of the various settings possible in
the jrun-web.xml file, *that part* of it is *specifically* dealing with the
JRun internal web server mappings. And I'm not using the JRun internal web
server. So why is CF even looking at them?

Or, more to the point, why is JRun even offering them up as a possibility
(which I guess is closer to the mark). Only the web-server part of JRun
should ever be considering those mappings, and given there's no traffic on
the port the JRun web server has been told to listen to... *WTF does it
think it's doing*?

If instead we're pretending these things are analoguous to CF mappings in
the JRun sphere of influence... again, why is CF paying any attention to
them? It's got its own mapping system. It makes no sense to kinda use its
own mappings, and kinda use JRun's too.

I fully understand why JRun might have this sort of facility, but not too
sure why CF is paying any attention to them.

Capisce?

--
Adam

Report · Jul 06, 2007

I didn't skip over that part, but I probably wasn't as clear as I needed to be. web.xml (and jrun-web.xml) are deployment descriptors for a J2EE web application. That actually has nothing to do with a "web server", it has to do with telling the application server (JRun, in this case), any information it needs to deploy the web application (ColdFusion, in this case). The jrun-web.xml file simply includes stuff that isn't apart of the J2EE spec but JRun developers thought it helpful to add in.

Again, _it has nothing to do with the "web server" as you see it_.

If you are using IIS as your frontend web server, you're still using JRun, the Application Server. In order for the JRun Application Server (_not_ the web server) to start, it looks at certain files to determine what web applications to deploy and how to deploy them. Those files are web.xml and jrun-web.xml, among others. The reason they're named "web.xml" and "jrun-web.xml" is because it's deploying a "J2EE Web Application". It has absolutely nothing to do with a web server (an application that listens on port 80 or 443 and responds to HTTP requests).

Let's see if I missed anything from your post:

quote:

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.

Nope. It's not a "web server configuration file". It's a web application deployment descriptor. Lots different. It all stems from the fact that ColdFusion is nothing more than a J2EE web application being deployed on JRun.

quote:

{snip}
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?

See my first post, and clarification at the top of this post

quote:

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?

I have no idea how that mapping got in there in the first place, but this is standard J2EE deployment descriptor stuff. Most other J2EE servers (BEA, Glassfish, JBoss, etc) all have a server-specific ___-web.xml deployment descriptor that goes along with each web app, telling the Application Server the information it needs to deploy the web app.

So, to sum up:
jrun-web.xml is not a web server configuration file.
jrun-web.xml is a JRun-specific J2EE Web Application deployment descriptor file.
J2EE Web Application deployment descriptor files have nothing to do with a web server (an application that responds to HTTP requests), though the web.xml and jrun-web.xml files do tell JRun how to interpret the requests passed to it via the IIS ISAPI filter.
I don't know how you got that mapping in there in the first place.

Report · Jul 07, 2007

You do understand that - along with everything else - JRun *does* ship with
its own web server, don't you? It doesn't seem like you do.

That's why one does not need IIS or Apache (etc) to serve up web pages on
CF, if one is just using the developer install (on port 8300, and such
like, depending on what the JRUN WEB SEVRER is configured to listen on).

So, yes, that file does extend the J2EE's "web application deployment
descriptor" for JRun. And *part of that extension*... is the configuration
of its internal web server.

I understand JRun is not a web server. You don't seem to understand that
it *includes* a web server.

Now *I thought* (lead on by various CF and JRun docs, and indeed the
comments in the file, not to mention the node name itself) that those
<virtual-mapping> nodes where *specifically* and *entirely* related to
JRun's internal web server. Obviously other things in that file are NOT
web-server specific, but that part seemed to be.

However it seems they are not. It seems it uses them as web server virtual
directories (one can browse to them, after all, if one sets the browseDirs
parameter in default-web.xml (groan)), but it also uses them as generic
"you can find application resources here" (in this case, CF being the
application). So CF pays them heed to them.

It would have been more sensible on the part of JRun to separate out its
deployment configuration from its web server configuration (and maybe have
all the web-server config in one file!), but they have not done that, and -
worse - the two seem intertwined.

This I understand now.

--
Adam

Report · Jul 09, 2007

> You do understand that - along with everything else - JRun *does* ship with its own web server, don't you? It doesn't seem like you do.

Yes, I understand that. It sounds like you now understand how jrun-web.xml is utilized.

web.xml (and jrun-web.xml) doesn't equal web server, that's all I was trying to get across.

What I was trying to get across was that just because the file is named *web.xml doesn't mean it's a web server configuration file, which was the conclusion you jumped to.

Report · Jul 09, 2007

Cheers to Kronin and Jochem for the responses. I might not like / approve
of / agree with what I've learned, but I've learned something. Which is a
good thing.

:-)

--
Adam

Report · Jul 07, 2007

Adam Cameron wrote:
>
> 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?

Where do you suppose the IIS connector gets its configuration
information? :)

Jochem

--
Jochem van Dieten
Adobe Community Expert for ColdFusion

Report · Jul 07, 2007

> Where do you suppose the IIS connector gets its configuration
> information? :)

Beyond "send all CFM requests to [this] port, and expect a response back at
some stage", I'm not sure what "configuration" it would need?

IIS maintains its own virtual directories, after all.

But, sure... if those mappings aren't *just* web server mappings, their
application mappings too: IIS would need to know about them. It's that
part that I didn't get (for the reasons stated in my previous post).

Cheers.

--
Adam

Report · Jul 07, 2007

> their
> application mappings too

THEY'RE application mappings too.

oops.

--
Adam

Report · Jul 07, 2007

Adam Cameron wrote:
>> Where do you suppose the IIS connector gets its configuration
>> information? :)
>
> Beyond "send all CFM requests to [this] port, and expect a response back at
> some stage", I'm not sure what "configuration" it would need?

The connector works in two ways, it sends certain extensions (configured
with -map on the wsconfig command) to JRun and it does pattern matching
in the wildcard connector. For the latter it needs to know what is
mapped to servlets and what is not, i.e. the information in web.xml.

Jochem

--
Jochem van Dieten
Adobe Community Expert for ColdFusion