noep, there since 1.3.6 and enabled by default. if you use httpsessionstore the problem will only appear when clustering or when servlet container spools sessions to disk.
-igor On Thu, May 28, 2009 at 7:26 PM, Chris Colman <chr...@stepaheadsoftware.com> wrote: > Is that a relatively new feature because we're still on 1.4m2 > (2008/05/24) and haven't had any trouble with non serializeable model > objects when going back to pages that have been spooled to disk. > > Maybe if it's a newer feature and we upgrade to the latest wicket we > might start seeing some problems due to the lack of serializability of > our model objects.... hmmm > > Chris > >> to keep memory overhread low only the last visisted page is stored in >> http session. the rest of the pages are spooled to disk for long-term >> storage in case the user uses the back button, and are cleaned up on >> session expiration. >> >> -igor >> >> On Thu, May 28, 2009 at 6:54 PM, Chris Colman >> <chr...@stepaheadsoftware.com> wrote: >> > When you say "offline storage" do you mean that the user has chosen > to >> > save pages for future offline reference or do you mean a more >> > 'automated' process that wicket performs when system memory becomes > too >> > low? >> > >> > Chris >> > >> >> -----Original Message----- >> >> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] >> >> Sent: Friday, 29 May 2009 11:43 AM >> >> To: users@wicket.apache.org >> >> Subject: Re: Anemic domain model and are @SpringBean's compatible > with >> > the >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"? >> >> >> >> well, this is why salve removes the dependency field to at least > help >> >> with those. >> >> >> >> other then that you can use a loadabledetachablemodel to release > the >> >> reference when the page is not used. >> >> >> >> -igor >> >> >> >> On Thu, May 28, 2009 at 6:40 PM, Chris Colman >> >> <chr...@stepaheadsoftware.com> wrote: >> >> > Is that controllable? >> >> > >> >> > What if I have complex object models referenced from wicket UI >> >> > components that I don't want (can't reasonably with Java's non >> > optimal >> >> > serialization) serialized? >> >> > >> >> > If we're serializing for offline storage aren't we going to > require >> > the >> >> > underlying model objects to get serialized as well? >> >> > >> >> >> -----Original Message----- >> >> >> serialization in the context when you need to serialize the > object >> > - >> >> >> eg wicket serializes its pages for offline storage, etc. >> >> >> >> >> >> -igor >> >> >> >> >> >> On Thu, May 28, 2009 at 5:51 PM, Chris Colman >> >> >> <chr...@stepaheadsoftware.com> wrote: >> >> >> > Another extremely light weight IoC with ORM wrapping (JDO and >> >> > Hibernate) >> >> >> > is exPOJO at http://www.expojo.com >> >> >> > >> >> >> > No need for old fashioned DAOs etc., just POJOs being > persisted >> >> >> > transparently the way they should be. >> >> >> > >> >> >> > In terms of serialization: >> >> >> > >> >> >> > Is that for the purpose of scaling in a cluster environment? I >> > vote >> >> > for >> >> >> > 'session affinity' every time - it's almost necessary when you >> > have >> >> >> > anything more sophisticated than an anemic domain model. Do > you >> >> > really >> >> >> > want to be shifting complex object models from server to > server >> > via >> >> >> > serialization? >> >> >> > >> >> >> > If it's not for a cluster environment but for a single server > to >> >> > allow >> >> >> > stale sessions to be swapped out then let the garbage > collection >> >> > clean >> >> >> > out the ORM's object cache instead. >> >> >> > >> >> >> >> -----Original Message----- >> >> >> >> From: Igor Vaynberg [mailto:igor.vaynb...@gmail.com] >> >> >> >> Sent: Friday, 29 May 2009 3:38 AM >> >> >> >> To: users@wicket.apache.org >> >> >> >> Subject: Re: Anemic domain model and are @SpringBean's >> > compatible >> >> > with >> >> >> > the >> >> >> >> solution in "Spring 2.0 vs. the Anemic Domain Model"? >> >> >> >> >> >> >> >> On Thu, May 28, 2009 at 10:09 AM, Kent Larsson >> >> >> > <kent.lars...@gmail.com> >> >> >> >> wrote: >> >> >> >> > Nice! I think Salve looks great! And it solves more than > this >> >> >> > problem, >> >> >> >> > I like the design by contract module too as it allows me to >> >> > validate >> >> >> >> > parameters in a bit more declarative way. >> >> >> >> > >> >> >> >> > Do you think Salve is ready to be used in production? I'm a >> > bit >> >> >> >> > concerned by "Although already usable, Salve is still in > its >> >> >> > infancy. >> >> >> >> > Not all features have been implemented and not all problems >> >> > worked >> >> >> >> > out.". I only see one open issue and it doesn't seem too > major >> >> > for >> >> >> > me >> >> >> >> > to pick it up. >> >> >> >> >> >> >> >> we have been using it in production for a while without any >> >> > problems. >> >> >> >> i just need to find the time to update the website text :) >> >> >> >> >> >> >> >> > If I'm not mistaken Salve may be used (for lots of things, > but >> >> > one >> >> >> > is) >> >> >> >> > to solve serialization issues with Spring beans in Wicket >> >> >> > components? >> >> >> >> > But isn't that the same issue that the Wicket IOC and it's >> >> >> > @SpringBean >> >> >> >> > annotation solves? >> >> >> >> >> >> >> >> wicket ioc can only take it so far. because it has to > generate a >> >> > proxy >> >> >> >> there are limitations to what classes can be proxies - eg no >> > final >> >> >> >> methods, default constructor, etc. salve doesnt use a proxy > so >> > it >> >> >> >> doesnt have any problems. >> >> >> >> >> >> >> >> although small, wicket ioc does have an overhead of having to >> >> >> >> serialize the proxy with the componnet. since salve removes > the >> >> > field >> >> >> >> it has no such overhead, this is more important when you are >> >> > returning >> >> >> >> large resultsets of entities that use dependencies. >> >> >> >> >> >> >> >> > If that's the case: Could I use Spring to inject my > entities >> > with >> >> >> >> > DAO's for now, and use the @SpringBean annotation on those > as >> >> > well >> >> >> > in >> >> >> >> > my Wicket components (In those cases I have entities as > class >> >> > vars)? >> >> >> >> > And the @SpringBean will solve the serialization issue? >> >> >> >> >> >> >> >> you can use whatever works for you. salve is an alternative > :) >> >> >> >> >> >> >> >> > By just looking at Salve a bit it seems I could migrate to >> > Salve >> >> > in >> >> >> >> > two steps that way. And it might be a pretty smooth path to >> > take? >> >> > It >> >> >> >> > would mean that I inject 1000 entities for no good reason. > But >> > if >> >> > I >> >> >> >> > see a performance problem in doing so I could just migrate > to >> >> > Salve? >> >> >> >> > By smooth path I mean that I would have access to my DAO's > in >> > my >> >> >> >> > entities and would essentially only change the dependency >> >> >> > annotations >> >> >> >> > and setup Salve. >> >> >> >> >> >> >> >> as long as you do not use spring-specific injection rules you >> >> > should >> >> >> >> be fine. salve uses lookup by type primarily, but also does > have >> >> >> >> @SpringBeanId that can be used as a qualifier. >> >> >> >> >> >> >> >> >> >> >> >> > Of course, if Salve is production ready. Then could I throw >> > out >> >> >> > Wicket >> >> >> >> > IOC and the @SpringBean annotation and use Salve instead to >> > solve >> >> >> >> > serialization issues? In this case I would use Salve for my >> >> >> >> > presentation/Wicket -layer as well as dependency injection > in >> > my >> >> >> >> > entities and Spring as I already do for my service/business >> >> > -layer >> >> >> > and >> >> >> >> > my persistence/DTO -layer. Or would it be nicer to have > Salve >> >> > handle >> >> >> >> > dependencies in the last two layers as well? >> >> >> >> >> >> >> >> we use salve to inject across all layers. it gives you a >> > consistent >> >> >> >> approach to use and mock in unit tests. we have a spring > context >> >> > that >> >> >> >> contains true services - eg session factory, mail sender, > credit >> >> > card >> >> >> >> processor, etc. all of our domain model then uses salve to >> > inject >> >> >> >> these wherever needed. >> >> >> >> >> >> >> >> -igor >> >> >> >> >> >> >> >> > A lot of questions and text. Thanks for reading this far! > :-) >> >> >> >> > >> >> >> >> > Best regards, Kent >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > On Thu, May 28, 2009 at 5:36 PM, Igor Vaynberg >> >> >> > <igor.vaynb...@gmail.com> >> >> >> >> wrote: >> >> >> >> >> this is why i built salve.googlecode.com >> >> >> >> >> >> >> >> >> >> you can easily hook it into spring and have all your > objects >> >> > (doman >> >> >> >> >> objects or wicket components) injected via @Dependency >> > without >> >> >> >> >> worrying about serialization issues or eager injection - > eg >> > if >> >> > you >> >> >> >> >> load a result set of 1000 hibernate entities that need >> > injection >> >> >> > you >> >> >> >> >> dont want all those injected for no reason. >> >> >> >> >> >> >> >> >> >> -igor >> >> >> >> >> >> >> >> >> >> On Thu, May 28, 2009 at 6:38 AM, Kent Larsson >> >> >> > <kent.lars...@gmail.com> >> >> >> >> wrote: >> >> >> >> >>> Hi, >> >> >> >> >>> >> >> >> >> >>> Our current architecture: >> >> >> >> >>> --- >> >> >> >> >>> >> >> >> >> >>> We're currently using a 3-tier architecture > (presentation, >> >> >> >> >>> service/business and persistence) consisting of Wicket (+ > a >> >> > little >> >> >> >> >>> Spring), Spring and Spring + Hibernate: >> >> >> >> >>> >> >> >> >> >>> Wicket: >> >> >> >> >>> >> >> >> >> >>> Does presentation, we're not inside a transaction / >> > Hibernate >> >> >> > session >> >> >> >> >>> so all used fields must be loaded by Spring. We call > Spring >> >> >> > singleton >> >> >> >> >>> beans and annotate those fields with @SpringBean. >> >> >> >> >>> >> >> >> >> >>> Spring: >> >> >> >> >>> >> >> >> >> >>> In the service layer we have Spring singleton beans, >> > services, >> >> >> > which >> >> >> >> >>> are called from the Wicket layer. We have our transaction > / >> >> >> > Hibernate >> >> >> >> >>> session boundary at this layer. We call DAO's from this >> > layer. >> >> >> >> >>> >> >> >> >> >>> Spring + Hibernate: >> >> >> >> >>> >> >> >> >> >>> Our DAO's are Spring singleton beans which performs > database >> >> >> >> >>> operations using HibernateTemplate. >> >> >> >> >>> >> >> >> >> >>> And common to all the layers are our entities. We use the >> >> > @Entity >> >> >> >> >>> annotation on them (not XML), from the Wicket layer we > just >> > use >> >> >> > the >> >> >> >> >>> accessor methods making sure that the relevant fields are >> >> > loaded >> >> >> > (as >> >> >> >> >>> we would get an exception if they were Lazy and not yet >> >> > loaded). >> >> >> > Our >> >> >> >> >>> entities are stupid, they lack logic and are used mostly >> > like a >> >> >> > struct >> >> >> >> >>> in C/C++. >> >> >> >> >>> >> >> >> >> >>> I think the general pattern is pretty common for Java EE > and >> >> >> > Spring >> >> >> >> >>> based web applications (feel free to disagree!). Yet it's >> >> >> > classified >> >> >> >> >>> as an anti-pattern by Martin Fowler as we are using > mostly >> >> >> > procedural >> >> >> >> >>> programming and have an anemic domain model ( >> >> >> >> >>> http://en.wikipedia.org/wiki/Anemic_Domain_Model ). >> >> >> >> >>> >> >> >> >> >>> What I would like: >> >> >> >> >>> --- >> >> >> >> >>> >> >> >> >> >>> I would like to use a more OOP approach and have logic in >> > our >> >> >> > current >> >> >> >> >>> entities, creating a rich domain model. For that to work > in >> > all >> >> >> > cases >> >> >> >> >>> they need to be able to load and save data. I would still >> > use a >> >> >> > Spring >> >> >> >> >>> singleton bean's for different services. But instead of >> >> > changing >> >> >> > the >> >> >> >> >>> entities like structs they would be rich objects capable > of >> >> >> > chaning >> >> >> >> >>> themself's and other objects. >> >> >> >> >>> >> >> >> >> >>> I found this article very interesting: >> >> >> >> >>> >> > http://www.nofluffjuststuff.com/blog_detail.jsp?rssItemId=96860 >> >> >> >> >>> >> >> >> >> >>> But how would something like that work with Wicket? Could > I >> >> > just >> >> >> > use >> >> >> >> >>> @SpringBean like I'm currently doing but use it on both >> >> > "entities" >> >> >> > and >> >> >> >> >>> Spring singleton services? >> >> >> >> >>> >> >> >> >> >>> For me this has a purely practical benefit, as I could > use >> > some >> >> >> >> >>> inheritance in the domain object model to create > different >> >> >> > variations >> >> >> >> >>> of logic and not just data. Wicket feels quite agile and >> > nice >> >> > to >> >> >> > work >> >> >> >> >>> with, but I still feel that the current architecture is a >> > bit >> >> >> > stale >> >> >> >> >>> and seldom supports elegant OO solutions (that said, of >> > course >> >> >> > things >> >> >> >> >>> can still be solved elegantly, I just think it would be >> > easier >> >> > if >> >> >> > I >> >> >> >> >>> could do it in a more OO oriented way). >> >> >> >> >>> >> >> >> >> >>> Comments? What are the pros and cons of this kind of >> >> > architecture? >> >> >> >> >>> >> >> >> >> >>> All comments are greatly appreciated! >> >> >> >> >>> >> >> >> >> >>> Best regards, Kent >> >> >> >> >>> >> >> >> >> >>> >> >> >> > >> >> > >> > > --------------------------------------------------------------------- >> >> >> >> >>> To unsubscribe, e-mail: > users-unsubscr...@wicket.apache.org >> >> >> >> >>> For additional commands, e-mail: >> > users-h...@wicket.apache.org >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > >> > > --------------------------------------------------------------------- >> >> >> >> >> To unsubscribe, e-mail: > users-unsubscr...@wicket.apache.org >> >> >> >> >> For additional commands, e-mail: > users-h...@wicket.apache.org >> >> >> >> >> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> >> > >> > > --------------------------------------------------------------------- >> >> >> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> >> > For additional commands, e-mail: > users-h...@wicket.apache.org >> >> >> >> > >> >> >> >> > >> >> >> >> >> >> >> >> >> >> > >> > > --------------------------------------------------------------------- >> >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> >> >> >> >> >> >> No virus found in this incoming message. >> >> >> >> Checked by AVG - www.avg.com >> >> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release >> > Date: >> >> >> > 05/28/09 >> >> >> >> 18:09:00 >> >> >> > >> >> >> > >> >> > >> > > --------------------------------------------------------------------- >> >> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> > For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> > >> >> >> > >> >> >> >> >> >> >> > > --------------------------------------------------------------------- >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> >> >> >> No virus found in this incoming message. >> >> >> Checked by AVG - www.avg.com >> >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release > Date: >> >> > 05/28/09 >> >> >> 18:09:00 >> >> > >> >> > >> > > --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> > For additional commands, e-mail: users-h...@wicket.apache.org >> >> > >> >> > >> >> >> >> > --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> >> >> >> No virus found in this incoming message. >> >> Checked by AVG - www.avg.com >> >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date: >> > 05/28/09 >> >> 18:09:00 >> > >> > > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> >> No virus found in this incoming message. >> Checked by AVG - www.avg.com >> Version: 8.5.339 / Virus Database: 270.12.44/2140 - Release Date: > 05/28/09 >> 18:09:00 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
