Build Failure

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Build Failure

ammulder
        Okay, I am building offline, but this seems a little silly:

$ maven -o
...
+----------------------------------------
| Executing default Geronimo Packaging Plugin
| Memory: 50M/89M
+----------------------------------------

BUILD FAILED
File......
/Users/ammulder/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly
Element... maven:reactor
Line...... 217
Column.... 9
The build cannot continue because of the following unsatisfied dependency:

geronimo-kernel-1.0-169154.jar

        Why are we depending on this one super-specific version of the
kernel instead of the version that I just built as part of the build?

Thanks,
        Aaron
Reply | Threaded
Open this post in threaded view
|

Re: Build Failure

Jeremy Boynes
Aaron Mulder wrote:
> The build cannot continue because of the following unsatisfied dependency:
>
> geronimo-kernel-1.0-169154.jar
>
> Why are we depending on this one super-specific version of the
> kernel instead of the version that I just built as part of the build?
>

Because we do not maintain API or serialization compatibility.
--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: Build Failure

ammulder
On Fri, 13 May 2005, Jeremy Boynes wrote:
> Because we do not maintain API or serialization compatibility.

        Okay, that makes sense.  I guess it's the serialized configuration
information that's a problem?  And if the Maven plugin writes your
serialized stuff and a later version of the Maven plugin reads it, then
things are OK?  What if the config was written by tools generated from a
HEAD build and then you try to deploy to that server with the Maven tool?  
Would that be expected to fail?

Aaron
Reply | Threaded
Open this post in threaded view
|

Re: Build Failure

Dain Sundstrom
In reply to this post by ammulder
On May 13, 2005, at 1:42 PM, Aaron Mulder wrote:

>     Okay, I am building offline, but this seems a little silly:
>
> $ maven -o
> ...
> +----------------------------------------
> | Executing default Geronimo Packaging Plugin
> | Memory: 50M/89M
> +----------------------------------------
>
> BUILD FAILED
> File......
> /Users/ammulder/.maven/cache/maven-multiproject-plugin-1.3.1/
> plugin.jelly
> Element... maven:reactor
> Line...... 217
> Column.... 9
> The build cannot continue because of the following unsatisfied  
> dependency:
>
> geronimo-kernel-1.0-169154.jar
>
>     Why are we depending on this one super-specific version of the
> kernel instead of the version that I just built as part of the build?

it is here

http://cvs.apache.org/repository/geronimo/jars/geronimo- 
kernel-1.0-169154.jar

-dain
Reply | Threaded
Open this post in threaded view
|

Re: Build Failure

ammulder
On Fri, 13 May 2005, Dain Sundstrom wrote:
> it is here
>
> http://cvs.apache.org/repository/geronimo/jars/geronimo- 
> kernel-1.0-169154.jar

        Thanks -- I'll probably just suck it up and do an online build, at
least from that directory.  :)  I was just wondering why that particular
version of the kernel was necessary.

Aaron
Reply | Threaded
Open this post in threaded view
|

API and serialization compatibility, was: Build Failure

Jeremy Boynes
In reply to this post by ammulder
Aaron Mulder wrote:

> On Fri, 13 May 2005, Jeremy Boynes wrote:
>
>>Because we do not maintain API or serialization compatibility.
>
>
> Okay, that makes sense.  I guess it's the serialized configuration
> information that's a problem?  And if the Maven plugin writes your
> serialized stuff and a later version of the Maven plugin reads it, then
> things are OK?  What if the config was written by tools generated from a
> HEAD build and then you try to deploy to that server with the Maven tool?  
> Would that be expected to fail?
>

The real issue here is that there is no way to specify the dependency
version for jars in the root config of the target configuration and as a
result then they get loaded from the classloader being used by the
deployer. This effectively means the kernel version for all
configurations must be exactly the same.

This is an issue for the packaging plugin as it uses a serialized
configuration for the deployer.

