There are other, just as simple options. A couple of examples below.
Really, you're not being "forced" to do this by Wicket. If you want to hold
*anything*, in *any* framework, in the HTTP session, it should be
serializable. If you don't want to be forced to do it, don't hold it in the
session. Hold a lookup of some sort in the session, or don't hold it in the
session at all - that's your design choice.
Here's an example of what I think you're talking about with your classes,
and one possible solution. I haven't tested the code, but the theory is
good.
import java.io.ObjectStreamException;
import java.io.Serializable;
import java.util.HashMap;
import java.util.Map;
public class FlyweightOne implements Serializable {
private static final long serialVersionUID = 1L;
private static final Map<String, FlyweightOne> INSTANCES = new
HashMap<String, FlyweightOne>();
public static final FlyweightOne THING_A = new FlyweightOne("a");
public static final FlyweightOne THING_B = new FlyweightOne("b");
public static final FlyweightOne THING_C = new FlyweightOne("c");
public static final FlyweightOne THING_D = new FlyweightOne("d");
private final String ID;
private FlyweightOne(String id) {
ID = id;
INSTANCES.put(id, this);
}
private Object readResolve() throws ObjectStreamException {
return INSTANCES.get(ID);
}
}
OR - you could create one class that takes the class name and the instance
name or ID as a parameter (and is serializable), and when it needs to
deserialize, it can look up the appropriate instance. Since you'd probably
be using reflection, I'd cache the lookups after they're done the first
time. Pretty simple, and one single class, used globally.
Hope this helps. I'm only disagreeing on the part about it being Wicket
forcing you to do it.
--
Jeremy Thomerson
http://www.wickettraining.com
On Thu, Jul 24, 2008 at 2:22 PM, Fabrizio Giudici <
[EMAIL PROTECTED]> wrote:
>
> On Jul 24, 2008, at 20:39 , Jeremy Thomerson wrote:
>
> 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.
>>
>
> I know that technique (but thanks for the pointer), I've implemented it for
> other "unique" objects in a different project, where they _need_ to be
> serializable, because they are transferred over the network. But in that
> case the extra work is justified by the network - I mean, you must do that
> because it's a distributed environment. I find still funny to be forced to
> do the same in an application which is not distributed in nature. If I'm
> forced to write extra code, probably some model wrapper is better at this
> point, and probably it's worth while spend a few time to try finding
> something that can be extensively reused in the same project for different
> classes (this is what I referred to "design workaround" in my first mail).
> But, I repeat, I feel like it would be better if I wouldn't be forced to do
> that.
>
> BTW, things are more complex than your example: my objects are not
> "singletons", rather they are similar to "flyweights", they are instantiated
> in multiple instances, but have an uniqueness constraint - that is, each
> instance represents a concept (say, with an internal id) and there can't be
> two instances with the same id.
>
> --
> 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]
>
>
