You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Peng Tuck Kwok <pe...@makmal.net> on 2002/12/10 02:02:55 UTC
Re: I don´t understand the objective of this open list !
The documentation sure does need some work in certain areas, but it is
hardly in the sad state that you claim it is in.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I don´t understand the objective of this open list !
Posted by Peng Tuck Kwok <pe...@makmal.net>.
Mike DiChiappari wrote:
>> The documentation sure does need some work in certain areas, but it is
>> hardly in the sad state that you claim it is in.
Ok so I manage to get you to describe some of the problems you are
having. I consider that an improvement from all the other mails I have
seen so far :)
>
>
> Okay, let me give a specific example. I will describe to you a likely
> standard configuration for a server that would be used in a typical
> commercial setting. Prove tomcat can handle this. Prove the
> documentation is available in normal English. I will also show you
> absolute geek-speak in the documentation.
>
> Typical Server Configuration: tomcat serving pages through apache on
> port 80 for multiple (virtual) web sites on one web server. How many
> out there have this? Yes, you can get tomcat up and running on port
> 8080 very quickly. How often do you commerical software developers type
> http://www.company.com:8080/foo.jsp when visiting commercial sites?
>
> Problems with the "documentation" (using the term liberally in this case):
>
> 1) First, no where on Jakarta's main site is it mentioned that some type
> of connector is needed to have tomcat serve page through Apache. I
> believe the connectors go by several names (mod_jk, mod_jk2, mod_webapp,
> and Catalina being some). None of these are mentioned or are listed
> (there are certainly no links).
I believe you are trying your best to look for information but you have
been looking in the wrong area. You said you were looking at the
Jakarta's main website. It's a repository for jakarta projects. mod_jk2
is under the tomcat project. You said there are absolutely no links yet
you list them below ? Huh ?
> Now I could go on and on. But what is the point. It is just more geek
> speak.
It is a fairly technical product and some patience is required but that
is true of most app servers in 'commercial' quality products. Take the
Sun One App server for instance. The amount of documentation for that is
mind boggling. I managed to get my app working on it but it was quite
difficult. I actually found the solution in one of the examples that
they gave but the volumnious documentation makes it difficult to find
what you want, although they have done their best to organize it.
>And I haven't even gotten to other situations: running multiple
> instance of tomcat, having tomcat run on a different server,
What's so difficult about that? To run mutliple instances just make sure
the ports are different.
> clustering,
> etc...
There's load balancing but to do that you need to use ..... mod_jk2.
There's no compulsion or requirement for you to use tomcat. I would on
ocassion use Sun One App server as it is actually quite good.
Oh yeah, if memory serves, John Turner has written a document about
getting Tomcat & apache to work together. If you'd look in the archive
you might find the link to his page or just ask him .
>
> Why waste my time. I'll vote with my feet and use something else.
>If developers aren't interested in making their software usable by writing
> clear documentation, I won't use it.
>
> Mike
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I don¥t understand the objective of this open list !
Posted by micael <ca...@harbornet.com>.
I think that you may find, from my experience, that you are going to have
to pay more than a "little" for "accountability" to get what you are asking
for here. What is your problem that is Tomcat's fault anyway?
At 09:43 PM 12/9/2002 -0500, you wrote:
>Mark,
>
>Thank you for your candid response. I believe I understand the point of
>Jakarta now.
>
>>We're happy not to have you use the software. If you
>>read the documentation for other application servers,
>>you'll quickly find that there is an equal amount of
>>'geek' speak.
>
>Since you say "we're" I assume you have had your hand in tomcat
>development. If this is so, then I believe it is true that in order to be
>able to successfully use tomcat, one must be involved in it. I am glad
>that is not true about other things in life. For example, I can drive a
>car, but can't (and have no desire to) build or fix one.
>
>>
>>Sad to say, but at some point you need to understand
>>the technology and know what you are doing in order to
>>accomplish a reasonably complex configuration.
>
>I understand J2EE methodology, design standards, how to design, build,
>develop and code in Java. I can figure out how to setup Weblogic,
>iPlanet, and JRun. I guess I still am not savy enough to use tomcat.
>
>>
>>Currently, I run Tomcat 4.12 and Apache 2.043 on a
>>Windows/2000 Pro development box with multiple virtual
>>hosts.
>
>That's one of you (and I'm assuming you're a developer of tomcat)./
>
>>
>>Complaining about what isn't is in general not in
>>anyone's best interest. Rather than complain, do. If
>>you don't wish to do, then don't complain.
>>
>>I understand it if your management has asked you to
>>perform some application build on Tomcat, and your
>>experience has only been with vendor hand-holding.
>>It's time to start learning the basics, and not
>>vendor-speak.
>>
>>This I think is the major cause of IT issues today.
>>People implement vendor solutions without
>>understanding the underlying technology used to meet
>>the business requirements. This leads to people being
>>familiar with vendor implementations, and not the
>>underlying standards.
>>
>>What happens when a vendor goes out of business? What
>>happens when the vendor decides not to support your
>>favorite feature? What happens when the vendor
>>decides not to implement your desired feature.
>>
>>Sure they may lose your business, but it's hardly the
>>only business that they have. However, what you've
>>lost is all the investment in vendor technology, since
>>you've not invested in the fundamentals underlying
>>that technology.
>>
>>In short, you either change your business practices to
>>suit the technology that past [bad] decisions have
>>constrained you to, or you throw away a lot of
>>investment.
>
>First of all, this thread was started by someone who could get no support
>and was complaining. I'll leave it up to you to go through the mail
>archive to find the original poster (how do you like being referred to the
>mail archives). At least with a vendor I have someone to yell at. And
>I've seen that technique work.
>
>Secondly, I am not so full of myself to take responsibility for an entire
>app server. Yes, it is worth it to pay a few bucks to a company - just
>for the accountability. When your medical software can not meet FDA
>guidelines or you get sued because of a bug in your app server - good
>luck. I feel like I can depend on my app server vendor more than whoever
>is Jakarta.
>
>Third, I'm not worried about my J2EE vendor going out of business. The
>entire point of J2EE is that it is a portable platform. I've already
>ported between real J2EE app servers with little trouble.
>
>Fourth, I've had success with much of the open source and Linux
>software. We run Redhat with sendmail, Apache with PHP (Horde and IMP),
>and have built solutions with Xerces/Xalan. My main complaint is with
>Jakarta/tomcat. It really is awful.
>
>Even though I disagree with you on just about every point, I am going to
>take your invitation. Bye bye tomcat.
>
>Mike
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
Micael
-------------------------------------------------------
This electronic mail transmission and any accompanying documents contain
information belonging to the sender which may be confidential and legally
privileged. This information is intended only for the use of the
individual or entity to whom this electronic mail transmission was sent as
indicated above. If you are not the intended recipient, any disclosure,
copying, distribution, or action taken in reliance on the contents of the
information contained in this transmission is strictly prohibited. If you
have received this transmission in error, please delete the message. Thank
you
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE:_I_donYt_understand_the_objective_of___this_open___list__!
Posted by Mark Eggers <it...@yahoo.com>.
Thank you Noel. I did use the "we" in terms of the
list. I apologize to the list, the Jakarta
development community (which does a great job), and
the Apache organization.
I'll happily use Tomcat since it works well for my
purposes.
Having written and suffered with tons of computer
documentation over the last 30 years, I find the
Tomcat documentation more "liveable" than most.
However, that's just my opinion.
/mde/
just my two cents . . . .
PS - Again, I apologize for the misunderstanding.
--- "Noel J. Bergman" <no...@devtech.com> wrote:
> Mike,
>
> As far as I know (and I just looked), Mark Eggers is
> not a representative of
> any Apache project. As with many happy members of a
> Community, he feels
> like a part of it and speaks with the pronoun "we".
>
> > Thank you for your candid response. I believe I
> understand the point
> > of Jakarta now.
>
> Jakarta is not tomcat. Tomcat is a project under
> the auspices of the
> Jakarta portion of the Apache Software Foundation.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: I donYt understand the objective of this open list !
Posted by "Noel J. Bergman" <no...@devtech.com>.
Mike,
As far as I know (and I just looked), Mark Eggers is not a representative of
any Apache project. As with many happy members of a Community, he feels
like a part of it and speaks with the pronoun "we".
> Thank you for your candid response. I believe I understand the point
> of Jakarta now.
Jakarta is not tomcat. Tomcat is a project under the auspices of the
Jakarta portion of the Apache Software Foundation.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I don¥t understand the objective of this open list !
Posted by Mike DiChiappari <md...@domanisoft.com>.
Mark,
Thank you for your candid response. I believe I understand the point
of Jakarta now.
>We're happy not to have you use the software. If you
>read the documentation for other application servers,
>you'll quickly find that there is an equal amount of
>'geek' speak.
Since you say "we're" I assume you have had your hand in tomcat
development. If this is so, then I believe it is true that in order
to be able to successfully use tomcat, one must be involved in it. I
am glad that is not true about other things in life. For example, I
can drive a car, but can't (and have no desire to) build or fix one.
>
>Sad to say, but at some point you need to understand
>the technology and know what you are doing in order to
>accomplish a reasonably complex configuration.
I understand J2EE methodology, design standards, how to design,
build, develop and code in Java. I can figure out how to setup
Weblogic, iPlanet, and JRun. I guess I still am not savy enough to
use tomcat.
>
>Currently, I run Tomcat 4.12 and Apache 2.043 on a
>Windows/2000 Pro development box with multiple virtual
>hosts.
That's one of you (and I'm assuming you're a developer of tomcat)./
>
>Complaining about what isn't is in general not in
>anyone's best interest. Rather than complain, do. If
>you don't wish to do, then don't complain.
>
>I understand it if your management has asked you to
>perform some application build on Tomcat, and your
>experience has only been with vendor hand-holding.
>It's time to start learning the basics, and not
>vendor-speak.
>
>This I think is the major cause of IT issues today.
>People implement vendor solutions without
>understanding the underlying technology used to meet
>the business requirements. This leads to people being
>familiar with vendor implementations, and not the
>underlying standards.
>
>What happens when a vendor goes out of business? What
>happens when the vendor decides not to support your
>favorite feature? What happens when the vendor
>decides not to implement your desired feature.
>
>Sure they may lose your business, but it's hardly the
>only business that they have. However, what you've
>lost is all the investment in vendor technology, since
>you've not invested in the fundamentals underlying
>that technology.
>
>In short, you either change your business practices to
>suit the technology that past [bad] decisions have
>constrained you to, or you throw away a lot of
>investment.
First of all, this thread was started by someone who could get no
support and was complaining. I'll leave it up to you to go through
the mail archive to find the original poster (how do you like being
referred to the mail archives). At least with a vendor I have
someone to yell at. And I've seen that technique work.
Secondly, I am not so full of myself to take responsibility for an
entire app server. Yes, it is worth it to pay a few bucks to a
company - just for the accountability. When your medical software
can not meet FDA guidelines or you get sued because of a bug in your
app server - good luck. I feel like I can depend on my app server
vendor more than whoever is Jakarta.
Third, I'm not worried about my J2EE vendor going out of business.
The entire point of J2EE is that it is a portable platform. I've
already ported between real J2EE app servers with little trouble.
Fourth, I've had success with much of the open source and Linux
software. We run Redhat with sendmail, Apache with PHP (Horde and
IMP), and have built solutions with Xerces/Xalan. My main complaint
is with Jakarta/tomcat. It really is awful.
Even though I disagree with you on just about every point, I am going
to take your invitation. Bye bye tomcat.
Mike
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I don�t understand the objective of this open list !
Posted by Mark Eggers <it...@yahoo.com>.
Mike,
We're happy not to have you use the software. If you
read the documentation for other application servers,
you'll quickly find that there is an equal amount of
'geek' speak.
Sad to say, but at some point you need to understand
the technology and know what you are doing in order to
accomplish a reasonably complex configuration.
Currently, I run Tomcat 4.12 and Apache 2.043 on a
Windows/2000 Pro development box with multiple virtual
hosts.
This poor beleagured box also supports mod_perl,
mod_php, cocoon (2.1 - reasonably late CVS release),
Xindice (1.1 - reasonably late CVS release), jetspeed
(reasonably late CVS release), postgresql, mysql, cvs
server, soon to have ColdFusion, and a partridge in a
pear tree (sorry - obligatory seasonal greating).
I also switch occaisionally to IIS 5.0 (mostly to
torture myself - but also to check interoperability).
I will run the same mixture on Solaris and Linux (sans
IIS 5.0) when the machines arrive.
We've covered the ground, have demonstrated where the
documentation is, have provided several commercial
books for the software, and pointers to resources
available on the Internet.
What there isn't for the Apache products is a company
to rant and rave at. In a way that's a good thing,
since it frees the developers to do what they do best
- develop leading edge software.
Us user types get the fruit of that development effort
at a cost - we have to learn about the technology. If
we find the technology particularly useful, then we
contribute back to the effort. Some of us write bug
fixes, others of us write documentation, and others of
us answer what we can on the mailing list.
Complaining about what isn't is in general not in
anyone's best interest. Rather than complain, do. If
you don't wish to do, then don't complain.
I understand it if your management has asked you to
perform some application build on Tomcat, and your
experience has only been with vendor hand-holding.
It's time to start learning the basics, and not
vendor-speak.
This I think is the major cause of IT issues today.
People implement vendor solutions without
understanding the underlying technology used to meet
the business requirements. This leads to people being
familiar with vendor implementations, and not the
underlying standards.
What happens when a vendor goes out of business? What
happens when the vendor decides not to support your
favorite feature? What happens when the vendor
decides not to implement your desired feature.
Sure they may lose your business, but it's hardly the
only business that they have. However, what you've
lost is all the investment in vendor technology, since
you've not invested in the fundamentals underlying
that technology.
In short, you either change your business practices to
suit the technology that past [bad] decisions have
constrained you to, or you throw away a lot of
investment.
Or, you take the third road, which is learn what
you're doing with the technology, how it works, and
why [the business reasons] you're doing it.
Short answer - grab the rope and pull, or go find
another effort.
/mde/
just my two cents . . . .
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: I don?t understand the objective of this open list !
Posted by Jim Urban <ju...@parkcitysolutions.com>.
> Why waste my time. I'll vote with my feet and use something else.
> If developers aren't interested in making their software usable by
> writing clear documentation, I won't use it.
Remember, you get what you pay for. You paid for nothing, you got nothing!
Don't go away mad, just go away (and stop bitching)!
Jim
-----Original Message-----
From: Mike DiChiappari [mailto:mdichiappari@domanisoft.com]
Sent: Monday, December 09, 2002 7:31 PM
To: Tomcat Users List
Subject: Re: I don?t understand the objective of this open list !
>The documentation sure does need some work in certain areas, but it
>is hardly in the sad state that you claim it is in.
Okay, let me give a specific example. I will describe to you a
likely standard configuration for a server that would be used in a
typical commercial setting. Prove tomcat can handle this. Prove the
documentation is available in normal English. I will also show you
absolute geek-speak in the documentation.
Typical Server Configuration: tomcat serving pages through apache on
port 80 for multiple (virtual) web sites on one web server. How many
out there have this? Yes, you can get tomcat up and running on port
8080 very quickly. How often do you commerical software developers
type http://www.company.com:8080/foo.jsp when visiting commercial
sites?
Problems with the "documentation" (using the term liberally in this case):
1) First, no where on Jakarta's main site is it mentioned that some
type of connector is needed to have tomcat serve page through Apache.
I believe the connectors go by several names (mod_jk, mod_jk2,
mod_webapp, and Catalina being some). None of these are mentioned or
are listed (there are certainly no links).
2) Lets say one wants to use a relatively new version of software -
say Apache 2.0 with mod_jk2. There is some nice background info on
mod_jk2 at:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/
Reading through that and links on that page is of little help.
However, there appear to be other useful links on that page.
Configuration info for mod_jk2 is at:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/configtce
x.html
This is in the second paragraph, "There is no need to use the jkjni
logic to use normal socket". Why would one care about "jkjni"? How
the hell is this even relevant to anything?
Now I could go on and on. But what is the point. It is just more
geek speak. And I haven't even gotten to other situations: running
multiple instance of tomcat, having tomcat run on a different server,
clustering, etc...
Why waste my time. I'll vote with my feet and use something else.
If developers aren't interested in making their software usable by
writing clear documentation, I won't use it.
Mike
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: I don´t understand the objective of this open list !
Posted by Mike DiChiappari <md...@domanisoft.com>.
>The documentation sure does need some work in certain areas, but it
>is hardly in the sad state that you claim it is in.
Okay, let me give a specific example. I will describe to you a
likely standard configuration for a server that would be used in a
typical commercial setting. Prove tomcat can handle this. Prove the
documentation is available in normal English. I will also show you
absolute geek-speak in the documentation.
Typical Server Configuration: tomcat serving pages through apache on
port 80 for multiple (virtual) web sites on one web server. How many
out there have this? Yes, you can get tomcat up and running on port
8080 very quickly. How often do you commerical software developers
type http://www.company.com:8080/foo.jsp when visiting commercial
sites?
Problems with the "documentation" (using the term liberally in this case):
1) First, no where on Jakarta's main site is it mentioned that some
type of connector is needed to have tomcat serve page through Apache.
I believe the connectors go by several names (mod_jk, mod_jk2,
mod_webapp, and Catalina being some). None of these are mentioned or
are listed (there are certainly no links).
2) Lets say one wants to use a relatively new version of software -
say Apache 2.0 with mod_jk2. There is some nice background info on
mod_jk2 at:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/
Reading through that and links on that page is of little help.
However, there appear to be other useful links on that page.
Configuration info for mod_jk2 is at:
http://jakarta.apache.org/builds/jakarta-tomcat-connectors/jk2/doc/configtcex.html
This is in the second paragraph, "There is no need to use the jkjni
logic to use normal socket". Why would one care about "jkjni"? How
the hell is this even relevant to anything?
Now I could go on and on. But what is the point. It is just more
geek speak. And I haven't even gotten to other situations: running
multiple instance of tomcat, having tomcat run on a different server,
clustering, etc...
Why waste my time. I'll vote with my feet and use something else.
If developers aren't interested in making their software usable by
writing clear documentation, I won't use it.
Mike
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>