Dan, I like having you around, your a good detective, always picking up
on important details.
Yes, this could mean that an object (and all other serializable fields
it contains) may have an equal serialized form, but be unequal in object
form after unmarshalling.
Object unmarshalled equality would be determined by the implementor of
CodebaseAccessClassLoader. We need to provide a default implementation,
with similar behaviour to PreferredClassProvider.
The question is of course, what to do in the case of version conflicts?
1. Use an already downloaded earlier version (with identical codebase
annotations when present)?
2. Ask the local environment to decide if it wants to use the latest
codebase, or try using the local codebase instead? (after
checking the serial version UID is compatible). This allows the
client to force object equality if it's required. This couldn't
be set in a modular environment, in that case the client would
have to live with inequality.
3. Another option might be to use reflective proxy's to refer to
smart proxy instances and keep a weak register of smart proxy's
and their version information and codebase annotations (a @proxy
annotation might be required to help us identify the smart proxy),
and persist all smart proxy's that share the codebase to disk and
reload them with the new codebase version, again allowing the
client to decide if object equality should be enforced, as this
wouldn't be free, the update operation would have to block. We'd
also have to make sure the local reflective proxy was replaced by
the smart proxy in any object streams. Only after all local smart
proxy's are updated is is possible to check for boomerangs. If
object equality is not enforced, then the newer version would be
loaded into a different ClassLoader and not be equal, this
includes boomerangs.
4. A class might not belong to a proxy, other classes are transmitted
in the object tree, these may be platform classes or
implementation classes. So we need a way for the client
environment to resolve a class if we can't work it out. For
example maven codebase provisioning or OSGi etc. This is where it
might be useful to provide a CodebaseAccessClassLoader
implementation with a method the client can override, to resolve
classes our implementation can't, after we first attempt to but
can't find the right class, since most clients don't want to
reinvent the wheel, they can accept the default behaviour and
override it for corner cases.
This doesn't look as hard to solve as it used to.
I think I'm leaning towards 3 and 4, although this would cause some
backward compatibility issues, developers would have to recompile with
@proxy annotations. Remember the smart proxy's public API will likely
not implement Remote, unless someone's got a better idea?
So the client can fully implement CodebaseAccessClassLoader if they so
desire, or they can use a default implementation that does most of the
leg work and only asks for help when it gets stuck, reducing the
implementation burden. If a developer is in charge of both the service
and the clients, then they can develop their own object stream
properties they can utilise in this situation. I think if our
implementation detects stream properties it doesn't understand, then it
should probably delegate first to the protected method overridable by
the user developer before attempting to resolve the class itself.
Cheers,
Peter.
On 23/08/2012 6:43 PM, Dan Creswell wrote:
I haven't thought about this in any depth at all so I'm unsure whether this
matters but:
JavaSpace implementations have, obviously, an equality rule for the fields
in the Entry's they handle. The basics of this are that content is compared
whilst codebase annotations etc are excluded.
The act of splitting out the annotations and so on is trivial but dependent
upon a good understanding of codebases, serialization etc.
And I would expect that changes such as the below will impact both space
matching and (de)serializing of Entry's given the above.
We'd best account for the impact there in this design effort?
On 23 August 2012 08:46, Peter Firmstone<[email protected]> wrote:
Yes, however the ObjectStream used, also annotates other information, like
superclasses and version metadata to ensure the correct ClassLoader is
selected locally.
Object Streams are not easily changed, MarshalOutputStream annotates a
codebase string, however this could be much more flexible, if we could
annotate a second string that contained key value pairs separated by pipe
symbols.
This would allow any future changes to be easily accommodated, such as
version information and superclasses, this is similar to system properties.
CodebaseAccessClassLoader could be passed a Map<String,String> that
contains additional information. Then we can standardise certain
properties that can be defined along with codebase annotations. This will
assist to accommodate future modular environments.
We need to increment the stream version, then continue to use the old
stream for now, however when the time comes, the existing releases will be
compatible with the new stream version, so we could see a few releases
before we need the ability to use it.
So a MarshalOutputStream would utilise the old stream version by default
for a few releases, while MarshalInputStream is capable of reading both
stream versions. Then at some time in the future, we set
MarshalOutputStream to use the new stream version by default and users have
to set a property if they want MarshalOutputStream to revert back to the
existing protocol.
Obviously the stream properties will have to be standardised over time,
but it will enable us to do so without again needing to revise the stream
protocol, then CodebaseAccessClassLoader doesn't need to change again
either.
Regards,
Peter.
On 23/08/2012 1:17 AM, GREGG WONDERLY wrote:
So a quick look at this, tells me that the JBoss resolver is position
with the duties that the CodebaseClassAccess interface is at. It allows
the resolution of classes to be resolved to a class loader which is
appropriate for the application environment.
Gregg
On Aug 22, 2012, at 7:36 AM, Peter Firmstone<[email protected]> wrote:
This is relevant to OSGi and jboss as well as Jigsaw, now delayed to
Java 9.
https://community.jboss.org/**wiki/ModularSerialization<https://community.jboss.org/wiki/ModularSerialization>
I strongly suggest anyone interested in River read this.
Regards,
Peter.
