tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Tomcat 3.2.2 beta 4 - AJP14 continuation
Date Tue, 08 May 2001 17:30:36 GMT
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

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. 


> > >	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 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 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 (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:)

View raw message