RE: [VOTE] Committer Status for Marc Saegesser (was: Re: 3.x subm itters [was RE: [MY_OPINION] Tomcat 3.x])

[GOMEZ Henri]

+1

"Pour la plupart des hommes, se corriger consiste à changer de défauts."
-- Voltaire 

Re: Re: Question about CLIENT-CERT on web.xml file ?

[jerome . camilleri]

Yes I understand what you said about CLIENT-CERT and I add a new entry in my tomcat-usr.xml file :

  
  
  
  


Functions getSubjectDN().getName() return OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr value for the
first certificate chain, so I consider this value is the new user name.
I have yet auth-method into CLIENT-CERT value and when I try to connect on my tomcat serveur I have the same message :

"You are not authorized to view this page"

My local_host_access.log file give me this information :
camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:07:50 1000] "GET /examples/servlet/SnoopServlet HTTP/1.1" 200 4017
camilleri - OID.0.9.2342.19200300.100.1.1=mvittel, CN=michel vittel, O=frec.bull.fr [21/Dec/2000:11:08:32 1000] "GET /examples/servlet/SnoopServlet HTTP/1.1" 403 -

So I try to cut attribut password on tomcat-users file because when I use a certificate I don't understand what I would say... but 
with no success...

So thank you if you are a another good idea ?

Best Regards

Jérôme

Commiters WHO and WHERE

[GOMEZ Henri]

Hi to all commiters,

Many new commiters these days came with christmas.

After all the noise about TC 3.3, It could be nice to know where each 
commiter (oldies and newbies) plan to works :

There is still now, 3 projects (Sorry jon ;-) : 

TOMCAT 3.2:

TOMCAT 3.3:

TOMCAT 4.0:

Could each commiter add itself on projects he will contribute and indicate
on which parts :

In my case :

TOMCAT 3.2: RPM packaging, mod_jk, ajp12/ajp13, ssl stuff & doc, french
localization

TOMCAT 3.3: RPM packaging, mod_jk, ajp12/ajp13, ssl stuff & doc, french
localization

TOMCAT 4.0: RPM packaging, mod_webapp,  ssl stuff & doc, french
localization 


This will clarify certainly who do what.

May be we will discover there is sufficiant resource to keep support on 
3.2, 3.3 and 4.0.

I'll stats answers and give a daily report.

Re: [MY_OPINION] Tomcat 3.x

[Pier P. Fumagalli]

Sam Ruby <[EMAIL PROTECTED]> wrote:
> GOMEZ Henri wrote:
>> 
>> I remember the hard discution about spinaker on xerces
>> mailing-list and IBM became more open after Sun position.
>> But in the Tomcat case we have Sun on one side and
>> individuals on the others.
>> Not really the same condition. Hello Sam ?-)
> 
> Tomcat 3.0 was clearly a Sun project.  Most of the design discussions were
> held in conference rooms in Sun.  The release was made with virtually no
> prior discussion on the mailing list (remember sideswiped?).

And we, as the newly formed Apache Software Foundation, accepted that code
in donation as a point of start for the Jakarta Project. I was there, in
that meeting room, that day when we outlined how the process would have
evolved, with Jon, Stefano and Brian. And I was there, on stage at JavaONE,
when Patricia Sueltz announced the spinoff of the project againg with Jon,
Stefano and Brian. If that has been a wrong decision, we four are the people
to blame...

> Fairly or unfairly, a number of Sun people felt excluded from participating
> in Xerces.

That's a slightly different thing, but again is not Sun or IBM to blame, is
the people behind that thing (oh shit, I'm one of them! Again!)

> None of this is the case for any current release of Tomcat.  In particular,
> I personally do not feel like I am being denied an opportunity to
> contribute to Tomcat 3.2.2, 3.3, or 4.0.

And let's consider that Catalina is the good old Apache-JServ 2.0 who was
never released... I believe that for all of us who started this thing
Catalina is our little child. At that time none of us were paid to work on
Servlet Engines, what happened later has a very small relevance...

> Yes, many of the people working on Catalina are employed by Sun.  Arguably,
> in many cases (including Craig), they are employed by Sun because they work
> on Catalina, not the other way around.

Yes, I now work at Sun, and let me tell you guys, it's fucking fun. I'm not
working there because I like Sun, or I'm a Sun fanatic. Yes, I use Solaris,
but I'd rather work at Apple if it was for my preference. They were simply
the right kids with the right offer at the right time... Can you blame Sun
for that? I can't, they saved my butt as an Open Source developer, paying me
to work on what I wanted to (shit, why Apple is not interested in Tomcat?)

And let me tell you that hiring me and Craig was probably their worst
mistake, as we don't shut up and say "yes" to whatever our managers say.
Actually, it's all the way around, we make so much noise that Jim sometimes
hates us :) :) We're open source developers first...

Pier

-- 
Pier Fumagalli    

Re: [MY_OPINION] Tomcat 3.x

[Pier P. Fumagalli]

Jon Stevens <[EMAIL PROTECTED]> wrote:
> on 12/19/2000 10:48 AM, "Larry Isaacs" <[EMAIL PROTECTED]> wrote:
> 
>> If Tomcat 3.3 can prove it is as stable as Tomcat 3.2.x and is
>> more spec compliant than 3.2.x,
> 
> Why does it have to be called Tomcat 3.3?
> Why not Tomcat 3.2.x+1?

Because it's architecture is so much different from 3.2 :)

>> I think it would be a disservice to not release it as the final RI for
>> Servlet
>> 2.2/JSP 1.1.
> 
> I'm not suggesting that we not release it.

If the architecture doesn't change, neither do I :)

Pier

-- 
Pier Fumagalli    

Re: Fuck It.

[Pier P. Fumagalli]

Jon Stevens <[EMAIL PROTECTED]> wrote:

> To: Costin and the rest of you who commented.
> 
> You obviously know what is best and have shown me that I simply have my head
> up my ass and I'm just a complete jerk and I should stop now and just let
> you do whatever you want.
> 
> I give up. All of my previous -1 votes are now +1.
> 
> Have fun.

It's sad, my friend, to see you giving up like this. We've traveled a long
way together, from my very first steps in open-source land in January 1998,
to our marvelous meeting at the first ApacheCON in October 1998, the Jakarta
room meeting, all JavaONEs, and all we did together to bring this project
where it is right now.

It's sad, because you are the real light who guided my path from Italy to
here, from being a nobody to be somehow recognized by this community.

And it's even worse because you are FUCKING RIGHT! It makes me puke to read
comments like the one that James Cook sent "My personal impression of you is
in the toilet now", or Gomez Henri "IBM == xml.apache.org and SUN ==
jakarta.apache.org". Where were you KIDS when we were fighting the big
corporations to have them looking into open source, to contribute
significant parts of their technologies to the Foundation, where were you
while we were changing this world? You were home, and one day, you looked up
on your browser, saw a thing called Jakarta and started weening if things
weren't as nice as you wanted them.

Now, I believe that _I_ deserve some respect, and even if all your comments
were not directly targeted to me, they hurt as if they were. Jon, you might
be annoying and obnoxious at times, but those kids don't even care about
reading what you're writing...

What do I see? A fucking mess, and help me God, because now I'm not shutting
up until this whole shit is solved.

Let's start from the always recurring problem, Tomcat 3.3: I'm so glad to
hear that people like Paul Frieden (the only person that did put some salt
in what he said) are using Tomcat 3.2 in their products. That makes me feel
alive, that makes the work we made in the last three year worth something.

You're completely right Paul. I don't want you to loose one single cent of
your investment. Being a member of the ASF, you have my personal warranty
that it won't happen. I'm not asking to drop any kind of support from the
3.x tree, neither to close the bug-fixing process. But let's see what is
_exactly_ happening: from what I see in the commit messages, it seems to me
that even if on an evolutionary track, the container structure is completely
different between 3.2 and 3.3. The architecture is almost as different as
3.2 and 4.0. What does it mean? That if you, Paul, are going to pick up 3.3
as your next servlet engine, you will probably have to fight with more or
less the same quantity of issues you would have to deal with if you picked
up 4.0.

So, here we are: bugs... Let's see a little bit what's happening in the 3.x
tree. Who is actually FIXING the 3.2 bugs and trying to get a better
container on the old architecture? Not certainly Costin, Nacho or the
others, they are all so busy in rearchitecting the container, and
back-porting features from 4.0 that they don't have time to maintain the old
codebase. Kudos go to Craig, and his team (apart from me, since I'm working
on other sides of the code in 4.0) to find those bugs and fix them. And of
course he's doing that while he's trying to get 4.0 out of the door.

Sorry Costin, but I feel betrayed by you. Two weeks ago we had a pleasant
conversation in your office, and I was looking straight to your face when
you told me that 3.3 would have been a bug-fix and performance only update
of 3.2. This is not what's happening. You're not fixing them, you're
re-architecting a new container on the ashes of 3.2, but you are not doing
what you promised ME, you're not supporting your baby...

You're going against what we decided and agreed upon. You are loosing my
respect, my friend...

So, here I stand, my vote is a big -1 on a 3.3 as a newly architected
servlet container, +1 on fixing bugs on 3.2 (actually 3.2.1 since Craig
excellently pulled out all those security issues), +1 on improving
performances on 3.2.1 (and I don't care if it's going to be called 3.2.2,
3.3 or 3.9, fuck release numbers on 3.x) and a big +1 on Catalina as the
base servlet container for 4.0 no matter what this is our future, whether
you like it or not. All other containers, please wait for a 5.0.

And for once, so, my votes are in disagreement with you, Jon... :)

As one of the people behind the scenes since before each of you got here, I
believe my vote counts, and now, please prove me wrong.

Pier

-- 
Pier Fumagalli    

RE: [MY_OPINION] Tomcat 3.x

[GOMEZ Henri]

>And we, as the newly formed Apache Software Foundation, 
>accepted that code
>in donation as a point of start for the Jakarta Project. I was 
>there, in
>that meeting room, that day when we outlined how the process would have
>evolved, with Jon, Stefano and Brian. And I was there, on 
>stage at JavaONE,
>when Patricia Sueltz announced the spinoff of the project 
>againg with Jon,
>Stefano and Brian. If that has been a wrong decision, we four 
>are the people
>to blame...

Please, nobody is to blame. You and others have made Tomcat a credible
alternative to PRODUCTS like WebSphere or WebLogic. 
Sun give code to the Apache Foundation and whatever the original code
was (design, coding, ...) you have made it involving and it's certainly
better now that before.

>> None of this is the case for any current release of Tomcat.  
>In particular,
>> I personally do not feel like I am being denied an opportunity to
>> contribute to Tomcat 3.2.2, 3.3, or 4.0.
>
>And let's consider that Catalina is the good old Apache-JServ 
>2.0 who was
>never released... I believe that for all of us who started this thing
>Catalina is our little child. At that time none of us were 
>paid to work on
>Servlet Engines, what happened later has a very small relevance...

Nobody say that Cataline/JServ2 is a bad piece of software.
The original thread as derived since I and others 3.x commiters
just want to see Tomcat 3.3 code to be evolution of 3.2. 

I never say that TC 3.3 is better than TC 4.0/JServ 2.0, I just say
that TC 3.3 is much more easier to understand than 3.2 and since it
didn't require a JDK 1.2, it will be much more suited for low end 
configuration. Costin (certainly an old assembler hacker) have done
a great job in optimizing many area of the code. It will be a pitty
to see this works trashed.

>Yes, I now work at Sun, and let me tell you guys, it's fucking 
>fun. I'm not
>working there because I like Sun, or I'm a Sun fanatic. Yes, I 
>use Solaris,
>but I'd rather work at Apple if it was for my preference. They 
>were simply
>the right kids with the right offer at the right time... Can 
>you blame Sun
>for that? I can't, they saved my butt as an Open Source 
>developer, paying me
>to work on what I wanted to (shit, why Apple is not interested 
>in Tomcat?)

Sun has hired the right developpers for the right project. May be 
OpenSource will became also a good way for corporations to detect 
talentuous peoples. The question is not why didn't Apple contact you
but why didn't IBM or WebLogic didn't try to hire you ;-)))

>And let me tell you that hiring me and Craig was probably their worst
>mistake, as we don't shut up and say "yes" to whatever our 
>managers say.
>Actually, it's all the way around, we make so much noise that 
>Jim sometimes
>hates us :) :) We're open source developers first...

When you hire in a cooporation an OpenSource fellow, you hire 
more than one developper, you hire a community ;-)

At least IBM and Sun have understood that.

I hope that will be the end of this thread.
But as a side effect I notice that many people offers to help
on TC 3.2 or 3.3, and some goes commiters.

Long life to Apache Foundation.

Merry Christmas and an Happy New Year to all of you ;-)

Re: Fuck It.

[Mikael Helbo Kjær]

Nicely put

Re: Tomcat 3.3

[Andy]

Hello,

I've been reading both this and the dev list for about a month and
asking/answering the more well put user questions (meaning I don't do to well
on the ones that just say "Tomcat 3.x.x doesn't work on linux) and nothing
else).