The lack of compatibility, however, is a problem in general as it means
you need to redeploy everything for each new version of Geronimo.

There is a solution to the classloader but I have been holding off
making any kernel changes until after certification. If it would be
useful, let me know.

Solving the compatibility problem will require the developers to pay
attention to versioning. We will need to require that at some point though.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

David Blevins
On Fri, May 13, 2005 at 03:42:58PM -0700, Jeremy Boynes wrote:

> Aaron Mulder wrote:
> >On Fri, 13 May 2005, Jeremy Boynes wrote:
> >
> >>Because we do not maintain API or serialization compatibility.
> >
> >
> > Okay, that makes sense.  I guess it's the serialized configuration
> >information that's a problem?  
> >[...]
>
> The lack of compatibility, however, is a problem in general as it means
> you need to redeploy everything for each new version of Geronimo.
>
[...]
>
> Solving the compatibility problem will require the developers to pay
> attention to versioning. We will need to require that at some point though.

Paying attention is an understatement.  In order to serialize data to and from class definitions, those classes cannot change in any significant way, ever.  No refactoring, repackaging, reorganizing, no removing methods, no removing class variables.  This doesn't just apply to public APIs, but even the internal classes of each component.

Considering that at deploy time we are building and serializing Jetty web containers, Tomcat web containers, ActiveMQ queues/topics, OpenEJB ejb containers, Axis webservices, TranQL connectors and more, is it reasonable to ask or expect these projects basically not to change their code?

Clearly, projects will clean and improve their code, we can't and shouldn't try and stop them.  We want them to optimize and improve things.  As this change is going to occur, people *will* have to redeploy their apps as we support no other way to store configurations.

Serializing and deserializing server state for fast startup is a cool feature, but not something we are in any position to guarantee between releases of Axis, ActiveMQ, OpenEJB, Jetty, Tomcat, et. al.


-David
Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

ammulder
In reply to this post by Jeremy Boynes
On Fri, 13 May 2005, Jeremy Boynes wrote:
> ...
> Solving the compatibility problem will require the developers to pay
> attention to versioning. We will need to require that at some point though.

        Yeah, I think we'll want to set a lot of serial IDs...  Perhaps we
ought to plan on a big pass before the "1.0" release, so our bug fix
release don't immediately break serialization compatibility.  Anyway, not
a big deal right this second.

Aaron
Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Jeremy Boynes
Aaron Mulder wrote:

> On Fri, 13 May 2005, Jeremy Boynes wrote:
>
>>...
>>Solving the compatibility problem will require the developers to pay
>>attention to versioning. We will need to require that at some point though.
>
>
> Yeah, I think we'll want to set a lot of serial IDs...  Perhaps we
> ought to plan on a big pass before the "1.0" release, so our bug fix
> release don't immediately break serialization compatibility.  Anyway, not
> a big deal right this second.
>

Given the number to do, perhaps we should start now ;-)
--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Jeremy Boynes
In reply to this post by David Blevins
David Blevins wrote:

> On Fri, May 13, 2005 at 03:42:58PM -0700, Jeremy Boynes wrote:
>> Solving the compatibility problem will require the developers to
>> pay attention to versioning. We will need to require that at some
>> point though.
>
>
> Paying attention is an understatement.  In order to serialize data to
> and from class definitions, those classes cannot change in any
> significant way, ever.  No refactoring, repackaging, reorganizing, no
> removing methods, no removing class variables.  This doesn't just
> apply to public APIs, but even the internal classes of each
> component.
>

In other words, the level of stability users expect from
enterprise-grade software.

<snip/>
>
> Serializing and deserializing server state for fast startup is a cool
> feature, but not something we are in any position to guarantee
> between releases of Axis, ActiveMQ, OpenEJB, Jetty, Tomcat, et. al.
>

True, but the configuration management archtecture in Geronimo is
designed to handle this. The main principle behind it is that the
bundles being run are, to the largest extent possible, pre-built and
ready to go. There are two things in play here - the code and the data.

