ATTN: TC users, reply requested

[Eric Strain <er...@hotmail.com>]

Hi All:
I've noticed a wide range of (Java and TC related ) topics being discussed 
on this mailing list. The people here are having problems rangeing from 
initial construction of tomcat upto and including problems connected with 
using the software on various OS and development platforms ( configuration 
problems, security issues, the list goes on... )

I've also noticed that some of the members of this list have successfully 
beaten some of the problems that other users cannot get past. I have an idea 
that can help turn TC from the barage of misdirection and unanswered 
questions into a standard of programming excellence and productivity for the 
TC community. My idea is this:

I can setup a website with fully executable downloadable versions of the 
Tomcat compiler for any number of the OS platforms (Win95 / 98, Win2k, 
Linux, Unix, NT4.0 etc...) where TC is used. The website would also include 
installation instructions for TC use on the various OS platforms and the 
donors contact information such as:
"This program was donated to this site by: user@E-mail.com"

EX: The user calls up my website and clicks the Linux link, they are taken 
to a site for TC use on Linux and would have a download link for a fully 
executable TC (on the Linux platform ) with configuration instructions 
etc... links to the TC mailing list etc... this example is portable to any 
of the other OS platforms where TC is used.

In order to create this project I need a few things from the users of this 
mailing list:

1) ideas, feedback, opinions (both positive and negative) from the users of 
this list about this idea

2) if the response is good and the idea is supported, I'll set up the web 
site and post its address to this list, I'll also     setup an off site 
E-mail address where the members with a working TC for various OS platforms 
can send attachments of their TC which will be available to the TC community 
for download from my / our web site.

I think this idea will prevent the members of this TC community from having 
to "reinvent the wheel" everytime they need TC functionality. I also think 
it will help TC evolve into a standard of execellence and productivity for 
the programming community on this list.  Ideas, opinioins, and feedback 
about this idea are requested. Also, if this idea is supported, I appeal to 
your sense of decency and request that "as a matter of programming 
courtesey", don't do anything to this website that you would not want 
someone to do to your site, EX: malicious code of any kind.

Thank you all, and I look forward to your response





_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>

Re: ATTN: TC users _&_ For Gods's Sake Do Something

[Richard Troy <rt...@ScienceTools.com>]

Hi All,

Regarding the suggestion that we gather together a bunch of ready-to-go
downloads, listee Felix <fe...@crucial-systems.com> correctly pointed out
that the existing software downloads aren't necessarily "ready to go,"
though I had a good initial experience with both Tc 3.2.3 and 4.0.1. The
real trouble for most of us seems to come after the initial setup when
we're trying to configure for something specific.


I would like to point out that virtually _every_ complaint or suggestion
for improvement that I've heard in this several-thread dialogue can be
completely resolved with better documentation. And I have an idea.


Instead of trying to gather together a plethora of "certified working"
downloads, I propose something we can begin implementing _right_now_ on a
resource we already have at our finger tips - The Forum: We can use it as
a place where we can all easily contribute to specific configuration  (or
other) problem resolution. The idea here is to gather together the
necessary solutions from those among us who have actually solved the
problems. To accomplish this, we create new anchor posts to which
SOLUTIONS _and_not_questions_ are attached. If a person has a problem and
can't find the appropriate topic entry, they create a new one. If a person
finds the topic category but does not find their problem solved under the
appropriate topic heading, when and if they ever solve it, they then go
back to the Forum and contribute their solution to that topic anchor.

This approach has a lot of advantages to what's happening - or not
happening - now. Hopefully these advantages are clear and I don't have to
enumerate them now. ...To illustrate the way, I've posted the first such
topic anchor, "How To Configure JDBC connectivity" - my personal topic of
the day. Perhaps a solution to this was posted yesterday but I haven't
gotten it to work yet. If I do, I'll be SURE to post what I learned under
that topic heading. Each of us has the power to do the same. This makes
each of us responsible for doing our part to contribute to this great
community, and easily empowers us to make a valuable contribution at the
moment we are ready. No muss, no fuss. Just contribute solutions where
people can find them - and they can find them a bit more easily than
digging through a mountain of emails for that needle. (Maybe we should
have these topic-anchors have "ANCHOR"  in the subjec so they're even
easier to find?)

Once again, forum URL: http://nagoya.apache.org:8080/jive/index.jsp

Before signing off, I had a few more thoughts to share regarding these
threads and in particular about Felix's comments. These thought constitute
the remainder of this post - most of which are off topic, and a bit
long...


> > Is exactly the same as the windows version, the vms version ,etc,etc... I
> > thought that was the purpose of java in the first place ;))
>
> business people are supposed to believe this.
> programmers are supposed to know that that is a limited claim at best.
> <snip>
> java is portable...until you get to the real issues like connecting to the
> rest of the machine.

