geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gianny Damour <>
Subject Re: Incompatible API change in Configuration
Date Wed, 06 Apr 2005 11:12:40 GMT
Personally, I don't mind redeploying all my configurations when 
upgrading to a newer release. I even think that I would tend to  
redeploy all of them just to make sure that they can be successfully 
deployed with the new version.

To some extent, I think that binary compatibility between sub-modules 
matters. Let's assume that (this is a scenario that I am considering; 
any ressemblance is pure coincidence):
* I run M3;
* EJB is allegedegly broken; and
* I am happy with the other service stack.

Should I upgrade to M4, where EJB is fixed? Or, should I partially 
upgrade openejb-core and openejb-builder if I know that they are binary 
compatible with the depending sub-modules?

Another scenario is where a newer version of a given sub-module brings 
additional capabilities that I badly want. Also, in this case, I will 
only partially update.

It seems that binary compatibility is only a part of the overall picture 
if one wants to support forward-portability of backed configurations. 
Let's assume that I have a configuration defining a CMP 2.x deployment. 
This configuration contains a bunch of serialized CMPField instances. I 
want to upgrade to a newer server version defining a CMPField class with 
an additional field. I think that we will face some serialization 
incompatibilities when reading back the GBean state.

I agree: I'm happy to worry about that way way way further down the road.


On 5/04/2005 4:17 AM, Dain Sundstrom wrote:

> I personally think this is way way way too early to be worried about 
> binary compatability between configuration objects build with pervious 
> releases and builds.  Also, are you taking only about the official M1, 
> M2 and M3 releases or builds from code?
> What do you, the community, think about us spending time thinking 
> about binary compatibility between milestone releases?
> -dain
> -- 
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
> On Apr 4, 2005, at 3:08 AM, Gianny Damour wrote:
>> My bad :(
>> I must admit that this is a side effect that I have not duly 
>> considered. I considered the source and binary compatibility and I 
>> missed this serialization specific incompatibility.
>> Gianny
>> On 3/04/2005 6:15 AM, Jeremy Boynes wrote:
>>> On 3/22 in revision 158589 the API for Configuration changed in that 
>>> the return type from getConfigurationClassLoader() changed from 
>>> ClassLoader to a ConfigurationClassLoader. This means all 
>>> configurations built before then are now inoperable with the current 
>>> tree as the attribute type in the persisted GBeanData does not match 
>>> the new signature.
>>> I can't find any discussion on the list around then that would alert 
>>> users to this change. It is critical that we let people know when 
>>> this kind of change is made.
>>> -- 
>>> Jeremy

View raw message