For the code, each configuration defines precisely the codebase it uses.
Right now, it uses the *UNIQUE* id of its parent config plus the
*UNIQUE* version numbers of its repository dependenies.

The emphasis on *UNIQUE* is critical - it means the version of code that
the configuration uses (both internal and external) is known precisely.
That means we can guarantee that the the configuration state can be
restored. How that it is done is a matter of implementation; we use
serialization because it is fast and requires less infrastructure but we
could just have easily used XML. The data versioning problem applies
equally to both. In other words, we don't use serialization just to get
fast startup, we use it because it is an effective way to store
configuration state.


Right now we have a very restrictive model where we only allow exact
matching of codebase versions. This works well in a development
environment where a lot of things are changing and being rebuilt all the
time for but production rollout we always knew that this would need to
be enhanced to support looser binding (the so-called 'capabilities model').

With that in place, the builders can choose how tightly the bind the
generated configuration to the runtime environment. For some components
they may still choose to bind precisely, perhaps because there is some
implementation issue, or perhaps because the component itself handles
skewed versions. For other components, it might specify a looser binding
letting the runtime configuration management system choose which
implementation to use.


Another thing to remember is that the only classes where serialization
compatibility really matters are those that are actually placed in
persistent attributes. I would hope all the projects we use do support
serialization properly, including providing UIDs and dealing with
version drift; if not we should encourage them to do so and help where
necessary - it is generally a /good thing/. That will make configuration
management easier for both system administrators as well as the runtime
and deployment systems.


Coming back to the original issue though, there are some places where
all the configuration management magic in the world can't help -
specifically in the kernel and in the configuration management system
itself. It is critical that the APIs and implementations there are
stable and that they support serialization properly.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

David Blevins
On Sat, May 14, 2005 at 09:47:31AM -0700, Jeremy Boynes wrote:

> David Blevins wrote:
> >On Fri, May 13, 2005 at 03:42:58PM -0700, Jeremy Boynes wrote:
> >>Solving the compatibility problem will require the developers to
> >>pay attention to versioning. We will need to require that at some
> >>point though.
> >
> >
> >Paying attention is an understatement.  In order to serialize data to
> >and from class definitions, those classes cannot change in any
> >significant way, ever.  No refactoring, repackaging, reorganizing, no
> >removing methods, no removing class variables.  This doesn't just
> >apply to public APIs, but even the internal classes of each
> >component.
> >
>
> In other words, the level of stability users expect from
> enterprise-grade software.

I can't argue with you there.  Code not changing significantly from release to release is the ultimate of stable....

Who needs bug fixes and optimizations anyway ;-)

-David
Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

ammulder
In reply to this post by Jeremy Boynes
        Okay, well, as long as we've opened this can of worms...

        Jeremy, what is your intention WRT editing configurations without
the server running?  For example, let's say you do a default install, but
do not start the server.  Now you start a different product that binds to
port 8080.

        At this point, I think you'll be unable to start Geronimo due to
the port conflict (assuming that J2EE services are enabled).  You're also
unable to change the Jetty port without re-installing, and then only if
you use the installer rather than a ZIP distribution.  Needless to say,
and web-based configuration or management system is also inaccessible.

        This certainly seems like a good case for XML based configuration
state, where you could trivially edit a config file to change the Jetty
port and *then* start the server.  But it's not the only option.  Do you
have a vision for some kind of tool that would let you change the server
configuration while it is not running?  Perhaps something that will let
you deserialize and edit arbitrary configurations?

        I'm also assuming that the end user does not have access to (or
substantial knowledge of) the plans used to construct the server in the
first place.

Aaron

P.S. I also feel that it would be unfortunate if the kernel APIs changed
across bug-fix releases.  So I'm happy to try to freeze those.

On Sat, 14 May 2005, Jeremy Boynes wrote:

