Thanks for the quick response, Dan! I want to understand the classloading a bit better. Let me explain to you how I *think* it works. Also, for reference, I'm using the rio project, that has a special classloader that understands URLs in the form "artifact:foo:bar:1.0" and which loads classes from Maven artifacts, but I think it's conceptually the same as any other URL scheme etc.
* When an Entry it written to space, it's turned into a MarshalledInstance. This is annotated with the codebase (a collection of URLs). Immediate question: Is there only one codebase at the top-level of the entry, or does every object in the graph have (or can have) its own codebase? * When a worker takes/reads an entry (which might contain things that both are on the worker's classpath, and perhaps lower-level content that is not (i.e. specialisations that it does not have to understand), how does the space proxy know what to do? I imagine it uses the thread context class loader, but then how does it deserialise the objects that is not on that classpath (using the codebase annotation of the MarshalledInstance, I imagine) whilst not colliding with the classes already available to the worker? Using some sort of parent/child delegation? I've got a very tricky ClassCastException problem I'm trying to debug, where it's clearly the same class loaded by two classloaders, and thus the field cannot be assigned. I don't know how to get "in there" and solve the problem, it seems I can only respond to the UnusableEntryException, get the partial entry, and lose the rest? thanks so much, Dawid On Mon, 2013-02-04 at 11:17 +0000, Dan Creswell wrote: > On 4 February 2013 11:10, Dawid Loubser <[email protected]> wrote: > > Hi all, > > > > I have a bunch of entries in a JavaSpace (representing long-running > > process state, i.e. they exist for days or weeks), and these contain > > some objects that were generated from XML (using JAXB). That vocabulary > > has evolved (additions only) but now, of course, the computed > > SerialVersionUIDs will be different. When I redeploy my workers that > > have been built against the new API, they will surely fail when reading > > the old entries. > > > > Any strategies as to how I can migrate the data in the space? I'm > > running a persistent outrigger (snaplogstore). I was thinking of, in a > > worker with an 'old' classpath, draining the space, and storing those > > entries in some non-java representation on disk, and then in a worker > > with the 'new' classpath, reading those entries and re-populating the > > space. > > Slightly more complicated but it's possible to have one worker do all > this with some classloader magic. You basically load old and new > definitions into separate classloaders with the old version being > directly on the classpath, the other dynamically loaded from something > not on the classpath. > > Then you can take the old easily and use reflection magic to populate > a new and write it. > > One other challenge is that most JavaSpace implementations don't like > mixed schemas do probably you're better to create a second space, > write the migrated ones into that and then turn off the old one (or > copy back to the old once you've cleared it down/re-built it). > > > > > Migrating data in a space is surely something that must have caused > > problems for somebody before, and I'd love to tackle this problem > > drawing on some experience of others. > > > > regards, > > Dawid > >