Yes, this is plainly true. But what gets my goat isn't that, it's the
refusal to provide methods to do fundamental things in the name of
running everywhere, forcing each of us to implement our own solutions.
It's insulting. I have had to write C code to do the functions Java just
won't do and I'm quite embarassed to have to do so! ...Still, that said, I
really like Java...


> > If documentation doesn't seem to cover EVERYTHING
> > needed, then the documentation should be updated,
>
> actually i'm more concerned that so much of the documentation covers things
> that aren't needed, are temporary, or are depreciated.

Good point. We need some better "overview" documentation. ... Once I feel
I have a good overview, I'll be GLAD to write one!

> From: "Martin van den Bemt" <ma...@isallineed.org>
> Help and fixing issues are done at a very high speed rate on tomcat, I
> wouldn't bet my money on getting this with commercial companies!
> The beautiful way of open source is indeed, as said by Graham, if it
itches,
> scratch it (yourself..)


Neither open-source, nor proprietary solutions are a panacia. We
_need_both._ Those that do not realize this are causing us all grief - and
that includes people in _both_ camps, though you can throw a lot more
stones at Microsoft in particular on this point.


> but another failure of commercial software is that the biz people
> drive the development pace so that too many features get added at the
> cost of stability and purity of concept.


That's just plain wrong. It's all to easy to blame "biz people" whoever
they are. The truth is all the players share in whatever blame there is
for unsuccessful projects. From the technologists side, it's usually that
they either obfuscate their work (often intentionally), or they are
completely unable to communicate at a functional level with anyone who's
not in their peer group. Therefore, the "biz people" don't get the whole
picture and make errant decisions. This is quite typical.


As for purity of concept, lack of it is usually the result of committee
thinking. In a business project context, I'm a STRONG advocate that _one_
person needs to be in charge of and responsible for design. (Responsible
for means that if it doesn't work, they get removed - plain and simple.)
That person then uses a team or committee to figure out what the choices
are and get clued-in on topics that would otherwise blind-side them. It's
very rare for a team any bigger than two to architect a complex project
successfully.


In an open-source context, things work a little differently, but it's
still true that committee and group architecting is very risky. ...Take
for example, a subject near and dear to our hearts: Web-based
applications. Any good software architect could have told you right off
the bat that while HTML is great for static things, it's the COMPLETELY
WRONG MODEL for any kind of interactive application for the simple reason
that it completely lacked _any_ form of context. That's why cookies were
invented and why we now have sessions and so forth - all an attempt to
solve this fundamental problem that was architected wrong from the get-go.
Now we're band-aiding. ...The strongest argument for what happened is that
it jump-started the standards work that will eventually see us through to
a competent strategy with fairly universal interoperability. As it stands
right now, though, if you have a sophisticated application, there's a LOT
to be said for traditional client-server - sans "web". Use the web to get
the customer/user to down-load your app and then they can run it and
connect to your servers directly...


> this is very common in web-shops.  crap code because its all about
> what the manager sees coming out the other end.

Very often it's crap code because they're using a crappy architecture,
have no standards, don't do design-review, and so forth and has _nothing_
to do with the competency of the programmers, per se, and also nothing to
do with the line-manager. It's _usually_ either the architect's fault, or
the upper managers who don't set up their development strategies
competently (tools, code review processes, etc).


> tomcat's config problems have wasted thousands and thousands of
> development dollars/hours that could have been spent fixing the
> problem in the first place.

"Fixing the problem," in my eyes, is _all_ about good documentation.

Well, maybe that's enough stirring of the hornet's nest!

Cheers everybody. Have a good Saturday night - I'm going out dancing!

RT

--
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>

Re: ATTN: TC users, reply requested

[felix <fe...@crucial-systems.com>]

> From: "Martin van den Bemt" <ma...@isallineed.org>

>> I can setup a website with fully executable downloadable versions of the
>> Tomcat compiler for any number of the OS platforms (Win95 / 98, Win2k,
>> Linux, Unix, NT4.0 etc...) where TC is used. The website would
>> also include
>> installation instructions for TC use on the various OS platforms and the
>> donors contact information such as:
>> "This program was donated to this site by: user@E-mail.com"
> 
> I don't think the problem is there for getting a compiled release ;)) You
> can downlaod that already and is working perfectly if you read the
> installation document.

No it doesn't.  As i posted recently, the workers file for the linux binary
distribution is set up for NT
even without apache running, tomcat failed to start as a standalone.
i tried for a while, and then just got on with stage two, getting it to work
with apache. no point whatsoever in solving twice the problem.

> Is exactly the same as the windows version, the vms version ,etc,etc... I
> thought that was the purpose of java in the first place ;))

business people are supposed to believe this.
programmers are supposed to know that that is a limited claim at best.
perl and php are also completely portable...
so is squeak, many kinds of smalltalk.
so what does java defeat ?   different separaters : / \ ?

java is portable...until you get to the real issues like connecting to the
rest of the machine.
anyone who runs a mac knows java isn't portable at all.
anyone who has tried audio knows it isn't true.