> David Blevins wrote:
> > On Fri, May 13, 2005 at 03:42:58PM -0700, Jeremy Boynes wrote:
> >> Solving the compatibility problem will require the developers to
> >> pay attention to versioning. We will need to require that at some
> >> point though.
> >
> >
> > Paying attention is an understatement.  In order to serialize data to
> > and from class definitions, those classes cannot change in any
> > significant way, ever.  No refactoring, repackaging, reorganizing, no
> > removing methods, no removing class variables.  This doesn't just
> > apply to public APIs, but even the internal classes of each
> > component.
> >
>
> In other words, the level of stability users expect from
> enterprise-grade software.
>
> <snip/>
> >
> > Serializing and deserializing server state for fast startup is a cool
> > feature, but not something we are in any position to guarantee
> > between releases of Axis, ActiveMQ, OpenEJB, Jetty, Tomcat, et. al.
> >
>
> True, but the configuration management archtecture in Geronimo is
> designed to handle this. The main principle behind it is that the
> bundles being run are, to the largest extent possible, pre-built and
> ready to go. There are two things in play here - the code and the data.
>
> For the code, each configuration defines precisely the codebase it uses.
> Right now, it uses the *UNIQUE* id of its parent config plus the
> *UNIQUE* version numbers of its repository dependenies.
>
> The emphasis on *UNIQUE* is critical - it means the version of code that
> the configuration uses (both internal and external) is known precisely.
> That means we can guarantee that the the configuration state can be
> restored. How that it is done is a matter of implementation; we use
> serialization because it is fast and requires less infrastructure but we
> could just have easily used XML. The data versioning problem applies
> equally to both. In other words, we don't use serialization just to get
> fast startup, we use it because it is an effective way to store
> configuration state.
>
>
> Right now we have a very restrictive model where we only allow exact
> matching of codebase versions. This works well in a development
> environment where a lot of things are changing and being rebuilt all the
> time for but production rollout we always knew that this would need to
> be enhanced to support looser binding (the so-called 'capabilities model').
>
> With that in place, the builders can choose how tightly the bind the
> generated configuration to the runtime environment. For some components
> they may still choose to bind precisely, perhaps because there is some
> implementation issue, or perhaps because the component itself handles
> skewed versions. For other components, it might specify a looser binding
> letting the runtime configuration management system choose which
> implementation to use.
>
>
> Another thing to remember is that the only classes where serialization
> compatibility really matters are those that are actually placed in
> persistent attributes. I would hope all the projects we use do support
> serialization properly, including providing UIDs and dealing with
> version drift; if not we should encourage them to do so and help where
> necessary - it is generally a /good thing/. That will make configuration
> management easier for both system administrators as well as the runtime
> and deployment systems.
>
>
> Coming back to the original issue though, there are some places where
> all the configuration management magic in the world can't help -
> specifically in the kernel and in the configuration management system
> itself. It is critical that the APIs and implementations there are
> stable and that they support serialization properly.
>
> --
> Jeremy
>
>
Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Tim Ellison-2
In reply to this post by Jeremy Boynes
Jeremy Boynes <[hidden email]> wrote on 14-05-2005 17:47:31:
> <lots of good stuff snipped />
>
> Another thing to remember is that the only classes where serialization
> compatibility really matters are those that are actually placed in
> persistent attributes. I would hope all the projects we use do support
> serialization properly, including providing UIDs and dealing with
> version drift; if not we should encourage them to do so and help where
> necessary - it is generally a /good thing/. That will make configuration

> management easier for both system administrators as well as the runtime
> and deployment systems.

Glad you agree ;-)
   http://issues.apache.org/jira/browse/GERONIMO-644

Regards,
Tim
Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Jeremy Boynes
In reply to this post by ammulder
Aaron Mulder wrote:
> Okay, well, as long as we've opened this can of worms...
>
> Jeremy, what is your intention WRT editing configurations without
> the server running?  

