It's not possible, the requirement is an identical layout for printout and html (as far as possible), so from a layouter application (kind of WYSIWIG-DTP-Editor) a screen (jsp) and a print representation (pdf) is created for each physical page(including multiple columns layout, formated text with fixed line breaks, copy pages, ...). So each jsp has it's own layout and believe me the layouts are not simple, I just checked: the largest JSP representing one physical page has ~360kB (w/o debug information) containing ~150 page objects (50 rendering to fields(input, textarea)) from Layout-program.
-----Ursprüngliche Nachricht----- Von: Leon Rosenberg [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 7. März 2006 23:15 An: Tomcat Developers List Betreff: Re: What's about unloading policy of jsp-servlets ? Why do you create jsps from the database instead of filling a small set of jsps with the content from the database? Leon On 3/7/06, S. Dierkes <[EMAIL PROTECTED]> wrote: > If you're still searching for a real world application: we have an > application where JSP's are generated dynamically from database (no > on-the-fly because to time consuming, so they are created offline), > currently there had been ~1500 JSP's (~100MB) created (plus the > application itself). The application creates JSP and PDF of real-world > forms (fill in as html, print out as pdf) for different customers > (mainly banks), so the jsp-base is constantly increasing. Ok, memory > is not really an issue in production, since we can increase it on > demand, but a configurable memory behaviour could be a nice feature > and might save memory for other server purposes. Don't get me wrong, I > think the best solution for production is still more RAM, but at least > for testing it would be nice to have less needs for RAM. > > -----Ursprüngliche Nachricht----- > Von: Leon Rosenberg [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 7. März 2006 16:20 > An: Tomcat Developers List > Betreff: Re: What's about unloading policy of jsp-servlets ? > > > On 3/7/06, Renato <[EMAIL PROTECTED]> wrote: > > a webhosting company that has a shared JVM instance of tomcat for > > its websites and runs unmanaged code bumps into this kind of problem > > all the time ;)). > > hmm... sorry, I host java webapps for customers, and this is my last > problem. I mean a typical webapp contains approx. 100 classes and 50 > jsps? Most of the classes are always in use and therefore in memory as > well as the jsps. I don't really see the problem here. I mean before I > run out of memory for JSPs, I will run out of memory for classes.... > Leon > > > > > --- Leon Rosenberg <[EMAIL PROTECTED]> > > wrote: > > > > > Yaroslav, > > > > > > you've made great work with the patch, but honestly, which > > > real-world application uses hunderds of megabytes of jsps? > > > > > > that just doesn't make sense... > > > > > > regards > > > Leon > > > > > > P.S. don't want to be offending, but i just can't > > > find a single use-case... > > > > > > On 3/7/06, Yaroslav Sokolov <[EMAIL PROTECTED]> > > > wrote: > > > > Ok, I can make the next conclusions: > > > > > > > > 1. Tomcat eats resources on first opening of any > > > jsp page and never returns > > > > them back - servlets just are never unloaded. > > > > 2. As it happens in all the versions of Tomcat, > > > there are many jsps, not > > > > meeting requirements > > > > of the specification (no destroy() method when > > > there is some useful data in > > > > fields) but well working under Tomcat. > > > > 3. We do not want to change this situation ( -> I > > > shall not even try to send > > > > any better patch here :-\ (but I will ;-) ) ) > > > > > > > > One more conclusion - if all the jsp content of > > > our web site does not fit in > > > > memory, we > > > > should buy more memory. Else we must not use jsp > > > technology in all the > > > > pages. We should choose > > > > something other than jsp, for example velocity, > > > SSI,... > > > > > > > > P.S. by the way, when web application is unloaded > > > such bad jsps lose data > > > > anyway. > > > > > > > > On 06/03/06, Costin Manolache <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > Starting is different from stopping. > > > > > > > > > > Yes, the spec allows unloading - but in reality > > > most JSPs and servlets > > > > > can't deal well with that. And the argument that > > > it is optional > > > > > doesn't work - in many cases the person who > > > writes the servlet/jsp is > > > > > not the same as the person who is running the > > > production server or > > > > > does the configuration tunning. > > > > > > > > > > There are subtle bugs that may show up when this > > > feature would be > > > > > enabled - people doing the config might be > > > tempted to reduce memory > > > > > use, and this would result in extremely hard to > > > reproduce and debug > > > > > problems. > > > > > > > > > > By 'spec compliance' I mean more 'compatibility > > > with the existing spec > > > > > _and_ the current usage of the spec'. The later > > > is IMO more important > > > > > in many cases than the letter or any > > > interpretation of the spec. > > > > > > > > > > Costin > > > > > > > > > > On 3/6/06, Yaroslav Sokolov > > > <[EMAIL PROTECTED]> wrote: > > > > > > On 04/03/06, Remy Maucherat <[EMAIL PROTECTED]> > > > wrote: > > > > > > > > > > > > > > Costin Manolache wrote: > > > > > > > > But it's a separate issue - I agree that > > > unloading unused jsps is > > > > > the > > > > > > > > most important. > > > > > > > > > > > > > > The recommended production usage (= optimal) > > > of JSPs is when they are > > > > > > > precommpiled, which means that the Jasper > > > servlet is not used, and the > > > > > > > JSPs are plain servlets. Their lifecycle is > > > then identical to the > > > > > > > lifecycle of servlets. > > > > > > > > > > > > > > > > > > I do not see any reason, why different > > > servlets could not have different > > > > > > life cycles. > > > > > > Even more, the last sentence is in contrary to > > > current implementation - > > > > > > some servlets can be loaded not on demand, but > > > on starting of a web > > > > > > application. > > > > > > So, their life cycle has already been _not_ > > > identical to the life cycle > > > > > of > > > > > > other servlets. > > > > > > > > > > > > > > > > > > I understand the Jasper servlet is junk, and > > > is a testing ground for bad > > > > > > > ideas, though (ex: the background > > > compilation thread, and now this). > > > > > > > > > > > > > > Rémy > > > > > > > > > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Yaroslav Sokolov. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Regards, > > > > Yaroslav Sokolov. > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > - > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam protection around > > http://mail.yahoo.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
