http://www.coremedia.de http://www.reddot.com http://www.magnolia.info/en/magnolia.html and further 100-200 cms vendors...
Of course you now your applications need better, but it seems like finding an excuse for a bad design. If the jsps are static, like in your case, they aren't jsps anymore, are they? But well, this is going very far OT :-) regards leon On 3/7/06, S. Dierkes <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
