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 <[EMAIL PROTECTED]> 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 > >
