tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Kartashov <andrey.kartas...@sonatainc.com>
Subject Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
Date Sat, 12 May 2001 20:40:53 GMT

Sorry for not replying back sooner. I just wanted to look at the latest stuff
from CVS ( I used to look at my local CVS repository which is based on TC3.2.1).
Couldn't do it sooner - had to to some other things first:)

In case you, guys still interested - here it goes:)
First I'd like to apologize for not looking at CVS sooner. A lot of things
have changed since 3.2.1. I know that you, guys are busy so I'll try to make
it short:)

This is what I think is still relevant:
TC binds to all interfaces. This is insecure (think of "shutdown" command for
example). Also configuration stuff has changed and I haven't found a new way
to "bind" connector to a particular interface.
I'm going to try to implement all this in current jakarta-tomcat repository.
I'll send another mail with diffs (hopefully today) for your review.


On Tue, May 08, 2001 at 10:30:36AM -0700, cmanolache@yahoo.com wrote:
> On Tue, 8 May 2001, Andrey Kartashov wrote:
> 
> > What I'm trying to say is:
> > To address this group of people I'd suggest splitting distribution into
> > "pure java" Tomcat part + extensions. This way only NECESSARY files will
> > make their way to "conf" directory. If someone is (for example) interested
> > in running stand-alone TC - he only downloads "pure java" part. If he needs
> > to hook it into some Web server like Apache or IIS - he downloads "apache
> > extensions" or "IIS extensions", etc.
> 
> +1 on the idea - but for 3.2.2 it's out of question, and for 3.3 someone
> has to do it - and closing bugs has bigger priority.
> 
> If this is an itch for you, and you want to propose something ( and write
> some code ) - we're listening :-)
> 
> I think Henri is also considering spliting the distribution in
> "base tomcat", web applications. The connectors are already in a separate
> RPM.
> 
> BTW, I like very much the idea of keeping the WARs ( examples, admin, 
> etc) in separate distribution files. 
> 
> It was on the "goals" list to produce a minimal container, that
> implements the servlet API and nothing else, and separate the
> "features". That didn't happen so far. 
> 
> Costin
> 
> > 
> > 
> > > >	Some people would prefer to use some UI tool to 
> > [skpd]
> > > Some Admin Servlet could do the job....
> > My point exactly:)
> > 
> > > >2) changed shutdown code to make it work correctly if "inet" 
> > > >parameter is used.
> > > 
> > > Thanks to (re)send the code to list.
> > Do you want me to send it again?
> > 
> > > >4) modified tomcat.sh file in "bin" to redirect stdout&stderr 
> > > >to a log file (people complained about not seeing System.out.println()
> > > stuff)
> > > 
> > > Done by the official Tomcat RPM which modify tomcat.sh to
> > > feed /var/log/tomcat.log
> > Not everyone uses Linux:) Not everyone uses RPM:)
> > I use linux for developiment (but I prefer getting TC as *.tgz), our production
> > systems are running Solaris.
> > I'd still suggest to modify tomcat.sh (don't make this fix RPM-only).
> > There is another cross-platform way of doing the same:
> > System.setOut(errorLogStream);
> > System.setErr(errorLogStream);
> > 
> > 
> > > >5) modified default load balancing behavior to make use of 
> > > >wireless device's 
> > > >   "global id" (I'm not giving details on this one because 
> > > >it's specific to 
> > > >   what we are doing and probably useless for others. But I'm 
> > > >not hiding it:)
> > > >   I can describe it if anyone is interested).
> > > 
> > > Please. I realize I must'nt be too stupid since we have done
> > > many common things :)
> > I would suggest it if it wasn't:))) I'm not proud of it:)
> > It's a hack and I know about it's problems and limitations.
> > That being said - here is what it does:
> > 
> > Problem: We are doing wireless ad serving. One of the business rules says that
> > we should support "static" URL to ad server. Ad server serves multiple ads -
> > hence we need to remember what we've served to whom. It can't be part of the
> > URL (it's static) and it can't be cookie (not all the wireless browsers
> > have it).
> > 
> > Solution: We are trying to use device's Global Id (part of the request on most
> > of the devices) as SessionId. The TC java code has been modified accordingly
> > and LB code has been modified to route based on Global Id ( "session
> > stickiness" ). This solution doesn't address fail over issue properly.
> > A better one would be to have persistent sessions (keep them in Data Base or
> > something ...) but it would cost more. We've made similar modifications to 
> > JServ and it's been up for some time. Recently we decided to switch to TC
> > because it supports newer API and is being developed/supported. I reimplemented
> > modifications in TC as well although it hasn't been tested yet.
> > 
> > As I said - it's not an elegant solution and If the requirement to have this
> > feature turns out to be not important - we'll get rid of this hack:)
> > 
> > 
> > 
> > > >Sorry for the long E-Mail:) Hope you've read it:)
> > > I read all of it. Hope to read you soon.
> > I'm glad you did:)
> > 
> > 

-- 
oo Andrey
oo
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo
"All mail clients suck. This one just sucks less."
           -- http://www.mutt.org/  Jeremy Blosser
oOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOoOo


Mime
View raw message