I'd like to contribute to a tomcat, but since there are three of them I'm
not horribly sure where to start.  I know 4.0 is a rearchitecture and 3.2.x
is basically the old architecture, and that 3.3 is probably less supported
than 4.0 (in that sun will probably package 4.0 in the next major j2ee).
But, that being the case (and I know I'm touching on a sore spot) what will
be the lifespan of 3.3.  There've been a few messages on this subject but all
of them were a bit too hotheaded for me to gain the information I desired
from them.  I know this is somewhat of a partisan issue and the lines have
been drawn, but just delving in I'd guess 3.2.x would probably not be the
best place to start (even though I'm using it) as being unfamiliar with the
code and it being supposidly "the worst" code of the 3, I'd probably learn it
in time to see it go out of fashion (though I'm guessing, without a real idea
what the planned lifespan is).  I'm guessing 4.0 might be a bit hard to get
into as I picture the major decisions being made in a sun boardroom somewhere
in cupertino where i'd not have the time to make it to and probably wouldn't
be invited anyhow...  But is 3.3 going to have a long enough lifespan to make
it worth my while?  Is help needed there?  I probably prefer to start out
with bug fixes as its easier to get into "if you do this than this breaks".
So some direction (preferrably without the partisan slant) would be very
helpful.

Thanks,

Andy


__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

RE: Fuck It.

[GOMEZ Henri]

>And it's even worse because you are FUCKING RIGHT! It makes me 
>puke to read
>comments like the one that James Cook sent "My personal 
>impression of you is
>in the toilet now", or Gomez Henri "IBM == xml.apache.org and SUN ==
>jakarta.apache.org". Where were you KIDS when we were fighting the big
>corporations to have them looking into open source, to contribute
>significant parts of their technologies to the Foundation, 
>where were you
>while we were changing this world? You were home, and one day, 
>you looked up
>on your browser, saw a thing called Jakarta and started 
>weening if things
>weren't as nice as you wanted them.

I sent a couple of hours a mail about commenting TC3 and TC4/JServ2 and 
all the thanks for you to have provided such an alternative.

But the mail arrived just too late, and get back flame on us.

I couldn't speak for others but I'm just 35 years old and 
in OpenSource for at least 6 years. I started to help in both 
coding and lobbying for OpenSource use when a co-worker 
(died now) René Cougnenc (a friend of Remy Card ext2 creator) 
went at job to install on a Dell 486sx25, five disks with a 
pre 0.98 Linux system. 

The alpha networking code crashed our Sun's network and 
we have to take a look in source to locate the problem.

Since that time I promoted OpenSource products in all the companies I worked
for.
I've done that for Linux, GCC, PERL and Apache HTTP server.
Just to note that I'm not really a kid and that I've done my part of
job in pushing the OpenSource concept. 

Thanks to my actual employeer (SLIB), I could even spend time 
during my job to package some RPMs to help others users 
(everyone is not a developper) to install and discovers 
many OpenSourced products (from jakarta.apache.org, xml.apache.org or
others). 
Because I think that OpenSource will gain much more users 
with easy to use packaged solutions than with great design and coding. 
That's my VISION.

You could take a look at ftp://ftp.falsehope.com/home/gomez/ to 
see what I've done on packaging.

>Let's start from the always recurring problem, Tomcat 3.3: I'm 
>so glad to hear that people like Paul Frieden (the only person that did 
>put some salt in what he said) are using Tomcat 3.2 in their products. That

>makes me feel alive, that makes the work we made in the last three year 
>worth something.

I also use Tomcat 3.2 on production servers. I use it since the first M1. 
So when I'm worried about production, deployement, memory conso, I speak
d'experience.

>You're completely right Paul. I don't want you to loose one 
>single cent of your investment. Being a member of the ASF, you have my 
>personal warranty that it won't happen. I'm not asking to drop any kind of 
>support from the 3.x tree, neither to close the bug-fixing process. But
let's 
>see what is _exactly_ happening: from what I see in the commit messages, 
>it seems to me that even if on an evolutionary track, the container
structure 
>is completely different between 3.2 and 3.3. The architecture is almost as 
>different as 3.2 and 4.0. What does it mean? That if you, Paul, are going 
>to pick up 3.3 as your next servlet engine, you will probably have to fight

>with more or less the same quantity of issues you would have to deal with 
>if you picked up 4.0.

I hope to see 3.2 tree maintened for some times. It's the reason why I
switched
for ApacheJserv to 3.2M1 after a little step by the now dead Tomcat 3.1.
 
>So, here we are: bugs... Let's see a little bit what's 
>happening in the 3.x tree. Who is actually FIXING the 3.2 bugs and trying
to get a better
>container on the old architecture? Not certainly Costin, Nacho or the
>others, they are all so busy in rearchitecting the container, and
>back-porting features from 4.0 that they don't have time to 
>maintain the old codebase. 

Sorry but all my recent commits were for the 3.2 base. I even adapt some
patches 
from 3.3 source tree (ajp). I add french localized messages to 3.2 but 
still not to 3.3.

>Kudos go to Craig, and his team (apart from me, 
>since I'm working on other sides of the code in 4.0) 
>to find those bugs and fix them. And of
>course he's doing that while he's trying to get 4.0 out of the door.

You could note that I also package RPM for Tomcat 4.0 even if the 
build is told so complex. I spend time on that project too.

>Sorry Costin, but I feel betrayed by you. Two weeks ago we had 
>a pleasant conversation in your office, and I was looking straight to 
>your face when you told me that 3.3 would have been a bug-fix and
performance 
>only update of 3.2. This is not what's happening. You're not fixing them,
you're
>re-architecting a new container on the ashes of 3.2, but you 
>are not doing what you promised ME, you're not supporting your baby...
>You're going against what we decided and agreed upon. You are 
>loosing my respect, my friend...

I'm sorry to see two friends in such situation for a piece of code.
Catalina is your baby, TC 3.3 is Costin baby why couldn't

How to do my own JSP processing

[Christian Mallwitz]

Hi,

I want to write a servlet that reads JSP files from somewhere outside the
servlets web application context, compiles them to a location outside the
servlets web application (if necessary) and then invokes the compiled
servlet class.

I started looking at org.apache.jasper.servlet.JspServlet for a start but it
looks really messy. Besides the Jasper classes lack some documentation to
put it mildly ... :-)

What should I really look at and what things do I have to look out for?

The result should work similar to using request dispatchers include() but
with more control over it (especially response header generation, response
buffering, etc.) Tag lib stuff should work seemless in all the pages.

Thanks
Christian
-- 
Christian Mallwitz INTERSHOP Communications Germany
Senior Software Engineerphone: +49 3641 50 3453

Re: Fuck It.

[Sam Ruby]

Pier Fumagalli wrote:
>
> So, here I stand, my vote is a big -1 on a 3.3 as a newly
> architected servlet container

Pier, I beg of you to reconsider.

I was not present in the ApacheCon in 1998.  Nor was I in the room when the
Jakarta decision was made.  Nor was I on the state at JavaONE, when
Patricia Sueltz made the announced with you, Jon, Stefano, and Brian.

I can tell you that from my perspective, after all that transpired - and a
merge twelve months ago - Jakarta Tomcat was hardly an open source project.
It took a lot of hard work to make it open and viable.  And a lot more that
those four mentioned above were involved.

Pier, take a step back.  Look at where servlets were as a technology two
years ago.  One year ago.  Today.  Project where you think they will be one
year from now, two years from now.  Do you really believe that irreparable
harm is going to come from today's explorations and fleshing out possible
alternatives - particularly since this is all being done in the open and
under a license that would very much encourage code sharing and reuse?

I very much believe the contrary - that the only potential irreparable harm
that can come from this is the stifling of innovation.

Pier, Is now the right time, and is this the right way to fight this
particular battle?

I don't personally care whether any particular change made by any committer
is described as a bug fix, a feature enhancement, or an architectural
change - these descriptions, after all, are subjective.

My suggestion is that discussion returns to the technical merits of the
various approaches, and exploration of ways in which the various branches
can exploit and cannibalize the best ideas from each other.  Independent of
the labels currently associated with each proposal.

- Sam Ruby

RE: Fuck It.

[Sam Ruby]

Gomez Henri wrote:
>
> The future of Tomcat 3.3 seems to be outside Apache
> now. It's really sad.

As Pier recently said on another mailing list "You can't stop open source
developers...".

Is this really what everybody wants?  I'm sure it could be made to happen.
And quickly upgraded to the latest servletapi.  And gather a substantial
following.

Obviously a fork is a nightmare scenario.

It is an ironic twist.  One has to wonder if such a fork is inevitable.
Not for any technical reason.  But rather because those that worked so hard
to create the place where everyone was to come together have become
intolerant of exactly the spirit that makes open source successful.
Innovation.  Exploration.  Revolution.  And, yes, dead ends.

My recommendation: put your energies into the proposal that most gets your
juices flowing.  Keep the discussion to the technical merits.

> I propose to commiters to vote to drop my COMMITER STATUS.

Note to other PMC/ASF members - we should probably institute a mandatory 48
hour cooling off period before requests such as the one above are
considered.

- Sam Ruby

Decision Making

[Ted Husted]

Are there additional "protocol" documents for the humans besides

<
http://jakarta.apache.org/jyve-faq/Turbine/screen/DisplayQuestionAnswer/
action/SetAll/project_id/2/faq_id/12/topic_id/40/question_id/222 >

< http://jakarta.apache.org/site/decisions.html >

And the others linked under Guidelines on the Web site

Reading that document, I take it that "Lazy Consensus" means nobody is
actually counting until there is a < -1 > (or veto). 

Though, is there such a thing as a "non-lazy" consensus? 

I'm also confused by the term "Lazy Majority" (under Release Plan).

And, it is now true that in practice Tomcat and other Jakarta projects
now are being managed openly, and that critical decisions are not now
being made behind closed doors. (Excepting the ordinary private contact
that may occur between individuals before taking a public stance.)

Finally, is it true that the PMC is an advisory committee, and has no
special authority outside of their binding votes as committers. 


-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 425-0252; Fax 716 223-2506.
-- http://www.husted.com/

RE: Fuck It.

[GOMEZ Henri]

>My recommendation: put your energies into the proposal that 
>most gets your
>juices flowing.  Keep the discussion to the technical merits.
>
>> I propose to commiters to vote to drop my COMMITER STATUS.
>
>Note to other PMC/ASF members - we should probably institute a 
>mandatory 48
>hour cooling off period before requests such as the one above are
>considered.
>

It's more a question than a request. I was really sad with Pier
reaction. I really don't want to appear as a someone disturbing the 
Tomcat Project.

As many others today, I wonder about the future of OpenSource and
projects independance when corporations like IBM and Sun put (or hire)
so many of the core developpers.
 
It's a great thing that such companies goes to opensource.

But if major decisions are allready taken behind the scene, there is a real 
risk for OpenSource.

RE: ajp13 evolution or ajp14

[GOMEZ Henri]

>> Way back to technic ;-)
>
>Great too see that.
>

May be the last time :-(

>I think Dan is the authority in this, but I'll add my 2c anyway.
>
>- it's not a bad idea - as long as it's an option

That's could be a secured ajp13 or ajp14 ?-)

>- maybe there are ways to do it without too much code change - 
>you can use 
>tunnels ( and you can get that done even in hardware ). Cryptography is
>slow and hard to implement it the right way, so I would rather 
>prefer to
>use existing solutions.

I used such solutions with ssh tunnels (like CVS at apache.org) but I
really like to have a built-in solution. I know also a little SSL since
I produced sometimes ago the SSL Proxy jonama
(http://www.multimania.com/jonama/),
but SSL is just too slow at conect time and SSH is also a little too hard. 
I was thinking a more simple algorithm, ie: DES with known keys.
But there is a great SSH job in Java done by mindterm
(http://www.mindbright.se/mindterm/)
and also fine crypto (www.cryptix.org)

>- Having a group of URLs sent over a different protocol is certainly a
>good thing ( for example you could have the encrypted tunnel on a
>different port ) - and should be coordinated with the load 
>balancing stuff ( where it can also be usefull)

Yep...

>- BTW, SSH or SSL tunnels are very easy to set and available to most
>people. 

Yes but it is an out of the box solution. I really like having a integrated
solution.

>- Proably the best contribution to resolve this problem will 
>not be code
>added to mod_jk, but a documentation describing how to do that with
>available tools, and maybe some way to automate it. 

Easy under Redhat boxes, with some OpenSSL and OpenSSH RPM. 
May be later I could send some doc about ? 

RE: Fuck It.

[Curtis Dougherty]

so... why not add something to the EULA... designated OpenSource Developers
sign an agreement to NOT go to "work" until their "time" is up... a
year...two...whatever... Keep the job they have - sure...but new employment
(especially those with deep pockets) - Hands-Off...


Please don't flame me...

CaDalyst out...

[Fwd: Tomcat 3.3]

[Andy]

Hello,

I've been reading both this and the dev list for about a month and
asking/answering the more well put user questions (meaning I don't do to well
on the ones that just say "Tomcat 3.x.x doesn't work on linux) and nothing
else).

I'd like to contribute to a tomcat, but since there are three of them I'm
not horribly sure where to start.  I know 4.0 is a rearchitecture and 3.2.x
is basically the old architecture, and that 3.3 is probably less supported
than 4.0 (in that sun will probably package 4.0 in the next major j2ee).
But, that being the case (and I know I'm touching on a sore spot) what will
be the lifespan of 3.3.  There've been a few messages on this subject but all
of them were a bit too hotheaded for me to gain the information I desired
from them.  I know this is somewhat of a partisan issue and the lines have
been drawn, but just delving in I'd guess 3.2.x would probably not be the
best place to start (even though I'm using it) as being unfamiliar with the
code and it being supposidly "the worst" code of the 3, I'd probably learn it
in time to see it go out of fashion (though I'm guessing, without a real idea
what the planned lifespan is).  I'm guessing 4.0 might be a bit hard to get
into as I picture the major decisions being made in a sun boardroom somewhere
in cupertino where i'd not have the time to make it to and probably wouldn't
be invited anyhow...  But is 3.3 going to have a long enough lifespan to make
it worth my while?  Is help needed there?  I probably prefer to start out
with bug fixes as its easier to get into "if you do this than this breaks".
So some direction (preferrably without the partisan slant) would be very
helpful.

Thanks,

Andy


__
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com

Changes to the servletapi build.xml file

[Sean]

I had to made changes to the build.xml file to get 
it to work with the latest version of any.  I was not sure if this was the 
place to submit these changes.  I have attached my modified build.xml 
file.  It works great ... let me know if there are any problems or if this 
is the wrong forum to submit this.
 
When I tried using the old one I got errors with 
the depreciated copyDir command that is used in it.
 
Sean
 



  

  
  
  
  
  

  
  













  

  
  


  

  

  
  

  


  
  

  



 

 

  



  

  
  



  

  
  

 

Re: Fuck It.

[Costin Manolache]

> they were. Jon, you might
> be annoying and obnoxious at times, but those kids
> don't even care about reading what you're writing...

Too bad all this is on an open mailing list where the
mails can be read again and again - and people may 
form their own opinions. 

> _exactly_ happening: from what I see in the commit 
> messages, it seems to me
> that even if on an evolutionary track, the container
> structure is completely
> different between 3.2 and 3.3. The architecture is
> almost as different as
> 3.2 and 4.0. 

It's sad that on this list so many people are experts 
in spinning facts and politics.

This is a _false_ statement, or a gross
misunderstanding of what "architecture" means and what
"refactoring" means.

The _architecture_, _ideas_ and _patterns_ in tomcat3
are the same - the code, code organization changed.

I just had to deal with a major change in Apache2.0 - 
it seems some time ago they reorganized the whole
tree,
moved apr in a different repository, etc. Is this a
different architecture ?

And looking back to Apache1.3 - most of the concepts
are still there - you have more flexibility with the
hooks and mpms, but I hope you're not claiming that 
moving from 1.3 to 2.0 will be as hard as moving from
Apache to IIS.

And one more - Tomcat3.2 is also a refactoring of
Tomcat3.1. Refactoring == improving code readability, 
better organization - same design.
If tomcat3.2 is indeed "better" and user are well
served by moving from 3.1 to 3.2 - the same will be
true for 3.3


> others, they are all so busy in rearchitecting the
> container, and
> back-porting features from 4.0 that they don't have
> time to maintain the old

That's even worse - all the flames that start up
whenever code from 4.0 is reused in 3.x. What's the
problem ??? Are you afraid of "featurism" ( i.e. are
good for 4.0 but bad for 3.3 ) ? 

It's open source code, and it's right to reuse it
instead of reinventing the wheel. If someone writes a
JAAS authenticator for 4.0 - why not making it
available to 3.3 users too ?

After all, if 4.0 is "better", that's because of the
architecture, not because of the features - or else
next spin will be that people should use 4.0 because
of all the features. 

In any case, I made clear that all those "features"
will not be checked into 3.3 - but on an external 
tomcat-contrib-like repository. 

> This is not what's happening. You're not
> fixing them, you're
> re-architecting a new container on the ashes of 3.2,
> but you are not doing
> what you promised ME, you're not supporting your
> baby...

Take a look at "changes" in tomcat 3.3. It's a
description of all the "evolutions" from 3.2 to 3.3.
Too bad I haven't done the same when I worked on 3.2. 

You can also take a look at commit messages - yes,
some are big ( code moved around for better
organization ), 
and some deprecated interfaces are removed ( is this
an "architecutre change" ? They were introduced in
3.2, 3.1 or 3.0 to help refactoring, and "evolved"
into something better ).
 
Costin

__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

RE: ajp13 evolution or ajp14

[Costin Manolache]

> >> Way back to technic ;-)
> >
> >Great too see that.
> >
> 
> May be the last time :-(

I hope not - it's great working with you :-)

> >- it's not a bad idea - as long as it's an option
> 
> That's could be a secured ajp13 or ajp14 ?-)

AFAIK ajp13 can be extended in a backward-compatible
way ( or at least it should be ) by adding new packet
ids.

I wouldn't mind an ajp14, mod_jk is based on the idea
that there is no "perfect" protocol, but I would try
first to extend 13 ( I'm not even sure if this is
possible - if not then we need a 14). 
 
 
> I used such solutions with ssh tunnels (like CVS at
> apache.org) but I
> really like to have a built-in solution. I know also
> a little SSL since
> I produced sometimes ago the SSL Proxy jonama
> (http://www.multimania.com/jonama/),
> but SSL is just too slow at conect time and SSH is
> also a little too hard. 

I'll take a look.

> I was thinking a more simple algorithm, ie: DES with
> known keys.

AFAIK both SSL and SSH are using DES after the initial
connection is set up ( or IDEA, or other symatrical
alghoritm  - some faster than DES ).

Also ( based on 3-4 old memories ) you could extend
both protocols with other encryption alghoritms.

> >- BTW, SSH or SSL tunnels are very easy to set and
> available to most
> >people. 
> 
> Yes but it is an out of the box solution. I really
> like having a integrated
> solution.

Having it "bundled" with tomcat is very hard -
encryption is allways a problem. 

> 
> Easy under Redhat boxes, with some OpenSSL and
> OpenSSH RPM. 
> May be later I could send some doc about ? 

Check it in - as long as we are still commiters :-)

Costin


__
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

RE: Fuck It.

[Nacho]

> tree. Who is actually FIXING the 3.2 bugs and trying to get a better
> container on the old architecture? Not certainly Costin, Nacho or the

Please be carefull when you write something about anybody, have a look
at commits please... Henri, P. Delisle and I are the only ones here that
had contribute to ALL present versions of Tomcat, *ALL* dont forget
that, and i feel involved on ALL of them, if this is a waste of my poor
capacities , well no problem i do with my time what i want , i do not
admit opinions on that..

You were kids, are kids, and will be kids, regardles of your age, if you
continue playing with invaluable items as is the confidence of your
people ( as i am like it or not, i'm in your side dont forget that ).
And you are losting my confidence with every flame you put in public
lists. We are all here for another reason that hear you scream.

I'm too old ( 35 FYI ) to believe that the volume of your voice gives
you more reason than i have, no.

I believe that architecture of 3.3 is right one. Why we are not talking
about that ? because there arent technical arguments against my believes
? are you truly sure that tomcat 4.0 is right when perfomace comes to
discussion ? well i think this is the stuff that matters, and nobody can
assure that until products mature and are compared in a controlled
environment. It seems that putting this thread under technical glass i
can not find any bit of technical arguments, i need to go at least 6
month back  to read something techincal about it.

Saludos ,
Ignacio J. Ortega

RE: Fuck It.

[Rob S.]

Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is
that neither of them will be all that they could be because the resources
are so limited and divided.

Of what value would enhancing JServ to the point of technical perfection, be
right now when it is clearly not the direction things are headed?  To me, if
someone said, "i want to make all these great changes to JServ" I'd be like,
"ok sure, but no one is going to use it since it's old school.  Why not help
out the people on 3.2.x or 4.0?"  HOWEVER!  3.1 and 3.2.1 are being used by
LOTS of people, so lots of people would benefit by releasing a killer 3.2.x
or 3.3 or 3.9 as Pier puts it.  In this regard, I can totally agree with the
general idea of "making 3.2.x better!"

But, and forgive me if everyone understands and realizes this, all of these
changes will come at a price - namely slower development of the agreed-upon
"future of Tomcat."  If committers didn't think TC 4.0 was the future, and
didn't want to work on, then why all of the +1s?

As well, there will be less time for the necessary bug fixes and performance
enhancements for the 3.2.x line, the introduction of even more bugs that are
fixed even more slowly as more code is changed/added/removed.  Sure "they
will come in time" but will they?  During all that time, I end up with a
functionally-equivalent container that's more technically sound underneath,
but with more bugs (because the old ones are there while all of the new
changes were taking place, and the newly-introduced ones as well).  So how
is the user better off at the point that 3.2.x/3.x is released?

So at the end of all of this, we have slowed development of 4.0 while we end
up with a functionally equivalent container to 3.2.1, but with more bugs,
and more people's time having to be spent fixing those bugs instead of
contributing to 4.0, which I'm sure will be all the rage, as 3.2 is.

This also goes back to a philosophical question - How many big "changes"
(architectural or not) before someone is "happy" with the code?  I worked
with a developer who chronically rewrote the things he worked on "to get
them perfect."  As a result, he never progressed, continually outputting
things that were functionally identical, just written differently.  Do the
end-users care?  Nope.  Even for a 5-10% performance enhancement?  Who's to
say...

Anyways, just my 2c.  I don't really care who does what or when or whatever,
or how perfect the code is or what.  "I want" a container NOW that has very
little bugs, and works the way it should (adheres to the spec, etc.).
Personally, I don't care if it's spaghetti or what, so long as when I
install it, it's easy to configure, does what it should, and does it well.

Yeah, and I think anyone who spends time contributing to open source, at
work or not, is a Good Person(tm) =)  So know that people everywhere,
everyday, appreciate the efforts and expertise of people like Costin, Craig,
Pier, Larry, Henri, Remy, Sam, Pottymouth-Jon =b, James, and I'm sorry I
can't remember all of the committers off the top of my head.

Good day,

- Rob Slifka

RE: Fuck It.

[[EMAIL PROTECTED]]

On Thu, 21 Dec 2000, Rob S. wrote:

> Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is
> that neither of them will be all that they could be because the resources
> are so limited and divided.
> 
> Of what value would enhancing JServ to the point of technical perfection, be
> right now when it is clearly not the direction things are headed?  To me, if
> someone said, "i want to make all these great changes to JServ" I'd be like,
> "ok sure, but no one is going to use it since it's old school.  Why not help
> out the people on 3.2.x or 4.0?"  HOWEVER!  3.1 and 3.2.1 are being used by
> LOTS of people, so lots of people would benefit by releasing a killer 3.2.x
> or 3.3 or 3.9 as Pier puts it.  In this regard, I can totally agree with the
> general idea of "making 3.2.x better!"

i second this. 
good,stable, bug free servlet engine now 
with load balancing -> tomcat 3.2.x (equivalent to apache 1.3.x)
development, future release servlet engine
with sessions in permanent storage -> tomcat 4.x (equiv. to apache 2.x)

Merge the 3.3 code tree with 3.2 and make it better..dropping 3.3
is much better than struggling with a dead end tree/codebase and it
will make 3.2.x better for all. 
Any project should have only ONE development path..just like linux 
2.3.x->2.4.x and one stable like linux 2.2.x...any other simply
wastest resources which arent available in the first place.
-Ys-
[EMAIL PROTECTED]

help for EJB

[Boby Micheal]

 
We are soft ware 
developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are 
developing application in EJB under weblogic server. We required  to deploy the application (what we 
developed in EJB under weblogic server)in Tomcat server. Please give me a step 
by step Instructions for the deployment of  
EJB application in Tomcat server
 
1.Will tomcat 
server support EJB? 
2. Is it required 
any additional support program, to support EJB in Tomcat,?  
Boby Michael
 

Tomcat 3.2.1 bug if not root-context defined.

[Klaus Friedel]

Tomcat 3.2.1 fails to deliver a resource, if no root-context is defined in serverl.xml.
If you do not define the root-context "" in server.xml and request a non-existing 
resource,
Tomcat will loop forever in PrefixMapper.getLongestPrefixMatch() trying to find a 
Container for "".

Bye,
Klaus.

Re: Fuck It.

[Jon Stevens]

on 12/21/2000 9:44 AM, "Rob S." <[EMAIL PROTECTED]> wrote:

> So at the end of all of this, we have slowed development of 4.0 while we end
> up with a functionally equivalent container to 3.2.1, but with more bugs,

Just to clarify your misconceptions:

Not true at all. 3.x only implements Servlet API 2.2 and 4.0 implements
Servlet API latest and greatest.

On top of it, I (and others) would be STRONGLY -1 for adding Servlet API 2.3
support to 3.x within the Jakarta project. That is why Costin has already
agreed and stated that he will fork that addition to another location.

Therefore, as long as 3.x does not have support for 2.3, it is a dead end
solution IMHO and adding support for 2.3 within 3.x would be a duplication
of effort since we already have a 2.3 container (hence the reason why I am
-1 and why Costin has already stated he plans to fork that addition
somewhere else).

> "I want" a container NOW that has very
> little bugs, and works the way it should (adheres to the spec, etc.).

Then you should commit code. :-)

-jon

Re: Tomcat 3.2.1 bug if not root-context defined.

[Shawn McMurdo]

Hi Klaus,
I ran into this as well and thought it was particular to the way that Tomcat is 
integrated
with Enhydra.  I think I have a fix for it.  I'll try to get a patch together and post 
it soon.
Shawn

Klaus Friedel wrote:

> Tomcat 3.2.1 fails to deliver a resource, if no root-context is defined in 
>serverl.xml.
> If you do not define the root-context "" in server.xml and request a non-existing 
>resource,
> Tomcat will loop forever in PrefixMapper.getLongestPrefixMatch() trying to find a 
>Container for "".
>
> Bye,
> Klaus.

--
Shawn McMurdo  mailto:[EMAIL PROTECTED]
Lutris Technologieshttp://www.lutris.com
Enhydra.Orghttp://www.enhydra.org

Re: How to do my own JSP processing

[Craig R. McClanahan]

Christian Mallwitz wrote:

> Hi,
>
> I want to write a servlet that reads JSP files from somewhere outside the
> servlets web application context, compiles them to a location outside the
> servlets web application (if necessary) and then invokes the compiled
> servlet class.
>
> I started looking at org.apache.jasper.servlet.JspServlet for a start but it
> looks really messy. Besides the Jasper classes lack some documentation to
> put it mildly ... :-)
>
> What should I really look at and what things do I have to look out for?
>
> The result should work similar to using request dispatchers include() but
> with more control over it (especially response header generation, response
> buffering, etc.) Tag lib stuff should work seemless in all the pages.
>

Sounds like you are planning on inventing your own variant of a servlet+JSP
server, since you're wanting to change or ignore many of the spec requirements.
And you will end up with an app that will only run in your own server.  Unless
you like building servers as a hobby, you've got a *lot* of hard work ahead of
you.

I would suggest you look at how you can architect your application *within* the
requirements of the servlet and JSP specs.  That way, you can focus on writing
an app rather than a server, and have some assurance that you can run that app
elsewhere if and when you outgrow Tomcat.

>
> Thanks
> Christian
> --
> Christian Mallwitz INTERSHOP Communications Germany
> Senior Software Engineerphone: +49 3641 50 3453

Craig McClanahan

Re: Changes to the servletapi build.xml file

[Craig R. McClanahan]

This is definitely the place ... thanks Sean!
Jon Stevens has committed some changes to the servletapi build scripts. 
I will take a look and merge your ideas for anything he missed.
Craig
 
Sean wrote:

I
had to made changes to the build.xml file to get it to work with the latest
version of any.  I was not sure if this was the place to submit these
changes.  I have attached my modified build.xml file.  It works
great ... let me know if there are any problems or if this is the wrong
forum to submit this. When
I tried using the old one I got errors with the depreciated copyDir command
that is used in it. Sean

Re: Tomcat 3.3

[Craig R. McClanahan]

Andy wrote:

> But, that being the case (and I know I'm touching on a sore spot) what will
> be the lifespan of 3.3.

Since a proposal to publish a "Tomcat 3.3" has never been formally presented and
voted on, the only logically correct answer is "I don't know."  Depending on the
results of a vote, it could be anything from "it will never be released (as
Tomcat -- the code is free for anyone to do what they want with)" to "live long
and prosper".

Given the current emotionally charged climate, I would not suggest that anyone
propose a vote on 3.3 at the moment :-).

> [snip]

> I'm guessing 4.0 might be a bit hard to get
> into as I picture the major decisions being made in a sun boardroom somewhere
> in cupertino where i'd not have the time to make it to and probably wouldn't
> be invited anyhow...

I'm guessing (well, not really -- it's pretty obvious :-) you haven't studied
your history very well.

For an interesting bit of background, you might go check out the CVS repository
for Apache JServ at http://java.apache.org and  select the branch labelled
"JSERV1_1DEV".  (Yes, it started before there was a 1.1 release of Apache
JServ).  Note the dates on those files (early to mid 1999, before the Sun
contribution of Tomcat was announced).  Go look at the source, and you will see
the recognizable architecture that is Catalina (the servlet container part of
Tomcat 4.0) today.

For the record, Sun hired me in March, 2000, so that I could work on Tomcat full
time instead of it just being a hobby (as it was when the original code was
written).  :-)


>
> Andy

Craig McClanahan

Re: help for EJB

[Shawn McMurdo]

 
Boby Micheal wrote:

 

We
are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now
we are developing application in EJB under weblogic server. We requiredto
deploy the application (what we developed in EJB under weblogic server)in
Tomcat server. Please give me a step by step Instructions for the deployment
ofEJB application in Tomcat server
 
 


1.Will
tomcat server support EJB?
No, not directly.
 
 

2.
Is it required any additional support program, to support EJB in Tomcat,?
Yes.  You need to get either Enhydra Enterprise at http://www.enhydra.org
or
jBoss at http://www.jboss.org and then follow the appropriate directions.
Shawn
 
 
 

Boby
Michael

 urn:schemas-microsoft-com:office:office" />

--
Shawn McMurdo 
mailto:[EMAIL PROTECTED]
Lutris Technologies    http://www.lutris.com
Enhydra.Org   
http://www.enhydra.org
 

Re: F**k It. (off topic)

[mclinden]

I don't mean to sound as though I am a prude, but we do a lot of our
consulting at customer sites,  much of it face-to-face with the customer's
staff and management. I can control what messages I read and when but I
cannot control when people are in my office and when the message alert with
the Subject: line pops up on the screen.

I can't do much to diffuse the anger but I would like to ask that we try to
reserve our anger (and expletives), when appropriate, to the message body
rather than the Subject: line so that I don't have to act like I was caught
browsing porn sites every time my customers walk into my office.

Thanks in advance.

RE: Fuck It.

[cmanolache]

On Thu, 21 Dec 2000, Rob S. wrote:

> Correct me if I'm wrong, but maybe the whole focus of 3.3 / 3.2.x thing, is
> that neither of them will be all that they could be because the resources
> are so limited and divided.

About the same resources that made the evolution from 3.1 to 3.2 are
available and working for 3.3.

3.2.x are maintainance releases - i.e. minor bug fixes or security issues.
You can't and shoulnd't do any serious change ( like rewriting of the
cookie handling, or reduce the use of Strings, or the refactoring that is
still needed ).

There is no difference AFAIK between 3.1->3.2 and 3.2->3.3 ( except that
for 3.1 we didn't had a 3.1.x until recently )

Keep in mind that "resources" are not mind-less kids that work on what
the "grown-up" people tell them to do - most open source developers I know
can decide for themself what they want to do, and express that in doing
what they want of they are allowed to. 


> Of what value would enhancing JServ to the point of technical perfection, be
> right now when it is clearly not the direction things are headed?  To me, if
> someone said, "i want to make all these great changes to JServ" I'd be like,
> "ok sure, but no one is going to use it since it's old school.  Why not help

Yet I don't think you have the right to stop him - it's his time, and this
is open source. We are in fact still reusing and enhancing  JServ code (
mod_jserv is still used in tomcat3, and mod_jk is based in part of that
code ).



> out the people on 3.2.x or 4.0?"  HOWEVER!  3.1 and 3.2.1 are being used by
> LOTS of people, so lots of people would benefit by releasing a killer 3.2.x
> or 3.3 or 3.9 as Pier puts it.  In this regard, I can totally agree with the
> general idea of "making 3.2.x better!"

We could easily re-do all the changes that we did in 3.3 using the 3.2.x
numbers - yet it'll be a lie. The difference between 3.2 and 3.3 may be
slightly smaller than 3.1 and 3.2, but it's still big and significant
enough.

( many of the changes in 3.3 were moving code around changing the
representation of request info from String to MessageBytes. The rest is
removing deprecated code and adding comments and removing ambiguous
behavior ).



> But, and forgive me if everyone understands and realizes this, all of these
> changes will come at a price - namely slower development of the agreed-upon
> "future of Tomcat."  If committers didn't think TC 4.0 was the future, and
> didn't want to work on, then why all of the +1s?

It doesn't look at all like "agreed-upon future of tomcat" - yes, we had a
vote to implement servlet2.3 in TC4.0, and there was no -1 on the vote.
And it was the right decision - nobody should -1 alternate ideas ( I
learned that very late, as you know one year ago I was fighting against
catalina and revolutions ). 

If you look at the commits that went into 3.3 and read this mailing
list carefully, you'll notice that there are developers who think that the
future is decided by code commits and real contributions. 

( in any case, strictly speaking there is no 4.0 and no 3.3 - you can't
vote or decide on something that doesn't exist, and so far both of them
are in work. )


> As well, there will be less time for the necessary bug fixes and performance
> enhancements for the 3.2.x line, the introduction of even more bugs that are

Most of the bug fixes and performance enhancements of the 3.2 line are
made in 3.3. That's what happened after 3.1, that's what happened after
3.0.

BTW, most of the performance enhancements that went into 3.3 existed
_before_ 3.2 was released ( and some were actually implemented and ready
to go). I felt at that time that it's better to postpone them in order to
shorten the release cycle - it is my belief that too long release cycles
are bad for an open source project. 

That's one of the reasons I tried as hard as possible to make sure that
tomcat3 can be developed in a modular way, with independent cycles for
each module. In order to do that we need the modularity that is result of
refactoring and reorganization done in 3.3.

> but with more bugs (because the old ones are there while all of the new
> changes were taking place, and the newly-introduced ones as well).  So how

That's again wrong - some of the bugs in 3.2 can't be fixed without
serious changes in the code. AFAIK most commits from 3.2 tree are or will
be merged into 3.3, and I think a number of bugs were fixed as a result of
refactoring ( my example is Cookies - the parser in 3.2 supported only 
v0 cookies, and sent the wrong header for v1 cookies ).


> So at the end of all of this, we have slowed development of 4.0 while we end
> up with a functionally equivalent container to 3.2.1, but with more bugs,

3.3 is based on 3.2 - and bug fixes for 3.2 are bug fixes for 3.3 as well.

> This also goes back to a philosophical question - How many big "changes"
> (architectural or not) before someone is "happy" with the code?  I worked
> with a developer who chronically rewrote 

Re: Fuck It.

[Christopher Cain]

"Pier P. Fumagalli" wrote:

> Where were you KIDS when we were fighting the big
> corporations to have them looking into open source, to contribute
> significant parts of their technologies to the Foundation, where were you
> while we were changing this world? You were home, and one day, you looked up
> on your browser, saw a thing called Jakarta and started weening if things
> weren't as nice as you wanted them.

Nice. Now as a newcomer who wishes to give back to the community, do you think
that this makes me feel more welcome or less? Why don't you just post a big sign
that says, "If you were not here in the beginning, you are irrelevent. Go Away."
That would probably be a slightly more effective means of keeping new developers
away than simply making fun of them.

> Now, I believe that _I_ deserve some respect, and even if all your comments
> were not directly targeted to me, they hurt as if they were. Jon, you might
> be annoying and obnoxious at times, but those kids don't even care about
> reading what you're writing...

I assume that I fall under that auspise since I also called Jon out directly. And
yes, as I stated in no uncertain terms, many times I do _not_ care about reading
what Jon writes. Many of his posts are so demeaning to whomever they addressed
that it is difficult to read them all the way through, quite literally. It makes
me uncomfortable to see well-meaning people treated like that. And trust me, I
received enough private mail on the subject to assure you that I am far from the
only one. The bottom line is, Jon is currently getting no more and no less than
he gives everyone else.

> hear that people like Paul Frieden (the only person that did put some salt
> in what he said)

Hey, thanks =)



> As one of the people behind the scenes since before each of you got here, I
> believe my vote counts, and now, please prove me wrong.

This post is a better example of my original point than I could possibly dream
up, and it has nothing to do with the technical merits of the architecture. Sam
is right on the money. Do you think that this little scuttle over 3.x vs. 4.x
will be too terribly important six months from now? Probably not. What will be is
the one or two or ten developers who eventually decided to contribute their
limited time and resources to a different OSS project because this one is getting
too contentious for their tastes. There are other great projects out there to get
involved in, and whether or not a project has some fun people to work with, as
opposed to everyone treating each other like shit when they disagree, is
definitely a consideration for most of us.

> Pier

- Chirstopher

Re: [T4][Classloaders][PATCH Suggestion] Bug in toURL() and new URL(x,x,x,x)

[Craig R. McClanahan]

Stuart Roebuck wrote:

> In the course of fixing a problem I was having getting Apache Cocoon to run, I came 
>across a bug in Java in the File.toURL() method.  This fault, combined with the use 
>of the URLClassLoader resulted in a classloading issue.
>

Stuart,

I'm trying to create a simple, reproducible test case that causes Tomcat 4.0 to fail 
because of this -- but so far, I have not been able to.

For example, I would assume that the following scenario should fail due to this 
problem:
* Run on Linux (RH 6.2) + JDK 1.2.2
* Do *not* set the CATALINA_HOME environment variable
* Set current directory to where Tomcat 4.0 is installed
* Start it by typing "./bin/catalina.sh start".

This would cause CATALINA_HOME (and therefore the "catalina.home" system property) to 
be set to "./bin/..", which would cause all the URLs in the "system" class loader -- 
the one created from JAR files in the "bin" directory -- to have absolute pathnames 
with ".." in them, which should trigger this problem.

Yet, it still runs correctly.  Can you help me identify a failure case?

Craig

Tomcat session replicator

[shai]

Hi,

 

Two weeks ago I posted note here saying I’m going to write patch for
Tomcat 3.2 to support redundancy, in manner of having session information
stored between reloads and shared between tomcat instances.

In order to support tomcat redundancy I thought on implementing that in
two phases:


 (dumping)
 While shutting down Tomcat it will save sessions in file and reload them
 while going up. This feature will allow restarting tomcat without loosing
 state.
 (replication)
 Sending session from one Tomcat to another (AKA: buddy). This will allow the
 session to have backup on another machine. mod_jk  will send user connection requests to
 the second machine while the original machine is unavailable.


 

Number 1. above is already implemented, and 2. is going to be finish
soon.

The question I have is: Should I implement the session replicator listener
as stand-alone connector, or incorporate in into Ajpv13? This will require
adding two commands to the protocol implementation.

Options:


 Stand-alone
 connector. This will require another listener.
 Incorporate
 it into Ajp13.
 Incorporate
 it into Ajp13 and calling it Ajp14.


 

Other ideas?

 

Implementation details will be followed soon.

 

 



Shai Fultheim

Chief Technology Officer

BRM Seed

 

E-Mail: [EMAIL PROTECTED]

Mobile: 972-53-866-459

Office: 972-2-5891-459

 

Re: Fuck It.

[cmanolache]

> Not true at all. 3.x only implements Servlet API 2.2 and 4.0 implements
> Servlet API latest and greatest.
> 
> On top of it, I (and others) would be STRONGLY -1 for adding Servlet API 2.3
> support to 3.x within the Jakarta project. That is why Costin has already
> agreed and stated that he will fork that addition to another location.
> 
> Therefore, as long as 3.x does not have support for 2.3, it is a dead end
> solution IMHO and adding support for 2.3 within 3.x would be a duplication
> of effort since we already have a 2.3 container (hence the reason why I am
> -1 and why Costin has already stated he plans to fork that addition
> somewhere else).

Thanks Jon, you are right about this and I now agree with you that servlet
2.3 support for tomcat 3.x shouldn't be developed as part of this project,
but as an independent module.

But you can look at the good side - people using Tomcat3.2 will have a
smooth transition from Servlet2.2 to Servlet2.3, and why not even further
in the future. 

Tomcat3.3 is designed to allow multiple facades - while it'll be only a
servlet 2.2 container, people can make a Servlet2.3 module available and
you will be able to do a gradual transition ( and  when all your
applications are 2.3 you could switch to another 2.3 container ).

And ( in case someone will flame that "this is an architecture change in
3.3" ) - this design was part of tomcat from 3.0 and before - but the
implementation was pretty bad, and only in 3.3 we can take advantage of
this architecture. ( and no, it's not my idea, I actually believed it's a
bad idea when I first saw it ).

Speaking of future, the same thing can happen when the next servlet spec
is released - and again you could use tomcat3.3 to have a smooth future.
I know how painfull it is to upgrade a production server - how many small
things will stop working and many things will be different.

Yes, a Servlet2.3 container should run any 2.2 servlet - but will this be
true for Servlet 3.0 ( or 2.4 or whatever will be next ) ? 
( not to mention that there are still 2.2 servlets that have problems
moving from one 2.2 container to another :-)

And another "read of the future" - you can be sure you'll have a better
and better container as we move forward. Having more than one solution is
allways better then having only one, and as long as none is perfect I'm
sure some synergy can exist ( or at least I'm trying to learn and reuse
as much as possible from 4.0 - so whatever will happen in the future in
4.0 can happen in 3.3 too ) 
 

Costin

Re: F**k It. (off topic)

[Christopher Cain]

[EMAIL PROTECTED] wrote:

> I don't mean to sound as though I am a prude, but we do a lot of our
> consulting at customer sites,  much of it face-to-face with the customer's
> staff and management. I can control what messages I read and when but I
> cannot control when people are in my office and when the message alert with
> the Subject: line pops up on the screen.
>
> I can't do much to diffuse the anger but I would like to ask that we try to
> reserve our anger (and expletives), when appropriate, to the message body
> rather than the Subject: line so that I don't have to act like I was caught
> browsing porn sites every time my customers walk into my office.
>
> Thanks in advance.

Exact same scenerio here. I second that.

Re: Tomcat session replicator

[Craig R. McClanahan]

Shai,
I apologize for not responding to you earlier ... substantive discussions
are getting a little lost in the noise at the moment.
For some reason, my Netscape mail reader won't let me intersperse comments
-- so I've put them at the end.
I think I read into your earlier comment that you'd be interested in
being a committer to work on this stuff.  If you're still interested,
you've got my +1.
Craig
 
[EMAIL PROTECTED] wrote:



Hi,




Two
weeks ago I posted note here saying I’m going to write patch for Tomcat
3.2 to support redundancy, in manner of having session information stored
between reloads and shared between tomcat instances.
 
 

In
order to support tomcat redundancy I thought on implementing that in two
phases:


(dumping)
While shutting down Tomcat it will save sessions in file and reload them
while going up. This feature will allow restarting tomcat without loosing
state.


(replication)
Sending session from one Tomcat to another (AKA: buddy). This will allow
the session to have backup on another machine. mod_jk  will
send user connection requests to the second machine while the original
machine is unavailable.





Number
1. above is already implemented, and 2. is going to be finish soon.

The
question I have is: Should I implement the session replicator listener
as stand-alone connector, or incorporate in into Ajpv13? This will require
adding two commands to the protocol implementation.

Options:


Stand-alone
connector. This will require another listener.


Incorporate
it into Ajp13.


Incorporate
it into Ajp13 and calling it Ajp14.





Other
ideas?



Implementation
details will be followed soon.







Shai
Fultheim

Chief
Technology Officer

BRM
Seed



E-Mail:
[EMAIL PROTECTED]

Mobile:
972-53-866-459

Office:
972-2-5891-459




The biggest problem I have with integrating session replication
into AJPxx is that it means this will only work if you're running Apache
connected, versus when Tomcat is running stand alone.  Even in that
environment, does the Apache instance really need to know what's going
on?  Wouldn't it just be a case of updating the cookie to include
the new "router" information when you migrate a session from one JVM to
another?
Personally, I'd like to see a session migration mechanism that works
between the "back end" Tomcat instances.  There are probably few enough
of those (in most use cases) that you can maintain a spiderweb of persistent
connections that is used only to communicate session migration information.
Just as a small technical detail -- the servlet spec says that an application
*must* run within a single JVM unless it marks itself as 
in the deployment descriptor -- don't forget to check for that.
As to what version of Tomcat to work on, no matter what the future holds
it seems like the current 3.2 code base is not really appropriate for major
innovation.  I would only point out that the 4.0 architecture has
an interface (org.apache.catalina.Store) behind which session migration
stuff can easily be hidden -- as well as support for persistence, swapping,
and other advanced features -- without modifying the remainder of the servlet
container.  Several other folks have expressed interest in working
on this at various times, so collaboration would be quite useful.
Craig McClanahan
 
 
 

[humor] Why should I care what color the bikeshed is?

[Jon Stevens]

-jon

Getting around Facade

[Seth Riney]

I am interested in calling toString on a Request, but am prevented from this
by the Facade wrapping infrastructure.  I understand the security reasons
for this, but want to see the stringified Request.  I tried getting the
Context and creating a SimpleFacadeManager, but I got some run time errors
when I tried to getRealRequest and toString that.

Anyone have some simple code for working around the Facade (or know how to
turn it off from a setting)?

Thanks in advance,

Seth

help EJB

[Boby Micheal]

  
We are soft ware 
developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are 
developing application in EJB under weblogic server. We required  to deploy the application (what we 
developed in EJB under weblogic server)in Tomcat server. Please give me a step 
by step Instructions for the deployment of  
EJB application in Tomcat server
 
1.Will tomcat 
server support EJB? 
2. Is it required 
any additional support program, to support EJB in Tomcat,?  
Boby Michael
 

cvs commit: jakarta-tomcat/src/doc NT-Service-howto.html

[marcsaeg]

marcsaeg00/12/21 11:24:21

  Modified:src/doc  Tag: tomcat_32 NT-Service-howto.html
  Log:
  Added notice about the NT service termination feature of JDK1.3
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.2.2.4   +13 -4 jakarta-tomcat/src/doc/NT-Service-howto.html
  
  Index: NT-Service-howto.html
  ===
  RCS file: /home/cvs/jakarta-tomcat/src/doc/NT-Service-howto.html,v
  retrieving revision 1.2.2.3
  retrieving revision 1.2.2.4
  diff -u -r1.2.2.3 -r1.2.2.4
  --- NT-Service-howto.html 2000/10/16 02:20:08 1.2.2.3
  +++ NT-Service-howto.html 2000/12/21 19:24:19 1.2.2.4
  @@ -1,9 +1,9 @@
   
   
   
   
   
  @@ -89,6 +89,15 @@
   Tomcat service will kill Tomcat abruptly (that is murder it) without giving it
   a chance to clean up. 
   
  +Notice for JDK 1.3 users:  There is a 
  +http://developer.java.sun.com/developer/bugParade/bugs/4323062.html">known 
problem
  +in JDK 1.3 that affects Java applications being run as Windows NT 
services.  The bug causes the
  +service to terminate when the currently logged in user logs out.  The 
simplest way to work
  +around this problem is to use JDK 1.2.  If your application requires JDK 
1.3 features then you 
  +may want to look into http://www.kcmultimedia.com/javaserv/">javaserv 
or
  +http://www.alexandriasc.com/software/JavaService/">JavaService.  Users
 have reported
  +success with both of these packages but there may be others that work as well.
  +
   To remove the installed service, execute jk_nt_service -R 
   
   Advance Setup
  
  
  

BugRat Report #646 has been filed.

[BugRat Mail System]

Bug report #646 has just been filed.

You can view the report at the following URL:

   

REPORT #646 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: critical
Confidence: public
Environment: 
   Release: 3.2.1
   JVM Release: jdk1.2.2
   Operating System: win32
   OS Release: 4.0
   Platform: NT

Synopsis: 
Ctx(  ): IOException in: R(  + /index.html + null) socket write error (code=10053)

Description:
I just downloaded Tomcat 3.2.1 and try to access localhost:8080/index.html and get the 
following error on every access.

Ctx(  ): IOException in: R(  + /index.html + null) socket write error (code=10053)

Not sure if it is a bug or I am not doing something right?
Thanks

Title: 
BugRat Report #
646





BugRat Report #
646




Project:
Tomcat


Release:
3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
critical




Confidence:
public





Submitter:
_Anonymous ( [EMAIL PROTECTED] )

Date Submitted:
Dec 21 2000, 01:58:08 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Ctx(  ): IOException in: R(  + /index.html + null) socket write error (code=10053)


 Environment: (jvm, os, osrel, platform)

jdk1.2.2, win32, 4.0, NT



Additional Environment Description:





Report Description:

I just downloaded Tomcat 3.2.1 and try to access localhost:8080/index.html and get the following error on every access.

Ctx(  ): IOException in: R(  + /index.html + null) socket write error (code=10053)

Not sure if it is a bug or I am not doing something right?
Thanks



How To Reproduce:

null



View this report online...

How do you spell relief?

[Roy Wilson]

Title: How do you spell relief?




Jon,

Thanks (and thank God) for comic relief (which is nevertheless not
off-topic).

Roy
-- 

Roy Wilson
E-mail: [EMAIL PROTECTED]

>> Original Message <<

On 12/21/00, 2:16:48 PM, Jon Stevens <[EMAIL PROTECTED]> wrote regarding
[humor] Why should I care what color the bikeshed is?:


> 

> -jon

Re: [humor] Why should I care what color the bikeshed is?

[Sam Ruby]

Jon Stevens wrote:
>
> 

+1

- Sam Ruby

Re: Tomcat session replicator

[cmanolache]

> Two weeks ago I posted note here saying I'm going to write patch for Tomcat
> 3.2 to support redundancy, in manner of having session information stored
> between reloads and shared between tomcat instances.
> In order to support tomcat redundancy I thought on implementing that in two
> phases:


> 1.Stand-alone connector. This will require another listener.
> 2.Incorporate it into Ajp13.
> 3.Incorporate it into Ajp13 and calling it Ajp14.

My preference would be wither 2 or 3. 

I think we should be able to add new message types to Ajp13 - that's
needed to support the autoconfiguration anyway, and will be needed in
future.

If that's not possible - we should add what's needed and make it 14.
( AFAIK it should be - I remember this was a thing Gal had in mind when he
wrote the code )

Costin

Re: Fuck It.

[Jon Stevens]

on 12/21/2000 11:11 AM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Tomcat3.3 is designed to allow multiple facades - while it'll be only a
> servlet 2.2 container, people can make a Servlet2.3 module available and
> you will be able to do a gradual transition ( and  when all your
> applications are 2.3 you could switch to another 2.3 container ).

That is a bad "excuse" as all 2.3 containers need to be backward compatible
with 2.2. It is part of the spec. You actually end up clarifying that little
fact below.

Let me also state that after having just migrated a fairly complex Turbine
based application from Tomcat 3.x to 4.0, I can state that I had to make
absolutely NO changes to any of my files in order to do this. I'm not
worried about the future being on top of Tomcat 4.x.

> Speaking of future, the same thing can happen when the next servlet spec
> is released - and again you could use tomcat3.3 to have a smooth future.
> I know how painfull it is to upgrade a production server - how many small
> things will stop working and many things will be different.

And I'm 100% sure you will be able to use 4.0 as a base for future Servlet
API's as well. What is your point here?

> Yes, a Servlet2.3 container should run any 2.2 servlet - but will this be
> true for Servlet 3.0 ( or 2.4 or whatever will be next ) ?
> ( not to mention that there are still 2.2 servlets that have problems
> moving from one 2.2 container to another :-)

You can't promise that for Tomcat 3.3. If you go away, there is absolutely
no promise that someone else will pick up and implement whatever the latest
spec is on top of Tomcat 3.x.

However, you CAN promise that someone will do it on Tomcat 4.x because that
is the direction that Sun is going and Sun will pay someone to do it as long
as J2EE is around (which I don't see it going away any time soon, if
anything, it is getting larger and more important with the .NET crap).

> And another "read of the future" - you can be sure you'll have a better
> and better container as we move forward. Having more than one solution is
> allways better then having only one, and as long as none is perfect I'm
> sure some synergy can exist ( or at least I'm trying to learn and reuse
> as much as possible from 4.0 - so whatever will happen in the future in
> 4.0 can happen in 3.3 too )

Very true, but not under the ASF because you will be forked elsewhere as you
have already stated.

p.s. I hear that Resin is a very good container. That doesn't stop the ASF
from providing one as well. Competition is good. I like forks and your fork
would be the first fork of the Tomcat platform. I am totally +1 on that
without a doubt because it proves that the people here at the ASF are
producing quality code.

thanks,

-jon

Re: Fuck It.

[Pier P. Fumagalli]

"Rob S." wrote:
> 
> Of what value would enhancing JServ to the point of technical perfection, be
> right now when it is clearly not the direction things are headed?  To me, if
> someone said, "i want to make all these great changes to JServ" I'd be like,
> "ok sure, but no one is going to use it since it's old school. [...]

Thanks Rob. You EXACTLY hit the point... When  we started the Jakarta
project, what happened to JServ? NOTHING, it's still there, kicking
asses since two years with no maintainers because Tomcat was the way to
go... We developers got it, understood it, and carried on with our
decisions, even if to someone that was a wrong one.

And what happened? Of course Craig felt left out in that, he was writing
JServ 2.0, but he said "yes" to Jakarta, and because of that, he simply
dropped the old container, until he came along and made the Catalina
proposal... And now that's the way to go, that's what we decided, that's
what I want to see happen.

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: Tomcat 3.3

[Andy]

"Craig R. McClanahan" wrote:

> Andy wrote:
>
> > But, that being the case (and I know I'm touching on a sore spot) what will
> > be the lifespan of 3.3.
>
> Since a proposal to publish a "Tomcat 3.3" has never been formally presented and
> voted on, the only logically correct answer is "I don't know."  Depending on the
> results of a vote, it could be anything from "it will never be released (as
> Tomcat -- the code is free for anyone to do what they want with)" to "live long
> and prosper".
>

Kinda hard to go on.

>
> Given the current emotionally charged climate, I would not suggest that anyone
> propose a vote on 3.3 at the moment :-).
>

I'd say you might have just invited it.


>
> > [snip]
>
> > I'm guessing 4.0 might be a bit hard to get
> > into as I picture the major decisions being made in a sun boardroom somewhere
> > in cupertino where i'd not have the time to make it to and probably wouldn't
> > be invited anyhow...
>
> I'm guessing (well, not really -- it's pretty obvious :-) you haven't studied
> your history very well.
>

