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. >>> >>> >
