It looks like my earlier message didn't go through. If really your big
problem is that you have singleton restraints, where there must be only one
instance ever of a particular object, Wicket is NOT the problem. Anytime
you have that constraint, there are defensive programming things that you
need to consider, even without Wicket. Joshua Bloch describes this well in
Effective Java. To get around the problem you have, simply override
readResolve and return the unique instance of that class. This can also be
done with enums, etc, by overriding the serialization methods to provide
custom serialization. And this *should* be done at any time that you think
something is going to be serialized and you have unique constraints such as
this.
There are no helper classes needed. Just implement the readResolve method
as follows:
import java.io.ObjectStreamException;
import java.io.Serializable;
public final class FakeSingletonUtil implements Serializable {
private static final long serialVersionUID = 1L;
private static final FakeSingletonUtil INSTANCE = new
FakeSingletonUtil();
private FakeSingletonUtil() {
// no-op constructor - hides it from public instantiation
}
private Object readResolve() throws ObjectStreamException {
// instead of allowing a new object to be created, return the
singleton
return INSTANCE;
}
}
You could also implement the
Object writeReplace() throws ObjectStreamException
method so that you can provide custom serialization - say if this class were
an enumumeration of singletons. You could return a single integer or String
value that you could then resolve to a particular instance (like in a switch
statement) in readResolve.
Hopefully this link works for you, but look in page 11 of Effective Java:
http://books.google.com/books?id=ZZOiqZQIbRMC&dq=effective+java&pg=PP1&ots=UZL1bofF1-&sig=dBD-gGBBUf_FISklBa_nuocTTOg&hl=en&sa=X&oi=book_result&resnum=1&ct=result#PPA11,M1
I highly recommend this book to anyone who has not read it. I look forward
to reading the new edition that also deals with generics, etc, since I have
not read this book in many years.
I hope this helps!
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Jul 24, 2008 at 8:58 AM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:
>
> ----- Original Message -----
> Da : "Matej Knopp" <[EMAIL PROTECTED]>
> A : users@wicket.apache.org
> Oggetto : Re: "This time last year" .... is Wicket really a
> disappointment?
> Data : Thu, 24 Jul 2008 15:45:49 +0200
>
> > Too many constrains? Really?
> > Just write a model that pull the image from whatever you
> > want (even as static object property for that matter).
> > Just because the model is serializable doesn't mean that
> > the model object has to be serializable. That's a big
> > differece.
>
> It's what I've done for v1. But it's what I don't like: for
> every model object I have to write a separate class. Now,
> I've been used to write adapter classes such as in this case
> for years, and usually I didn't complain very much. In EJB
> and JSF after all you have lots of code and complexity.
> Turning to Spring (but also EJB3) in the latest years I've
> been able to get rid of a lot of code in the business layer.
> My disappointment with Wicket is that I believed that it
> would have enabled me to do the same in the presentation
> layer.
>
>
> --
> Fabrizio Giudici, Ph.D. - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -
> www.tidalwave.it/blog
> [EMAIL PROTECTED] - mobile: +39 348.150.6941
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