Other than reading the site and newsgroups without actually being here x years ago,
its not as if there is a "Complete history of tomcat".   And honestly I probably
would find it a bit dry.  (see Shakespeare's "Loves Labours Lost" for more
entertaining reading).  I'm just trying to find a starting point.

>
> For an interesting bit of background, you might go check out the CVS repository
> for Apache JServ at http://java.apache.org and  select the branch labelled
> "JSERV1_1DEV".  (Yes, it started before there was a 1.1 release of Apache
> JServ).  Note the dates on those files (early to mid 1999, before the Sun
> contribution of Tomcat was announced).  Go look at the source, and you will see
> the recognizable architecture that is Catalina (the servlet container part of
> Tomcat 4.0) today.
>

Cool.

>
> For the record, Sun hired me in March, 2000, so that I could work on Tomcat full
> time instead of it just being a hobby (as it was when the original code was
> written).  :-)
>

My comments were not directed at you, I appologize if I offended anyone as was not
my intention.  My desire is to get involved in a piece of open source software I
actually use (therefore can have the time to study and contribute to in my free
time without getting a divorce ), working for a money has been taking the fun
out of computers so I wanted to work for something else.  Again, no offense was
intended, I was just summing up the best conclusions I could come up with from
reading the newsgroups.

Maybe the best thing would be if one of the commiters gave me a piece of their
bug they don't feel like finding.

