Wow, this is a pretty specialised case. And I can't say I entirely like such a specialised call back in the listener, although I can't think of an alternative way of achieving the same. I presume you need this in 1.4.1 though, for AS 4.2?
Also, as an FYI, the way the marshalling works in 2.0.0 for ST is that a List of NodeData objects is passed to the VAM. I suppose the callbacks could happen before and after generating each NodeData object in a loop.
And would the callback be for every node being marshalled for ST, or the fqn representing the region/subroot?
No, I don't think I want this for 1.4.1.SP1. I think I can use something like this:
1) Call prePassivate before caching any context.
2) Call postActivate after getting any context (to hand out to a request).
That means the context will be in the passivated state when state transfer occurs.
Whether in 2.0 having an event anyway makes sense, I still think it does, as it's a pretty major operation to happen to a node (bigger IMHO than a visit) and we emit callbacks for everything. But I don't feel at all strongly about it. How about this -- if you (or anyone) think it's really bad, veto it and we're done. :-) If you don't think it's that bad an idea, I'll open an unassigned JIRA for Beta2. If someone (aka Brian) gets it done, fine. If not, we WON'T_FIX the JIRA. Feature prioritization. :)
I was too wishy-washy above. I meant: "No, I don't want this for 1.4.1.SP1".
:-) Ok, if that's the case then I will veto it for 2.0.0. I was just concerned that you did not have any other way to be compliant with the EJB3 spec. Since you do, I'd rather not have this callback.
I think this is a very specific callback (region being marshalled for ST) and is very implementation/release specific, and only will be of use to very few applications/use cases.
Wouldn't it be possible to create your own state transfer wrapper that intercepted this?
Actually don't see any APIs that allow you to customize this..