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
One easy option may be to write a simple client using your old code to
serialize the entries in the space to XML on disk. Then launch your new
application and put entries into the space instance.
On Mon, Feb 4, 2013 at 3:34 AM, Dawid Loubser da...@travellinck.com wrote:
Thanks for the quick
Thanks Gerard,
That does sound reasonable, but wouldn't I effectively lose the unique
individual codebase annotations of each entry? I have various unrelated
services that interact in often-complex ways. Consider the following:
* In foo-api, I have an entry called FooEvent
* In my space-based
On 4 February 2013 17:32, Dawid Loubser da...@travellinck.com wrote:
Thanks Gerard,
That does sound reasonable, but wouldn't I effectively lose the unique
individual codebase annotations of each entry? I have various unrelated
services that interact in often-complex ways. Consider the
Out of curiousity, how frequently do people use JavaSpaces as a
long-term persistence mechanism? Obviously, it's one of the
possibilities envisioned by the JavaSpace spec, but most examples I've
seen (and certainly the ones I've implemented) have JavaSpaces as more
of short-term communications
Hi Greg, One of the major players providing space backed persistence is
Gigaspaces. The whole company is now modeled around concept of java spaces.
One of the big pushes for Gigaspaces is the concept of a space based
in-memory distributed data grid. Their architecture makes the space the
primary
I'm actually not sure if Dawid has to actually do anything here. The entries
have been written into the space and have as their annotation a URL that has
been provided by the entries defining classloader. In this case the entry is
annotated using Rio's artifact URL scheme.
If the change(s) are
See https://builds.apache.org/job/river-qa-refactor-arm/8/
--
[...truncated 8418 lines...]
[java] Test Passed: OK
[java]
[java] -
[java]