Re: IIS is not supported in Tomcat 4.1.29.

Christopher Schultz Mon, 24 Nov 2003 09:48:06 -0800

Roeland,

Before I sound too much like byting the hand that feeds, let me thank you
for the useful information that you have provided.

Fair enough. Although we must be in different time zones, 'cause I definately didn't write that at 4:26 AM :)

For one thing, whether you guys know it or not, Java is competing against MS
.NET. I surfaced specific issues that need to be covered. I have a case
where the requirements are Win2K and IIS. Neither Linux nor Apache are
viable options, although I've argued for, at least, Apache.

Okay, let's fix the docs for IIS. What have you found. I was objecting to the lack of useful information (other than to point out problems) in your post. Please post the *correct* information, and you're more likely to get the problem fixed.

We hear "your stuff sucks" a lot, and that doesn't exactly motivate anyone to make those people happy.

I'm doing good
to get Tomcat, okay? I don't want to do C# as that doesn't port more than 5
micro-inches from the MS platforms.

The mom project works pretty well. It even comes with a servlet-container-type thing.

Actually, I would gladly [submit patches, etc.]. I am considering compiling my notes 
for
subbmital after I get this stuff working.

Excellent! I look forward to reading the updated documents.

Do you mean this HOWTO:

http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/iishowto.html

Yep and these are the offending lines;

---
workers.properties - A file that describes the host(s) and port(s) used by
the workers (Tomcat processes). A sample workers.properties can be found
under the conf directory.
uriworkermap.properties - A file that maps URL-Path patterns to workers. A
sample uriworkermap.properties can be found under the conf directory as
well.

You are completely right. Those files do not exist in the distros. However, you are looking in the wrong distro. Unfortunately, the 'distro' that I would suggest is *NOT* the Tomcat distro. It's the tomcat-connectors distro. The source distro has the source of the isapi redirector. Unfortunately, this archive does not (as promised) contain example files. The pre-built isapi_redirector.dll file comes without an archive, and without those example files in the download directory :(

"
The ajp12  has been deprecated  with Tomcat 3.3.x and you should use
instead ajp13  which is the only ajp protocol known by Tomcat 4.0.x,
4.1.x and 5.

Of course Tomcat 3.2.x and 3.3.x also support ajp13 protocol.
"


If you'd truely read my email then you'd have noticed that I never mentioned
ajp13. I had already read and understood that part. The isue isn't
documented changes, the issues are changes that aren't documented. A slight
difference.

You said the documents hadn't been updated since Tomcat 3.3. That passage clearly indicates that they have been (since they mention both Tomcat 4.1, 4.2 and 5.x).

> [I can't figure out workers, and I find the workers HOWTO to be
> worthless. By the way, what is a worker?]

>

BTW, your quoted portion is not anything that I wrote. I just checked.

That's true: that's why it's in []s

It explains pretty much every line of the workers.properties file.

Yes, with incorrect data.

Really? You said you didn't understand worker types and properties. Every type is documented:

ajp12 - old skool not supported by 4.x and later
ajp13 - new skool, also supported by 3.3, so forget ajp12
jni - uses JNI to communicate directly with Tomcat
lb - load-balances across multiple Tomcat instances

Choose one: do you need load balancing? Do you want to use JNI (if you don't know what it is, then you don't want to use it)? If not, go with ajp13.

I think [the apparently crappy HOWTO is] a better guideline that the source code for 
the
connector,
don't you think?
Hacking the sources is something I am specifically prohibited from doing.

Is this your company policy? You're not allowed to find anything out except by reading documentation shipped with a package?

Also, with that error rate, it is better to not have it and admit that IIS
isn't supported, rather than embarras one's self by exhibiting such
problems. This is a quality issue at this point.

You're right, the IIS HOWTO isn't as step-by-step as it should be.

