Say Jon schrieb:
public void prepare() throws Exception {
super.prepare();
BaseEntity model = null;
if (getId() != null) {
model = (BaseEntity) session.get(getEmbeddedModelKey() + getId());
if (model == null) model = service.retrieve(modelClass, getId());
}
if (model == null && !(this instanceof EmbeddedDrivenAction)) model =
getNewModel();
setModel(model);
}
This code does not look particularly wrong. It does what we also do
frequently (without the service.retrieve() part and without the user
using several sessions for his work). So i guess that your problem is
not located here.
I have another class EmbeddedDrivenAction which subclasses
ModelDrivenAction:
public void prepare() throws Exception {
//call modeldriven's prepare to load in the model
super.prepare();
if (embeddedModelClass != null)
setEmbeddedModel((IEmbeddable)Class.forName(embeddedModelClass).newInstance());
Object suffixObj = (getId()!= null?getId():getParentId());
String suffix = "";
if (suffixObj != null) suffix = suffixObj.toString();
String sessionKey = getEmbeddedModelKey() + suffix;
//for main action, will use id
if (session.get(sessionKey) == null) { // for main action
if (getModel() == null) setModel(getNewModel());
if (!WebUtility.getInstance().isReloadPagePreservingValues(session))
removeSessionObjects();
session.put(sessionKey, getModel());
}
//for embedded action, will use parentid
else {
setModel((BaseEntity) session.get(sessionKey));
}
}
This is how my model is initialized. It will first check if the model have
been put into the session (I'm using an architecture whereby the user is
using 2 or more screens for the same model object). If eventually the model
is not found, the getNewModel() object will return a newly instantiated
model. In any case, a instantiated model will definitely be returned.
I didn't check (and in fact, not completely understand) your code above,
but i think you should investigate a bit further into the area below:
According to my first email, my call chain is "userAddress.country.id". If I
don't remember wrongly, if my userAddress is null, Struts will initialize it
for me. If my country is null, Struts will also initialize it for me. After
both are initialized, the ID is set. In all cases, Struts will initialize
the objects in the chain and apply the final value. Pls correct me if I'm
wrong here.
I can't tell you off the top of my head, but i'd suggest to verify your
assumption with the debugger. If your assumption is correct, theny you
should see calls to getUserAddress(), getCountry() and getId(). We here
in our application frequently use nested instances and we always make
sure that anything that is necessary for such a call chain is
initialized properly by our own code. My strong guess is that Struts
does not initalize the objects for you. (And, btw, even if it did: How
would your container class obtain the correct reference to the object
created for you by Struts?) And how would the ultimate setter be then
called on an instance that is referenced from the object at the start of
your call chain? Try to use lazy initialization and reference
bookkeeping when your getter method is accessed and you find your local
member variable pointer null.
For point 3, what do you mean by "not ok"? Pls elaborate on that if
possible.
By "not ok" i meant that your parent object does not have all its child
objects correctly initialized so that when Struts calls along your
object nesting chain, it encounters null return values and either has to
deal with NPEs or (if your guess that it initializes objects on the fly
which i'm still a bit unsure about) it creates new instances that only
live in the nether outside of your original object. So if you later need
to query the value of an object further down the call chain, all parent
objects need correct references to the child objects. I'm not aware of
any mechanism in Struts to establish such a proper reference chain for
you, so you need to make sure that is exists before Struts comes into play.
The behavior you describe hints that your reference chain somehow gets
broken during the lifetime of your model object so that your call chains
don't work correctly anymore.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscr...@struts.apache.org
For additional commands, e-mail: user-h...@struts.apache.org