it doesn't even run on more than one browser (applets).
it doesn't even run on that browser if you're not on m$

> The problem is in connecting tomcat to webservers..  And if you want
> binaries for ALL possible combinations, it's best to have a package which
> also includes the webserver (which for apache+tomcat is already there
> somewhere I believe).

no it isn't, and considering jserv is supposed to be depreciated, why does
every one of us have to jump through a badly documented conflicting hoop to
remove the damn thing, get mod_jk, compile that and then figure out how this
maze of configs is supposed to work so that we can remove it ?

why is tomcat-apache.conf auto generated ?
where does it say it is ?
what config are  we supposed to use ?
anybody that knows the answers to this has moved on to 4 which means that
the recommended stable version of tomcat has no support.

why did we have to waste this much time removing a 2 year old depreciated
connector ?

at least lets get a working apache-tomcat distribution for a couple of major
OS.





> If documentation doesn't seem to cover EVERYTHING
> needed, then the documentation should be updated,

actually i'm more concerned that so much of the documentation covers things
that aren't needed, are temporary, or are depreciated.
it makes it much longer, much harder to find what is correct, and much more
error prone (witness that the 3.2.3 documentation has been accidentally
overwritten with 3.3 docs so that there is no longer any info about auto
generated configs).

WHAT TOMCAT NEEDS IS LESS NOT MORE !! SERIOUSLY LESS!
too many configurations of configurations, too many possible ways to skin
too many cats.



> but that has to come from
> the people who are actually faced those problems, so it can be added in
> those documents (you cannot get any valuable input from me, if everything
> works fine...)

unfortunately what happens to most of us is that we eventually get it
working, and can barely figure out what we changed to get that.  or what the
original set up was.
every single step by step tutorial i went through failed to get me up and
running in the end.


> A big problem solver is actually that people read the documents supplied
> (something we don't like to do though, or at least most of the time we just
> skim through it briefly, in which case you miss some important notes).

> 
> So in short :
> Do what you think is necessary, but I tend to think this is only adding
> confusion instead of solving it..
> 
> Mvgr,
> Martin
> 
> 
> 
> --
> To unsubscribe:   <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
> 
> 
> 


--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>

RE: ATTN: TC users, reply requested

[Martin van den Bemt <ma...@isallineed.org>]

See below for comments..

Mvgr,
Martin

> -----Original Message-----
> From: Eric Strain [mailto:eric_strain@hotmail.com]
> Sent: Saturday, November 10, 2001 2:46 AM
> To: tomcat-user@jakarta.apache.org
> Subject: ATTN: TC users, reply requested
>
>
> Hi All:
> I've noticed a wide range of (Java and TC related ) topics being
> discussed
> on this mailing list. The people here are having problems rangeing from
> initial construction of tomcat upto and including problems connected with
> using the software on various OS and development platforms

> configuration
> problems, security issues, the list goes on... )

Don't forget webservers...

> I've also noticed that some of the members of this list have successfully
> beaten some of the problems that other users cannot get past. I
> have an idea
> that can help turn TC from the barage of misdirection and unanswered
> questions into a standard of programming excellence and
> productivity for the
> TC community. My idea is this:
>
> I can setup a website with fully executable downloadable versions of the
> Tomcat compiler for any number of the OS platforms (Win95 / 98, Win2k,
> Linux, Unix, NT4.0 etc...) where TC is used. The website would
> also include
> installation instructions for TC use on the various OS platforms and the
> donors contact information such as:
> "This program was donated to this site by: user@E-mail.com"

I don't think the problem is there for getting a compiled release ;)) You
can downlaod that already and is working perfectly if you read the
installation document.

> EX: The user calls up my website and clicks the Linux link, they
> are taken
> to a site for TC use on Linux and would have a download link for a fully
> executable TC (on the Linux platform ) with configuration instructions
> etc... links to the TC mailing list etc... this example is
> portable to any
> of the other OS platforms where TC is used.

Is exactly the same as the windows version, the vms version ,etc,etc... I
thought that was the purpose of java in the first place ;)) So what are you
trying to achieve here? If tomcat doesn't run standalone on a platform, it
is either a bug in tomcat or a bug in the jvm.

The problem is in connecting tomcat to webservers..  And if you want
binaries for ALL possible combinations, it's best to have a package which
also includes the webserver (which for apache+tomcat is already there
somewhere I believe). If documentation doesn't seem to cover EVERYTHING
needed, then the documentation should be updated, but that has to come from
the people who are actually faced those problems, so it can be added in
those documents (you cannot get any valuable input from me, if everything
works fine...)
A big problem solver is actually that people read the documents supplied
(something we don't like to do though, or at least most of the time we just
skim through it briefly, in which case you miss some important notes).

So in short :
Do what you think is necessary, but I tend to think this is only adding
confusion instead of solving it..

Mvgr,
Martin



--
To unsubscribe:   <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>