You know I'm not going to give a short answer to a question like that
;-) I'm going to move it to another thread.

> For example, let's say you do a default install, but
> do not start the server.  Now you start a different product that binds to
> port 8080.
>
> At this point, I think you'll be unable to start Geronimo due to
> the port conflict (assuming that J2EE services are enabled).  You're also
> unable to change the Jetty port without re-installing, and then only if
> you use the installer rather than a ZIP distribution.  Needless to say,
> and web-based configuration or management system is also inaccessible.
>
> This certainly seems like a good case for XML based configuration
> state, where you could trivially edit a config file to change the Jetty
> port and *then* start the server.  But it's not the only option.  Do you
> have a vision for some kind of tool that would let you change the server
> configuration while it is not running?  Perhaps something that will let
> you deserialize and edit arbitrary configurations?
>
> I'm also assuming that the end user does not have access to (or
> substantial knowledge of) the plans used to construct the server in the
> first place.
>

I think that's not a good assumption. We should not expect them to be
hacking XML but reconstructing configurations should be a routine matter
not a /big thing/. But more in that other thread...

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Dain Sundstrom
In reply to this post by Tim Ellison-2
Tim,

As you point out, the problem of serialization is far reaching.  
Basically, we need to get every project included in Geronimo to buy  
into serialization stability, and to my knowledge there are no  
projects in Geronimo that today have committed to this.  In addition,  
Geronimo itself is does not support serialization stability, and if  
we choose this path, we must clean up our own house by verifying  
every serializable class is set up for upward compatible  
serialization.  This is by no means an easy task, but I think before  
we ask something of other project we are aware of the effort involved  
in what we are asking.

Alternatively, we could choose to do like Sun did with swing and give  
up on serialization and use an xml based storage mechanism based on  
Java Beans rules.

-dain


On May 14, 2005, at 1:13 PM, Tim Ellison wrote:

> Jeremy Boynes <[hidden email]> wrote on 14-05-2005 17:47:31:
>
>> <lots of good stuff snipped />
>>
>> Another thing to remember is that the only classes where  
>> serialization
>> compatibility really matters are those that are actually placed in
>> persistent attributes. I would hope all the projects we use do  
>> support
>> serialization properly, including providing UIDs and dealing with
>> version drift; if not we should encourage them to do so and help  
>> where
>> necessary - it is generally a /good thing/. That will make  
>> configuration
>>
>
>
>> management easier for both system administrators as well as the  
>> runtime
>> and deployment systems.
>>
>
> Glad you agree ;-)
>    http://issues.apache.org/jira/browse/GERONIMO-644





Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Jeremy Boynes
Dain Sundstrom wrote:

> Tim,
>
> As you point out, the problem of serialization is far reaching.  
> Basically, we need to get every project included in Geronimo to buy  
> into serialization stability, and to my knowledge there are no  projects
> in Geronimo that today have committed to this.  In addition,  Geronimo
> itself is does not support serialization stability, and if  we choose
> this path, we must clean up our own house by verifying  every
> serializable class is set up for upward compatible  serialization.  This
> is by no means an easy task, but I think before  we ask something of
> other project we are aware of the effort involved  in what we are asking.
>
> Alternatively, we could choose to do like Sun did with swing and give  
> up on serialization and use an xml based storage mechanism based on  
> Java Beans rules.
>

The issue is not the implementation (serialization vs. XML) but the
compatibility of the information set between versions.

As David Jencks has pointed out elsewhere, we do not need every project
to commit to serialization stability everywhere, just in the classes
that are being used in GBean attributes. If they do great; if they don't
we just don't use those classes as attribute values and handle
reconstruction ourselves.

And after all, one requirement Sun place on a JavaBean is that it is
Serializable.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Jeremy Boynes
In reply to this post by David Blevins
David Blevins wrote:

