possible Tomcat 3.1 issues

[Jason Hunter <jh...@acm.org>]

Here's a list of possible tomcat issues before 3.1.  One big issue, 
lots of little things to chat about.

Bug 188:  sendError() doesn't reset() the buffer as the specs say it
should.  See spec section 6.3.

Is there a reason we don't have a Server: header anymore?  Security
maybe?  Without the header Tomcat will never get any official market
share.  :-)

The <l:startEndpoint> logging is now going to tomcat.log while other
<l:*Context> logging is going to stdout.  Is this intentional?  Why the
split?

The logs aren't timestamped, even when written to files.  That makes
debugging quite a pain.

jasper.log *does* contain timestamps but within the <JASPER_LOG> tag
mixed with the log data, which is a ridiculous place to put it.  And 
why the JASPER_LOG name when elsewhere it's <l:camelCase>?

Basically, we have this weird XML output going all over the place
without any general consistency.  Last I recall, we were debating
whether to add it or not and we decided stdout should be human 
readable.  Now it's this odd XML showing up everywhere.  When did I 
miss my chance to -1 that?

-jh-

Re: possible Tomcat 3.1 issues

[Anil Vijendran <ak...@pipedream.org>]

Jason Hunter wrote:

> Anil Vijendran wrote:
>
> > I agree with you that logging output is generally haphazard and
> > should be made uniform. Why don't you file a bug report Jason?
>
> Because all I have now is a gripe, not a solution.  :-)  Do we have a
> jakarta.apache.org/gripes/ setup yet?

Generally people use http://jakarta.apache.org/bugs to sink in their gripes
:-)

> > The idea is that there should be a logger per significant
> > subsystem and
> > each subsystem can generate a message that can be XML wrapped OR can
> > inidicate to the logger that it will format its own messages and the
> > logger shouldn't wrap them in <XML>...</XML>.
>
> Right, I remember the idea flying by.  Then one day XML logging
> appeared.  Yes, it was a day a while back and I could have spoken then,
> but I'm kinda busy with other things right now -- you'll see *what* when
> I release -- hint, it's not a book.

P l e a s e... I can't stand the suspense ;-)

> > want to have all kinds of transformations declaratively specified that
> > postprocess these XML logs to all kinds of cool things -- for example
>
> We need to get a unified story together.  Did anyone have one?  I don't
> remember there being an official proposal that got 3 +1 votes for this.
> If someone did make the proposal, can they did it up or give some clue
> where we could dig it up?
>
> Assuming there isn't a unified story, we need to consider if we should
> have one before 3.1 release.

Well, the part of the unified story that is missing right now is a
tool/servlet that postprocesses these logs and generates HTML out of them
and this would be integrated with the admin tool. Nice idea, I thought.

I guess the people that had logging as their deliverable for beta didn't
have the time to do it :-)

For now, my suggestion would be to make all these logs consistent both in
nomenclature/appearance and where they go -- file or stdout. Much of this
is configurable though, BTW.

> > Now w.r.t your missing a chance to -1 things... you should either
> > follow cvs messages or build Tomcat more often, Jason :-)
>
> <friendly-spar>
> Oh, I follow and build.  Not all of us have Tomcat as our primary day
> job though.  :-)
> </friendly-spar>

Oh I understand :-). 'Tis perfectly okay to stand up and -1 things when you
notice them. It is better that way than never.

--
Peace, Anil +<:-)

Re: possible Tomcat 3.1 issues

[Jason Hunter <jh...@acm.org>]

Anil Vijendran wrote:

> I agree with you that logging output is generally haphazard and 
> should be made uniform. Why don't you file a bug report Jason?

Because all I have now is a gripe, not a solution.  :-)  Do we have a
jakarta.apache.org/gripes/ setup yet?

> The idea is that there should be a logger per significant 
> subsystem and
> each subsystem can generate a message that can be XML wrapped OR can
> inidicate to the logger that it will format its own messages and the
> logger shouldn't wrap them in <XML>...</XML>.

Right, I remember the idea flying by.  Then one day XML logging
appeared.  Yes, it was a day a while back and I could have spoken then,
but I'm kinda busy with other things right now -- you'll see *what* when
I release -- hint, it's not a book.

> want to have all kinds of transformations declaratively specified that
> postprocess these XML logs to all kinds of cool things -- for example 

We need to get a unified story together.  Did anyone have one?  I don't
remember there being an official proposal that got 3 +1 votes for this. 
If someone did make the proposal, can they did it up or give some clue
where we could dig it up?

Assuming there isn't a unified story, we need to consider if we should
have one before 3.1 release.

> Now w.r.t your missing a chance to -1 things... you should either
> follow cvs messages or build Tomcat more often, Jason :-)

<friendly-spar>
Oh, I follow and build.  Not all of us have Tomcat as our primary day
job though.  :-)
</friendly-spar>

-jh-

Re: possible Tomcat 3.1 issues

[Anil Vijendran <ak...@pipedream.org>]

Jason Hunter wrote:

> Basically, we have this weird XML output going all over the place
> without any general consistency.  Last I recall, we were debating
> whether to add it or not and we decided stdout should be human
> readable.  Now it's this odd XML showing up everywhere.  When did I
> miss my chance to -1 that?

I agree with you that logging output is generally haphazard and should be
made uniform. Why don't you file a bug report Jason?

The idea is that there should be a logger per significant subsystem and
each subsystem can generate a message that can be XML wrapped OR can
inidicate to the logger that it will format its own messages and the
logger shouldn't wrap them in <XML>...</XML>.



<tongue>
  <in>
    <cheek>

The reasoning behind XML-logs is that XML is cool :-) I believe
perl/sed/awk based log processing is more than enough but these days we
want to have all kinds of transformations declaratively specified that
postprocess these XML logs to all kinds of cool things -- for example an
MS Word document which will then be at its peak of human readability :-)

Now w.r.t your missing a chance to -1 things... you should either follow
cvs messages or build Tomcat more often, Jason :-)

    </cheek>
   </in>
</tongue>


--
Peace, Anil +<:-)