OK, I just made the lifecycle changes and my application runs again.
This is a pretty good test (I do some funky stuff), at least on the
older code (I don't have any JPA/etc in it). I'm +1 for this
milestone release.
I'd like to put on my Devil's Advocate hat for a minute, though. (And
keep in mind I'm still a NeXTer at heart.) To get it working with the
new lifecycle stuff, I did:
1) Added the registry.addListener(LifecycleListener.POST_LOAD,
MyDataObject.class, "fetchFinished"); calls in my ApplicationListener
class. (It is a servlet-based application and this class receives the
contextInitialized event, which is where I registered.) This step
required me to go find all of my classes that implemented
fetchFinished() so I could register each of them.
2) I created a new DataContextUtility singleton class (I didn't have a
good globally-visible class available) to create new DataContexts.
The real purpose of this class was to store the
DataChannelCallbackInterceptor and ObjectStore instances so it could
later create a DataContext with them as parameters. I chose to create
the singleton so I wouldn't have to duplicate the code every place I
created a new DataContext.
3) I had to go update every place I created a new DataContext and have
it obtain one through the DataContextUtility singleton -- otherwise my
fetchFinished methods would not be called.
This all seemed to me to be a lot more work (and obfuscating) to
accomplish something that used to "just work" in the past. The simple
has become more complex (which seems to be the way of Java, with
subclassing being evil and such). Now instead of one place (and a
logical place in my mind) for the fetchFinished() code to reside, it
is scattered across many classes. And if you forget to register a
class, your method will never get called.
I'm not saying the lifecycle stuff isn't useful, but I'm not convinced
that making simple things more complex is a good thing, either.
Just my rambling thoughts ... comments welcome. Back to the original
thread of releasing now. :-)
Thanks,
/dev/mrg
On 7/27/07, Andrus Adamchik <andru..bjectstyle.org> wrote:
>
> On Jul 27, 2007, at 2:25 AM, Michael Gentry wrote:
>
> > Option 2 would be to remove it from the actual
> > code and documentation since it looks like it is still supported.
>
> That would be my preference too - let's remove it M2.
>
> Andrus
>
>
This archive was generated by hypermail 2.0.0 : Fri Jul 27 2007 - 09:29:15 EDT