Ben, >>what made you choose Tomcat and why you wanted to integrate it with IIS. I'd >>also like to know why, specifically, you are so against using .NET.
I was wondering how could .NET compare with Tomcat. Is .NET a J2EE app server? Well I don't think so, .NET is completely different from Tomcat. And you know how the java and J2EE works. You can compare Tomcat with other J2EE app server or ONE and so on. There is no way you can tie J2EE with .NET. If that is the case .NET is not even worth to consider. If my platform is JAVA then I would be going towards Tomcat or anyother J2EE servers. Regards, Kannan -----Original Message----- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: Monday, November 24, 2003 3:20 PM To: Tomcat Users List Subject: [OT] Why did you choose Tomcat? (FKA: Re: IIS is not supported in Tomcat 4.1.29.) Roeland, Just out of curiosity, why did you choose Tomcat, or any OSS app, over .NET (and no, this isn't an attempt to start another thread about J2EE vs .NET)? You've stated that: 1.) That you are deploying on WinXXX and, more specifically, IIS. 2.) That you are specifically prohibited from hacking the source code. (IMHO: that's where the "WTFs" belong) 3.) Although you didn't didn't say so specifically, it's plain to see that you are looking for an app server that can be quickly set up and run with a minimum amount of effort (reading) on your part. The reason that I say this is that you didn't know what a "context" is. I have a half a dozen Servlet/JSP books on my desk and they all explain what a Servlet Context is in the first chapter. You also mentioned JNI which is not a Tomcat or Servlet feature but a component of the core JAVA language. It's not possible that you spent any time learning about JSP/Servlets or Tomcat before jumping in and trying to integrate the app server with IIS. It sounds like you're a perfect candidate for a pre-packaged, commercial platform, like .NET, which allows you to purchase support. There are also plenty of commercial J2EE app servers out there, with a wide range of price and support options. Either way, you will get a specific list of what platforms and products are supported and you can rightly EXPECT to get explicit, step by step instructions for installation and integration. One of the biggest difference between Open Source Software (OSS) and commercial software is the release cycle. A common motto in OSS is "Release Early and Release Often". Compare the number of releases that Tomcat has had with any commercial app server. It's dizzying. There are many advantages to this. Bugs and security issues get fixed and integrated much faster, useless features get phased out much more quickly, and OSS projects like Tomcat are usually ahead of commercial products when it comes to features. How many other java app servers support the Servlet 2.4 and JSP 2.0 specs? All this, however, comes at a cost. In the commercial world, software product releases are often held back until the documentation is "complete". In any OSS project it is generally expected that the documentation will lag behind the core functionality. Most people who get involved with OSS expect to have to roll up their sleeves and learn about the product (at least a little) in order to start using it. Often the best documentation isn't written by the developers, it's written by people like yourself, who've gone through an installation, got stuck, got help, and then decided to give back to the community by writing a HOWTO that explains the procedure from an end user's perspective. In other words, with commercial software, you pay for support. With OSS you earn it. Nobody on this list is being paid to answer your questions. The people who do either do so because, they believe in the product and they want to see it used, or because in doing so, they learn more about the product. Some of the questions posted today have been answered by committers (developers who have taken part in building Tomcat). Try getting help from one of the developers of IIS. Is it reasonable to expect senior developers to take time to answer basic questions such as "What is JNI?" or "What is a context?"? By asking such questions, you have, in effect, said "I'm not interested in doing the work needed to understand this technology. I want to jump into the advanced topics and I expect someone else to write documentation that takes me by the hand and walks me through everything, step by step without any expectation that I have the prerequisite knowledge to be doing so in the first place AND.. if it doesn't do so, it's a 'pile of manure'". What's amazing is that, in your case, this approach worked very well. You insulted the product, the documentation, and all the people who have spent their own time and energy participating in this list enough that someone who's very knowledgeable got defensive enough to want to prove you wrong and and not only pointed you to the documentation but answered a lot of questions directly. I wouldn't count on getting continued support that way. If you missed it, there was a link to this essay on the page with the links to this list. http://www.catb.org/~esr/faqs/smart-questions.html I would suggest that you read it, read up on both JSP/Servlet technology, and read up on OSS in general and seriously consider whether you want to use an OSS product or whether you would be better off paying for a commercial solution. If you choose to go with Tomcat, welcome aboard. I think you'll find it to be a great app server at a great price. Either way, I would really like to know what made you choose Tomcat and why you wanted to integrate it with IIS. I'd also like to know why, specifically, you are so against using .NET. -Ben On Monday 24 November 2003 11:51 am, Christopher Schultz wrote: > 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. > > <!-- A "Connector" represents an endpoint by which requests are > received > and responses are returned. Each Connector passes requests on > to the > associated "Container" (normally an Engine) for processing. > > By default, a non-SSL HTTP/1.1 Connector is established on > port 8080. > You can also enable an SSL HTTP/1.1 Connector on port 8443 by > following the instructions below and uncommenting the second > Connector > entry. SSL support requires the following steps (see the SSL > Config > HOWTO in the Tomcat 4.0 documentation bundle for more detailed > instructions): > * Download and install JSSE 1.0.2 or later, and put the JAR files > into "$JAVA_HOME/jre/lib/ext". > * Execute: > %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA > (Windows) > $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA > (Unix) > with a password value of "changeit" for both the certificate > and the keystore itself. > > By default, DNS lookups are enabled when a web application calls > request.getRemoteHost(). This can have an adverse impact on > performance, so you can disable it by setting the > "enableLookups" attribute to "false". When DNS lookups are > disabled, > request.getRemoteHost() will return the String version of the > IP address of the remote client. > --> > > > <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] -- Ben Souther --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