>From your comments I have a question:  Has 4.0 been voted on ?  ( if this is
politically charged please read this in the context it is intended which is NOT
controversy, I'm a programmer not a political type)...  If it will indeed be
released and maintained and contributions are welcome than maybe that's a good
starting point.

Thanks,

Andy


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: TC 3.2 - Better logging messages when something bad happens?

[David Rees]

Replying to my own message here,

Anyone have any technical comments on the message below?  I think that
printing a stack dump in this case can be very useful, but someone else may
have a different view.

Thanks,
Dave

> -Original Message-
> From: David Rees [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 19, 2000 8:53 PM
> To: Tomcat Dev List
> Subject: TC 3.2 - Better logging messages when something bad happens?
>
>
> While doing some development, I started getting this Exception:
>
> org.apache.jasper.JasperException: error in invoking method
> at
> org.apache.jasper.runtime.JspRuntimeLibrary.createTypedArray(JspRu
> ntimeLibra
> ry.java:353)
> at
> org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(JspRu
> ntimeLibra
> ry.java:194)
>
> I was trying to populate a bean with an array from a form, but
> the bean was
> throwing an exception during the population.  The confusing part was that
> there was nothing in any logs to help me figure out what was going on
> because the JspRuntimeLibrary was catching the exception and
> suppressing the
> real error message.
>
> Simply printing out a stack trace like this helped me find the
> problem in no
> time (diff against TC 3.2.1 release):
>
> ---
> ./src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java.orig   Tue
> Dec 19 20:51:23 2000
> +++ ./src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
>   Tue
> Dec 19 20:38:50 2000
> @@ -349,6 +349,7 @@
> method.invoke (bean, new Object[] {tmpval});
> }
> } catch (Exception ex) {
> +   ex.printStackTrace();
> throw new JasperException ("error in invoking method");
> }
>
>
> Is there any reason to not include a similar patch in the official tree?
>
> -Dave
>

Re: Fuck It.

[Pier P. Fumagalli]

GOMEZ Henri wrote:
> 
> The future of Tomcat 3.3 seems to be outside Apache now.
> It's really sad.

Sorry, but that's not what I said Henry. Last month I even came up with
a proposal that got accepted (but never turned to reality) on how to
handle this situation... But it seems to me, that everyone here is more
interested in flaming others rather than read and discuss... And this
sucks...

I'm not saying to kick the 3.3 proposal out, I'm just saying that, from
what I see 3.3 is as different from 3.2 as 4.0 is, it is a different
container. And because of this, rules for revolution and evolution are
given:
- old container = bugfixes, improvements (TC3.2)
- current container = developement (Catalina)
- new container(s) = proposals (whatever you want for 5.0)

> >And for once, so, my votes are in disagreement with you, Jon... :)
> >As one of the people behind the scenes since before each of
> >you got here, I believe my vote counts, and now, please prove me wrong.
> 
> I don't want to appear as a someone disturbing the Tomcat Project,
> it's really sad to see that Jon show as a personal attack some
> answers on TC 3.3.

Your comments were to the overall Jakarta and XML projects, and being a
father for both of them, it made me feel so sad. As now taking you an
example on my email makes you feel sad. With one line it's like you
washed away years of work and commitment of many people including me.
With one line I washed away your involvement on this project...

> I propose to commiters to vote to drop my COMMITER STATUS.

And I'm sorry, but I'm going to vote -1 on this. What we did in the last
years stays there in the records, no matter what we say. Our work and
commitment on the project was untouched by your one line, you invaluable
contribution on packaging and distributing was untouched by my one line.

> I'm sorry but English is not my primary lang, and I couldn't really express
> 'le fond de ma pensée' on this.

English is not my primary language too, and many many times I can't
express what I feel exactly. But I've been here long enough to see that
no matter what we say around here, what lasts is our contributions to
the project. And I've been here long enough to know how to understand
and digest flamewars Where would I be now if I dropped out when Ed
Korthof wrote me and Stefano "Enjoy your cathedral" two years ago?

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

java.lang.UnsatisfiedLinkError: init

[Harvu, Jamuna S]

Hello Mr. McClanahan and thanks   advance for your  prompt answer,

My applet code needs to use javascript
functionality for navigating through 
parent and child windows.
When I try to include the java40.jar in
my classpath and also in the makefile,
 and then try to compile using make , I
get the following  error :


  java.lang.UnsatisfiedLinkError: init