(Before I go on, I'll mention that there's a complete example
workers.prperties file included in the "Worker HOWTO".

No there isn't.

Yes, there is. Click on this link: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/jk/workershowto.html

Then, press the "end" button on your keyboard. Voile! A full example workers.properties file. You can even copy-and-paste it, then modify it.

I'll make a bet that you haven't even unpacked the Tomcat
4.1.29 binary distro for Win32, eh?

You're got me, there. I've only unpacked the 4.1.27 binary distro on win32.

Nowhere in there, does it exist.

Again, workers.properties doesn't belong to Tomcat -- it belongs to the connector project. They are separate. Tomcat also doesn't include the JNI headers required to compile C++ code wrapped by JNI. They come with the JDK. Tomcat is not required to contain everything you might ever possibly use with it. Many people use Tomcat without another web server. In that case, having workers.properties files all over the place would make things (even more?) confusing.

workers.properties can easily be generated using the example provided in the Workers HOWTO. uriworkermap.properties simply contains entries like this:

/context-name/*=worker_name

One per line, one for ech of your contexts. You can get more complicated, if you want, but that's the basics and will work.

As I
stated in the original email, the path values are wrong and files such as
tomcat.jar DO NOT EXIST. WTF do you think, that I don't know how to use
files search?

No, I just don't think you know which archive to look in.

I no longer quite trust a doc that has so many glaring errors.

Okay, then. Either figure it out, or hang yourself on .NET. Because you obviously didn't intent to get any valuable information out of this crowd by simply telling us that the documentation sucks.

Ask a question, get an answer. Bitch randomly and you rarely get a response.

You're kidding, right? You're trying to couple IIS to Tomcat and you
need a Context tutorial?


Actually, yes. Context of contexts, if you will. How does Tomcat view
contexts?

A context is a web application deployed into Tomcat. The 'context path' is the part of the URL that denotes which web application you're talking about. Let's say you have applications "entry" and "search" deployed onto the same Tomcat instance. You're likely to have URLs to them like:

http://host/entry/...
http://host/search/...

The /entry/ in the first URL and the /search/ in the second URL denote the context of the web application. That lets Tomcat know which web application should be used to service the request.

I figured that you had already deployed an application on Tomcat, and just wanted to get IIS working with it. That's what people usually do. You seem to want to get IIS coupled to Tomcat and then deploy an application. If this is your first experience with Tomcat, I'd recommend starting by deploying an application to Tomcat standalone first. Then, tackle the connection to a 3rd party web server.

I've been
finding a lot of misleading and incorrect information in the pile of manure
that Java calls operational documentation.

Are you talking about Java documentation or Tomcat documentation? I just want you to be precise.

Pointing me back to that same
pile of manure is less than helpful. Do you *really* know the answers or are
you a troll?

I really know the answers. I have given you some answers. The Tomcat documentation is actually pretty good. If you click on the "Tomcat 4.1" documentation link from the Tomcat hope hape, you get a nice screen full of information. Here's the link for you: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/index.html

Choose "introduction" from the "Getting Started" section. It states that a context is, in short, a web application.

In the IIS HOWTO, is has a section about "Adding additional Contexts" (the 'additional refers to having already gotton it to work with the 'examples' context that ships with Tomcat).

I'm looking for a process model here. I've found a lot of detail but, no
model. Like trying to derive an elephant by only seeing the trunk. I want to
see what the whole elephant looks like.

One of the problems here is that the connector is such a small thing. The connector documentation (including the IIS HOWTO -- it only covers the connector) doesn't include a Tomcat tutorial. However, Tomcat has a wealth of information about running web apps in it.

How does a worker relate to the calling program? What does the calling
program have to do and how does it know which worker it has? Look at it from
the outside. Why am I doing this?

I think you're looking for an overview like this:

"
How does it work ?

1. The IIS-Tomcat redirector is an IIS plugin (filter + extension), IIS load the redirector plugin and calls its filter function for each in-coming request. 2. The filter then tests the request URL against a list of URI-paths held inside uriworkermap.properties, If the current request matches one of the entries in the list of URI-paths, the filter transfer the request to the extension. 3. The extension collects the request parameters and forwards them to the appropriate worker using the defined protocol like ajp13 . 4. The extension collects the response from the worker and returns it to the browser. "

(This comes directly from the IIS HOWTO)

So, why do you have a uriworkermap.properties file? Because that's how the redirector figures out that it's supposed to handle the request. Why do you need a worker? Because workers actually connect to Tomcat. Why do you have to configure a worker? Because the worker needs to know where Tomcat lives (host, port, protocol, etc.).

What properties do you want to set to what values? Read the Workers
HOWTO to figure out what properties might be applicable.
As we already established, the Workers HOW-to is borked.

Do you know the questions, or are you just a troll?

What settings are confusing. I'd be glad to help.

The most important settings for the workers are as follows:

workers=worker1
ps=/
worker.worker1.type=ajp13
worker.worker1.host=localhost
worker.worker1.port=8080

I'll explain each of them:

"workers=worker1"

This line tells the IIS plugin what each of the worker names is. Without this line, the plugin would not be able to look for other configuration lines like "worker.[worker-name].name=value". If you have more than one worker, you can say "workers=worker1, worker2, worker3, etc.".

"ps=/"

This line tells all the workers what the local path separator is. On UNIX, this should be "/", for win32, it is "\".

"worker.worker1.type=ajp13"

This sets the "type" property for the worker called "worker1" to be "ajp13". As previously discussed, this is the protocol which the worker should speak. ajp13 is the most common protocol, and you should use it unless someone has told you that another one might be better.

"worker.worker1.host=localhost"

This sets the host for the worker to be "localhost". This assumes that you have Tomcat and the hosting IIS running on the same machine. If this is not the case, please substitute your hostname or IP address for "localhost:.

"worker.worker1.port=8080"

This sets the port number that the worker should use to communicate with Tomcat. That port should be configured in Tomcat's server.xml with a <Connector> wrapped around it. Since we're using the ajp13 protocol, you should have this in your server.xml:

Here's the documentation from the server.xml describing a connector. There's also a Connector-HOWTO on the Tomcat site. Look at the"Configuration reference", and choose "Jk" from the "Connectors" list.




    <Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
               port="8080" minProcessors="5" maxProcessors="75"
               enableLookups="true" redirectPort="8443"
               acceptCount="10" debug="99" connectionTimeout="0"
               useURIValidationHack="false"

protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/>

This sets up an ajp13 listener within Tomcat to respond to and handle requests that come from the workers running within the IIS plugin.

8) "Classpath" - There is no tomcat.jar file to be
found anywhere in the 4.1.29 directory tree.


That's correct. A legitimate complaint! Hey, someone change
that path in the HOWTO!


So, WTF does it change to? Did you really look and note that there are TWO paths
pointing to files of the same name but differrent sizes?

You need to provide the classpath based upon your configuration. The classpath needs to include everything you need to run Tomcat. The JNI connector, as the Workers HOWTO mentions, embeds Tomcat within the web server process. Pretty much nobody does this (which should be documented!), and so the docs are a little thin, here. Just don't use the JNI connector, and you don't have to worry about any of the settings described (quite clearly) under the "jni configuration" section.

Since you didn't grok the whole "type" thing on your first run through the documentation, I can see how this might have been very confusing. Each type has some configuration that the other types do not need. Since you don't need to use the JNI connector, you can ignore the JNI configuration.

> Do you really know or are you just here to be nasty to people?

I really know the answers. I just like being nasty to people, sometimes. Mostly the non-constructive ones. Note that I'm giving you a lot of help, here. Normally, this type of service costs a lot of money. Because I'm so pissed off at you for being a schwantz, I'm going to publicly embarras you by showing you where all the documentation is that you should have read. :)

9) All references to "*\jre\bin\classic" are
broken. Such a path does not exist in the tomcat
4.1.29 directory tree.
Right you are! That puppy comes with the JRE, not Tomcat.


Gee whiz, you get a brownie point. The point is that the Tomcat dox are not
correct. What's the proper value?

Depends on the JRE. Both IBM and Sun make JREs that most people use. There are other ones, too. You have to enter the path that's right for the JRE. Again, let's just forget the JNI configuration for now, 'cause you shouldn't use it.

Because I knew I was going to a get either a response like yours or dead
silence. I've already posted simple questions earlier this week. They were
summarily ignored.

Actually, I see responses to most of your questions. I even answered one of them. (It looks like my answer was wrong; there's no example workers.properties file in the jk connector distro -- that needs to be fixed. Someone even posted a followup with a link to an example).

So, I wrote up all the issues in one nice consistent
document. Normal escalation procedure, IMHO.

"Paths are all wrong" doesn't help. "Windows has spaces in path names" doesn't help. There are reasons that Tomcat shys away from spaces in filenames (and pathnames). That's because they are handled inconsistently in script files and sometimes Java. They are generally a pain in the arse. It's easier to say "don't use spaces" than to answer the same question about "why doesn't Tomcat work; I've installed it in 'C:\My Path Has Way\Too Many Spaces In It For Its Own\Good Ha Ha Ha\Tomcat'?".

Yes, I don't expect the dox to be perfect.
But, I do expect whatever dox
there are to be accurate. If they are inaccurate then they are better off
being removed completely and the Tomcat group admitting that such
configuration isn't supported yet. Otherwise the Tomcat project looses much
credibility with both technical and management staff. The key dox I need are
far from accurate, as I've proven. What are the correct answers and where
can they be found?

I think the problem is that the docs are asking you to make a few leaps that you aren't ready to make. I'm sure there are lots of people like you that get confused, but many just don't ask the questions. So, it never gets fixed. They go away mad and our product never gets any better.

So, thank you for providing this valuable service (I'm actually being serious) to us. Please help us make the IIS docs better. I realize that for a well-seasoned Java and/or UNIX type person, this stuff may be pretty easy. You just look at the docs to fill-in the details. But, starting from nothing, it's tough to grok the whole thing all at once. We need to work on that part of the documentation.

Since you are gathering all the answers, let us have your notes at the end.

Lesse, you hit me over the head with a mallet and *then* you want me to hire
you?

Yeah. You know that Kevin Mitnik does security consulting, now? Ain't that some shizit. :)

I figure that's worth about 8USD per hour and you have to pay your own
expenses for daily on-site visits.

Sorry, for short-term SAR-type-stuff, I charge 185USD per hour, and you pay the expenses.

It doesn't sound like you have much Win2K time anyway.

You're right: all my deployments have been on Solaris and Linux. However, I manage a groups of developers, most of which develop and test on win32 environments. I set up all of them myself -- none happen to use IIS, all Apache instead. We feel that IIS is too much of a security issue to run in production (even IF we ran win32 in production). Therefore, supporting it in development is not worth our time.

If this is a test of how I react to trolls, did I pass?

Nope. Your troll detector is a little off. I'm not one.

Ask away. I've got more answers. Remember, I generally earn my contacts. :)

-chris


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

Re: IIS is not supported in Tomcat 4.1.29.

Reply via email to