Yep, we use HttpSessionStore in a non clustered environment.
We also turn off session persistence in Tomcat in context.xml with
<Manager pathname="" />
So we there should be no session spooling to disk by the servlet
container.
Cool, I can relax now =]
> 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
>
>
> 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