at java.util.zip.Inflater.(Compiled Code)
at java.util.zip.ZipFile.getInputStream(Compiled Code)
at sun.tools.java.ClassFile.getInputStream(Compiled Code)
at sun.tools.javac.BatchEnvironment.loadFile(Compiled Code)
at sun.tools.javac.BatchEnvironment.loadDefinition(Compiled Code)
at sun.tools.java.Environment.loadDefinition(Compiled Code)
at sun.tools.java.Environment.loadDefinition(Compiled Code)
at sun.tools.java.Environment.loadDefinition(Compiled Code)
at sun.tools.java.ClassDeclaration.getClassDefinition(Compiled Code)
at sun.tools.javac.SourceClass.checkSupers(Compiled Code)
at sun.tools.javac.SourceClass.resolveTypeStructure(Compiled Code)
at sun.tools.javac.SourceClass.basicCheck(Compiled Code)
at sun.tools.java.ClassDeclaration.getClassDefinition(Compiled Code)
at sun.tools.javac.Main.compile(Compiled Code)
at sun.tools.javac.Main.main(Compiled Code)
error: An error has occurred in the compiler; please file a bug report
(http://java.sun.com/cgi-bin/bugreport.cgi).
1 error
*** Error code 1
make: Fatal error: Command failed for target `dro.jar'


   I have been seeking help from various sources. Could you
PLEASE spare a few moments of 
   your precious time and help me out ?


  Thanks again for your time and information.


  Jamuna Harvu.

 

Re: Fuck It.

[Pier P. Fumagalli]

Sam Ruby wrote:
> 
> Pier Fumagalli wrote:
> >
> > So, here I stand, my vote is a big -1 on a 3.3 as a newly
> > architected servlet container
> 
> Pier, I beg of you to reconsider.

Read my email in detail... Read that phrase. I don't vote -1 on 3.3. I
vote -1 if 3.3 is based on a new architecture would introduce more bugs
and differences as 4.0 is doing.

> I was not present in the ApacheCon in 1998.  Nor was I in the room when the
> Jakarta decision was made.  Nor was I on the state at JavaONE, when
> Patricia Sueltz made the announced with you, Jon, Stefano, and Brian.

I love myself :) Sometimes I can just be sooo poethic :) :) :)

> I can tell you that from my perspective, after all that transpired - and a
> merge twelve months ago - Jakarta Tomcat was hardly an open source project.
> It took a lot of hard work to make it open and viable.  And a lot more that
> those four mentioned above were involved.

No, I disagree. I might have not contributed to the Tomcat 3.x tree
(hey, I'm stupid, I can't understand that code, I admit it), but the Sun
folks - including Costin - were always very open and tried hardly to
build this community. And they succedeed, we wouldn't be here arguing
about this whole mess if they didn't.

> Pier, take a step back.  Look at where servlets were as a technology two
> years ago.  One year ago.  Today.  Project where you think they will be one
> year from now, two years from now.  Do you really believe that irreparable
> harm is going to come from today's explorations and fleshing out possible
> alternatives - particularly since this is all being done in the open and
> under a license that would very much encourage code sharing and reuse?

No, again, read my posts on this topic Sam, I'm not asking anyone to
fork or go away. Shit, all I'm saying is that we decided that Catalina
was the container for 4.0, and that Tomcat 3.2 and its container would
have been a bug-fix and performance increase only.
I don't want a fork. All I'm saying is that, if 3.3 is -as I see it- a
major rearchitecture of the container that would introduce more bugs,
and support issues, that should be done as a proposal, to be evaluated
for Tomcat.NEXT.

> I very much believe the contrary - that the only potential irreparable harm
> that can come from this is the stifling of innovation.

And I'm not here to stop innovation. Shit, I didn't say no when we
dropped JServ in favour of Tomcat, even if it was MY baby. And I'm not
saying NO to other proposals for the next generation of Tomcat.

> Pier, Is now the right time, and is this the right way to fight this
> particular battle?

No, it's not... It's too late, and I already written "closed" on this
chapter at least 2 times. But it seems that part of this community is
not considering the "closed" word with the same strength another part
does

> I don't personally care whether any particular change made by any committer
> is described as a bug fix, a feature enhancement, or an architectural
> change - these descriptions, after all, are subjective.

Bug fix and feature enhancements are one thing, and architectural
changes ARE another... You IBM folks taught me that when I was working
there :) :) 

> My suggestion is that discussion returns to the technical merits of the
> various approaches, and exploration of ways in which the various branches
> can exploit and cannibalize the best ideas from each other.  Independent of
> the labels currently associated with each proposal.

Agreed. And AGAIN, all I say, if anyone wants to make a proposal for a
new Servlet Container, please, our CVS is open, the mailing list is
here, and we're all going to examine it for Tomcat.NEXT. But now 3.x is
bugfix only and 4.0 is development, wasn't this what we agreed upon?

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: Fuck It.

[Pier P. Fumagalli]

Sam Ruby wrote:
> 
> As Pier recently said on another mailing list "You can't stop open source
> developers...".

And I'm not here to stop them... Proove me wrong :) :) :)

> Is this really what everybody wants?  I'm sure it could be made to happen.
> And quickly upgraded to the latest servletapi.  And gather a substantial
> following.
> 
> Obviously a fork is a nightmare scenario.

Not _everytime_ (from the different *BSD forks something good came out,
FreeBDS) :) :)

> It is an ironic twist.  One has to wonder if such a fork is inevitable.
> Not for any technical reason.  But rather because those that worked so hard
> to create the place where everyone was to come together have become
> intolerant of exactly the spirit that makes open source successful.
> Innovation.  Exploration.  Revolution.  And, yes, dead ends.
> 
> My recommendation: put your energies into the proposal that most gets your
> juices flowing.  Keep the discussion to the technical merits.

That's what I keep saying from months, Sam. I keep saying let's fix the
bugs on 3.x and improve its performance. You don't want to do that? Help
us develop 4.0 and Catalina. You don't even want to do that either?
Create a proposal and work on it, I'll be the first to analyze it when
Tomcat.NEXT comes along.

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: Fuck It.

[Pier P. Fumagalli]

GOMEZ Henri wrote:
> 
> It's more a question than a request. I was really sad with Pier
> reaction. I really don't want to appear as a someone disturbing the
> Tomcat Project.

As I don't want to appear as someone who gave up Jakarta and XML to Sun
and IBM respectively... And that's what you said...

> As many others today, I wonder about the future of OpenSource and
> projects independance when corporations like IBM and Sun put (or hire)
> so many of the core developpers.

You can't blame a company for saving my butt when I was about to be torn
away from what I did in the last years... And everything is going to be
great until developers keep their own integrity towards open-source,
even sometimes going against their employer. I'm not afraid to start a
war at Sun if that's nedeed, as I'm scared to start one here. But
sometimes I need to do it.

> It's a great thing that such companies goes to opensource.
> 
> But if major decisions are allready taken behind the scene, there is a real
> risk for OpenSource.

Don't worry. No decisions are taken "behind the scenes" in some
corporate offices by managers and such. I wouldn't be working in one of
them :) :) :)

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: Tomcat session replicator

[Jason Brittain]

Hi guys..

I'm one of the other folks that have voiced some desire to implement
distributed sessions and distributed servlet container functionality in
Tomcat (although I only want to work on 4.0!).  I'd love to collaborate
with others on the design and implementation.  More below:

Craig R. McClanahan wrote:

> 
> The biggest problem I have with integrating session replication into 
> AJPxx is that it means this will only work if you're running Apache 
> connected, versus when Tomcat is running stand alone.  Even in that 
> environment, does the Apache instance really need to know what's going 
> on?  Wouldn't it just be a case of updating the cookie to include the 
> new "router" information when you migrate a session from one JVM to 
> another?
> 
> Personally, I'd like to see a session migration mechanism that works 
> between the "back end" Tomcat instances.  There are probably few 
> enough of those (in most use cases) that you can maintain a spiderweb 
> of persistent connections that is used only to communicate session 
> migration information.
> 

I'm still wrestling with how it's best designed, but I agree that it 
probably has nothing to do
with AJP.  It should work no matter what web server you're using.  I 
believe that it can.

Also, the idea of a spiderweb of TCP connections is what I had in mind 
also, since then if one
machine goes down or is unreachable, the system knows almost 
immediately, and can
take appropriate action with the remaining servers in the cluster.  I 
like it.

> Just as a small technical detail -- the servlet spec says that an 
> application *must* run within a single JVM unless it marks itself as 
>  in the deployment descriptor -- don't forget to check 
> for that.
> 

Yep, this is a feature of "distributed servlet containers" as defined by 
the Servlet 2.2 and
2.3 specs.

> As to what version of Tomcat to work on, no matter what the future 
> holds it seems like the current 3.2 code base is not really 
> appropriate for major innovation.  I would only point out that the 4.0 
> architecture has an interface (org.apache.catalina.Store) behind which 
> session migration stuff can easily be hidden -- as well as support for 
> persistence, swapping, and other advanced features -- without 
> modifying the remainder of the servlet container. 
> 

I'm looking into that already, and have been following all discussion about
making (any version of) Tomcat distributable.  But, I haven't begun
designing/coding yet (mostly due to lack of time).


Anyone who has ideas: I'm listening, and I'd sure like to discuss
how you think we should make this work.

-- 
Jason Brittain
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org

Re: Tomcat 3.3

[Craig R. McClanahan]

Andy wrote:

>
> Maybe the best thing would be if one of the commiters gave me a piece of their
> bug they don't feel like finding.
>

The interim bug reporting system we are using  has tons of
outstanding bugs.  I would not bother with the Tomcat 3.1 bugs -- anyone who is using
3.1 is strongly urged to upgrade to 3.2.  The easiest way to find them is go to the
Viewer, then "Display all bug reports in a specific project", then select "Tomcat".
(The 4.0 bugs are supposed to be under "Catalina" and "Jasper", but not everyone does
it that way, so you have to check the "Tomcat" list as well.)

Everyone using 3.2 or 3.2.1 in production would be incredibly appreciative if bugs on
it were found and fixed, and a 3.2.2 release was prepared.  Submit a few bug fixes, and
you'll probably find yourself nominated as a committer if you're interested :-).

As for future versions, it should be obvious what I spend my time on -- everyone of
course is free to do what they want in that respect.

>
> >From your comments I have a question:  Has 4.0 been voted on ?  ( if this is
> politically charged please read this in the context it is intended which is NOT
> controversy, I'm a programmer not a political type)...  If it will indeed be
> released and maintained and contributions are welcome than maybe that's a good
> starting point.
>

Yes, in September 2000 the vote to use Catalina as the basis for Tomcat 4.0 took place
on the TOMCAT-DEV mailing list.  The votes would be in the mailing list archives (and
yes, the web site can do a better job of pointing people to where various archives of
TOMCAT-DEV can be found -- updating the web site is yet another useful way to
contribute).

Welcome!

>
> Thanks,
>
> Andy
>

Craig


>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com

Re: Fuck It.

[Pier P. Fumagalli]

Costin Manolache wrote:
> 
> > they were. Jon, you might
> > be annoying and obnoxious at times, but those kids
> > don't even care about reading what you're writing...
> 
> Too bad all this is on an open mailing list where the
> mails can be read again and again - and people may
> form their own opinions.

Oh, that's why I flame people on the ML and not mailbomb them privately!

> > _exactly_ happening: from what I see in the commit
> > messages, it seems to me
> > that even if on an evolutionary track, the container
> > structure is completely
> > different between 3.2 and 3.3. The architecture is
> > almost as different as
> > 3.2 and 4.0.
> 
> It's sad that on this list so many people are experts
> in spinning facts and politics.

And surely you're a master on this... How you're able to twist facts and
promises is somehow intriguing.

> This is a _false_ statement, or a gross
> misunderstanding of what "architecture" means and what
> "refactoring" means.
> 
> The _architecture_, _ideas_ and _patterns_ in tomcat3
> are the same - the code, code organization changed.

Doesn't seem like that to me...

> I just had to deal with a major change in Apache2.0 -
> it seems some time ago they reorganized the whole
> tree,
> moved apr in a different repository, etc. Is this a
> different architecture ?

Apache 2.0 is not yet OUT in final... Try to go down in HTTP land and
build a 1.4 on the ashes of 1.3 but with a whole new architecture.. I
wonder what the peeps down there would say...

> > others, they are all so busy in rearchitecting the
> > container, and
> > back-porting features from 4.0 that they don't have
> > time to maintain the old
> 
> That's even worse - all the flames that start up
> whenever code from 4.0 is reused in 3.x. What's the
> problem ??? Are you afraid of "featurism" ( i.e. are
> good for 4.0 but bad for 3.3 ) ?

That's TWISTED. Holy shit, you don't even care about supporting our
users. Jesus Lord! Every single feature you back port from 4.0 will need
to be supported in BOTH 3.3 and 4.0 and that means doubling our efforts
in bug tracking and issue solving.

You're not even doing that for 3.2, why the hack would you care to do it
for 3.3. The 3.2.1 release, MAJOR SECURITY HOLES was made by Craig while
dodging a M5 release for Catalina... DO YOU SEE THAT? YOU ARE THE FIRST
ONE WHO FUCKING DROPPED 3.2 TO GO ON 3.3.

> Take a look at "changes" in tomcat 3.3. It's a
> description of all the "evolutions" from 3.2 to 3.3.
> Too bad I haven't done the same when I worked on 3.2.
> 
> You can also take a look at commit messages - yes,
> some are big ( code moved around for better
> organization ),
> and some deprecated interfaces are removed ( is this
> an "architecutre change" ? They were introduced in
> 3.2, 3.1 or 3.0 to help refactoring, and "evolved"
> into something better ).

Costin, if you want to work on an evolutionary track, go on and help
Craig in supporting 3.2 and making it better. If you want to go on your
own do a 3.3, I don't care what you do in your time. But my -1 stands on
3.3 and +1 on bugfixing 3.2.

You didn't prove me wrong.

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: TC 3.2 - Better logging messages when something bad happens?

[Craig R. McClanahan]

David Rees wrote:

> Replying to my own message here,
>
> Anyone have any technical comments on the message below?  I think that
> printing a stack dump in this case can be very useful, but someone else may
> have a different view.
>

For developers, you certainly want to be able to see the stack traces.  However,
many developers do *not* want such cruft showing to users -- so it was made
configurable (thanks to the efforts of Larry Isaacs) -- see the 
attribute called "showDebugInfo" in the conf/server.xml file.

It looks like this case was missed.  I'm +1 on adding a stack trace, but it
should be made conditional just like other stack traces are.

>
> Thanks,
> Dave
>

Craig


>
> > -Original Message-
> > From: David Rees [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, December 19, 2000 8:53 PM
> > To: Tomcat Dev List
> > Subject: TC 3.2 - Better logging messages when something bad happens?
> >
> >
> > While doing some development, I started getting this Exception:
> >
> > org.apache.jasper.JasperException: error in invoking method
> > at
> > org.apache.jasper.runtime.JspRuntimeLibrary.createTypedArray(JspRu
> > ntimeLibra
> > ry.java:353)
> > at
> > org.apache.jasper.runtime.JspRuntimeLibrary.introspecthelper(JspRu
> > ntimeLibra
> > ry.java:194)
> >
> > I was trying to populate a bean with an array from a form, but
> > the bean was
> > throwing an exception during the population.  The confusing part was that
> > there was nothing in any logs to help me figure out what was going on
> > because the JspRuntimeLibrary was catching the exception and
> > suppressing the
> > real error message.
> >
> > Simply printing out a stack trace like this helped me find the
> > problem in no
> > time (diff against TC 3.2.1 release):
> >
> > ---
> > ./src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java.orig   Tue
> > Dec 19 20:51:23 2000
> > +++ ./src/share/org/apache/jasper/runtime/JspRuntimeLibrary.java
> >   Tue
> > Dec 19 20:38:50 2000
> > @@ -349,6 +349,7 @@
> > method.invoke (bean, new Object[] {tmpval});
> > }
> > } catch (Exception ex) {
> > +   ex.printStackTrace();
> > throw new JasperException ("error in invoking method");
> > }
> >
> >
> > Is there any reason to not include a similar patch in the official tree?
> >
> > -Dave
> >

Re: Fuck It.

[Pier P. Fumagalli]

Nacho wrote:
> 
> I believe that architecture of 3.3 is right one.

And you're free to believe what you want. As I am...

> Why we are not talking about that ?

Because we already did, we closed that discussions months ago when the
first 4.0 proposal came out and was voted upon. Where was your -1 when
the decision was made? Sorry, but you're too late now.

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: Fuck It.

[Pier P. Fumagalli]

Jon Stevens wrote:
> 
> Therefore, as long as 3.x does not have support for 2.3, it is a dead end
> solution IMHO and adding support for 2.3 within 3.x would be a duplication
> of effort since we already have a 2.3 container (hence the reason why I am
> -1 and why Costin has already stated he plans to fork that addition
> somewhere else).

Welcome back, my friend :) :) :)

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: help EJB

[Falcon cheetah]

 Tomcat does not handle EJB and there is no way to make it do that unless you add some extension server, something like the one from this site. www.ejboss.org Try it, it should work with Tomcat.
 
Ahmed Alawy.
  Boby Micheal <[EMAIL PROTECTED]> wrote: 




 
We are soft ware developers(Calrion systems (P)Ltd. , Cochin ,Kerala, India).Now we are developing application in EJB under weblogic server. We required  to deploy the application (what we developed in EJB under weblogic server)in Tomcat server. Please give me a step by step Instructions for the deployment of  EJB application in Tomcat server
 
1.Will tomcat server support EJB? 
2. Is it required any additional support program, to support EJB in Tomcat,?  
Boby Michael
 Do You Yahoo!?
Yahoo! Shopping - 
Thousands of Stores. Millions of Products.

Re: Tomcat 3.3

[Pier P. Fumagalli]

"Craig R. McClanahan" wrote:
> 
> For the record, Sun hired me in March, 2000, so that I could work on Tomcat full
> time instead of it just being a hobby (as it was when the original code was
> written).  :-)

And thank you for not accepting my offer at that time, otherwise you
would be working on Business Processes right now, and not on Catalina...

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

BugRat Report #648 has been filed.

[BugRat Mail System]

Bug report #648 has just been filed.

You can view the report at the following URL:

   

REPORT #648 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: medium
Severity: critical
Confidence: public
Environment: 
   Release: Tomcat 3.2
   JVM Release: JDK 1.3
   Operating System: Windows NT4.0
   OS Release: NT4 service Pack 6
   Platform: Windows

Synopsis: 
When a connectino is reset, tomcat should retry sending the response object instead of 
re-executing the entire jsp.

Description:
When a when a jsp response is asked to be resent because of a "connection reset by 
peer" only the response object should be resent again. Currently the JSP is 
re-executed, which can lead to unpredictable results if the jsp is requesting or 
changing data on a 3rd process. Consider:

jsp code:


  someServer = (ServerInterface)Naming.lookup(serverURL);
  someServer.incrementConnections();


If the jsp is executed again because of a connection reset, then incrementConnecions() 
will be executed again. This is not desired behavior.



Title: 
BugRat Report #
648





BugRat Report #
648




Project:
Tomcat


Release:
Tomcat 3.2




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
medium


Severity:
critical




Confidence:
public





Submitter:
Christian Mattix ( [EMAIL PROTECTED] )

Date Submitted:
Dec 21 2000, 03:25:36 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

When a connectino is reset, tomcat should retry sending the response object instead of re-executing the entire jsp.


 Environment: (jvm, os, osrel, platform)

JDK 1.3, Windows NT4.0, NT4 service Pack 6, Windows



Additional Environment Description:





Report Description:

When a when a jsp response is asked to be resent because of a "connection reset by peer" only the response object should be resent again. Currently the JSP is re-executed, which can lead to unpredictable results if the jsp is requesting or changing data on a 3rd process. Consider:

jsp code:


  someServer = (ServerInterface)Naming.lookup(serverURL);
  someServer.incrementConnections();


If the jsp is executed again because of a connection reset, then incrementConnecions() will be executed again. This is not desired behavior.





View this report online...

Re: Fuck It.

[Pier P. Fumagalli]

Christopher Cain wrote:
> 
> "Pier P. Fumagalli" wrote:
> 
> > Where were you KIDS when we were fighting the big
> > corporations to have them looking into open source, to contribute
> > significant parts of their technologies to the Foundation, where were you
> > while we were changing this world? You were home, and one day, you looked up
> > on your browser, saw a thing called Jakarta and started weening if things
> > weren't as nice as you wanted them.
> 
> Nice. Now as a newcomer who wishes to give back to the community, do you think
> that this makes me feel more welcome or less? Why don't you just post a big sign
> that says, "If you were not here in the beginning, you are irrelevent. Go Away."
> That would probably be a slightly more effective means of keeping new developers
> away than simply making fun of them.

That was not my intent, sometimes I just get too epic :) :) :)
What I wanted to say is that when decisions are made, even if in an open
source project, you have to stick with them. That's why new developers
are "hinted" to read the list for a while before coming along and trying
to revolution the whole thing.

> I assume that I fall under that auspise since I also called Jon out directly. And
> yes, as I stated in no uncertain terms, many times I do _not_ care about reading
> what Jon writes. Many of his posts are so demeaning to whomever they addressed
> that it is difficult to read them all the way through, quite literally. It makes
> me uncomfortable to see well-meaning people treated like that. And trust me, I
> received enough private mail on the subject to assure you that I am far from the
> only one. The bottom line is, Jon is currently getting no more and no less than
> he gives everyone else.

And that's wrong... Why sending you email privately? Come on out, my old
flameproof vest is on, and kids, you don't even know how much I can
take.
Get out, tell me I'm an ignorant idiot (Duncan, what was that? Arrogant
Pig? I believe that's how you've been called somewhere else! :) :)

All I ask you guys it to prove me wrong. Prove me that 3.3 is not a new
servlet container, prove me that it's just bugfix and performance. Give
me some damn facts.

> > hear that people like Paul Frieden (the only person that did put some salt
> > in what he said)
> 
> Hey, thanks =)
> 
>  little kiddie who stumbled across Jakarta a mere six months ago and can therefore
> not possibly have anything meaningful to say>

Did I overlook one of your emails? Subject please, since you posted 6
times on this mailing list and the first time in september. Were you
around when 4.0 was voted on? 

> > As one of the people behind the scenes since before each of you got here, I
> > believe my vote counts, and now, please prove me wrong.
> 
> This post is a better example of my original point than I could possibly dream
> up, and it has nothing to do with the technical merits of the architecture. Sam
> is right on the money. Do you think that this little scuttle over 3.x vs. 4.x
> will be too terribly important six months from now? Probably not. What will be is
> the one or two or ten developers who eventually decided to contribute their
> limited time and resources to a different OSS project because this one is getting
> too contentious for their tastes. There are other great projects out there to get
> involved in, and whether or not a project has some fun people to work with, as
> opposed to everyone treating each other like shit when they disagree, is
> definitely a consideration for most of us.

Go back, read the archives and take a look to what I said when we voted
on tomcat 4.0. Then go again and read what I proposed Costin for his new
servlet container.

Cute, now I'm the bad guy. I like this position... You still didn't
proove me wrong.

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: Tomcat session replicator

[Craig R. McClanahan]

Jason Brittain wrote:

> Hi guys..
>
> I'm one of the other folks that have voiced some desire to implement
> distributed sessions and distributed servlet container functionality in
> Tomcat (although I only want to work on 4.0!).  I'd love to collaborate
> with others on the design and implementation.  More below:
>

At ApacheCon Europe (it was also presented in Orlando last March, but I missed
it then), there was a very interesting session by Theo Schlossnagle
<[EMAIL PROTECTED]> about the Backhand Project, which is focused on providing
load balancing support for Apache as a web server.  There are some good ideas we
can glean from this approach (and possibly even some code???).  More info at:

http://www.cnds.jhu.edu/~jesus/

Craig

Re: Tomcat 3.3

[Pier P. Fumagalli]

Andy wrote:
> 
> From your comments I have a question:  Has 4.0 been voted on ?  ( if this is
> politically charged please read this in the context it is intended which is NOT
> controversy, I'm a programmer not a political type)... 

Yes, Tomcat 4.0 as been voted on months ago and all -1s have been
converted to +0s after a short "battle".

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

Re: Future

[cmanolache]

> > Speaking of future, the same thing can happen when the next servlet spec
> > is released - and again you could use tomcat3.3 to have a smooth future.
> > I know how painfull it is to upgrade a production server - how many small
> > things will stop working and many things will be different.
> 
> And I'm 100% sure you will be able to use 4.0 as a base for future Servlet
> API's as well. What is your point here?

Upgrading from 2.0 to 2.2 isn't so easy. As of "using 4.0 as a base" -
it's a difference between that and just plugging in a module ( and having
even multiple versions of the API in use at the same time - as you upgrade
and test your applications with the new APIs). That's part of the design.

( plus the preference that some people seem to have with throwing away
and rewriting in a "better" way - the history tends to repeat itself )


> You can't promise that for Tomcat 3.3. If you go away, there is absolutely
> no promise that someone else will pick up and implement whatever the latest
> spec is on top of Tomcat 3.x.

Do you believe in open source ? 

It seems to me thare are quite a few people not paid to work on 3.3 ( I
would say the reverse is true - actually paying a price for working on
it), yet it seems to move on. 

I heard the same argument about Linux BTW, but that doesn't make me start
using Windows 2000. ( and I'm using Emacs, even if the original author
stoped working on it many years ago )


> However, you CAN promise that someone will do it on Tomcat 4.x because that
> is the direction that Sun is going and Sun will pay someone to do it as long
> as J2EE is around (which I don't see it going away any time soon, if
> anything, it is getting larger and more important with the .NET crap).

I think Sun does the right thing letting the open source work, and I hope
it'll continue to do so.

If you remember, the comunity is more important than the product - and
that used to be the power behind open source, not the pay you get. 

I do believe tomcat4.0 has a future too - but that's because of the
individuals behind it, and will have a future as long as those individuals
will be there or other will take their places.


> > as much as possible from 4.0 - so whatever will happen in the future in
> > 4.0 can happen in 3.3 too )
> 
> Very true, but not under the ASF because you will be forked elsewhere as you
> have already stated.


Even if ASF is "forking me", the code will continue to exist and probably
will keep working.


> from providing one as well. Competition is good. I like forks and your fork
> would be the first fork of the Tomcat platform. I am totally +1 on that
> without a doubt because it proves that the people here at the ASF are
> producing quality code.

The only problem is that I don't like forks. The only reason I have for
forking is that the people there at ASF ( you, Pier, Craig ) are asking
and forcing me to do so. 


Costin

Re: cvs commit: jakarta-tomcat/src/doc NT-Service-howto.html

[Craig R. McClanahan]

[EMAIL PROTECTED] wrote:

> marcsaeg00/12/21 11:24:21
>
>   Modified:src/doc  Tag: tomcat_32 NT-Service-howto.html
>   Log:
>   Added notice about the NT service termination feature of JDK1.3
>
>   Revision  ChangesPath
>   No   revision
>
>
>   No   revision
>
>
>   1.2.2.4   +13 -4 jakarta-tomcat/src/doc/NT-Service-howto.html
>
>   Index: NT-Service-howto.html
>

Congrats on your first check-in :-).

The CVS check-in message got delayed this time because I forgot to make one change on 
the mailing list so that your
commit messages would flow directly to TOMCAT-DEV.  This has been fixed, so the future 
ones should flow immediately
(although sometimes the server gets pretty busy and CVS commit messages take a while).

Craig

RE: Fuck It.

[Nacho]

> > Why we are not talking about that ?
> 
> Because we already did, we closed that discussions months ago when the
> first 4.0 proposal came out and was voted upon. Where was your -1 when
> the decision was made? Sorry, but you're too late now.
> 

Perhaps!! check that
http://marc.theaimsgroup.com/?l=tomcat-dev&m=86951938815078&w=2 .

Of course I have no problem with the actual status-quo, and this a was
-0 no a -1 :-), but at least i have a clean soul..:-)


>   Pier
> 
> --
> Pier Fumagalli <[EMAIL PROTECTED]> 



Saludos ,
Ignacio J. Ortega

[tomcat-4.0] Session Creation Slowness

[Jon Stevens]

Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
of code is causing the slowness that I keep reporting here and I have now
found it...

Log.note ("RunDataFactory: 11");
// Get the HttpSession object.
data.setSession ( data.getRequest().getSession(true) );
Log.note ("RunDataFactory: 12");

As you can see above, essentially, all that is happening is that I'm storing
an instance of the HttpSession object within the RunData object. Marking
things as "true" causes the redirect to happen, so there is another
request...

[Thu Dec 21 13:34:15 PST 2000] -- NOTICE  -- RunDataFactory: 11
[Thu Dec 21 13:35:01 PST 2000] -- NOTICE  -- RunDataFactory: 12
...
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 11
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 12

As you can see above the first request through this code takes bloody
FOREVER and the second one is quite fast.

The really *INSANE* part about all of this is that people have checked
Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
any real slowness at all (approx 4-5 seconds).

So, Craig, can we please try to do something about this? There has got to be
something wrong with either my setup or something else (I really don't think
this is entirely a classloader issue anymore). I also have this great
slowdown on MacOSX as well.

If you want to duplicate it, you can check Scarab out of CVS and do it
yourself. I have re-done the CVS tree and it is very easy to get things up
and running (even without a database installed...just ignore that part of
the README.txt file).



thanks,

-jon

Re: Tomcat 3.3

[Jon Stevens]

on 12/21/2000 1:13 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> updating the web site is yet another useful way to
> contribute).

It is even documented on how to do that!



:-)

-jon

-- 
Honk if you love peace and quiet.

Re: F... It.

[cmanolache]

> > 
> > The future of Tomcat 3.3 seems to be outside Apache now.
> > It's really sad.
> 
> Sorry, but that's not what I said Henry. Last month I even came up with
> a proposal that got accepted (but never turned to reality) on how to
> handle this situation... But it seems to me, that everyone here is more
> interested in flaming others rather than read and discuss... And this
> sucks...
> 
> I'm not saying to kick the 3.3 proposal out, I'm just saying that, from
> what I see 3.3 is as different from 3.2 as 4.0 is, it is a different
> container. And because of this, rules for revolution and evolution are
> given:
> - old container = bugfixes, improvements (TC3.2)
> - current container = developement (Catalina)
> - new container(s) = proposals (whatever you want for 5.0)

Again ??

Then what about tomcat3.2 - is it as different from 3.1 as 3.3 is from 3.2?

Is there any change in 3.3 that you feel is wrong ? You can send your -1
now, with the technical arguments for that.

I already accepted the -1 on implementing Servlet2.3 - even if it wasn't
on technnical but political reasons, and I'm open to any other changes.

Take the "changes" file, find something you feel is "making 3.3 as
different from 3.2 as 4.0 is" and send it to the list. 

Evolution doesn't mean everything is frozen and you make only small
changes here and there. And making tomcat3.3 faster, cleaner and more
modular than 3.2 requires a number of changes.

Generic statements are easy to make - what do you think is part of 3.2
architecture and isn't part of 3.3 ? Yes, some interfaces were removed -
because they were duplicating what Interceptor is doing ( and the
interfaces were introduced after 3.1 for the same reason, making the code
cleaner ). 

It's one thing to make the code more modular and cleaner, and another
thing to "change the architecture" and the design patterns.
  
Costin

Re: Fuck It.

[Pier P. Fumagalli]

Nacho wrote:
> 
> > > Why we are not talking about that ?
> >
> > Because we already did, we closed that discussions months ago when the
> > first 4.0 proposal came out and was voted upon. Where was your -1 when
> > the decision was made? Sorry, but you're too late now.
> >
> 
> Perhaps!! check that
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=86951938815078&w=2 .
> 
> Of course I have no problem with the actual status-quo, and this a was
> -0 no a -1 :-), but at least i have a clean soul..:-)

Great... You voted -0. Ok, so you're part of that decision and now stick
with what was agreed...

Pier

--
Pier Fumagalli <[EMAIL PROTECTED]> 

RE: Fuck It.

[Remy Maucherat]

Quoting Nacho <[EMAIL PROTECTED]>:

> Please be carefull when you write something about anybody, have a look
> at commits please... Henri, P. Delisle and I are the only ones here
> that
> had contribute to ALL present versions of Tomcat, *ALL* dont forget
> that, and i feel involved on ALL of them, if this is a waste of my poor
> capacities , well no problem i do with my time what i want , i do not
> admit opinions on that..

Yes, that's 100% true. I can't figure out why Pier included you in this.

> You were kids, are kids,
> and will be kids, regardles of your age, if
> you
> continue playing with invaluable items as is the confidence of your
> people ( as i am like it or not, i'm in your side dont forget that ).
> And you are losting my confidence with every flame you put in public
> lists. We are all here for another reason that hear you scream.
> 
> I'm too old ( 35 FYI ) to believe that the volume of your voice gives
> you more reason than i have, no.
> 
> I believe that architecture of 3.3 is right one. Why we are not talking
> about that ? because there arent technical arguments against my
> believes
> ? are you truly sure that tomcat 4.0 is right when perfomace comes to
> discussion ?

As far as I know, someone has still to point out why Catalina would be 
inherently slower than TC 3. I really can't figure that out.

Is it the intuitive feeling that C-style design + C looking code performs 
faster that object oriented code with a nice design ?

I don't see any optimization in TC 3 which couln't be intrduced in Catalina, 
whether it's the delayed char conversion or the recyclable buffers.

Remy

Re: Fuck It.

[Remy Maucherat]

Quoting Costin Manolache <[EMAIL PROTECTED]>:

> That's even worse - all the flames that start up
> whenever code from 4.0 is reused in 3.x. What's the
> problem ??? Are you afraid of "featurism" ( i.e. are
> good for 4.0 but bad for 3.3 ) ? 
> 
> It's open source code, and it's right to reuse it
> instead of reinventing the wheel. If someone writes a
> JAAS authenticator for 4.0 - why not making it
> available to 3.3 users too ?

For the same reason the JServ guys aren't making them available for JServ, I 
suppose.

> After all, if 4.0 is "better", that's because of the
> architecture, not because of the features - or else
> next spin will be that people should use 4.0 because
> of all the features. 

That has been one of your three arguments for a while.
Actually, I think that right now TC 3.3 has an edge feature-wise because of the 
web connectors.

Remy

Re: [tomcat-4.0] Session Creation Slowness

[Craig R. McClanahan]

Jon Stevens wrote:

> Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
> of code is causing the slowness that I keep reporting here and I have now
> found it...
>
> Log.note ("RunDataFactory: 11");
> // Get the HttpSession object.
> data.setSession ( data.getRequest().getSession(true) );
> Log.note ("RunDataFactory: 12");
>
> As you can see above, essentially, all that is happening is that I'm storing
> an instance of the HttpSession object within the RunData object. Marking
> things as "true" causes the redirect to happen, so there is another
> request...
>
> [Thu Dec 21 13:34:15 PST 2000] -- NOTICE  -- RunDataFactory: 11
> [Thu Dec 21 13:35:01 PST 2000] -- NOTICE  -- RunDataFactory: 12
>

This is the first session create since the webapp was started, right?
Currently, that is when the RNG is initialized.

> ...
> [Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 11
> [Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 12
>

And this is the behavior you would see after the first one.

>
> As you can see above the first request through this code takes bloody
> FOREVER and the second one is quite fast.
>
> The really *INSANE* part about all of this is that people have checked
> Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
> any real slowness at all (approx 4-5 seconds).
>

That's definitely strange ... 4-5 seconds is my experience even on much slower
hardware, on both 1.2.2 and 1.3.

>
> So, Craig, can we please try to do something about this? There has got to be
> something wrong with either my setup or something else (I really don't think
> this is entirely a classloader issue anymore). I also have this great
> slowdown on MacOSX as well.
>

This part isn't.  Aleady on my TODO list is moving the RNG initialization to
webapp startup time -- that will normally hide it for a 4-5 second delay, but
certainly won't fix a 45-second delay.

>
> If you want to duplicate it, you can check Scarab out of CVS and do it
> yourself. I have re-done the CVS tree and it is very easy to get things up
> and running (even without a database installed...just ignore that part of
> the README.txt file).
>
> 
>

You mean it's not just "check out, compile, and run"???  :-) :-)

Will do.


>
> thanks,
>
> -jon

Craig

BugRat Report #649 has been filed.

[BugRat Mail System]

Bug report #649 has just been filed.

You can view the report at the following URL:

   

REPORT #649 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: webbug
State: received
Priority: high
Severity: serious
Confidence: confidential
Environment: 
   Release: tomcat3.2.1
   JVM Release: jdk1.2.2
   Operating System: none
   OS Release: none
   Platform: none

Synopsis: 
Security bug

Description:
Environment:Tomcat 3.2.1 and apache1.3.14

For instance, please access following URL.

http://tomcat.3.2.1/examples/jsp/num/numguess.jsp

 The source code of this JSP can be seen.
 If USERNAME and PASSWORD are included in this source code The third party sees it. 

Title: 
BugRat Report #
649





BugRat Report #
649




Project:
Tomcat


Release:
tomcat3.2.1




Category:
Bug Report


SubCategory:
New Bug Report




Class:
webbug


State:
received




Priority:
high


Severity:
serious




Confidence:
confidential





Submitter:
Tomoaki Okitsu ( [EMAIL PROTECTED] )

Date Submitted:
Dec 21 2000, 04:03:51 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

Security bug


 Environment: (jvm, os, osrel, platform)

jdk1.2.2, none, none, none



Additional Environment Description:





Report Description:

Environment:Tomcat 3.2.1 and apache1.3.14

For instance, please access following URL.

http://tomcat.3.2.1/examples/jsp/num/numguess.jsp

 The source code of this JSP can be seen.
 If USERNAME and PASSWORD are included in this source code The third party sees it. 



View this report online...

RE: [tomcat-4.0] Session Creation Slowness

[Tomas Rokicki]

This is probably due to the new SecureRandom-based session IDs.
There is an option to turn that off somewhere.

-Original Message-
From: Jon Stevens [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 21, 2000 1:47 PM
To: tomcat-dev
Cc: [EMAIL PROTECTED]
Subject: [tomcat-4.0] Session Creation Slowness


Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
of code is causing the slowness that I keep reporting here and I have now
found it...

Log.note ("RunDataFactory: 11");
// Get the HttpSession object.
data.setSession ( data.getRequest().getSession(true) );
Log.note ("RunDataFactory: 12");

As you can see above, essentially, all that is happening is that I'm storing
an instance of the HttpSession object within the RunData object. Marking
things as "true" causes the redirect to happen, so there is another
request...

[Thu Dec 21 13:34:15 PST 2000] -- NOTICE  -- RunDataFactory: 11
[Thu Dec 21 13:35:01 PST 2000] -- NOTICE  -- RunDataFactory: 12
...
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 11
[Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 12

As you can see above the first request through this code takes bloody
FOREVER and the second one is quite fast.

The really *INSANE* part about all of this is that people have checked
Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
any real slowness at all (approx 4-5 seconds).

So, Craig, can we please try to do something about this? There has got to be
something wrong with either my setup or something else (I really don't think
this is entirely a classloader issue anymore). I also have this great
slowdown on MacOSX as well.

If you want to duplicate it, you can check Scarab out of CVS and do it
yourself. I have re-done the CVS tree and it is very easy to get things up
and running (even without a database installed...just ignore that part of
the README.txt file).



thanks,

-jon

Re: Future

[Jon Stevens]

on 12/21/2000 1:44 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

>>> Speaking of future, the same thing can happen when the next servlet spec
>>> is released - and again you could use tomcat3.3 to have a smooth future.
>>> I know how painfull it is to upgrade a production server - how many small
>>> things will stop working and many things will be different.
>> 
>> And I'm 100% sure you will be able to use 4.0 as a base for future Servlet
>> API's as well. What is your point here?
> 
> Upgrading from 2.0 to 2.2 isn't so easy. As of "using 4.0 as a base" -
> it's a difference between that and just plugging in a module ( and having
> even multiple versions of the API in use at the same time - as you upgrade
> and test your applications with the new APIs). That's part of the design.
> 
> ( plus the preference that some people seem to have with throwing away
> and rewriting in a "better" way - the history tends to repeat itself )

This discussion has absolutely nothing to do with 2.0-2.2. It has to do with
the future (see the subject of this email).

The fact of the matter is that the ServletAPI has gone through a good
portions of the changes that it has needed to go through. When 3.0 of the
Servlet API comes out, I'm sure that large portions of code will need to be
re-written (that is the evolution of things) and I'm confident that Sun will
have engineers be around to do that.

>> You can't promise that for Tomcat 3.3. If you go away, there is absolutely
>> no promise that someone else will pick up and implement whatever the latest
>> spec is on top of Tomcat 3.x.
> 
> Do you believe in open source ?

The fact that you are even questioning my belief in OSS, even in a sarcastic
manner, is pretty fucked up Costin.

Especially given that I quit a very successful 120 person company that I
co-founded to go work for an OSS company founded by the founder of the ASF
and you happen to work for a notoriously closed source company. Hello? Where
is the source code to Java, Mr. Sun Employee?

In OSS you can't *count* on anything. We are all volunteers and come and go
as easily as the flames around here.

> It seems to me thare are quite a few people not paid to work on 3.3 ( I
> would say the reverse is true - actually paying a price for working on
> it), yet it seems to move on.

As far as I'm concerned, that is only because you are the primary instigator
on things right now. If you go away, no offense to the rest of the people
with commit access, but I'm pretty certain that 3.x will die off pretty
quickly and the fact of the matter is that the code base is so badly
documented that it is hard for new people to get up to speed on it and that
in itself would prevent others from even wanting to start to work on it (it
did so with me, that is for sure).

>> However, you CAN promise that someone will do it on Tomcat 4.x because that
>> is the direction that Sun is going and Sun will pay someone to do it as long
>> as J2EE is around (which I don't see it going away any time soon, if
>> anything, it is getting larger and more important with the .NET crap).
> 
> I think Sun does the right thing letting the open source work, and I hope
> it'll continue to do so.
> 
> If you remember, the comunity is more important than the product - and
> that used to be the power behind open source, not the pay you get.
> 
> I do believe tomcat4.0 has a future too - but that's because of the
> individuals behind it, and will have a future as long as those individuals
> will be there or other will take their places.

Same with 3.x. DO NOT FORGET THAT!

However, 4.0 has a *promised future* from Sun because of their continued
involvement in J2EE. You still are not seeing the point that 3.x has no
promised future with large scale backing. Just like JServ doesn't and we
have moved on.

>>> as much as possible from 4.0 - so whatever will happen in the future in
>>> 4.0 can happen in 3.3 too )
>> 
>> Very true, but not under the ASF because you will be forked elsewhere as you
>> have already stated.
> 
> Even if ASF is "forking me", the code will continue to exist and probably
> will keep working.

READ WHAT I WRITE COSTIN. Damn.

I didn't say the "ASF is forking you (me)". I said that "you will be forked
elsewhere". YOU ARE THE ONE WHO SAID THAT!

You are the one who has decided that you will fork the project elsewhere. I
didn't decide that for you. In fact, I can't make any decisions for you or
anyone for that matter. That is up to you.

> The only problem is that I don't like forks. The only reason I have for
> forking is that the people there at ASF ( you, Pier, Craig ) are asking
> and forcing me to do so.

No, that isn't true at all. You are the one who said you were going to fork
and there is no "force" to do so.

As I said before: the path of the overall project is going in a direction
that you PERSONALLY don't happen to agree with. Because of that fact, it is
YOUR DECISION on what you can do in the future. For that matter, YOU are
DECID

Re: F....

[cmanolache]

> > I just had to deal with a major change in Apache2.0 -
> > it seems some time ago they reorganized the whole
> > tree,
> > moved apr in a different repository, etc. Is this a
> > different architecture ?
> 
> Apache 2.0 is not yet OUT in final... Try to go down in HTTP land and
> build a 1.4 on the ashes of 1.3 but with a whole new architecture.. I
> wonder what the peeps down there would say...

The point was - reorganizing the code doesn't make it
a "different architecture" - and 2.0 is built on top of 
1.3 and still shares a lot with it.


> > That's even worse - all the flames that start up
> > whenever code from 4.0 is reused in 3.x. What's the
> > problem ??? Are you afraid of "featurism" ( i.e. are
> > good for 4.0 but bad for 3.3 ) ?
> 
> That's TWISTED. Holy shit, you don't even care about supporting our
> users. Jesus Lord! Every single feature you back port from 4.0 will need
> to be supported in BOTH 3.3 and 4.0 and that means doubling our efforts
> in bug tracking and issue solving.

And that's why tomcat3.3 changed to make possible to back port the 
features from 4.0 ( and add new feature that are not present in 4.0)
in an independent way, _outside_ the 3.3 release.

> Costin, if you want to work on an evolutionary track, go on and help
> Craig in supporting 3.2 and making it better. If you want to go on your
> own do a 3.3, I don't care what you do in your time. But my -1 stands on
> 3.3 and +1 on bugfixing 3.2.

Let's see:
you have "evolutionary track" between 3.0 and 3.1
Same between 3.1 and 3.2

But suddenly 3.2 -> 3.3 is no longer "evolution" ?

As I said, 3.2 is the middle of the road - I think I made most of the
commits that went into 3.2, and I spent most of this year analyzing
tomcat3.1 and finding the best way to make it faster and cleaner. 

Tomcat3.2 is a big step forward versus Tomcat3.1 - but it still have many
issues - take a look at the ContextManager in 3.3, compare it with 3.2 -
there are still many undefined behaviors, even code from 3.0.



> You didn't prove me wrong.


Costin

Re: Tomcat 3.3

[Andy]

Yeah i saw that.  I'm planning a few updates.

Jon Stevens wrote:

> on 12/21/2000 1:13 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
> wrote:
>
> > updating the web site is yet another useful way to
> > contribute).
>
> It is even documented on how to do that!
>
> 
>
> :-)
>
> -jon
>
> --
> Honk if you love peace and quiet.


_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [tomcat-4.0] Session Creation Slowness

[Jon Stevens]

on 12/21/2000 2:04 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> Jon Stevens wrote:
> 
>> Ok, I put a whole bunch of logging into Turbine to see *exactly* what line
>> of code is causing the slowness that I keep reporting here and I have now
>> found it...
>> 
>> Log.note ("RunDataFactory: 11");
>> // Get the HttpSession object.
>> data.setSession ( data.getRequest().getSession(true) );
>> Log.note ("RunDataFactory: 12");
>> 
>> As you can see above, essentially, all that is happening is that I'm storing
>> an instance of the HttpSession object within the RunData object. Marking
>> things as "true" causes the redirect to happen, so there is another
>> request...
>> 
>> [Thu Dec 21 13:34:15 PST 2000] -- NOTICE  -- RunDataFactory: 11
>> [Thu Dec 21 13:35:01 PST 2000] -- NOTICE  -- RunDataFactory: 12
>> 
> 
> This is the first session create since the webapp was started, right?
> Currently, that is when the RNG is initialized.

Right.

>> ...
>> [Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 11
>> [Thu Dec 21 13:35:03 PST 2000] -- NOTICE  -- RunDataFactory: 12
>> 
> 
> And this is the behavior you would see after the first one.

As expected. :-)

>> 
>> As you can see above the first request through this code takes bloody
>> FOREVER and the second one is quite fast.
>> 
>> The really *INSANE* part about all of this is that people have checked
>> Scarab out of CVS themselves on the SAME JVM (1.3 on Windows) and don't see
>> any real slowness at all (approx 4-5 seconds).
>> 
> 
> That's definitely strange ... 4-5 seconds is my experience even on much slower
> hardware, on both 1.2.2 and 1.3.

I can deal with 4-5 seconds although that is a bit long as well. Is this
code re-executed when the classloader is dumped as well? If not I can deal
more with this 4-5 seconds. If so, then I think that 4-5 seconds is to slow
as well and we should find another RNG solution.

>> So, Craig, can we please try to do something about this? There has got to be
>> something wrong with either my setup or something else (I really don't think
>> this is entirely a classloader issue anymore). I also have this great
>> slowdown on MacOSX as well.
>> 
> 
> This part isn't.  Aleady on my TODO list is moving the RNG initialization to
> webapp startup time -- that will normally hide it for a 4-5 second delay, but
> certainly won't fix a 45-second delay.

A 45 second startup time? GAG!

>> If you want to duplicate it, you can check Scarab out of CVS and do it
>> yourself. I have re-done the CVS tree and it is very easy to get things up
>> and running (even without a database installed...just ignore that part of
>> the README.txt file).
>> 
>> 
>> 
> 
> You mean it's not just "check out, compile, and run"???  :-) :-)
> 
> Will do.

You don't even have to compile. :-) :-)

cvs co scarab
cd build
./build.sh prepare
cd ../target
./bin/catalina.sh run



It is a copy of m5 that is in Scarab's CVS. However, if you read the
README.txt I just checked in documentation that allows you to use a
.ant.properties to specify your own Tomcat installation to use. :-)

-jon

-- 
Honk if you love peace and quiet.

Re: F....

[Jon Stevens]

on 12/21/2000 2:18 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:

> Tomcat3.2 is a big step forward versus Tomcat3.1 - but it still have many
> issues - take a look at the ContextManager in 3.3, compare it with 3.2 -
> there are still many undefined behaviors, even code from 3.0.

Tomcat 3.2 has *only* happened because Tomcat 4.0 wasn't ready.

Remember the history of Tomcat 4.0 and the fact that if Sun didn't donate a
bunch of cruft software, we would have spent the time working on JServ 2.0
which is now what Tomcat 4.0 is. The fact of the matter is that because we
had to deal with 3.x and support improving it that delayed the development
of 4.0 to not being ready until now.

It is this duplication of effort that needs to stop. We need to quit sitting
back and trying to support something that should have been dead long ago.

-jon

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java

[craigmcc]

craigmcc00/12/21 14:27:12

  Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
  Log:
  Add some debugging instrumentation (still disabled by default) to track down
  the "non-normalized" URLs issue.  If you start Catalina using the standard
  startup script, without a CATALINA_HOME environment variable set, you do indeed
  get URLs that have "/../" in them passed to the classloader.  Interestingly
  enough, though, they continue to work.
  
  I'm going to check this out on Solaris and Windows to see if there might be
  platform-specific discrepancies in how URLClassLoader is implemented.
  
  Revision  ChangesPath
  1.7   +50 -4 
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
  
  Index: Bootstrap.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- Bootstrap.java2000/11/13 06:19:01 1.6
  +++ Bootstrap.java2000/12/21 22:27:11 1.7
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
 1.6 2000/11/13 06:19:01 remm Exp $
  - * $Revision: 1.6 $
  - * $Date: 2000/11/13 06:19:01 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
 1.7 2000/12/21 22:27:11 craigmcc Exp $
  + * $Revision: 1.7 $
  + * $Date: 2000/12/21 22:27:11 $
*
* 
*
  @@ -84,12 +84,21 @@
* class path and therefore not visible to application level classes.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.6 $ $Date: 2000/11/13 06:19:01 $
  + * @version $Revision: 1.7 $ $Date: 2000/12/21 22:27:11 $
*/
   
   public final class Bootstrap {
   
   
  +// --- Static Variables
  +
  +
  +/**
  + * Debugging detail level for processing the startup.
  + */
  +private static int debug = 0;
  +
  +
   // --- Main Program
   
   
  @@ -108,12 +117,17 @@
// Load our startup class and call its process() method
try {
   
  +// Instantiate a startup class instance
  +if (debug >= 1)
  +log("Loading startup class");
Class startupClass =
catalinaLoader.loadClass
   ("org.apache.catalina.startup.Catalina");
Object startupInstance = startupClass.newInstance();
   
   // Set the shared extensions class loader
  +if (debug >= 1)
  +log("Setting startup class properties");
   String methodName = "setParentClassLoader";
   Class paramTypes[] = new Class[1];
   paramTypes[0] = Class.forName("java.lang.ClassLoader");
  @@ -124,6 +138,8 @@
   method.invoke(startupInstance, paramValues);
   
   // Call the process() method
  +if (debug >= 1)
  +log("Calling startup class process() method");
methodName = "process";
paramTypes = new Class[1];
paramTypes[0] = args.getClass();
  @@ -150,6 +166,9 @@
*/
   private static ClassLoader createSystemLoader() {
   
  +if (debug >= 1)
  +log("Creating SYSTEM class loader");
  +
   // Construct the "class path" for this class loader
   ArrayList list = new ArrayList();
   
  @@ -170,6 +189,8 @@
   File file = new File(directory, filenames[i]);
   try {
   URL url = new URL("file", null, file.getAbsolutePath());
  +if (debug >= 1)
  +log("  Adding " + url.toString());
   list.add(url.toString());
   } catch (MalformedURLException e) {
   System.out.println("Cannot create URL for " +
  @@ -193,6 +214,9 @@
*/
   private static ClassLoader createCatalinaLoader(ClassLoader parent) {
   
  +if (debug >= 1)
  +log("Creating CATALINA class loader");
  +
   // Construct the "class path" for this class loader
   ArrayList list = new ArrayList();
   
  @@ -203,6 +227,8 @@
   try {
   URL url = new URL("file", null,
 classes.getAbsolutePath() + "/");
  +if (debug >= 1)
  +log("  Adding " + url.toString());
   list.add(url.toString());
   } catch (MalformedURLException e) {
   System.out.println("Cannot create URL for " +
  @@ -226,6 +252,8 @@
   File file = new File(directory, filenames[i]);
   try {

Re: Tomcat 3.3

[Remy Maucherat]

Quoting "Pier P. Fumagalli" <[EMAIL PROTECTED]>:

> "Craig R. McClanahan" wrote:
> > 
> > For the record, Sun hired me in March, 2000, so that I could work on
> Tomcat full
> > time instead of it just being a hobby (as it was when the original
> code was
> > written).  :-)
> 
> And thank you for not accepting my offer at that time, otherwise you
> would be working on Business Processes right now, and not on
> Catalina...

Lol.
At the end, I did the same :)

Remy

Re: [tomcat-4.0] Session Creation Slowness

[Craig R. McClanahan]

Jon Stevens wrote:

>
> I can deal with 4-5 seconds although that is a bit long as well. Is this
> code re-executed when the classloader is dumped as well?

Yep, although that's probably something that could be changed.

> If not I can deal
> more with this 4-5 seconds. If so, then I think that 4-5 seconds is to slow
> as well and we should find another RNG solution.

Patches are welcome.  (Now where have I heard that one before? :-).

Actually, you can configure this to use the java.util.Random class to speed up your
development scenario:





Craig

RE: TC 3.2 - Better logging messages when something bad happens?

[David Rees]

Thanks for the reply,

> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
>
> David Rees wrote:
>
> > Anyone have any technical comments on the message below?  I think that
> > printing a stack dump in this case can be very useful, but
> someone else may
> > have a different view.
> >
>
> For developers, you certainly want to be able to see the stack
> traces.  However,
> many developers do *not* want such cruft showing to users -- so
> it was made
> configurable (thanks to the efforts of Larry Isaacs) -- see the
> 
> attribute called "showDebugInfo" in the conf/server.xml file.
>
> It looks like this case was missed.  I'm +1 on adding a stack
> trace, but it
> should be made conditional just like other stack traces are.

OK, I'll see if I can get some time to create a proper patch for this case,
then (unless someone beats me to it, I probably won't have time until after
X-Mas)

-Dave

mod_webapp / mod_jk

[Dan Milstein]

Pier,

I wanted to ask you some questions about mod_webapp, and how you might see it working 
with mod_jk.  I seem to have become the default ajp13 / mod_jk expert, and people have 
been asking for various extensions.  I'm reluctant to invest much work in 
mod_jk/ajp13, given that TC 4.0 is using mod_webapp.  However, what would seem to make 
sense to me would be the following course of action:

 - Write connectors for TC 4.0 which talk ajp13, the mod_jk JNI protocol, and possibly 
ajp12.

I would be very interested in doing this work.  I believe it wouldn't take me very 
long, given that I could adapt the current 3.3 code wholesale (much of which I 
understand in detail).  Then, TC 4.0 would suddenly be able to talk to all the web 
servers which mod_jk talks to: Apache 1.3, Apache 2.0, Netscape, IIS, AOLServer.  This 
would be a huge win, and would (I believe) dramatically accelerate the adoption of TC 
4. It would also provide a very smooth upgrade path to current users.

The only disadvantage would be that we wouldn't see any of the advantages of 
mod_webapp.  I've never seen a design doc for webapp, but my understanding is that one 
of its big advantages is that it will directly read the web.xml (and server.xml) 
files, which will greatly ease the configuration process.  Could you possibly 
summarize some of its other features?

The reason I ask is that I think the mod_jk C code (the various modules which plug 
into the web servers), is actually extremely well-written and flexible.  It's totally 
undocumented, but, if necessary, I'd be willing to remedy that (I don't mind writing 
documentation).  One of the best things about that C code is that it allows many 
different web servers to talk to many different protocols in a very clean way.  So I 
wonder if it would be possible to make it to also talk whatever protocol you're 
developing as part of mod_webapp.

This would mean basically merging mod_webapp into mod_jk (or merging mod_jk into 
mod_webapp, depending on your perspective ;-).

What do you think of this course of action?  I'm hoping that you and I can align our 
efforts so that we can take as much advantage of each other's work as possible.

-Dan
-- 

Dan Milstein // [EMAIL PROTECTED]

Re: [tomcat-4.0] Session Creation Slowness

[Jon Stevens]

on 12/21/2000 2:35 PM, "Craig R. McClanahan" <[EMAIL PROTECTED]>
wrote:

> Yep, although that's probably something that could be changed.

+1

>> more with this 4-5 seconds. If so, then I think that 4-5 seconds is to slow
>> as well and we should find another RNG solution.
> 
> Patches are welcome.  (Now where have I heard that one before? :-).

If only I could get it to compile. :-) Sam where is your buildmaker? :-)

> Actually, you can configure this to use the java.util.Random class to speed up
> your
> development scenario:
> 
> 
> 
> 

I have:





This time it took 1 minute and 1 second on my Win98 box.

I just checked the modified server.xml into Scarab's CVS in case you want to
look at it. :-)

-jon

-- 
Honk if you love peace and quiet.

Re: Fuck It.

[Christopher Cain]

"Pier P. Fumagalli" wrote:

> Christopher Cain wrote:
> >
> > "Pier P. Fumagalli" wrote:
> >
> > > Where were you KIDS when we were fighting the big
> > > corporations to have them looking into open source, to contribute
> > > significant parts of their technologies to the Foundation, where were you
> > > while we were changing this world? You were home, and one day, you looked up
> > > on your browser, saw a thing called Jakarta and started weening if things
> > > weren't as nice as you wanted them.
> >
> > Nice. Now as a newcomer who wishes to give back to the community, do you think
> > that this makes me feel more welcome or less? Why don't you just post a big sign
> > that says, "If you were not here in the beginning, you are irrelevent. Go Away."
> > That would probably be a slightly more effective means of keeping new developers
> > away than simply making fun of them.
>
> That was not my intent, sometimes I just get too epic :) :) :)
> What I wanted to say is that when decisions are made, even if in an open
> source project, you have to stick with them. That's why new developers
> are "hinted" to read the list for a while before coming along and trying
> to revolution the whole thing.

Understood. I was simply trying to to give you a newcomers perspective of how some of
these posts are coming across (from all sides), which is pretty much my entire point
on this thread. And don't worry, you are deinitely not the only epic author in this
list :-)

> > I assume that I fall under that auspise since I also called Jon out directly. And
> > yes, as I stated in no uncertain terms, many times I do _not_ care about reading
> > what Jon writes. Many of his posts are so demeaning to whomever they addressed
> > that it is difficult to read them all the way through, quite literally. It makes
> > me uncomfortable to see well-meaning people treated like that. And trust me, I
> > received enough private mail on the subject to assure you that I am far from the
> > only one. The bottom line is, Jon is currently getting no more and no less than
> > he gives everyone else.
>
> And that's wrong... Why sending you email privately? Come on out, my old
> flameproof vest is on, and kids, you don't even know how much I can
> take.
> Get out, tell me I'm an ignorant idiot (Duncan, what was that? Arrogant
> Pig? I believe that's how you've been called somewhere else! :) :)

My private conversations are my own. They were mostly the musings of newcomers just
like myself, who have no desire to become involved in this extra-curricular stuff (and
understandably so). Which, again, speaks directly to my point: There are people who
want to help out but not in this kind of environment. Rather than calling on such
people to openly flame you in this list, further lowering the civility level, maybe
the better approach would be to try and raise it  to a level that would make people
feel good about getting involved.

> All I ask you guys it to prove me wrong. Prove me that 3.3 is not a new
> servlet container, prove me that it's just bugfix and performance. Give
> me some damn facts.
>
> > > hear that people like Paul Frieden (the only person that did put some salt
> > > in what he said)
> >
> > Hey, thanks =)
> >
> >  > little kiddie who stumbled across Jakarta a mere six months ago and can therefore
> > not possibly have anything meaningful to say>
>
> Did I overlook one of your emails? Subject please, since you posted 6
> times on this mailing list and the first time in september. Were you
> around when 4.0 was voted on?

No, you didn't overlook anything. I was not around for the 4.0 vote, and wouldn't have
had an informed opinion at the time anyway. This was simply further pointing out how
your initial "Where were you KIDS..." comments made some of us feel.

> > > As one of the people behind the scenes since before each of you got here, I
> > > believe my vote counts, and now, please prove me wrong.
> >
> > This post is a better example of my original point than I could possibly dream
> > up, and it has nothing to do with the technical merits of the architecture. Sam
> > is right on the money. Do you think that this little scuttle over 3.x vs. 4.x
> > will be too terribly important six months from now? Probably not. What will be is
> > the one or two or ten developers who eventually decided to contribute their
> > limited time and resources to a different OSS project because this one is getting
> > too contentious for their tastes. There are other great projects out there to get
> > involved in, and whether or not a project has some fun people to work with, as
> > opposed to everyone treating each other like shit when they disagree, is
> > definitely a consideration for most of us.
>
> Go back, read the archives and take a look to what I said when we voted
> on tomcat 4.0. Then go again and read what I proposed Costin for his new
> servlet container.

I didn't mean to imply that you yourself have a history being rude, and I apologize i

cvs commit: jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler JspParseEventListener.java

[pierred]

pierred 00/12/21 15:16:42

  Modified:jasper/src/share/org/apache/jasper/compiler
JspParseEventListener.java
  Log:
  Check for null value before invoking method.
  
  From email sent by Brian Bucknam:
  
  It's a long story, but I'm working on a project where Jasper 3.x is embedded
  inside a servlet, which can then be deployed to the container of our
  customer's choice.  The servlet uses JSP files as templates, which is where
  Jasper comes in.
  
  In this type of environment, sometimes thing can go really wrong, and the
  compiled JSP might, in some cases, fail to get a JspFactory, PageContext, or
  JspWriter.
  
  If any of _jspxFactory, pageContext, or out fail to be created, the catch{}
  and finally{} clauses just throw NPE's.
  
  Submitted by: "Bucknam, Brian" <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.19  +6 -6  
jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.18
  retrieving revision 1.19
  diff -u -r1.18 -r1.19
  --- JspParseEventListener.java2000/12/10 05:56:43 1.18
  +++ JspParseEventListener.java2000/12/21 23:16:41 1.19
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.18 2000/12/10 05:56:43 pierred Exp $
  - * $Revision: 1.18 $
  - * $Date: 2000/12/10 05:56:43 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/jasper/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.19 2000/12/21 23:16:41 pierred Exp $
  + * $Revision: 1.19 $
  + * $Date: 2000/12/21 23:16:41 $
*
* 
*
  @@ -369,16 +369,16 @@
writer.popIndent();
writer.println("} catch (Throwable t) {");
writer.pushIndent();
  -writer.println("if (out.getBufferSize() != 0)");
  +writer.println("if (out != null && out.getBufferSize() != 0)");
   writer.pushIndent();
writer.println("out.clearBuffer();");
writer.popIndent();
  - writer.println("pageContext.handlePageException(t);");
  + writer.println("if (pageContext != null) pageContext.handlePageException(t);");
writer.popIndent();
writer.println("} finally {");
writer.pushIndent();
/* Do stuff here for finally actions... */
  - writer.println("_jspxFactory.releasePageContext(pageContext);");
  + writer.println("if (_jspxFactory != null) 
_jspxFactory.releasePageContext(pageContext);");
writer.popIndent();
writer.println("}");
// Close the service method:
  
  
  

Re: Tomcat session replicator

[Jason Brittain]

Craig R. McClanahan wrote:

> At ApacheCon Europe (it was also presented in Orlando last March, but I missed
> it then), there was a very interesting session by Theo Schlossnagle
> <[EMAIL PROTECTED]> about the Backhand Project, which is focused on providing
> load balancing support for Apache as a web server.  There are some good ideas we
> can glean from this approach (and possibly even some code???).  More info at:
> 
> http://www.cnds.jhu.edu/~jesus/
> 
> Craig


I attended his session at ApacheCon in Orlando.  I also spoke with him 
about Backhand
and other high-availability and load balancing solutions (one that I 
helped create).
Backhand has many features that only commercial software had before.

Many of the tricks/approaches/patters that Backhand uses have been 
around for quite
a while, but just not implemented as open source software.  Yes, now we 
have a very
good open source example.

-- 
Jason Brittain
Software Engineer, Olliance Inc.http://www.Olliance.com
Current Maintainer, Locomotive Project  http://www.Locomotive.org

cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler JspParseEventListener.java

[pierred]

pierred 00/12/21 15:25:28

  Modified:src/share/org/apache/jasper/compiler Tag: tomcat_32
JspParseEventListener.java
  Log:
  Check for null value before invoking method.
  
  From email sent by Brian Bucknam:
  
  It's a long story, but I'm working on a project where Jasper 3.x is embedded
  inside a servlet, which can then be deployed to the container of our
  customer's choice.  The servlet uses JSP files as templates, which is where
  Jasper comes in.
  
  In this type of environment, sometimes thing can go really wrong, and the
  compiled JSP might, in some cases, fail to get a JspFactory, PageContext, or
  JspWriter.
  
  If any of _jspxFactory, pageContext, or out fail to be created, the catch{}
  and finally{} clauses just throw NPE's.
  
  Submitted by:  "Bucknam, Brian" <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  No   revision
  
  
  No   revision
  
  
  1.17.2.2  +7 -7  
jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
  
  Index: JspParseEventListener.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
  retrieving revision 1.17.2.1
  retrieving revision 1.17.2.2
  diff -u -r1.17.2.1 -r1.17.2.2
  --- JspParseEventListener.java2000/07/03 09:43:21 1.17.2.1
  +++ JspParseEventListener.java2000/12/21 23:25:27 1.17.2.2
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.17.2.1 2000/07/03 09:43:21 bergsten Exp $
  - * $Revision: 1.17.2.1 $
  - * $Date: 2000/07/03 09:43:21 $
  + * $Header: 
/home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
 1.17.2.2 2000/12/21 23:25:27 pierred Exp $
  + * $Revision: 1.17.2.2 $
  + * $Date: 2000/12/21 23:25:27 $
*
* 
*
  @@ -348,18 +348,18 @@
//writer.println("} catch (Throwable t) {");
writer.println("} catch (Exception ex) {");
writer.pushIndent();
  -writer.println("if (out.getBufferSize() != 0)");
  +writer.println("if (out != null && out.getBufferSize() != 0)");
   writer.pushIndent();
writer.println("out.clearBuffer();");
writer.popIndent();
  - writer.println("pageContext.handlePageException(ex);");
  + writer.println("if (pageContext != null) 
pageContext.handlePageException(ex);");
writer.popIndent();
writer.println("} finally {");
writer.pushIndent();
/* Do stuff here for finally actions... */
   //writer.println("out.close();");
  - writer.println("out.flush();");
  - writer.println("_jspxFactory.releasePageContext(pageContext);");
  + writer.println("if (out != null) out.flush();");
  + writer.println("if (_jspxFactory != null) 
_jspxFactory.releasePageContext(pageContext);");
writer.popIndent();
writer.println("}");
// Close the service method:
  
  
  

Bug #55: Default for included files is 8859_1, with no option to set otherwise

[Pierre Delisle]

Trying to close a few Jasper bugs before the holiday break.
I'd appreciate at least another pair of eyes to review what I believe
should be done on that one...  -- Pierre

-
Bug #55

   -
   Synopsis: 
 Default for included files is 8859_1, with no option to set otherwise. 

   Report Description: 
 The default for reading an included file is ISO_8859_1. We can,
 of course, set pageConent to read UTF-8 (which is what we need it
 to be to support international
code). Unfortunately, when there are two or more levels of
encoding (or the pageContent type ins't set), the encoding that
the JspReader gets set to a hard-coded
 "ISO_8859_1", and doesn't allow this to be set to anything else
 via the runtime system properties. In:
 org.apache.jasper.compiler.JspReader JspReader.java line
 158, encoding ALWAYS defaults to 8859_1, and the file.encoding,
 when set from the System properties. This is an easy fix, to set
 encoding to: encoding =
 System.getPropert("file.encoding","8859_1") ; The result,
 typically, is that the file will flake out and convert all of the
 non-UTF-8 characters to US-ASCII, @%, etc.
 -

I'm not sure I fully understand what's described there,
so here is what I believe should be done. 

The "encoding" for a JSP file is currently handled as follows:

1. In Compiler.java, we create a JspReader for the top-level
   ("including") jsp file using the 8859_1 encoding.

2. Using that JspReader, we check if there is a page directive
   with 'contentType' specified. If there is, then 
   a new JspReader for the page is created with the encoding set to the 
   "charset" specified in the contentType value of the page
   directive; otherwise we stick with the default 8859_1 encoding.

3. When a page is included, JspReader.pushFile() is called,
   and the encoding passed as argument appears to always 
   be null (since no encoding attribute can be specified in 
   the "include" directive, reading 'encoding' off of the 
   attributes appears to be a bug in JspParseEventListener).
   Because it is null, it always defaults to 8859_1. 

If I understand well the intent of the bug report, we'd need the 
following modifications:

- In step 2, if contentType is not specified in the "including" page,
  set the encoding to be:

 encoding = System.getProperty("file.encoding", "8859_1");

  This means that the default encoding of all JSP files at a site could
  be defined globally using system property "file.encoding".
  I don't think this is spec-compliant, and would be reluctant
  to make that change. 

- In step 3, use the encoding of the "including" page.

  This would fix what I believe is a bug in the current implementation.


Comments?

-- Pierre

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup Bootstrap.java

[craigmcc]

craigmcc00/12/21 15:47:20

  Modified:catalina/src/share/org/apache/catalina/startup
Bootstrap.java
  Log:
  Modify the bootstrap program to call file.getCanonicalPath() rather than
  file.getAbsolutePath() when constructing "file:" URLs to declare as
  repositories to URLClassLoader instances.  This will cause occurrences of
  "/./" and "/../" to be normalized out of the URLs, which apparently causes
  problems on some platforms -- although I haven't been able to duplicate it
  with my simple tests so far.
  
  There are other cases where this change needs to be applied, which will be
  dealt with separately.
  
  Submitted by: Stuart Roebuck <[EMAIL PROTECTED]>
  
  Revision  ChangesPath
  1.8   +24 -13
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java
  
  Index: Bootstrap.java
  ===
  RCS file: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- Bootstrap.java2000/12/21 22:27:11 1.7
  +++ Bootstrap.java2000/12/21 23:47:20 1.8
  @@ -1,7 +1,7 @@
   /*
  - * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
 1.7 2000/12/21 22:27:11 craigmcc Exp $
  - * $Revision: 1.7 $
  - * $Date: 2000/12/21 22:27:11 $
  + * $Header: 
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/startup/Bootstrap.java,v
 1.8 2000/12/21 23:47:20 craigmcc Exp $
  + * $Revision: 1.8 $
  + * $Date: 2000/12/21 23:47:20 $
*
* 
*
  @@ -66,6 +66,7 @@
   
   
   import java.io.File;
  +import java.io.IOException;
   import java.lang.reflect.Method;
   import java.net.MalformedURLException;
   import java.net.URL;
  @@ -84,7 +85,7 @@
* class path and therefore not visible to application level classes.
*
* @author Craig R. McClanahan
  - * @version $Revision: 1.7 $ $Date: 2000/12/21 22:27:11 $
  + * @version $Revision: 1.8 $ $Date: 2000/12/21 23:47:20 $
*/
   
   public final class Bootstrap {
  @@ -109,6 +110,12 @@
*/
   public static void main(String args[]) {
   
  +// Set the debug flag appropriately
  +for (int i = 0; i < args.length; i++)  {
  +if ("-debug".equals(args[i]))
  +debug = 1;
  +}
  +
   // Construct the class loaders we will need
   ClassLoader systemLoader = createSystemLoader();
   ClassLoader catalinaLoader = createCatalinaLoader(systemLoader);
  @@ -183,18 +190,19 @@
String filenames[] = directory.list();
for (int i = 0; i < filenames.length; i++) {
   String filename = filenames[i].toLowerCase();
  - if ((!filename.endsWith(".jar")) || 
  + if ((!filename.endsWith(".jar")) ||
   (filename.indexOf("bootstrap.jar") != -1))
continue;
   File file = new File(directory, filenames[i]);
   try {
  -URL url = new URL("file", null, file.getAbsolutePath());
  +URL url = new URL("file", null, file.getCanonicalPath());
   if (debug >= 1)
   log("  Adding " + url.toString());
   list.add(url.toString());
  -} catch (MalformedURLException e) {
  +} catch (IOException e) {
   System.out.println("Cannot create URL for " +
  filenames[i]);
  +e.printStackTrace(System.out);
   System.exit(1);
   }
}
  @@ -226,13 +234,14 @@
   classes.isDirectory()) {
   try {
   URL url = new URL("file", null,
  -  classes.getAbsolutePath() + "/");
  +  classes.getCanonicalPath() + "/");
   if (debug >= 1)
   log("  Adding " + url.toString());
   list.add(url.toString());
  -} catch (MalformedURLException e) {
  +} catch (IOException e) {
   System.out.println("Cannot create URL for " +
  classes.getAbsolutePath());
  +e.printStackTrace(System.out);
   System.exit(1);
   }
   }
  @@ -251,13 +260,14 @@
continue;
   File file = new File(directory, filenames[i]);
   try {
  -URL url = new URL("file", null, file.getAbsolutePath());
  +URL url = new URL("file", null, file.getCanonicalPath());
   if (debug >= 1)
   log("  Adding " + url.toString());
   list.add(url.toString());
  -} catch (MalformedURLException e) {
  +

BugRat Report #650 has been filed.

[BugRat Mail System]

Bug report #650 has just been filed.

You can view the report at the following URL:

   

REPORT #650 Details.

Project: Tomcat
Category: Bug Report
SubCategory: New Bug Report
Class: swbug
State: received
Priority: high
Severity: serious
Confidence: public
Environment: 
   Release: 3.1.1,3.2.1,3.3
   JVM Release: 1.3
   Operating System: NT
   OS Release: 4 SP6
   Platform: WINDOWS

Synopsis: 
RequestUtil.getCharsetFromContentType(String) does not strip " characters from 
returned string

Description:
HttpServletRequestFacade.getReader() throws a UnsupportedEncodingException during a 
PROPFIND request. The charset encoding returned from Request.getCharacterEncoding() 
has " characters surrounding the string. The 
RequestUtil.getCharsetFromContentType(String) method eventually returns the charset. 
It should remove the leading and trailing " characters before returning.


Title: 
BugRat Report #
650





BugRat Report #
650




Project:
Tomcat


Release:
3.1.1,3.2.1,3.3




Category:
Bug Report


SubCategory:
New Bug Report




Class:
swbug


State:
received




Priority:
high


Severity:
serious




Confidence:
public





Submitter:
Rick Rupp ( [EMAIL PROTECTED] )

Date Submitted:
Dec 21 2000, 06:15:54 CST

Responsible:
Z_Tomcat Alias ( [EMAIL PROTECTED] )


Synopsis:

RequestUtil.getCharsetFromContentType(String) does not strip " characters from returned string


 Environment: (jvm, os, osrel, platform)

1.3, NT, 4 SP6, WINDOWS



Additional Environment Description:





Report Description:

HttpServletRequestFacade.getReader() throws a UnsupportedEncodingException during a PROPFIND request. The charset encoding returned from Request.getCharacterEncoding() has " characters surrounding the string. The RequestUtil.getCharsetFromContentType(String) method eventually returns the charset. It should remove the leading and trailing " characters before returning.




How To Reproduce:

null



View this report online...

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/loader FileClassLoader.java

[craigmcc]

craigmcc00/12/21 16:34:37

  Removed: catalina/src/share/org/apache/catalina/loader
FileClassLoader.java
  Log:
  FileClassLoader has been obsolete for a while -- remove it to avoid
  any potential confusion.