> On Sat, May 14, 2005 at 09:47:31AM -0700, Jeremy Boynes wrote:
>
>> David Blevins wrote:
>>
>>>
>>> Paying attention is an understatement.  In order to serialize
>>> data to and from class definitions, those classes cannot change
>>> in any significant way, ever.  No refactoring, repackaging,
>>> reorganizing, no removing methods, no removing class variables.
>>> This doesn't just apply to public APIs, but even the internal
>>> classes of each component.
>>>
>>
>> In other words, the level of stability users expect from
>> enterprise-grade software.
>
>
> I can't argue with you there.  Code not changing significantly from
> release to release is the ultimate of stable....
>
> Who needs bug fixes and optimizations anyway ;-)
>

I would not classify "refactoring, repackaging, reorganizing, [no]
removing methods, [no] removing class variables" as "bug fixes and
optimizations", but heck, I only want it to work reliably.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Dain Sundstrom
In reply to this post by Jeremy Boynes
On May 14, 2005, at 3:56 PM, Jeremy Boynes wrote:

> Dain Sundstrom wrote:
>
>> Tim,
>> As you point out, the problem of serialization is far reaching.    
>> Basically, we need to get every project included in Geronimo to  
>> buy  into serialization stability, and to my knowledge there are  
>> no  projects in Geronimo that today have committed to this.  In  
>> addition,  Geronimo itself is does not support serialization  
>> stability, and if  we choose this path, we must clean up our own  
>> house by verifying  every serializable class is set up for upward  
>> compatible  serialization.  This is by no means an easy task, but  
>> I think before  we ask something of other project we are aware of  
>> the effort involved  in what we are asking.
>> Alternatively, we could choose to do like Sun did with swing and  
>> give  up on serialization and use an xml based storage mechanism  
>> based on  Java Beans rules.
>>
>
> The issue is not the implementation (serialization vs. XML) but the  
> compatibility of the information set between versions.

Actually implementation IS the issue.  If we choose serialization,  
the other projects must agree to implement Serialzable and maintain  
upward compatibility.  If we choose an xml strategy like Sun's  
JavaBeans xml stuff, the other projects must only agree to maintain  
compatibility of public property names (i.e., the getter and setter  
names not the private field names) and constructor arguments.  This  
is much smaller task to ask of other projects, since most are already  
providing IoC compatible services.

> As David Jencks has pointed out elsewhere, we do not need every  
> project to commit to serialization stability everywhere, just in  
> the classes that are being used in GBean attributes. If they do  
> great; if they don't we just don't use those classes as attribute  
> values and handle reconstruction ourselves.

I agree with the statement, but we have only pushed the problem down  
one level.  For example if we have the following bean in geronimo:

public class Person {
   private final String name;
   private final int age;
   private final Car car;
   private final Address address;

   public Person(String name, int age, Car car,  Address address) {
       ....
   }
}

The Person class does not need to be serializable, because Geronimo  
only serializes the class name and attribute values.  The attributes  
themselves must be either serializable of be a service reference in  
geronimo.  This is not a problem for most services written by  
Geronimo but for services from other projects this is a huge issue.  
Many projects do not initialize services with simple data types, but  
instead use complex configuration object that are not serializable  
stable.

In the end we have not solved the problem.  We have only pushed the  
problem down one level from the service to the service attributes.

-dain

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Jeremy Boynes
Dain Sundstrom wrote:

> On May 14, 2005, at 3:56 PM, Jeremy Boynes wrote:
>
>> Dain Sundstrom wrote:
>>
>>> Tim,
>>> As you point out, the problem of serialization is far reaching.    
>>> Basically, we need to get every project included in Geronimo to  buy  
>>> into serialization stability, and to my knowledge there are  no  
>>> projects in Geronimo that today have committed to this.  In  
>>> addition,  Geronimo itself is does not support serialization  
>>> stability, and if  we choose this path, we must clean up our own  
>>> house by verifying  every serializable class is set up for upward  
>>> compatible  serialization.  This is by no means an easy task, but  I
>>> think before  we ask something of other project we are aware of  the
>>> effort involved  in what we are asking.
>>> Alternatively, we could choose to do like Sun did with swing and  
>>> give  up on serialization and use an xml based storage mechanism  
>>> based on  Java Beans rules.
>>>
>>
>> The issue is not the implementation (serialization vs. XML) but the  
>> compatibility of the information set between versions.
>
>
> Actually implementation IS the issue.  If we choose serialization,  the
> other projects must agree to implement Serialzable and maintain  upward
> compatibility.  If we choose an xml strategy like Sun's  JavaBeans xml
> stuff, the other projects must only agree to maintain  compatibility of
> public property names (i.e., the getter and setter  names not the
> private field names) and constructor arguments.  This  is much smaller
> task to ask of other projects, since most are already  providing IoC
> compatible services.
>

Surely if a project is not prepared to maintain compatibility for
Serializable objects it is not going to maintain property compatibility
either. In fact, given the flexibility of the JavaBean model (well not
strictly as JavaBeans are meant to be Serializable) and the lack of any
indication of persistence (e.g. that it does not implement a tag
interface or have a marking annotation) I would argue that property
drift was more likely as there would not be anything to indicate to a
developer that compatibility would be required.

>> As David Jencks has pointed out elsewhere, we do not need every  
>> project to commit to serialization stability everywhere, just in  the
>> classes that are being used in GBean attributes. If they do  great; if
>> they don't we just don't use those classes as attribute  values and
>> handle reconstruction ourselves.
>
>
> I agree with the statement, but we have only pushed the problem down  
> one level.  

Indeed, but pushing it down that level is critical as it lets the GBean
implementation handle the reconstruction of the underlying object graph.

Most simple attributes have Serializable values. No problem.

Any project that tags its classes as Serializable ought to handle the
version drift. If it indeed does so, no problem. If it does not, then we
simply treat the values as if they were non-Serializable.

If the values are non-Serializable then the project needs to define how
the objects can be persisted; hopefully that includes a way to handle
version drift. The GBean can use that mechanism to convert the
non-Serializable object graph to/from its persistent form stored in a
Serializable object such as a byte[] or char[]


Let's be clear, there are several issues here:
1) persistent form. Serialization provides a very low-overhead, high-
    performance solution and can be used to underpin higher level
    abstractions.

2) object version skew. Again Serialization provides clearly documented
    ways to handle that.

3) adoption. Serialization is easy to implement especially for mature
    objects with little version skew. XML JavaBean persistence is not
    widely used as the external XML format is not designed for human
    modification. XML in conjuction with a persistence schema is more
    widely used but carries high overhead especially when schema
    validation is used.

4) configuration version skew. This is handled by the configuration
    management system as discussed elsewhere.

The current model provides a very effective, high-performance,
low-overhead configuration persistence mechanism that can be extended
with higher level mechanisms where appropriate.

--
Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: API and serialization compatibility, was: Build Failure

Jeremy Boynes
In reply to this post by Tim Ellison-2
Tim Ellison wrote:

> Jeremy Boynes <[hidden email]> wrote on 14-05-2005 17:47:31:
>
>><lots of good stuff snipped />
>>
>>Another thing to remember is that the only classes where serialization
>>compatibility really matters are those that are actually placed in
>>persistent attributes. I would hope all the projects we use do support
>>serialization properly, including providing UIDs and dealing with
>>version drift; if not we should encourage them to do so and help where
>>necessary - it is generally a /good thing/. That will make configuration
>
>
>>management easier for both system administrators as well as the runtime
>>and deployment systems.
>
>
> Glad you agree ;-)
>    http://issues.apache.org/jira/browse/GERONIMO-644
>

Sure do :-)

I assigned this to me as a place holder - if you can provide patches
that add the SUIDs I will make sure they get applied (at least in
Geronimo and other projects where I can).

--
Jeremy

12