I am by no means advocating introducing this for 1.0.2. I am sorry if I didn't make this clear. I was talking about doing this *post* 1.0.2.
-Andrew -----Original Message----- From: Ilkka Priha [mailto:[EMAIL PROTECTED] Sent: Fri 3/18/2005 1:48 AM To: OJB Developers List Subject: Re: Feature Proposal: Bytecode generated Proxies Why not release 1.0.2 ASAP with the current functionality, as the community has wished for it ever since 1.0.1 because of the small as such but pretty nasty hash code bug in cache handling, and release 1.0.3 with new stuff quite soon after it. Then we would get a labeled release known to be compatible with current apps (have had several months of time to test it ;-)). Proxy stuff typically generates strange compatibility issues and resolving them might delay the next 1.0.x release some more months. -- Ilkka Clute, Andrew wrote: >>From what I can tell at this point, providing a drop-in-replacement for >>proxies is extremely doable -- there should be no significant change. >>Provided that is the case, I would like to get a consensus that it would be >>acceptable to introduce that functional swap in the 1.0.X line (post 1.0.2). > > Part of my motivation is that I would like to get this introduced into *my* > current production system, and I don't want to deviate to far from official > releases of OJB (I have maintained separate versions a couple of times, but > it is a pain). > > At the same time, a new proxy system can be introduced into HEAD that > incorporates a plug-in style model. Get the best of both worlds: an immediate > scratch to the itch (or is that itch to a scratch) and a long-term clean, > flexible solution. > > Assuming this is acceptable, does anyone have comments or suggestions on the > changes I proposed to the metadata to support this? > > -Andrew > > > -----Original Message----- > From: Martin Kal�n [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 17, 2005 2:52 PM > To: OJB Developers List > Subject: Re: Feature Proposal: Bytecode generated Proxies > > > I agree with Tom that this work is best done in HEAD if it's not a > drop-in-replacement for 1.0.2, however it might be a bit of overworking it to > provide a pluggable approach in 1.0.x-branch. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > . > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
